AnyConnect failes to connect due to unsuccessful domain name resolution

[aryankanse6]

Hello,

I am having a bunch of trouble with our VPN lately, where people occasionally cannot connect to the domain when anyconnect fails to connect and throws this error:

"The VPN connection failed due to unsuccessful domain name resolution"

I have Googled it quite a bit and tried following all the fixes: no local statically defined dns servers, make sure the client is up to date, flush dns client-side

This error will come and go, maybe 1-2 users out of 200 will see it per day and it's usually different people, with a few exceptions. I've found that if they power cycle their modems they will be able to connect, at least for a while.

Any help will be appreciated, thanks

[rasmus.elmholt]

How are AnyConnect configured? Does the users use there local DNS server or do they use the corporate one though the VPN session?

[Mike.Cifelli]

This would be better off being posted in the Security->VPN section. However, in your xml profiles is the <HostAddress> by FQDN? I assume so, you have a couple of options.
1- make the <HostAddress> the IP of the VPN frontend; If you do this you will have to figure out the easiest way to update the profiles. If using ISE you can rely on Client Provisioning Portal to push the update profiles. Or if you have SCCM you could use that. Note that this will require some changes on the concentrator.
2- push static dns entries to the hosts in their local hosts file

[rnecker01]

We've just encountered this issue after upgrading from 4.10.00093 to 4.10.04071. We get that same error on a fraction of what is deployed, but we deploy to thousands at a time in our environment.

We've discovered that if we delete the Preferences.xml in the user profile folder, the issue goes away. I know there is a "client certificate preference" section which may be an issue if created from previous version of the app.

At first, our site support would clear DNS and it would work temporarily but then comes back (this is not the fix). But I believe the 1st resolution is working ... so far. 
We don't really believe it is a true DNS issue.

I feel I must give you a flow of the install from our environment so you could see where the issue may be.
- SCCM deployment of both prelogin (gina) app and then mobility app, and XML dropped in ProgramData Profile folder with default servers.

- For a client specific config (where our issue comes from), a Computer GPO overwrites the Profile XML.
- For some, they get that error and CAC is dead in the water. The only fix is to use FixMe or similar to remote to PC, delete the user's Preference.xml and restart.
- When we see this issue, the pre-overwrite connections are listed (due to the preferences.xml I'm sure.)

NOTE: We did NOT see this behavior with 4.10.00093

Any idea what has changed to where this would happen?
Are there other steps in this scenario where this could be avoided? We've already built a client-specific installer which deploys the client VPN connection during imaging and fresh deployments to avoid the issue.