1

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.

  1. Can someone confirm that the AnyConnect VPN client in fact does this (intercepts DNS traffic)?
  2. 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
3
  • What are you using for your VPN endpoint? ASA? Pix?
    – GregD
    Jan 20, 2010 at 18:08
  • Is your client set up for split-tunneling?
    – GregD
    Jan 20, 2010 at 18:09
  • I am on the end-user side of the table here, I am working with the IT department to test the VPN setup. I know the endpoint is ASA. As for split-tunneling, how do I check that? Would it show up in my client's routing table?
    – codeape
    Jan 20, 2010 at 18:23

2 Answers 2

0

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.

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .