I am in the middle of migrating WLC 5520 (8.10.190.0) to C9800-CL (17.12.05) while APs remain the same (3802i). AAA servers are ISE 3.4 patch 2. We use centralized switching (no Flex mode). I have an 802.1X SSID allowing both EAP-TLS and PEAP+MSCHAPv2. The SSID on WLC 5520 works for pretty much all devices we have. The same SSID on C9800-CL works for most devices I tested so far but one particular Windows laptop.
- The same laptop connects to the SSID on 5520 without any issues using EAP-TLS. Tried different Windows builds (10 and 11) and updated Wi-Fi NIC driver to the latest. Machine certificate is fine. Tried manually adding network with EAP-TLS, and PEAP + MSCHAPv2. None worked with the new C9800-CL.
- There is no logs for this particular laptop/MAC on ISE meaning the Authenticator (C9800-CL) is not sending Radius request to Authentication Server (ISE) when the Supplicant client tries to join the SSID.
- I did some packet captures on the C9800-CL by providing “Inner Filter MAC” and did a comparison between a successful connection and a failed one.
It’s interesting to notice the captured packets are between the C9800-CL and the AP, but 802.1X authentication is between the supplicant (laptop) and the AP (BSSID MAC). On a successful connection, after the supplicant sends Response with Identity (host/xxxxxx), the AP sends a EAP-TLS Request, and after quite a few EAP packets exchange authentication succeeds.
On a failed connection, after the supplicant sends Response with Identity (host/xxxxxx), the AP just sends a Failure EAP packet and never sends a 802.1X proposal:
This explains why ISE never sees a Radius request for this particular laptop. I’ve tested 5 Windows laptops and a few iOS/Android devices so far, and found only one problematic laptop, but I don’t know how many more out of about 1000 laptops may experience the same issue.
A TAC ticket is going nowhere, and the engineer insists something is wrong with the laptop but doesn’t know what exactly is wrong. I’ve seen some similar issues online and it seems nobody was able to explain why there is no logs on Radius servers. Has anyone seen this?
For a good connection, it's a bunch of EAP and TLSv1.2 packets:
I believe my issue is very similar to this one:
https://community.cisco.com/t5/wireless/reason-cred-fail-on-interface-capwap/td-p/4971126/page/2
The OP claimed he fixed the issue by adding a Windows Registry key named TTLS (to apply to EAP-TTLS) and a DWORD named Tlsversion in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13. I believe the value fc0 forces Windows to use one of TLS 1.0, 1.1 or 1.2, not TLS 1.3. I did the same to no avail.
Sorry @Parithosh Vema I missed your post. I followed the instruction. I specified src/dst as 5520/AP and AP/5520 and this is what I got:
Unfortunately there is no EAP traffic being captured. Not sure I used a wrong ACL. Apparently the client doesn't have an IP yet at this stage. I did notice there is some limitations by doing this:
Hi @MHM Cisco World, right after client replied with Identity host/<FQDN>, The AP requests for EAP-TLS, the client then starts a TLSv1.2 handshake, and client and server start to identity each other with certificates.
On a failed connection, the AP simply says Failure.
Client replies with this format: host/<hostname.xxx.org.local>, where xxx.org.local is our AD domain name. We have a CA infrastructure in the domain to issue certs to ISE and all clients.
No 48 is actually for WMI. The EAP packet is between 9800 and AP, but the 802.11 data inside shows communications between the client (Intel_xx:xx:xx) and BSSID MAC of the AP (Cisco_xx:xx:xx)
Same 9800 and same (and only) AP. For the failed one there is actually another Identity Response packet has tag 48 in it:
