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 192.0.0.2 IP, which is the ****DC01 device.
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.
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.
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 192.0.0.2 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 22.214.171.124 - 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 126.96.36.199 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.
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
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 172.16.1.1 > 192.0.0.2: icmp: echo request
2: 09:21:51.272340 192.0.0.2 > 172.16.1.1: icmp: echo reply
3: 09:21:52.239718 172.16.1.1 > 192.0.0.2: icmp: echo request
4: 09:21:52.240008 192.0.0.2 > 172.16.1.1: icmp: echo reply
5: 09:21:53.240755 172.16.1.1 > 192.0.0.2: icmp: echo request
6: 09:21:53.241045 192.0.0.2 > 172.16.1.1: icmp: echo reply
7: 09:21:54.241824 172.16.1.1 > 192.0.0.2: icmp: echo request
8: 09:21:54.242113 192.0.0.2 > 172.16.1.1: icmp: echo reply
9: 09:21:59.670695 172.16.1.1.1071 > 192.0.0.2.53: udp 40
10: 09:21:59.671245 192.0.0.2.53 > 172.16.1.1.1071: udp 69
11: 09:21:59.676402 172.16.1.1.1072 > 192.0.0.2.53: udp 40
12: 09:21:59.676768 192.0.0.2.53 > 172.16.1.1.1072: udp 69
13: 09:22:19.878464 172.16.1.1.1025 > 192.0.0.2.53: udp 53
14: 09:22:20.877975 172.16.1.1.1025 > 192.0.0.2.53: udp 53
15: 09:22:21.878158 172.16.1.1.1025 > 192.0.0.2.53: udp 53
16: 09:22:23.878204 172.16.1.1.1025 > 192.0.0.2.53: udp 53
17: 09:22:27.879394 172.16.1.1.1025 > 192.0.0.2.53: udp 53
18: 09:22:31.199040 192.0.0.2.53 > 172.16.1.1.1025: udp 53
19: 09:22:45.308699 172.16.1.1.1073 > 192.0.0.2.53: udp 40
20: 09:22:45.309096 192.0.0.2.53 > 172.16.1.1.1073: udp 69
21: 09:22:45.313582 172.16.1.1.1074 > 192.0.0.2.53: udp 53
22: 09:22:57.199986 192.0.0.2.53 > 172.16.1.1.1074: udp 53
23: 09:22:57.201237 172.16.1.1 > 192.0.0.2: icmp: 172.16.1.1 udp port 1074 unreachable
24: 09:23:07.541857 172.16.1.1.1025 > 192.0.0.2.53: udp 53
25: 09:23:08.541887 172.16.1.1.1025 > 192.0.0.2.53: udp 53
26: 09:23:09.541842 172.16.1.1.1025 > 192.0.0.2.53: udp 53
27: 09:23:11.541872 172.16.1.1.1025 > 192.0.0.2.53: udp 53
28: 09:23:15.542009 172.16.1.1.1025 > 192.0.0.2.53: udp 53
29: 09:23:19.200718 192.0.0.2.53 > 172.16.1.1.1025: udp 53
30: 09:23:32.017287 172.16.1.1.1075 > 192.0.0.2.53: udp 40
31: 09:23:32.017684 192.0.0.2.53 > 172.16.1.1.1075: udp 69
32: 09:23:32.022398 172.16.1.1.1076 > 192.0.0.2.53: udp 53
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.
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 192.0.0.2 from VPN Client (172.16.1.1)
2. NSLOOKUP 192.0.0.2 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?
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?
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.
Try disabling netbios inspection on the ASA, under the global_policy policy-map.
That said, are DNS requests working at all?
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.
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.
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.
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.