MS Switch Access Policies (802.1X) - Cisco Meraki Documentation

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

Summary

Cisco Meraki MS switches offer the ability to configure access policies, which require connecting devices to authenticate against a RADIUS server before they are granted network access. These access policies are typically applied to ports on access-layer switches to prevent unauthorized devices from connecting to the network.

This article outlines options available for access policies, how to configure access policies in the Meraki dashboard, and the configuration requirements for RADIUS servers.

Organization-wide RADIUS servers

The Org-Wide RADIUS servers feature provides the ability to define one or many RADIUS servers once and then re-use the configuration across the organization for access policies. Refer to the Organization Settings document for more information on how to define and use RADIUS server configurations at the organization level.

Configuration

After Org-Wide RADIUS Servers are configured at the organization level, navigate to the target access policy under Switching > Configure > Access policies

Scroll to Radius Servers, and then in the box that says 'Select RADIUS', check the box beside the desired RADIUS server and save the changes

Closed Mode (Default)

This is the high-security option. In Closed mode, only authorized devices (supplicants) based on policies on RADIUS server are granted network access. All unauthorized devices are denied access.

Open Mode

In this mode, all devices are granted network access regardless of their authentication status. However, authentication attempts are still processed by the RADIUS server, providing visibility into what policy would have been enforced if Closed mode were enabled. This allows organizations to monitor authentication results and prepare for a secure transition to Closed mode.

In comparison, Open mode is similar to Monitor mode and Low-impact mode on ISE:

When a permit all pre-authentication ACL is applied, Open mode functions like Monitor Mode, where all traffic is allowed.

When a granular pre-authentication ACL allowing only specific traffic is applied, Open mode behaves like Low Impact Mode, providing limited access to essential services (as defined by the ACL) until authentication is complete.

While Closed mode is recommended as the goal for strong network security, Cisco recommends organizations to implement Authentication Modes in phases - starting with Open mode and gradually moving to Closed mode. This phased approach helps minimize disruptions and unexpected connectivity issues that may arise during 802.1X (Dot1x) deployment.

Group Policy ACLs (GPACLs): Pre Auth, Critical Auth, Failed Auth & Guest

Pre-authentication GPACL

This defines what network access is allowed for a device before the authentication process is complete. It is recommended to begin with GPACL that permits any IP traffic (similar to Monitor mode on ISE), transitioning to permitting only network services such as DHCP, DNS etc. (similar to low-impact mode on ISE).

Critical Auth GPACL and SGT

Critical Authentication Group Policy ACL (Critical Auth GPACL) defines what network access is permitted for a device when the authentication server is unreachable or there is a communication failure during the authentication process.
By configuring a Critical-authentication GPACL, you can ensure that devices maintain access to essential business-critical resources - such as DHCP, DNS, or specific application servers, while still restricting access to the broader network during authentication outages.
Similarly, distinct Security Group Tags (SGTs) can be applied to data and voice traffic in a critical-authentication scenario to ensure appropriate access controls for each traffic type.

Failed Auth GPACL and SGT

Failed Authentication Group Policy ACL (Failed Auth GPACL) and Failed Authentication Security Group Tag (Failed Auth SGT) defines what network access is permitted for a device that fails the authentication process. By configuring a Failed-authentication GPACL or SGT, you can control and restrict the network resources accessible to devices that do not successfully authenticate, such as limiting access to remediation servers or helpdesk portals while blocking access to sensitive internal resources.

Guest GPACL

Guest Group Policy ACL (Guest GPACL) defines what network access is permitted for unauthorized devices. By configuring a Guest GPACL, you can ensure that these devices have access only to limited network resources, such as internet access, while restricting access to internal business systems and sensitive data.

Host Modes

Support for all host modes is available from firmware version MS 10.12.

There are four authentication host modes to choose from:

Single-Host (Default)

With single-host authentication, a connected device will attempt authentication and if it fails to authenticate, the client will be denied access. This mode is recommended for switch ports with only one client attached. If multiple devices are connected to the same switch port (for example a device connected via a hub or daisy-chained off of a VoIP phone), only one client will be allowed network access upon successful authentication. All subsequent authentication requests from other clients will be ignored and they will not be granted access as a result.

Multi-Domain

With multi-domain authentication, one device can be authenticated on each of the data and voice VLANs. If a second device is detected on one of the VLANs, the device will not be granted access. In this mode, Hybrid Authentication is used and Voice VLAN authentication is required. This mode is recommended for switch ports connected to a phone with a device behind the phone. Authentication is independent on each VLAN and will not affect the forwarding state of each other. To ensure proper authentication, a Voice VLAN must be specified on the switchport. Failure to specify this value will result in client devices being unable to pass traffic properly after authentication.
Cisco Meraki switches require the following attribute pairs within the Access-Accept frame to put devices on the voice VLAN:

Cisco- AVPair
device-traffic-class=voice

Multi-Auth

With multi-auth, each connected device is required to authenticate. Multiple devices may be connected to each port. After a VLAN is assigned to a host on the port, subsequent hosts must have matching VLAN information or be denied access to the port. Only one client is supported on the voice VLAN. Guest VLANs are not supported in this mode.
Cisco Meraki switches require the following attribute pairs within the Access-Accept frame to put devices on the voice VLAN:

Cisco- AVPair
device-traffic-class=voice

The MS390 and C9300-M support multi-VLAN assignment when using multi-auth as the host mode. This allows for multiple data domain sessions behind the same switch port to have different VLAN IDs assigned without blocking access.
Multi-VLAN assignment combined with a multi-auth host mode policy is currently only supported on the MS390 and C9300-M switches.

Multi-Host

With multi-host, a single successful authentication will put the port into a forwarding state. All subsequent authentication attempts are ignored. This is recommended in deployments where the authenticated device acts as a point of access to the network, for example, hubs and access points.

VLAN Profiles feature simplifies VLAN management across multiple sites by enabling dynamic assignment of VLANs based on descriptive names rather than numerical IDs. This facilitates easier management across multiple sites with varying VLAN configuration reducing the need for multiple RADIUS policies. Click here for additional information.

RADIUS Caching for MS390 and C9300-M

RADIUS caching allows for endpoints connecting to the switch to authenticate against a RADIUS server, and for the switch to cache the authorization result for that session. If the connection to the RADIUS server is severed, the switch will use the cached entry to reauthorize the endpoint. The switch will cache the authorization result for a default of 24 hours. This is user-configurable in the access policy.

Configuration instructions:

Navigate to Switching>Access Policies then select your access policy

Navigate to RADIUS caching enabled and change status to enabled

(Optional) Navigate to RADIUS cache timeout and enter new value in hours

Default is 24hrs or One Day

Max Value is 720hrs

For 802.1X sessions, a cached authorization will not send an EAPOL-Success message to the endpoint, but will re-authorize the session with the cached result. For windows machines, be sure to enable fallback to unauthorized access in the supplicant configuration for RADIUS Caching to work properly with windows machines.

Access Policy Types

There are three options available for an access policy in Dashboard:

802.1X (Default)

When an 802.1X access policy is enabled on a switch port , a client that connects to that switch port will be prompted to provide their domain credentials. If the RADIUS server accepts these credentials as valid, their device will be granted access to the network and get an IP configuration. If no authentication is attempted, they will be put on a "guest" VLAN, if one is defined .
802.1X access policies are commonly used in enterprise environments, since they can authenticate against the existing domain userbase .

MAC Authentication Bypass ( MAB )

When a MAB access policy is enabled on a switch port , the client's MAC address is authenticated against a RADIUS server without needing to prompt the user. If the server accepts the MAC as valid credentials for the network, the device will be allowed access.
MAB access policies are useful for a more seamless user experience, restricting the network to specific devices without needing to prompt the user.

Hybrid Authentication

When a hybrid access policy is enabled on a switch port , the client will first be prompted to provide their domain credentials for 802.1X authentication . If 802.1X authentication fails, or if the switch does not receive any EAP packets within 8 seconds to begin 802.1X authentication, then the client's MAC address will be authenticated via MAB. If both methods of authentication fail, the device will be put on a "guest" VLAN, if one is defined .
Hybrid authentication is helpful in environments where not every device supports 802.1X authentication since MAB exists as a failover mechanism. This is an image showing an MS 802.1X authentication flow chart, from start to finish.

This is an image showing an MS 802.1X authentication flow chart, from start to finish.

Concurrent Authentication

When a policy is set to concurrent authentication (AKA Increase Access Speed), the 802.1X and MAB access-request will be send in parallel, which can allow for MAB devices with no supplicant to gain access to the network without waiting for the 802.1X process to time-out. The 802.1X response for the same device will always override the MAB result received. For devices with a supplicant, it is advised to either configure the supplicant, or disable the supplicant to use MAB when the MAB result is the desired authentication mechanism.

Cisco Identity Services Engine does not officially support concurrent authentication behaviors and can cause outcomes that are not desirable including higher Policy Services Node and Monitoring node load, as well as potentially undesirable authentication/authorization behaviors.

Change of Authorization (CoA)

Meraki MS and Catalyst 9300-M switches support CoA for RADIUS reauthentication and disconnection as well as port bouncing. For more information, see the following KB article .

URL Redirect Walled Garden (Supported on MS210/225/250/350/355/390/410/420/425 and C9300-M)

By default, URL redirect is enabled with CoA. This can be used to redirect clients to a webpage for authentication. Before authentication, http traffic is allowed but the switch redirects it to the redirect-url. The walled garden can be used to limit access to the web server only. This feature will only be enabled if one or more supported switches are in the network. Configurations on this feature will be ignored by unsupported switches.

For URL redirect on the MS390 and C9300-Ms, there needs to be a walled-garden ACL name sent with the access-accept message from the RADIUS server. The first access-policy in the list will require an ACL name of Walled-Garden-00 and each subsequent access-policy will increment by 1. For example, Access Policy 2 will be Walled-Garden-01. The Walled Garden ACL on the MS390 and C9300-Ms will allow DHCP, DNS, and IP access to the walled garden IP addresses.

UDP/1700 is the default port used by all MS for CoA.

MS390s and C9300-Ms support RADIUS URL-Redirect as of MS 15.

Other RADIUS Features

RADIUS Accounting

RADIUS Accounting can be enabled to send start, interim-update (default interval of 20 minutes) and stop messages to a configured RADIUS accounting server for tracking connected clients. Meraki’s implementation follows the IETF’s RFC 2869 standard.
As of MS 10.19, device sensor functionality for enhanced device profiling has been added by including CDP/LLDP information the RADIUS Accounting message (MS120/125/130/130R/150/220/225/250/320/350/355/410/425/450). As of 14.19+ the MS390 and C9300-Ms also supports device sensor with enhanced attributes across LLDP, CDP, mDNS, and DHCP for profiling.

RADIUS Testing

Meraki switches will periodically send Access-Request messages to these RADIUS servers using identity 'meraki_8021x_test' to ensure that the RADIUS servers are reachable. If unreachable, the switch would transition into an alerting status to indicate a failure. A server is marked as unavailable at definition of an access policy or if a radius test fails or if a client authentication to that server fails on the switch

RADIUS test messages are sent every 24 hours. If a RADIUS test fails for a given node it will be tested again every 60 seconds until a passing result occurs. A subsequent pass will mark the server reachable and clear the alert, returning to the 24 hour testing cycle.

RADIUS Monitoring

In addition to the mechanism in RADIUS Testing, if all RADIUS servers are unreachable, clients attempting to authenticate will be put on the Guest or Critical Auth VLAN depending on which is defined. When the connectivity to the server is regained, the switch port will be cycled to initiate authentication. Contact Meraki Support to enable this feature.

RADIUS Testing should be enabled for RADIUS Monitoring to work.
This feature must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

It may be necessary to perform dynamic VLAN assignment on a per-computer or per-user basis. MS switches can accomplish this through the use of RADIUS authentication, allowing the local port VLAN to be overridden with one that's defined by a RADIUS server.
In order for clients to be dynamically assigned to a given VLAN, the following RADIUS attributes must be configured and passed in the RADIUS Access-Accept message from the RADIUS server:

Tunnel-Medium-Type: Choose 802 (Includes all 802 media plus Ethernet canonical format) for the Attribute value Commonly used for 802.1X.

Tunnel-Private-Group-ID: Choose String and enter the VLAN desired (ex. "500") . This string will specify the VLAN ID 500 .

Tunnel-Type: Choose Attribute value Commonly used for 802.1X and select Virtual LANs (VLANs)

For more information on how to configure these values with NPS, visit Microsoft's article on Configuring a Network Policy for VLANs .

Support for Dynamic VLAN Assignment for the Voice VLAN / domain was introduced in firmware version MS 15.
An additional attribute, device-traffic-class=voice , must also be received within the Access-Accept message for Voice VLAN assignment to occur.

When using 802.1X authentication or MAC Authentication Bypass (MAB) , it is a best practice to configure the port VLAN (PVID) and the voice VLAN with different VLAN IDs. This helps ensure proper traffic isolation, prevents conflicts, and maintains QoS for voice traffic

802.1X Control Direction (Wake-on-LAN support)
802.1X Control Direction is set by default to "both" directions. In this mode, the switch port doesn't allow ingress or egress traffic through the switch port until after the port is authorized via 802.1X or MAB authentication. Control Direction can also be set to "inbound-only", in which case the switch port doesn't allow ingress traffic, but will allow limited egress traffic from the network through the switch port to reach the connected device. This is often used to allow Wake-on-LAN magic packets to wake a sleeping host on the connected port, at which point the host can attempt a normal 802.1X or MAB authentication to authorize the switch port for full ingress and egress traffic.

Guest VLAN
Guest VLANs can be used to allow unauthorized devices access to limited network resources. This is not supported on the voice VLAN/domain.

RADIUS Monitoring must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

Failed Authentication VLAN
A client device connecting to a switch port controlled by an access policy can be placed in the failed authentication VLAN if the RADIUS server denies its access request.

Client devices may fail RADIUS authentication because they do not comply with the network's security requirements. The failed authentication VLAN provides such clients with limited access to the network for remediation purposes.

Failed Authentication VLAN is only supported in the Single Host, Multi Host and Multi Domain modes. Access policies using Multi Auth mode are not supported on MS Classic Switches, only Cloud Managed Catalyst .

Re-authentication Interval
When the Re-authentication Interval (time in seconds) is specified, the switch will periodically attempt authentication for clients connected to switch ports with access policies. Apart from providing for a better security policy by periodically validating client authentication in a network, the re-authentication timer also enables the recovery of clients placed in the Failed Authentication VLAN because of incomplete provisioning of credentials.
Re-authentication will not occur if no re-authentication interval has been configured, or if a reauthentication-interval has been configured but the switch has lost connectivity to all of the RADIUS servers listed under the access policy.

Suspend Re-authentication when RADIUS servers are unreachable
Periodic re-authentication of clients can be an issue when RADIUS servers are unreachable. The Suspend Re-authentication when RADIUS servers are unreachable allows users to choose whether the re-authentication should occur or not when none of the RADIUS servers are reachable. By default, re-authetication gets suspended when RADIUS servers are not reachable.

'Suspend re-authentication when RADIUS servers are unreachable,' is not a configurable option on the MS390 and C9300-M series switches . An MS390 and C9300-M switch will automatically ignore this configuration, and will always suspend client re-authentication, if it loses connectivity with the RADIUS server.

Critical Auth entication VLAN
The critical authentication VLAN can be used to provide network connectivity to client devices connecting on switch ports controlled by an access policy when all of the RADIUS servers for that policy are unreachable or fail to respond to the authentication request on time. The critical data and critical voice VLANs should not be the same.
When the RADIUS servers are not reachable from the switch, authentication requests for clients attempting to connect to the network will fail, resulting in clients being denied access. Critical authentication VLAN ensures that these clients are still able to access the business-critical resources by placing them in a separate VLAN. This also allows network administrators to better control the network access available to clients when their identities cannot be established using RADIUS.

Configuring Critical Authentication VLAN or Failed Authentication VLAN under an access policy may affect its existing Guest VLAN behavior. Consult the Interoperability and backward compatibility section of this document for details.

An "802.1X Canned EAP Success" event will be triggered if the authentication process places a client's VLAN on the critical, guest, or failed authentication VLAN. This alert is different from the "802.1X EAP Success" event where authentication is successful and planned connectivity is provided.

Critical Authentication VLAN is only supported in the Single Host, Multi Host, Multi Domain, and Multi Auth modes for Cloud Manager Catalyst switches running CS17 and higher.

Critical Authentication VLAN is only supported in Single Host, Mult Host and Multi Domain on MS Classic Switches.

Critical Authentication VLAN is not currently supported in Multi Auth modes on MS Classic Switches.

Suspend port bounce
When connectivity between the switch and any of the RADIUS servers is restored, the switch will attempt to authenticate the clients which it had placed in the Critical Authentication VLAN. The switch does this by bouncing (turning off and on) the switch ports on which these clients are connected. If required, this port-bounce action can be disabled by enabling the Suspend port bounce option. When port-bounce is suspended, the clients will be retained in the Critical Authentication VLAN until a re-authentication for these clients is manually triggered.

If Critical and/or Failed Authentication VLANs are specified in an Access Policy, the Guest VLAN functionality gets modified to ensure backward-compatibility and inter-op between the configured VLANs. Refer to the Interoperability and backward-compatibility table below for more details on this.

The following matrix shows the remediation VLAN, if any, that client devices would be placed in for the different combinations of the remediation VLAN configuration options and the RADIUS authentication result.

¹ When using hybrid authentication without concurrent authentication enabled, a client failing both 802.1X and MAB authentication will also be placed in the Guest VLAN. Refer to the Access Policy Types section of the MS Switch Access Policies documentation for details.

MS 14 is the minimum firmware version required for the following configuration options.

Failed Authentication VLAN

Re-authentication Interval

Suspend Re-authentication when RADIUS servers are unreachable

Critical Authentication VLANs

Suspend port bounce

RADIUS Attributes

When an access policy is configured with a RADIUS server, authentication is performed using PAP. The following attributes are present in the Access-Request messages sent from MS switch to the RADIUS server.

User-Name

NAS-IP-Address

Calling-Station-Id: Contains the MAC address of the end user machine (supplicant) (all caps, octets separated by hyphens, example: "AA-BB-CC-DD-EE-FF").

Called-Station-Id: Contains the MAC address of the Meraki MS switch (all caps, octets separated by hyphens).

Note: MS390 and C9300-M has an exception, it will send MACID of the switch port in the Called-Station-Id AVP.

Framed-MTU

NAS-Port-Type

EAP-Message

Message-Authenticator

Refer to RFC 2865 and RFC 3579 for details on these attributes, additional notes for certain attributes are included below.

Creating an Access Policy on Dashboard

Creating an Access Policy Using a Custom Radius Server

On the dashboard navigate to Switching > Configure > Access policies.

Click on the link Add an access policy in the main window then click the link to Add a server.

Enter the IP address of the RADIUS server, the port (default is 1812), and the secret created earlier.

Select the required options, as described above.

Click Save changes.

On the dashboard navigate to Switching > Configure > Access policies.

Click on the link Add an access policy in the main window then click the link to Add a server.

Under Authentication method select Meraki Authentication.

Select a Guest VLAN and whether to allow System Manager enrollment.

Click Save changes.

Navigate to Switching > Monitor > Switch ports.

Select the switch port(s) you would like to apply the access policy to and press the Edit button.

Convert the switch port type from trunk to access . Note: you can only apply an Access Policy to an access port.

From the Access Policy drop-down box, select the Access Policy you created and press the Update ports button.

Unmanaged Switches Between MS and Client for RADIUS Authentication

When using PEAP EAP-MSCHAPv2 on an MS switch port, if an unmanaged switch is between the end user machine (supplicant) and the RADIUS client (MS) the authentication will fail. The reasoning is explained below:

The destination of the eapol (RADIUS exchange) frame is a special multicast address that 802.1D-compliant bridges do not forward.

This destination is labeled as "nearest" in Wireshark which means that the frame should only be forwarded to the next layer 2 device.

If the unmanaged switch is added into the topology between the client and the MS, the next layer 2 device is the unmanaged switch and because the multi-cast nearest address is not meant to traverse multiple switches, the unmanaged switch drops the packets. This prevents the client from being authorized.

There is a work-around to this but special considerations must be taken before implementing them:

This is not due to a fault in the MS but is the way that eapol is designed.

It is possible to circumvent this by using MAC based RADIUS authentication . If one machine authenticates via MAC based RADIUS through the MS on an unmanaged switch, the machine that has authenticated will be granted access. It is a workaround but it is less secure and requires more configuration on the NPS and DC.