AnyConnect NAM "Limited or No Connectivity"

[Lahiruk]

Hi All,

Recently we have deployed a NAC Solution with Cisco ISE in one of our customer sites.

"Limited or No connectivity" message appears randomly in AnyConnect NAM module (Wireless). This is not depend on the client laptop or wireless adapter as per my observations. Error can be exist in any type of adapters and Win 10 patches.

Followings are my observations:
1. Randomly this error shown in NAM.
2. During the error shown, full network connectivity is possible. (GW, ISE, Proxy, Internet and all connectivity are possible )
3. Network adapter is enable during the error. Incoming and outgoing bytes are increasing.
4. Manually select the SSID and connected by NAM--> Successfully connect to WLAN

ISE Versoin : 3.0 patch 4
Any Connect : 4.10.04065 and 4.10.03104

Please assist us to resolve this error. Since I have not seen a proper resolution for this over the internet.


Regards,
Lahiru K

[rbill1967]

A temporary solution is to select "network repair" on the client side, it forces the client to obtain an IP and connect.  Yes a more permanent solution is needed.  Currently working a case with Cisco on the same issue.

[ahollifield]

Why are you using NAM at all?  Why not use the native Windows supplicant?

https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/identity-service-engine-software-3-0.html

https://www.cisco.com/c/en/us/products/collateral/security/anyconnect-secure-mobility-client/anyconnect-secure-mobility-client-v4x-eol.html 

[rbill1967]

We tried using the windows supplicant in the original build of ISE, when testing and going live.  It did not work well, so we fell back to the NAM, which for over year has worked without any issues.  Just for the last month, we just started receiving this error and cannot figure out what is causing it.  I reviewed switches and ISE, no luck there.

[ahollifield]

I would consider dropping the NAM.  Windows supplicant now supports EAP-Chaining (TEAP) so IMHO it removes the need for NAM.  I would be inclined to believe based on timing this was probably caused by a Windows or driver update.  I would collect a DART bundle and work with TAC to analyze the client logs.   

Also note you should probably upgrade your AnyConnect version due to some recent PSIRTs.  Why do you have two different versions of AnyConnect deployed?  

Although I don't think this is related to your issue, you should also at least install the latest patch of 3.0.  And plan for an upgrade to 3.2 and your AnyConnect upgrade to Cisco Secure Client 5.0.

[rbill1967]

As I said, almost a year ago we attempted to use Windows Supplicant and it didn't work, so we decided to use NAM.  Now almost a year later, full implementation is almost complete, one last sight.  It is great, they finally have those kinks worked out with Windows Supplicant but to uproot an entire structure to fix one issue, is not the best course of action right now.

I'm not saying I won't explore it again, but I hope support will find a solution to the current issue first.  Also, why do we have 2 different flavors, when we started it was 4.8, since then we've been pushing 4.10.  We still have a few clients with 4.8, but they can be updated to 4.10 or v5 from the application.  Of course, when changing to another version higher, need to assure 4.8 will still work until they've been updated and then policy within will continue to work and support.

All good ideas, something to consider, but I was hoping for another option or possible fix, just not the one I expected.

[rbill1967]

Believe it or not, it's now almost a year later and I still fighting this type of error in Windows 10 and now Windows 11.  In a way it came back after a year of no issues and now full implementation.  It was a security update from Windows that broke it, and instead of working with ISE it caused this to come back with a vengeance.

All I can say is good luck on getting an expert or anyone to figure this out.  We use NAM but with modifications within the XML file of the program, to eliminate the latest threat the reauthentication of user credentials (prompting over and over again) in this case.  We've had to make further modifications on the policy sets to authenticate differently, to get past this.  All experiencing the original issue of "limited or no connectivity" from the agent side.

As I said before, uprooting a whole setup is not the ideal answer.  Yet as we get closer and closer to ongoing issues, might not sound like a bad idea.  Especially if you are seeking Cisco help, all you will get it article-based support.  This has changed tremendously.

[ahollifield]

Do you have credential Guard enabled on the Windows Devices?  I would recommend you investigate using certificates for machine/user authentication instead.  

[rbill1967]

Yes we are using certificates now, that is the latest in attempts to get past the issues were experiencing. I hope a step in the right direction, but we will see.