Introduction
I have been an engineer in TAC for over a year now, and have been handling NAC cases for the past seven months.
Cisco NAC (formerly Cisco Clean Access), helps in enforcing security policy compliance on all devices that attempt to gain access to your network. It can be used to authenticate, authorize, evaluate and remediate wired, wireless and remote users, before they can access the network.
The primary components in a NAC deployment include the CAS and CAM which are physical devices. In addition to this, more often than not, a NAC agent is installed on the PCs which require authenticating against NAC.
In this blog, I am documenting the problem scenarios with NAC agent that are frequently observed. These include the NAC agent not popping up automatically, or taking time to login.
Pre-requisites
I am assuming that the readers are familiar with the various NAC components like CAS, CAM, etc. and features that can be configured using NAC like ADSSO, VPNSSO, etc.
NAC Agent Working
The NAC agent sends discovery packets on UDP and TCP ports 8905 and 8906, in order to find the CAS in the network. These packets are sent every 5 seconds. The agent sends these packets to the PCs default gateway(s)(in case of multiple NICs), the configured discovery host, and previously known CASs. Once the CAS responds to a discovery packet, the NAC agent begins communicating with it, and prompts for authentication (if required).
Commonly seen Issues
The following scenarios assume that routing configuration (VLANs, routes, PBRs, etc) is correct in your network, and despite that, the NAC agent is not popping up.
Discovery Host is missing or incorrect
The Discovery Host is an IP address that can be the CASs untrusted interface IP, or any IP on the trusted side. Basically, traffic meant to reach the discovery host, should reach the CAS.
To check the current discovery host: right-click on NAC agent on your task bar, and click Properties.
For automatically setting the discovery host for users who download the NAC agent, you can configure it in the CAM GUI under this tab: [Device Management > Clean Access > Clean Access Agent > Installation]
In a new setup, where the above may not be configured; OR, if the user downloads the agent from www.cisco.com, instead of the CAS, the discovery host may be missing from the NAC agent. As a result, the discovery packets would be sent only to the default gateway, which may not be lying beyond the CAS.
DNS information missing or incorrect
Once the discovery packets from the Agent reach the CAS, the CAS will send its certificate to the Agent. If the Agent cannot resolve the CN from the certificate, then it won’t be able to communicate with the CAS.
To verify, do an nslookup for the CAS CN, as seen in the CAS GUI, under this tab: [Administration > SSL > X509 Certificate]
If the nslookup does not show a result, then you may want to check if the DNS entry exists on the DNS server(s) configured on the PC. More importantly, you would need to check if the DNS server's IP is actually correct on the PC.
During ADSSO, the PC will do an nslookup for the domain. If your network is large, such that the reply to this DNS query could exceed 512 bytes, then you need to allow TCP DNS in the CAS traffic policies as it is not enabled by default.
CAS is not available on the network - I
The NAC agent presents an error: “Clean Access Server is not available on the network. Please contact your administrator if the problem persists.”
If DNS and routing are correct, then ideally you should not see this message. However, if your Internet Explorer is in “Work Offline” mode, then it shuts down certain important services which are required for the NAC agent to work properly. Simply un-checking this mode from Internet explorer should fix this.
This issue is documented here:CSCta39899
CAS is not available on the network - II
The NAC agent presents an error: “Clean Access Server is not available on the network. Please contact your administrator if the problem persists.”
If you see this error message only on Windows 7 and Windows Vista, but not for Windows XP users, while running version 4.8.2 on CAS and CAM, then you would be hitting this caveat: CSCtq35120
The version of Apache was upgraded in 4.8.2, and as a result, if the CAS certificate has its CN in mixed case, then CAS detects a mismatch between its certificate (mixed case), and the agent provided certificate (lower case).
To fix this, the CAS certificates would need to be generated with CN completely in lower case.
Invalid switch configuration-OOB Error
NAC agent pops up, but gives the error “Invalid switch configuration-OOB Error:OOB client MAC:IP not found.”
As evident from the error, this happens only in an OOB setup. The way this setup works: the switch sends an SNMP trap informing a new PC has connected to it. The NAC agent on the PC then authenticates with the CAS, and then, since the CAS is in OOB, it cross-checks with the Discovered Clients list on the CAM.
Of course this is a very simplified summary, but it helps us understand why the NAC agent gives that particular error message. If the CAM has not received an SNMP trap for the PC, then the NAC agent will show the above message.
To fix this, you would need to check routing for SNMP between the switch and the CAM.
If you see this during initial setup stage, then maybe you are testing with a PC, whose MAC the switch already knows. Therefore it is always a good idea to clear the mac address table before testing.
NAC agent does not work randomly for some users
One of the many reasons that this could happen, is due to a malware or “virus” blocking agent packets or internal messages. Installing an up-to-date anti-virus and anti-spyware and running a full system scan can resolve the issue.
Long login times with SEP v11
NAC agent takes a long time to log in on PCs with Symantec Endpoint Protection v11.
Symantec Endpoint Protection (SEP) v11 is known to block packets from and to certain versions of the NAC agent. One of the workaround is to white list the NAC agent folder in the SEP policy.
Detailed documentation for this issue can be found here: CSCto49390
Slow login with ADSSO
You may observe slow logins when ADSSO is configured, and login scripts or drive mappings are also configured.
This happens if access to the script servers or Windows File Sharing (SMB) servers is not allowed in the unauthenticated and temporary roles. The PC would log in to the domain, and then try to run a script or contact an SMB server, but fail. Thus the user would see the Windows Login screen for a really long time, while the PC waits for the aforementioned connections to time out.
To fix this, you can introduce a delay into the login scripts (as mentioned here), or allow access to the required servers, on the required ports, in the unauthenticated and temporary roles.
Further Troubleshooting
If any of the above doesn’t fix the problem, then we would need to verify our original premise: routing and switching between the PCs and the CAS. Comparison of simultaneous packet captures taken on the failing PC, and bi-directional span captures on the CAS untrusted will let us know if there is any issue in communication between the two.
If it is working for some PCs and not working for others, then it is extremely helpful to look into the differences between the two PCs. There may be static DNS configured, or it may have a different anti-virus, or it maybe getting a rogue DHCP IP, etc.
Hope you find this information useful. If you have any questions regarding any of the points mentioned above, please feel free to ask your queries in the comments section, and I will try my best to answer them.
-Shrikant
