02-27-2009 08:22 AM - edited 03-11-2019 07:58 AM
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?
Thanks.
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.
02-27-2009 09:11 AM
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.
HTH>
02-27-2009 10:26 AM
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.
02-27-2009 10:44 AM
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.
HTH>
02-27-2009 11:02 AM
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.
02-27-2009 11:14 AM
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 1.1.1.1 - 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 1.1.1.1 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.
02-27-2009 11:22 AM
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
02-27-2009 12:02 PM
Thanks, I'll give that a shot.
03-03-2009 06:30 AM
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
03-03-2009 06:45 AM
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
https://Internal_ASA_IP/capture/CAPTURE_NAME/pcap
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.
03-03-2009 07:19 AM
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?
03-03-2009 12:00 PM
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?
03-03-2009 12:42 PM
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.
03-03-2009 04:03 PM
Try disabling netbios inspection on the ASA, under the global_policy policy-map.
That said, are DNS requests working at all?
03-04-2009 05:15 AM
DNS is functioning normally in the current environment, yes.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: