Security

Here is the rundown

 

MAC AUTH service is hit

User loads a portal
Accepts terms and conditions

Countdown happens...

CoA is sent

MAC AUTH service is hit again and ACL is pushed to WLC to allow them onto the internet.

 

WHat is happening is that certain devices (especially Apple) devices don't seem to like the CoA and bounce off the SSID and connect back to another SSID (basically last known connected SSID) which I believe is how IOS handles this stuff...

 

Is there anything I can do to prevent this or ease the customer?

 

CoA delay is 5

Reject packet delay is 0

Portal delay is 15 sec...

 

 

What CoA are you using?

We are using session reauthenticate
https://www.cisco.com/en/US/docs/ios-xml/ios/san/configuration/xe-3se/3850/san-coa-supp.pdf

We are opening a ticket with Cisco.

The NADs (especially Apple ones) don't like the CoA reauthenticate especially on WPA2-PSK enabled SSIDs. Theoretically, on an Open SSID, a disconnection is not supposed to occur with session-reauthenticate but it does or its not always consistent and get the famous "Error hotspot login error"

If you look at
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html

Snippet from the bottom of the article:

Note that the type of CoA returned by ISE evolved across versions. ISE 2.0 will request the WLC to re-run the authentication rather than plainly disconnect the client.

The WLC will then not send a disassociation frame to the client and will run a radius authentication again and apply the new result transparently to the client.

However, things are still different if a PSK is in use. Since 8.3, the WLC supports setting a WPA pre-shared key on a CWA SSID. In that kind of situation, upon reception of the same CoA from ISE as above, the WLC will have to trigger a new WPA key exchange again. Therefore in case of PSK, the WLC will have to send a disassociate frame to the client which will have to reconnect. In classical non-PSK scenarios, the WLC will not send a disassociate frame to the client and will simply apply the new authorization result. However an "association response" will be still sent ot the client although no "association request" was ever received from the client, which might seem curious when analyzing sniffer traces.

Did you ever get a resolution for this?  We are seeing the same thing as well.

We increased the login delay on the web login page to 15 sec.
CoA delay to 5 sec
Reject Packet Delay to 0 sec.
That helped.

We did not run into this issue with an Open SSID but the customer refused to get rid of the WPA2-PSK on the SSID so we had to show them the Cisco article and explain to them IOS devices will connect to the last known SSID after being disconnected from the CoA.
Show them an Apple article on how the devices choose which SSID to connect to in priority
(https://support.apple.com/en-ca/ht202831)

Cisco sends a session disconnect to WPA2 enabled SSID when you perform a CoA and the client must re-authenticate to the SSID. (Article is in a previous post).

They are living with it but the thought it because this is a guest network, no device would be able to connect to any other SSIDs in the building since they are guests.