I’ve battled with Cisco Mobility Express for over three months attempting to make it work with FreeRADIUS with an enterprise 802.1x configuration with dynamic VLANs. My configuration of FreeRadius worked with the Cisco WAP371 small business access points seamlessly so I could not understand why it would not work with Cisco Mobility Express (CME) on a Cisco Aironet 1852i (AIR-AP1852I-Z-K9).
I figured out the issue but running Windows 2003 (yes that old) with Internet Authentication Service (IAS) configured with RADIUS and this worked seamlessly. By comparing dot1x debug outputs on the controller between Windows 2003 and FreeRADIUS, I was able to determine the root cause of the issue (more on that later).
As this article became a lot longer than I expected, I have split this into parts to ease reading.
Part 1 – Understanding the issue with CME and FreeRADIUS.
Part 2 – Configuring FreeRADIUS.
Part 3 – Configuring CME.
Part 4 – Migrating to a FreeRADIUS Web GUI (DaloRadius) for easier management.
Lab Kit and Configuration List
I am working with the following software and equipment:
- Two (2) x Cisco Aironet 1850i (AIR-AP1852I-Z-K9)
- Cisco Catalyst 3560-C running IOS 15.2(2)E10 configured with 5 VLANs in addition to the default VLAN.
- Ubuntu 23.10 (Mantic)
- FreeRadius 3.2.3 released on 27 May 2023
Previous Working Configuration
The previous configuration included two Cisco 371 small business WAPs in single point setup mode. The FreeRADIUS configuration did not need much configuration change to work with this hardware in a WPA2 Enterprise with 802.1X authentication configuration.
The configuration partially worked
To make the issue even more challenging, it partially worked with Cisco Mobility Express. 802.1X authentication worked. The user was authenticated but dynamic VLANs were not allocated and the wireless endpoint would always get an IP address on the default VLAN. The same FreeRADIUS configuration worked with dynamic VLANs with the Cisco WAP371 combo.
Debugging the issue with FreeRADIUS
To determine the issue with FreeRADIUS, we can use the debug mode of CME. There was enough information in the debug output and packet captures were not necessary.
To diagnose 802.1X issues, we can use the following command on the CLI of CME:
debug dot1x all enableIf CME is already receiving a volume of dot1x requests, then it may be difficult to find the debug output that relates to the FreeRADIUS configuration issue.
Examining the Debug Output
The best way to examine the debug output is copying the information to a text editor. Search the debug output for ‘processing avps‘ or ‘VLAN ID‘. AVPs are RADIUS attribute value pairs and these will contain the VLAN ID.
The key AVP required is attribute 81 (Tunnel-Private-Group-ID) which provides the VLAN number – this is shown in avps[3]. Attribute 64 (Tunnel-Type) and 65 (Tunnel-Medium-Type) are also required for this to work. More information on RADIUS AVPs and the attribute numbers are available at the IANA website.
Below is the debug output showing successful processing of dynamic VLANs. The debug prefix including date and MAC address have been removed for brevity.
(Cisco Controller) >debug dot1x all enable
<snip of output>
[BE-req] Sending auth request to 'RADIUS' (proto 0x140001), for RealmName nick (dot1xName :nick)
[BE-resp] AAA response 'Success'
[BE-resp] Returning AAA response
AAA Message 'Success' received for mobile b2:c1:bf:ff:ff:ff
Processing Access-Accept for mobile b2:c1:bf:ff:ff:ff
processing avps[1]: attribute 64, vendorId 0, valueLen 4
processing avps[2]: attribute 65, vendorId 0, valueLen 4
processing avps[3]: attribute 81, vendorId 0, valueLen 3
processing avps[4]: attribute 17, vendorId 311, valueLen 32
processing avps[5]: attribute 16, vendorId 311, valueLen 32
processing avps[6]: attribute 79, vendorId 0, valueLen 4
Received EAP Attribute (code=3, length=4,id=10) for mobile b2:c1:bf:ff:ff:ff
processing avps[7]: attribute 80, vendorId 0, valueLen 16
processing avps[8]: attribute 1, vendorId 0, valueLen 4
processing avps[9]: attribute 12, vendorId 0, valueLen 4
AAA override: Dot1x Authentication PMIP Client AAA Override Enable
AAA override: Dot1x Authentication, default MPC configuration
Tunnel-Group-Id 300 is not a valid VLAN ID for STA b2:c1:bf:ff:ff:ff
Received Session Key from AAA Server for STA b2:c1:bf:ff:ff:ff.
Inserting new RADIUS override into chain for station b2:c1:bf:ff:ff:ff
Comparing this to the debug output when FreeRADIUS is not configured to send the complete set of AVPs that are needed including the VLAN ID. In the debug output below, attributes 64, 65 and 81 are not sent by FreeRADIUS or processed by CME.
(Cisco Controller) >debug dot1x all enable
<snip of output>
[BE-req] Sending auth request to 'RADIUS' (proto 0x140001), for RealmName nick (dot1xName :nick)
[BE-resp] AAA response 'Success'
[BE-resp] Returning AAA response
AAA Message 'Success' received for mobile b2:c1:bf:ff:ff:ff
Processing Access-Accept for mobile b2:c1:bf:ff:ff:ff
processing avps[0]: attribute 17, vendorId 311, valueLen 32
processing avps[1]: attribute 16, vendorId 311, valueLen 32
processing avps[2]: attribute 79, vendorId 0, valueLen 4
processing avps[3]: attribute 80, vendorId 0, valueLen 16
processing avps[4]: attribute 1, vendorId 0, valueLen 4
processing avps[5]: attribute 12, vendorId 0, valueLen 4
AAA override: Dot1x Authentication PMIP Client AAA Override Enable
AAA override: Dot1x Authentication, default MPC configuration
Received Session Key from AAA Server for STA b2:c1:bf:3f:5b:b9.
Inserting new RADIUS override into chain for station b2:c1:bf:ff:ff:ffNow that we understand the requirements of CME, we can progress with configuring FreeRADIUS in part 2.
References and Links
Microsoft – Deploy Password-Based 802.1X Authenticated Wireless Access
Leave a Reply