01-13-2010 08:18 AM - edited 02-21-2020 04:26 PM
Hi,
I am having a issue with resolving local domain names when connected via an SSL VPN using anyconnect.
I have identified that this is due to the fact that the DHCP assigned DNS is not appending a Domain Suffix.
I have proved this by adding the local domain after the hostname I am trying to ping.
On the ASDM of the ASA5505 I have ensured that the correct domain is identified on the DNS, however this is still not working.
Please could someone guide me in the right direction. Should this be on the profile that is downloaded or a configuration that automatically appends the correct suffix when DNS requests are sent to the DNS server.
Solved! Go to Solution.
01-27-2010 08:49 AM
Hi again,
I just figured out my DNS suffix name resolution issue and I figured I'd share my solution in case it helps you:
Test by reconnecting to with an AnyConnect client and running an ipconfig /all.
For me, I now can see the dns suffix that I defined in the Group Policy and I can successfully ping internal hosts by name.
Good luck!
01-27-2010 08:15 AM
Hi,
I'm having the same exact issue. I can make an AnyConnect client connection, and ping local doman IP addresses and FQDN's (computername.domain.local) all day long but cannot ping by internal computer name only. I suspect it's the DNS suffix thing as well but can't seem to find a way to fix it. As you, I looked in ADSM too and can't find anything wrong or mis-configured.
Was wondering if you had any luck with this?
A temp workaround could be to add the FQDN's and IP address to the remote computers host file but that's a lame approach.
Any feedback is much appreciated.
01-27-2010 08:49 AM
Hi again,
I just figured out my DNS suffix name resolution issue and I figured I'd share my solution in case it helps you:
Test by reconnecting to with an AnyConnect client and running an ipconfig /all.
For me, I now can see the dns suffix that I defined in the Group Policy and I can successfully ping internal hosts by name.
Good luck!
01-27-2010 10:35 AM
Hi Michael,
I fix it using a similar methord, however I dropped down in the CLI and configured it under the profiles. Long live CLI, guess we get lazy now using a GUI.
Thanks for the feedback though.
Rich
02-09-2011 07:37 AM
Hi,
We have a similar issue, but with multiple suffix's... TunnelALL mode.
Let's say:
ping hostA (host1 resides in domain3, so host1.domain3)
dns query for hostA through vpn results in "no such name"
then silence for 14 seconds (in fact following DNS rules, it waits 2s tries again, waits another 2s, then tries with another interface which is not the vpn interface and due to tunnel all, there is no reply and then dns resolver waits 6 seconds.... bla bla bla)
dns query for hostA.domain1 results in "no such name"
silence for 14 seconds
dns query for hostA.domain2 results in "no such name"
silence for 14 seconds
dns query for hostA.domain3 results in "x.x.x.x"
FINALLY, reply from my host after 45 seconds !!!
How do we speed things up besides using split tunnel and then restrict access only to local lan...
We don't like split tunneling :-)
Johan
08-31-2011 04:21 PM
Johan,
I just found out we are having the exact same problem with AnyConnect 3.0.0629.
This makes the VPN operate extremely slow. We have the default domain field populated within our group policy.
Has anyone else seen this issue?
Thanks,
Tim H.
09-06-2011 08:54 AM
Johan and anyone else,
The AnyConnect client appears to modify and use the following registry key for the DNS Search List:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\SearchList
It appends the "Default Domain" AnyConnect Policy setting to the top of this registry key.
When an XP workstation's DNS Search List is managed by an Active Directory Group Policy, it uses the following registry key for the DNS Search list:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\SearchList
There are two things going on here. The "Default Domain" AnyConnect Policy setting is not being used during the VPN session and increased DNS lookup latency (12 - 14 seconds between lookups), because the AnyConnect client is trying to use one search list and the workstation is being enforced by Group Policy to use another search list.
Even if we move the most common or most used DNS domain to the top of the Group Policy DNS Search List, there will probably still be a 12 - 14 second delay between the 1st and 2nd entry in the search list. It would help, but not fix the overall issue.
Are you managing your DNS Search List with a Group Policy too?
Thanks,
Tim H.
09-24-2015 01:48 PM
I was actually working with Cisco on this DNS issue for AnyConnect Clients not resolving IP's via name space on internal subnets. Nice Job Voltaix_IT!!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide