Upgrade from PIX to ASA 5510. VPN not working properly

[ewellsie07]

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.

[andrew.prince]

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>

[ewellsie07]

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.

[andrew.prince]

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>

[ewellsie07]

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.

[andrew.prince]

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.

[auraza]

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]

Thanks, I'll give that a shot.

[ewellsie07]

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

[auraza]

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.

[ewellsie07]

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?

[ewellsie07]

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]

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]

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

That said, are DNS requests working at all?

[ewellsie07]

DNS is functioning normally in the current environment, yes.