Catalyst 9800 integration with NAC

[DJay11]

Wireless clients are experiencing difficulty transitioning from the quarantine VLAN (192.168.40.x) to the Production VLAN (172.22.x.x). Users often need to forget the SSID, toggle their Wi-Fi off and on, or restart their devices before they are successfully connected to the Production VLAN.

By default, wireless users are required to comply with posture checking before being assigned to the Production VLAN. There are instances where users are connected within less than a minute; however, more often it takes five minutes or longer, and they need to perform the steps mentioned above. There are also cases where users are reverted back to the quarantine VLAN from the Production VLAN, even though their devices are already compliant. As a result, users are having difficulty being authorized and consistently assigned to the Production VLAN.

We are using a unified SSID (Dynamic VLAN) with multiple networks behind it.

May we know where else we should check? Both platform support teams currently have no additional recommendations to resolve the issue. The only pending action is to synchronize the NTP of the wireless system NAC.

Our environment includes:
DHCP Server
802.1X authentication via RADIUS server (NAC). 
Active Directory
Firewall

WLC Catalyst 9800
C9120AXI-A
CW9164-ROW
AIR-AP2802I-A-K9

[balaji.bandi]

Do you know if this worked before? It never worked. If this were working, what were the changes in the network?

Check posture configuration:

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/222837-configure-posture-on-catalyst-9800-wlc-a.html

Check  below :

1.  Is IP Theft enabled and checked?

2. If "DHCP Required" is enabled in the Policy Profile, the WLC expects a new DHCP exchange immediately after the VLAN change. If the client's OS caches the old IP and doesn't trigger a new DHCP Discover, the WLC may time out and drop the client back to the previous state.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-best-practices.html

3.  Check the bugs below:

https://bst.cisco.com/bugsearch/bug/CSCwf35697

https://bst.cisco.com/bugsearch/bug/CSCwj42408

4. You can use  Radioactive Trace on a specific client's MAC address

https://mrncciew.com/2022/07/08/9800-client-troubleshooting

[DJay11]

It is working but there are days/times that users/clients have difficulty transitioning to Prod Network.  Always stuck in Quarantine network or from prod network back to quarantine. 

We will check on your recommendations. 

[Mark Elsen]

  - @DJay11    I would focus on client debugging  : https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity
                       These so called RadioActive Traces can be analyzed with : Wireless Debug Analyzer

                       + Outputs from https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/217738-monitor-catalyst-9800-kpis-key-performa.html#toc-hId-866973845 
                                                            can also be useful

                      + Validate the overall 9800 controller's configuration with the CLI command :
                         show tech wireless and feed the output from that into Wireless Config Analyzer

  M.

[Wireless Lab io]

What you are performing is generally called "layer 3 override".

Your client is not aware of any changes that occur in the background during your NAC procedure, like change of the vlan/subnet.

Often times, when clients are connected to the network, after any form of re-connection occurs (including NAC) they will not perform the full DHCP DORA process, which is what you generally expect every time.

If you perform the capture, you will likely see your client is sending dhcp request (skipping discovery) for the IP that it was initially assigned from quarantine VLAN/subnet (192.168.40.x). And your DHCP server ideally should send back a NAK. However, many devices are dumb and will go in a loop where they keep requesting the same IP from quarantene VLAN until you turn wifi off/on manually.

I worked in TAC and I have seen this design attempted 3 million times with different customers, and I can tell you that its straight up bad. It will never, ever work. Especially in a network where you don't have absolute control over the client device. In theory, the design idea is solid, but in practice, the clients don't behave as you expect them to. Even if it works, its just a matter of time some VIP user will be hit with the problem and complain.

The way to do this is to not override the VLAN.

Assign clients immediately to Production VLAN (172.22.x.x), and also assign a restrictive ACL via AAA override that only allows client to perform posturing. Once the client is postured, simply send back access accept with no ACL (or different ACL with more rights). Same end result, but no vlan changes and 0 issues.