Upgrade from PIX to ASA 5510. VPN not working properly

Unanswered Question
Feb 27th, 2009

After upgrading a client from a PIX 501 to an ASA 5510, I'm having problems with the VPN and specifically the hostnames for the internal devices.

Once active, the VPN on the ASA works perfectly fine by IP, but not by hostname.

If I edit the hosts file on the local machine, the hostname works fine, but that's not a feasible option to do for every machine that requires VPN access.

Can anyone check my config and see if I'm missing anything?


EDIT: It's not shown in that config, but the assigned DNS server for both VPN's is the IP, which is the ****DC01 device.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

If you are talking about the VPN clients not being able to perform DNS, I would add:-

group-policy DfltGrpPolicy attributes

dns-server value <>

default-domain value <>

As if there is NO dns server or domain name specific in the default config or anywhere else, the the remote machine will use the LOCAL DNS - if they are at home it will be the ISP. The ISP will NOT be able to resolve names to the internal domain.


ewellsie07 Fri, 02/27/2009 - 10:26

I have tried using the default policy with the DNS settings, as well as not inheriting the DNS and inputting the server/domain for each individual group policy, but with the same results.

Right now, I've still got the PIX running live, since the VPN is required for daily use, I'm trying to test it with a mini-network consisting of two laptops, the ASA, and an 1841 router.

But in my previous turn-ups, the DNS wasn't working even with the DNS server and default domain specified in the VPN policies.

well there are two ways to see if it's correctly configured and picking up the DNS settings from the VPN:-

1) ipconfig/all - should reveal the domain name and the DNS server for the VPN virtual adapter

2) a nslookup will reveal which DNS server will be used for all DNS resolutions,

post the output of the above - you issues the commands at the windows cli or cmd window.


ewellsie07 Fri, 02/27/2009 - 11:02

While plugged into the live environment, the DNS server shows correctly in the ipconfig, however the NSLOOKUPS don't work.

Unfortunately, I've got the ASA here in my office and not set up at the site, so showing the output wouldn't do much, since it won't find the server here.

However, in my previous live tests, it wouldn't do any nslookup's.

Eh! nslookups should always works IF your DNS works - they are the same thing.

That does not matter - you can have a server configured as - as long as when you connect to the test ASA, and the client recevies all the information when you issue the nslookup command you should see the server as the configured name server ready to resolve names.

Again - nslookup is the same as DNS. If nslookup is not working - then your DNS is liekly not to be working.

auraza Fri, 02/27/2009 - 11:22

nslookups are not supported on the vpn client.

Please make sure your DNS request is going through the tunnel - you can run a capture on the inside interface of the asa, to see if DNS requests are making it across, and if a reply is getting back from the DNS server.

To run a capture:

1) create an acl specifying the traffic, from your vpn client to the dns server, and the reverse, so to access-list entries for the hosts:

access-list capture permit ip host VPN_CLIENT_IP host DNS_SERVER_IP

access-list capture permit ip host DNS_SERVER_IP host VPN_CLIENT_IP

2) Create a capture:

capture capin int inside access-list capture pack 1522

Try pinging an internal name, and see if you capture anything.

To see the capture, issue the following command:

show capture capin

This will show you if any packets are getting to and from the DNS Server.

To delete the capture:

no cap capin

ewellsie07 Tue, 03/03/2009 - 06:30

Here's my results, with a test DNS server set-up.

Pings and NSLOOKUP's by IP work fine, but I still can't ping or run an NSLOOKUP by hostname.

32 packets captured

1: 09:21:51.272065 > icmp: echo request

2: 09:21:51.272340 > icmp: echo reply

3: 09:21:52.239718 > icmp: echo request

4: 09:21:52.240008 > icmp: echo reply

5: 09:21:53.240755 > icmp: echo request

6: 09:21:53.241045 > icmp: echo reply

7: 09:21:54.241824 > icmp: echo request

8: 09:21:54.242113 > icmp: echo reply

9: 09:21:59.670695 > udp 40

10: 09:21:59.671245 > udp 69

11: 09:21:59.676402 > udp 40

12: 09:21:59.676768 > udp 69

13: 09:22:19.878464 > udp 53

14: 09:22:20.877975 > udp 53

15: 09:22:21.878158 > udp 53

16: 09:22:23.878204 > udp 53

17: 09:22:27.879394 > udp 53

18: 09:22:31.199040 > udp 53

19: 09:22:45.308699 > udp 40

20: 09:22:45.309096 > udp 69

21: 09:22:45.313582 > udp 53

22: 09:22:57.199986 > udp 53

23: 09:22:57.201237 > icmp: udp port 1074 unreachable

24: 09:23:07.541857 > udp 53

25: 09:23:08.541887 > udp 53

26: 09:23:09.541842 > udp 53

27: 09:23:11.541872 > udp 53

28: 09:23:15.542009 > udp 53

29: 09:23:19.200718 > udp 53

30: 09:23:32.017287 > udp 40

31: 09:23:32.017684 > udp 69

32: 09:23:32.022398 > udp 53

auraza Tue, 03/03/2009 - 06:45

It seems like your DNS server is responding back - can you run a packet capture on the client machine, specifically on the VPN adapter, to see if those DNS packets are making it back?

Also, enable logging on the VPN Client for everything. Edit the vpnclient.ini file, and change all the LogLevel values to 15.

Grab the output and upload it here.

You can take a look at the packet captures on the ASA in pcap format by browsing to


Where Internal_ASA_IP is the IP you use to access the ASDM. If you use a different port for the ASDM, then put in the IP:port. CAPTURE_NAME is the name you gave to your capture when creating it. Make sure you don't remove the capture, before grabbing it from the ASA. Do a no cap CAPTURE_NAME after you grab the pcap file.

ewellsie07 Tue, 03/03/2009 - 07:19

Here's the output for the VPN client log and the PCAP output.

I've edited it slightly to change the public IP and my company's domain, which is not the domain I'm trying to access hostnames on.

The method I followed for this logging was

1. Ping from VPN Client (

2. NSLOOKUP from VPN Client

3. Ping internal hostname (win-mq6w62yv3ou) from VPN Client

4. NSLOOKUP internal hostname from VPN client.

That's the order when looking at the logs. I only copied the portion of the VPN client log when I was actually doing the ping tests, do I need to copy the entire thing and upload it here?

ewellsie07 Tue, 03/03/2009 - 12:00

I removed my test VPN Client machine from our domain, and made it a workgroup machine.

After doing that, I am now able to ping through the ASA by hostname and IP to both the test DNS server and another attached laptop.

Apparently it was still trying to resolve DNS names within my company's domain.

Unfortunately, our client uses Verizon broadband cards to access the VPN so that will be hard to duplicate here in the office, but they shouldn't be on a domain at all.

Any ideas what their problem would be?

ewellsie07 Tue, 03/03/2009 - 12:42

After some further testing, it appears I can do everything in my little test network here now, by either IP or hostname, and without any NBNS or ARP queries.

I connected to the current PIX VPN and used Wireshark to see what might not be happening with the ASA, based on that I'm thinking that for some reason the NBNS Name Queries are not being answered, hence why the VPN clients cannot find the hostnames when the ASA is connected.

Not sure why the ASA would block that though.

auraza Tue, 03/03/2009 - 16:03

Try disabling netbios inspection on the ASA, under the global_policy policy-map.

That said, are DNS requests working at all?

ewellsie07 Fri, 03/06/2009 - 05:55

Put the ASA back into the live environment yesterday and spent a few hours chasing down the problem, using Wireshark.

I was able to get it to work fine on my test laptop, however the client's laptops weren't working still.

After capturing the packets with Wireshark, I realized that the DNS requests from their laptops were querying to hostname.townof********.gov instead of hostname.********.local so the DNS queries were not being answered.

Not really sure why it was doing that, as the .gov is their public website address, and the *********.local is their domain. They are actually two different domain names.

If I pinged/nslookup the FQDN of hostname.********.local then I would get a response.

The temporary solution is that we created a batch file with a delay to automatically map drives to the FQDN servers after the VPN has connected.

I'd like to figure out why it's not querying the correct domain though, but ultimately it appears it may not have been an ASA problem at all.

auraza Fri, 03/06/2009 - 06:22

Do you already have the default-domain value specified under the group-policy? If you specify that, it should use the .local. However, if you are using split-tunneling, it *may* use the physical adapter first. One thing you can try is changing the binding order of the adapters, so the VPN client adapter is at the top. To do this, open Network Connections -> Advanced -> Advanced Settings, and put the adapter for the Cisco VPN client at the top (it should be one of the ones labeled as Local Area Connection). Make sure you verify you're moving the correct one to the top. See if that fixes the issue.

ewellsie07 Fri, 03/06/2009 - 06:30

Yes, the default domain value is specified as ********.local and it works correctly on my test laptop, even after I joined it to the client's domain similar to their laptops.

We didn't previously have split tunneling enabled, but I just enabled it this morning after we figured out the other issue.

auraza Fri, 03/06/2009 - 06:35

Then I would recommend changing the binding order on the adapters in Windows, and see if that does it.

Also, you can add a split-dns value using the .local domain, so all .local DNS requests will be sent over the tunnel. This is if you're using split-tunneling.


This Discussion