Back
Lesson 5 of 6

Common 802.1X Failures and Fixes

Objective

In this lesson you will troubleshoot common 802.1X failures seen with EAP-TLS: certificate-related drops, EAP timeout failures caused by fragmented RADIUS packets, and VLAN assignment failures after successful authentication. We will use the WLC SVI MTU feature and AAA/RADIUS mapping to demonstrate practical fixes. This matters in production because certificate exchanges and EAP payloads can be large; if fragments are lost or the RADIUS source interface has an incorrect MTU, clients will see timeouts or get removed before VLAN assignment — causing helpdesk calls and authentication outages.

Topology

ASCII diagram showing the devices and exact IPs used in this lesson:

        +----------------------+                 +------------------+
        |   Wireless LAN Ctrl  |                 |   ISE / RADIUS   |
        |   (9800 WLC)         |                 |   Server         |
        |                      |                 |                  |
        |  SVI Vlan289         |                 |  eth0            |
        |  192.168.189.31/24   |<--- L3 Network --->| 192.168.189.28/24|
        +----------------------+                 +------------------+

        WLAN: Cisco_Live_Dot1x
        Policy VLAN: 282

Device Table

DeviceInterface / ObjectIP Address
9800 WLC (or IOSXE controller)interface Vlan289192.168.189.31/24
ISE (RADIUS)N/A (RADIUS service)192.168.189.28 (auth-port 1812 / acct-port 1813)
WLAN Policywireless profile policyVLAN 282

Tip: All domain names in examples use lab.nhprep.com and passwords use Lab@123.

Quick Recap

This lesson builds on the topology and base configuration from Lesson 1. We assume the RADIUS server IP (192.168.189.28) is the authentication endpoint and that a WLAN named Cisco_Live_Dot1x exists using an AAA list named Cisco_Live_Authe. New or changed objects in this lesson:

  • SVI Vlan289 (192.168.189.31) - used as a source for RADIUS to control MTU/fragmentation.
  • AAA group Cisco_Live_Radius_Group mapped to radius server J_ISE.

Key Concepts (theory + protocol behavior)

  • EAP-TLS: EAP-TLS exchanges certificates between client and server inside EAP over RADIUS. Client and server certificates can be large and require RADIUS to transport multiple fragmented Access-Request or Access-Response packets if the MTU along the path is too small.
    • When a WLC (authenticator) sends an Access-Request that is larger than the path MTU, it gets fragmented at the IP layer. If intermediate devices or configuration prohibit fragmentation (DF set), fragments may be dropped and the EAP state machine will time out.
  • RADIUS MTU and SVI source-interface: Beginning in 17.11 the controller can send RADIUS from a Layer-3 SVI and you can set the SVI IP MTU. Mapping the AAA group to a specific SVI lets you control the MTU used for RADIUS packets, preventing unexpected fragmentation or enabling jumbo frames where tunnels require it.
  • 802.1X EAP timeout behavior: The authenticator expects EAP exchanges to complete within timeout windows. If fragments are lost, the authenticator logs a client EAP timeout failure and will remove the client.
    • Example log reasons: CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE or CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE.
  • VLAN assignment flow: After successful EAP, the authentication server returns attributes (e.g., Tunnel-Private-Group-ID or VLAN assignments). The WLAN policy/profile must map the correct VLAN (e.g., 282) for clients to be placed into the intended data VLAN. Misconfigured policy tags or profile VLANs result in clients authenticated but placed in a wrong VLAN or on the native (management) VLAN.

Think of the SVI like the WLC’s “RADIUS NIC” — you choose which network interface the controller uses to talk to RADIUS, and that interface’s IP MTU governs the maximum RADIUS packet size before fragmentation.

Steps (hands-on)

Each step includes commands, what they do, WHY they matter, and verification output.

Step 1: Ensure RADIUS Server and AAA Group Exist

What we are doing: We will create the RADIUS server entry for the ISE appliance and put it into an AAA group. This is essential so the WLC knows where to send Access-Request and Accounting packets. If these are absent or mis-keyed, EAP will never reach the authentication server and clients time out.

radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123

aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE

aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group

What just happened: The first block registers a RADIUS server object named J_ISE with IP 192.168.189.28 and shared secret Lab@123. The AAA group Cisco_Live_Radius_Group maps that server into a named group, allowing the WLAN to reference the group. The aaa authentication dot1x line tells the controller to use that group for 802.1X authentication decisions.

Real-world note: In production you commonly use server groups so you can load-balance or provide redundancy to multiple ISE nodes without changing WLAN definitions.

Verify:

show running-config | section radius
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group

Step 2: Create SVI and Configure MTU for RADIUS

What we are doing: Create or modify interface Vlan289, set its IP to 192.168.189.31/24 and set a controlled IP MTU. Then map the AAA group to use that SVI as the RADIUS source interface. This gives direct control over the MTU used for RADIUS traffic and prevents fragmentation issues between WLC and the ISE.

interface Vlan289
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 1200
 exit

aaa group server radius Cisco_Live_Radius_Group
 ip radius source-interface Vlan289

What just happened: The interface Vlan289 now uses 192.168.189.31/24 and has an IP MTU of 1200 bytes. By setting ip mtu you limit the size of IP datagrams sourced from that interface — RADIUS packets larger than this will be fragmented at the origin or prevented, depending on DF flags. Mapping the AAA group with ip radius source-interface Vlan289 forces RADIUS packets to originate from that SVI, ensuring the MTU you set is applied to RADIUS flows.

Real-world note: Use a smaller MTU (for example 1200) if intermediate GRE/IPsec tunnels reduce the available MTU. Alternatively, if your network supports jumbo frames end-to-end, you can set a large MTU (see Step 4).

Verify:

show running-config interface Vlan289
Current configuration : 106 bytes
!
interface Vlan289
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 1200
!
end

Step 3: Confirm WLAN and Policy Mapping for VLAN Assignment

What we are doing: Verify the WLAN is tied to the 802.1X authentication list and that the wireless policy profile maps to VLAN 282. Without the policy-to-VLAN mapping, even a successful EAP exchange won’t put the client into the correct data VLAN.

wlan Cisco_Live_Dot1x
 radio policy dot11 24ghz
 radio policy dot11 5ghz
 security dot1x authentication-list Cisco_Live_Authe
 exit

wireless profile policy Cisco_Live_Policy_profile
 description Cisco_Live_Policy_profile
 vlan 282
 no shutdown
 exit

wireless tag policy Cisco_Live_Policytag
 description CL -PolicyTag
 wlan Cisco_Live_Dot1x policy Cisco_Live_Policy_profile
 exit

What just happened: The WLAN named Cisco_Live_Dot1x was associated with the dot1x authentication list Cisco_Live_Authe. The policy profile Cisco_Live_Policy_profile is set to VLAN 282 and attached to the WLAN via the policy tag. When a user authenticates, the controller will place them into VLAN 282 (or honor a VLAN attribute from RADIUS if present).

Real-world note: In production you often map a policy profile to multiple WLANs or change VLANs per role from the authentication server; always verify the policy tag association.

Verify:

show running-config | section wlan
wlan Cisco_Live_Dot1x
 radio policy dot11 24ghz
 radio policy dot11 5ghz
 security dot1x authentication-list Cisco_Live_Authe

show running-config | section wireless
wireless profile policy Cisco_Live_Policy_profile
 description Cisco_Live_Policy_profile
 vlan 282
 no shutdown
wireless tag policy Cisco_Live_Policytag
 description CL -PolicyTag
 wlan Cisco_Live_Dot1x policy Cisco_Live_Policy_profile

Step 4: Adjust SVI MTU for Jumbo Frames (alternative fix for fragmentation)

What we are doing: If the path supports jumbo frames — for example, there are no tunnels that shrink MTU — you can increase the interface MTU so the entire certificate exchange fits without fragmentation. This is the alternative to reducing the MTU; choose the approach that matches your network topology.

interface Vlan289
 mtu 9100
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 9000
 exit

What just happened: The physical (or SVI) MTU is increased to 9100 and the IP MTU to 9000. This allows larger IP datagrams to be sent without fragmentation, which is useful when your network and any tunnels (GRE/IPsec) permit jumbo frames end-to-end. The controller will now source RADIUS packets from Vlan289 with the new MTU.

Real-world note: If any device along the path (firewall, router, or tunnel) cannot handle jumbo frames, increasing the MTU will not help and may make things worse. Always coordinate MTU changes across the path.

Verify:

show running-config interface Vlan289
Current configuration : 152 bytes
!
interface Vlan289
 mtu 9100
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 9000
!
end

Step 5: Observe and Interpret Authentication Failures (logs and symptoms)

What we are doing: Although specific log commands vary by platform, the symptoms of fragment/drop issues usually show as client delete reasons in WLC logs: AAA server unavailable, EAP timeout, or L2 auth connect timeout. We will verify the configuration we changed is present and remind you what to look for in logs.

show running-config | include radius
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
 aaa group server radius Cisco_Live_Radius_Group ip radius source-interface Vlan289

What just happened: You confirmed the RADIUS server, AAA group, and source-interface mapping are present. If EAP timeouts persist after configuration, the WLC logs usually include lines such as CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE or CO_CLIENT_DELETE_REASON_AAA_SERVER_UNAVAILABLE indicating either fragmentation/transport issues or reachability/secret mismatch.

Real-world note: When certificate fragments are dropped you often see EAP-ID Request/Response but never reach "Server Hello Done" phases in packet captures; this indicates mid-exchange loss.

Verify: (Look in your WLC logs for client delete messages; example textual symptom — the precise show log command varies by platform.)

! Example configuration verification (not a log) - presence of mapping
show running-config | section aaa
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
 ip radius source-interface Vlan289
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group

Verification Checklist

  • Check 1: RADIUS server configured and AAA group present.
    • Verify: show running-config | section radius -> should list J_ISE 192.168.189.28 and key Lab@123.
  • Check 2: SVI Vlan289 configured with intended MTU and IP.
    • Verify: show running-config interface Vlan289 -> interface shows ip address 192.168.189.31/24 and ip mtu (1200 or 9000) or mtu 9100.
  • Check 3: WLAN mapped to dot1x auth-list and policy profile that assigns VLAN 282.
    • Verify: show running-config | section wlan and show running-config | section wireless -> should show Cisco_Live_Dot1x and policy profile VLAN 282.
  • Check 4: If EAP timeouts persist, inspect WLC logs for client delete reasons such as CLIENT_EAP_TIMEOUT_FAILURE or AAA_SERVER_UNAVAILABLE.

Common Mistakes

SymptomCauseFix
Client deleted with reason CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURERADIUS packets are fragmented and fragments dropped (MTU mismatch along path)Configure SVI MTU and map AAA group to that SVI: set interface Vlan289 ip mtu 1200 (or increase to jumbo if path supports) and aaa group server radius Cisco_Live_Radius_Group ip radius source-interface Vlan289
Authentication appears successful in ISE but client stays in management/incorrect VLANWireless policy profile not mapped to WLAN or wrong VLAN in profileEnsure wireless profile policy Cisco_Live_Policy_profile vlan 282 is present and policy tag maps WLAN to that profile
No RADIUS communication from controller to ISEMissing/incorrect RADIUS server config or shared secret mismatchVerify radius server entry: radius server J_ISE address ipv4 192.168.189.28 auth-port 1812 acct-port 1813 key Lab@123 and AAA group contains J_ISE
Large certificate exchanges still fail after MTU changePath devices (firewall/IPSec/GRE) force a smaller MTU or block fragmentsEither lower the SVI ip mtu to match path MTU (e.g., 1200) or adjust intermediate devices to allow larger MTU/jumbo frames; coordinate MTU changes across path

Key Takeaways

  • EAP-TLS certificate exchanges can exceed default MTU and require careful MTU planning — lost fragments result in EAP timeouts.
  • The WLC’s ability to use a specific SVI as the RADIUS source gives you direct control over the MTU used for RADIUS traffic; map your AAA group to that SVI.
  • Two remediation strategies exist: reduce the SVI IP MTU to a value smaller than any problematic tunnel, or increase MTU (jumbo frames) end-to-end if supported — choose based on your topology.
  • Always verify three things after troubleshooting: RADIUS server & shared secret, SVI IP/MTU and AAA source-interface mapping, WLAN-to-policy VLAN mapping (e.g., VLAN 282).

Warning: Changing MTU without verifying every device in the path can cause additional packet drops. Coordinate MTU changes with network, firewall, and VPN teams.

This lesson covered the common 802.1X failures tied to certificates, fragmentation/MTU, and VLAN assignment. The next lesson will walk through packet captures and stepwise packet-flow analysis of an EAP-TLS session to pinpoint exactly where fragments are lost.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security