Does anyone have experience with configuring Cisco AnyConnect VPN? We have a problem with client DNS name resolution when connected over VPN.
To me, it looks as if the Cisco AnyConnect VPN client intercepts DNS queries from the clients.
- Can someone confirm that the AnyConnect VPN client in fact does this (intercepts DNS traffic)?
- Where is this configured on the VPN server?
EDIT:
Here's how the routing table changes when I connect to the VPN:
[~]
$ diff -u /tmp/route_normal /tmp/route_vpn
--- /tmp/route_normal 2010-01-20 19:23:47.000000000 +0100
+++ /tmp/route_vpn 2010-01-20 19:24:46.000000000 +0100
@@ -1,6 +1,10 @@
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
+xxx.xxx.xx.xx.i 10.0.0.1 255.255.255.255 UGH 0 0 0 ath0
172.16.53.0 * 255.255.255.0 U 0 0 0 vmnet1
10.0.0.0 * 255.255.255.0 U 0 0 0 ath0
+172.17.20.0 * 255.255.255.0 U 0 0 0 cscotun
0
+192.168.111.0 172.17.20.212 255.255.255.0 UG 0 0 0 cscotun
0
172.16.140.0 * 255.255.255.0 U 0 0 0 vmnet8
+172.16.0.0 172.17.20.212 255.255.0.0 UG 0 0 0 cscotun
0
default 10.0.0.1 0.0.0.0 UG 0 0 0 ath0
EDIT 2:
The IT guy has done "something" on the VPN endpoint. Now I get "recursion not available" when doing nslookup. The DNS servers have recursion enabled. So it must be the Cisco VPN DNS interception messing this up.
ubuntu@domU-12-31-39-00-ED-14:~$ /opt/cisco/vpn/bin/vpn connect xxx.xxxxxx.xx
...
>> Please enter your username and password
...
>> notice: Establishing VPN...
>> state: Connected
>> notice: VPN session established to ...
ubuntu@domU-12-31-39-00-ED-14:~$ nslookup www.vg.no
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
;; Got recursion not available from ..., trying next server
Server: 172.16.0.23
Address: 172.16.0.23#53
** server can't find www.vg.no.compute-1.internal: REFUSED
ubuntu@domU-12-31-39-00-ED-14:~$ ping 195.88.55.16
PING 195.88.55.16 (195.88.55.16) 56(84) bytes of data.
64 bytes from 195.88.55.16: icmp_seq=1 ttl=240 time=110 ms
64 bytes from 195.88.55.16: icmp_seq=2 ttl=240 time=111 ms
64 bytes from 195.88.55.16: icmp_seq=3 ttl=240 time=109 ms
^C
--- 195.88.55.16 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 109.953/110.379/111.075/0.496 ms
As mentioned in a comment, figure out your split-tunneling (routing) first. The endpoint (Concentrator, ASA, PIX, etc.) admin usually has full control of how the client will handle this; some companies will only tunnel their network (so your client's DNS would go over the ISP) and some require tunneling all traffic over the link (so DNS would go over the link to corporate). It's a business/IT decision most of the time.
Peak at the routing table on the client and see what the gateways and such look like and where the traffic is being routed in their specific instance to provide the beginning point for your debugging. You might then try direct DNS queries from the client against a public resource (i.e. Google's new DNS thing) to see what the results are, while using TCPview (if your client is Windows) type software to watch the bits fly around.
Check what apparent source IP address is being used when your DNS requests hit the internal DNS server.
It's probable that the server has been configured to only provide recursive service for requests that arrive from known internal IP addresses, and to otherwise only offer authoritative service for certain domain names that are hosted on the same server.
If your DNS requests appear to be coming from an off-net IP address then they'll only get authoritative answers, and no recursive ones.