Outage on 802.1X Wifi

[OrkhanRustamli]

Hello all,

I have had WiFi network with 8 APs with one SSID which was PSK secured. One month ago, we have added I have created new SSID which is 802.1X secured with ISE but it turned to be nightmare for me. Some part of people are complaining that they face a lot of outages in using new wifi and it is so bad. I have checked and they were right, some people have weird problems. I updated all their drivers and OS, moreover I disabled DFS channels from DCA(My APs was seeing a lot of radar signals on DFS channels) but nothing helped. Interesting part is that people sitting in same room next to each other and one has problem while for another everything is smooth. I wonder whether that is connected with any timeout timers or nor. I have disabled Re-Authentication timeout and Idle Session Timeout which was not helpful. I am using Cisco recommended software.

Any help is appreciated.

[Scott Fella]

Rule number 1, don’t add all the features on the SSID because it’s available. Like mentioned by others, disable 802.1r and also k/v. Look at your radius logs, if you see authentication “pass”, then there is nothing wrong with 802.1x. Not being able to ping the gateway is typical for old drivers. Have you tried to look at how old the driver is on the devices? Are you also doing aaa override where maybe ISE is send the correct or incorrect vlan? Is this FlexConnect or local?

[OrkhanRustamli]

Well,

11v has been disabled since WLAN creation. 11k - Neighbor List is only thing that is enabled. 11r was disabled by advise which then enabled back because people had both problem with same issue and with roaming.

I cannot be sure that it is because of ISE or 802.1x because all users are authenticated very well. The problem appears to happen after they are authenticated and been working with wifi for a while. I disabled re-authentication and idle-session timeout for minimizing re-authentication. 

90% percent of devices in our corporation is MAC and other part is also latest other vendor devices. We checked all drivers and updates which are up to date.

AAA override is enabled under WLAN but ISE is not pushing any VLAN. Authentication policy in ISE is configured to be EAP-TLS and Authorization Policy is set to be Access-Accept and SGT Values.

The current WLAN is in Fabric Network and APs for that WLAN plays standalone role working with VXLAN.

[Scott Fella]

Well it seems like you might need to open the Tac case with ISE team since you are also using SGT’s. AAA override is not needed if you are not changing the vlan, but unless SGT requires that then yes. That might be the issue as psk is not affected by SGT and that’s why it works.

[Jay Vivas]

What you are describing sounds like a compatibility issue with Macbooks and the WLC on the rekey that happens after a session timeout. You may have this disabled on the WLAN but ISE can override it in the authorization policy. Give me the TAC sr number and we can work on it together to confirm if this is the case.

[OrkhanRustamli]

Hello,

Here is ,SR 688082420, TAC serial number but as I said because I was in leave and my colleagues forgot to continue working on the case, it was closed. I would really appreciate any help because I already suffer from this problem for 3 months.

Really interesting, if it is compatibility problem then why not all users with same devices are infected. 2 users sitting next to each other with same device and in same AP, but only one faces the issue.

[Jay Vivas]

If this is the issue I'm thinking it is, then the difference would be the session timeout. The session timeout starts after the client authenticates. Both clients would have most likely authenticated at different times meaning their timeouts would happen at different times. This issue is also a race condition so it only happens on about 10% of the session timeouts. What happens is the client has an encryption key, after the session timeout the key changes, sometimes we already have packets in the queue that have been encrypted with the old key. We send these packets out to flush the queue. The Macbook receives these packets, thinks it is a replay attack and blacklists the bssid. See cisco bug CSCvo91525. I will send you an email to help dig into this further.

[Scott Fella]

Open another case with the security ISE team as the issue might be because you are using fabric. I don’t see this being an issue with the wireless since PSK works and in that scenario, ISE is out of the picture. Fabric and DNAc on wireless if very new and doesn’t mean that it is 100% solid.