Showing results for 
Search instead for 
Did you mean: 

Troubleshooting NAC Agent Issues

Shrikant Sundaresh
Cisco Employee


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.


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, 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.



Hi Shrikant:

I know this is and old publication, however I can not find information about this.

Do you have any information about the interation with Cisco NAC (4.8 or 4.9) with Nexus?

Are there some recomendations or limitations?

We are facing this issue right now:

We are running NAC 4.9 in OOB L2.

It is a CAS HA pair.

CAS directly connected to Nexus

The Nexus is the core/distribution layer. SVIs configured in Nexus

We lost conectivity to the CAS when we configure Managed Subnets. We are not able to ping it nor conect to it by SSH or HTTPs

For example:

CAS Admin Vlan 19

VLAN Mapping: Auth Vlan 312 / Acces Vlan 12

Managed Subnet:  IP /  Auth VLAN 312 / Gateway (SVI VLAN 12 in Nexus)

A user in VLAN 12 (access VLAN ) losses connectivity to the CAS.

A user in VLAN 312 (auth VLAN) can get an IP address by DHCP (a Microsoft Server) but can not get the Login Page.

The same behaviour occurs whith the other manage subnets.

Thank you very much


Alicio Santos

Hi Shrikant,

I have the same issue reported by Marco.

Can you help me?



Shrikant Sundaresh
Cisco Employee

Hi Alicio,

It is suprising, but I had actually replied to Marco's issue, and I can't find that reply here.

If you configure a managed subnet on a Virtual gateway device, it adds a route saying that this subnet is reachable over the untrusted interface.

However, you have put the PC in the corresponding trusted VLAN. If the PC was authenticated, then the CAS would have a route saying that the authenticated IP (/32) is located off the trusted interface.

Thus in summary, the traffic from the PC reaches CAS on trusted, and CAS tries to contact it through the untrusted.

Ideally, you should use  a non-managed subnet VLAN for managing the CAS. For example, the CAM's subnet.

Hope this helps.



Hi Everyone,

I have de same issue, my deployment consist in OOB Real IP Gateway, all configuration well done and test full conectivity, however, when the client launch the browser (IE: in url appears, the redirecion for authentication page is not working, but if the client write any url based in a IP address the redirection work and the user access authentication is shown. 

Have you any idea about that the redirection for NAC Web loggin is not working?


Tarik Admani

Check your unauthenticated role, when in real ip all dns traffic is inspected. In virtual gateway mode dns traffic is allowed through. Please add a rule that allows dns to flow through CAS so the clients can get their dns requests resolved.


tarik Admani


Hi Tadmani,

Can you show me, when I can add this rule? When I try add this rule on unauthenticated role, I can’t see the policy to add:roles.jpg

Let me know if it is the correct page to add the rule.

Thank you.


Tarik Admani

Dear all ,

I have same problem with my OOB virtual gateway Central deployment , I have a C3750 as destribution switch and a 2950 as an access switch , CAS and CAM are connected to C3750 , vlan mapping is between 110>50  (110 unauthenticated vlan  and 50 is access vlan ) and the manged sunbent is  .

DG of my client is the SVI for vlan 50 on C3750 ( .

my clients can get ip address form dhcp server but the Agent does not pop up.



Hi Narges,

please answer this questions:

1.- Your clients take the IP address from DHCP configured in vlan 50?

2.- Can you get ping from untrusted users to the NAC server trusted interface?

3.- You are using Cisco NAC Client or Cisco NAC Web Agent?

4.- From unathenticated user, open a CMD and type nslookup and make a query to any web page: banking, news, etc and let me know if you have the answer from your DNS.

5.-Remember: in OOB Virtual Gateway the DHCP and DNS response are passthrough allowed.



Hi Gugo ,

Thank you for your reply,

1. yes clients are in authenticated vlan (110) can get IP address configuration from vlan 50 subnet,(based on vlan mapping rule 110>50)

2. Trusted and Untrusted interface of NAC server have the same IP , yes clients can ping this ip address.

3. I am using NAC Agent

4. I do not have DNS server in my network , so I am using  public DNS servers like



Hi Narges,

Can you, from unathenticated user, open a CMD and type nslookup and make a query  to any web page: banking, news, and so on, and let me know if you have the response from your DNS.?

which type of OS are using your unathenticaed user?

your unathenticated must be able to get response from DNS server.

The DNS need reach to the unathenticated user to response.


Dear Gugo

My problem was resolved , I implemented my CAS server on ESX which is caused the problem , I edited my ESX configuration and everything works fine,



Excelent news Nager.

Can you post the change that you made in your ESX?, this must be helpfully to another guys with the same problem.



yes of course , you must configure PORT GROUP on untrusted  interface that is connected to switch port and put your Untrusted vlan number as an id there, after that restart your ESX and everything will work correctly.

thanks for your attention,

Bryan Wulfric

Hi Shrikant,

I often face "Invalid Switch Configuration - OOB Error" issue, usually when the NAC PC is going to sleep/hibernate then after the user login to NAC agent, they experience that issue. It can be resolved by clear mac-address table on the access switch where the user connected. But it is not acceptable for my customer. Is there anything that can be tuned in the NAC configuration for solving that issue?


Content for Community-Ad

This widget could not be displayed.