As a follow-up, I would like to briefly show administrators how to implement the second option, dynamic VLAN assignment. This allows a single SSID to serve multiple user roles tied to separate back-end network VLANs (as long as the same wireless authentication, key management, and encryption ciphers are used).
To prevent client devices from associating to the access point using an unauthorized VLAN, you can assign the user or group to a VLAN on your RADIUS authentication server.
The VLAN-mapping process consists of these steps:
- A client device associates to the access point using any SSID configured on the access point.
- The client begins RADIUS authentication.
- When the client authenticates successfully, the RADIUS server maps the client to a specific VLAN, regardless of the VLAN mapping defined for the SSID the client is using on the access point. If the server does not return any VLAN attribute for the client, the client is assigned to the VLAN specified by the SSID mapped locally on the access point.
The RADIUS attributes to configure for VLAN assignment are IETF RADIUS attributes 64, 65, and 81, which control VLAN assignment of users and groups. See RFC 2868 for more information.
- 64 (Tunnel-Type) should be set to VLAN (Integer = 13)
- 65 (Tunnel-Medium-Type) should be set to 802 (Integer = 6)
- 81 (Tunnel-Private-Group-ID) should be set to the VLAN number. This can also be set to VLAN name if using a Cisco IOS device (excludes Aironet and Wireless Controllers however).
Cisco Autonomous Environment Notes
Unicast and multicast cipher suites advertised in WPA information element (and negotiated during 802.11 association) may potentially mismatch with the cipher suite supported in an explicitly assigned VLAN. If the RADIUS server assigns a new VLAN ID which uses a different cipher suite from the previously negotiated cipher suite, there is no way for the access point and client to switch back to the new cipher suite. Currently, the WPA and CCKM protocols do not allow the cipher suite to be changed after the initial 802.11 cipher negotiation phase. In this scenario, the client device is disassociated from the wireless LAN.
Cisco Unified Environment Notes
The Allow AAA Override option of a WLAN allows you to configure the WLAN for identity networking. It allows you to apply VLAN tagging, QoS, and ACLs to individual clients based on the returned RADIUS attributes from the AAA server.
Cisco wireless LAN controllers also support Airespace vendor specific attributes that can allow an administrator to define a WLC Interface-Name, QoS-Level, or Access Control List (ACL) to be applied to the user or group being authenticated.
Radius attribute 26 (Vendor Specific Attribute) should be used to configure the Airespace values. The Airespace Vendor ID is 14179.
- Aire-Interface-Name (Type 5) should be a string matching the name of the WLC interface to map the user into
- Aire-QoS-Level (Type 2) should be a value (0-3) mapping to the following QoS levels:
- 0 = Bronze (Background)
- 1 = Silver (Best Effort)
- 2 = Gold (Video)
- 3 = Platinum (Voice)
- Aire-ACL-Name (Type 6) should be a string matching the name of the ACL to apply to the user session
Also, ensure that the RADIUS server is using a NAS type of "Cisco-Airespace" when returning Airespace VSAs, otherwise the attributes will not be returned to the controller. If not using Airespace VSAs, a NAS type of "Cisco-Aironet" will work.
Cheers,
Andrew
Does this work with an HREAP environment? If so can you give any specifics?
ReplyDeleteThanks
Hi Rudy,
ReplyDeleteUnfortunately no, AAA Override is currently not supported with H-REAP access points. I have an open feature request with Cisco to address this issue.
Andrew
Hi Andrew,
DeleteDo you have any feedback from Cisco about AAA Override is not supported in H-REAP ap mode ?
tks
Tiago Garcia
Hi Tiago,
DeleteYes, I do have an update. In Cisco's latest release, version 7.2.103.0, AAA Override is now supported with H-REAP mode APs!
See my blog post over at NSAShow.com for details:
Cisco WLC Code Release 7.2.101.0 New Features.
Cheers,
Andrew
Hello
ReplyDeleteDynamic VLANs can be made without using a Cisco RADIUS server, for example TekRadius server (freeware) and without the use of a wireless controller, just do AP by AP.
thanks
Yes, any RADIUS server that can return the correct attributes can perform dynamic VLAN assignment, and most enterprise grade AP and controller solutions will accept and enforce the returned attributes.
ReplyDeleteAll Ruckus APs inherently do HREAP and MESH, and you can exchange AAA attributes via 802.1x and AD/IAS.
ReplyDelete- Ex-Cisco Wireless TAC and Ruckus TSE
Hi Andy
ReplyDeleteHow does it work in case of Guest access scenario, when a user is layer 2 authenticated on a foreign controller and data traffic passes over EOIP tunnel to Anchor controller.
Is the Vlan information received from radius passed in the tunnel to anchor controller ?
regards
Nik
Hi Nik,
ReplyDeleteI have a customer who implemented this as part of a BYOD solution (keeping employee devices in the DMZ).
Even though the layer 2 authentication takes place at the foreign controller, the RADIUS attributes returned are passed down the EoIP tunnel to the anchor controller. This allows the VLAN assignment at the anchor controller, even though the L2 authentication is happening on the foreign WLC.
I must admit that this sounded a bit counter-intuitive to me when I first found out about it, but its certainly works in practice.
Hope this helps.
Nigel.