I've been see an occasional problem with AnyConnect VPN clients and traffic routing and I'm not sure how to address it. My network has been running VPN services using AnyConnect for 10+ years now. We are using split tunneling to insure the only traffic going over the VPN is traffic for our internal network. Over the course of time I've seen a repetitive issue where a user who has been using AnyConnect for years, looses the ability to surf the Internet whenever the VPN is active. Disconnecting the VPN restores Internet browsing. To be clear, out of 100 AnyConnect users maybe one or two will have this issue in a 3 to 6+ month time. All users using the same profile and policy.
99% of my users are Windows 10 clients. If I understand it correctly, Windows will roll traffic over from network connection to network connection until traffic passes, so traffic to a web site that's not permitted over the VPN because of split tunneling will roll over to the next network connection until it passes or fails. If this is true, it seems like the fault is how Windows handles the traffic.
Over the years, I've updated the version of the ASA OS and I've updated the AnyConnect client (currently on 4.8.x). Does anyone have any ideas on this?
Seeing such an inconsistent behaviour, it could be due to many reasons (maybe AnyConnect, maybe Windows). The only way to find the issue is to troubleshoot it live, when it happens, on both ends, ASA and AnyConnect
- from AnyConnect, send traffic to the Internet and see if it's sent in the tunnel (statistics)
- from ASA, use show vpn-sessiondb to ensure the proper policy has been applied
I know this is an old post, but it happens so infrequently that it's been hard to catch. I worked with a user today and this is clearly a DNS issue. When the user enables VPN, DNS request go to the DNS server over the VPN. If the on prem DNS server doesn't have a record for the request it should roll over to the Internet provider's DNS but it doesn't.... for this one client. All clients are using the same profile. With VPN enabled, I can see this by doing an NSLOOKUP and looking up internal vs. external names. If I set my NSLOOKUP server to be 22.214.171.124 I can resolve the name correctly for outside records. The quick fix (and I don't know why) is to disable IPv6 on the client. We don't run IPv6 on my network and my VPN isn't setup for anything to do with IPv6, but disabling the protocol on the network adapter fixes the issue. I double checked the policy and both split tunneling and split DNS are in use. Regardless, a mis-configuration in the policy should affect all logins that use that policy, not the occasional login.
i think we had the same problem when we upgraded to ASA code and move to anyconnect client 4.8. it only happened to our windows 10 clients.
we fixed it by removing the anyconnect registry files (regedit) and re-install anyconnect client.
it also help to set the “EnableActiveProbing” value to “1” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet