DNS Issue with AnyConnect on ASA

Answered Question
Jan 13th, 2010
User Badges:

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

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.

Correct Answer by voltaix_it about 7 years 1 month ago

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:


  • Log into ASDM, select Remote Access VPN, expand Network (Client) Access, highlight Group Policies.
  • On the right, edit the Group Policy that your remote users are connecting to.
  • In the Group Policy edit screen that comes up, highlight Servers on the left and then click the little down arrow on the right to show more options.
  • Fill in the default domain field with your internal domain name (for example, mydomainname.local)
  • Click Ok to save and save running config to flash.


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!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
voltaix_it Wed, 01/27/2010 - 08:15
User Badges:

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.

Correct Answer
voltaix_it Wed, 01/27/2010 - 08:49
User Badges:

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:


  • Log into ASDM, select Remote Access VPN, expand Network (Client) Access, highlight Group Policies.
  • On the right, edit the Group Policy that your remote users are connecting to.
  • In the Group Policy edit screen that comes up, highlight Servers on the left and then click the little down arrow on the right to show more options.
  • Fill in the default domain field with your internal domain name (for example, mydomainname.local)
  • Click Ok to save and save running config to flash.


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!

richard.jackson Wed, 01/27/2010 - 10:35
User Badges:

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

Johan Leuyckx Wed, 02/09/2011 - 07:37
User Badges:

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

Timothy Hornbeck Wed, 08/31/2011 - 16:21
User Badges:

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.

Timothy Hornbeck Tue, 09/06/2011 - 08:54
User Badges:

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.

Actions

This Discussion