Connection via Cisco VPN Client stops local DNS resolution

If you use the Cisco VPN Client with Windows XP, you may have noticed that all of your DNS requests go via the VPN, rather than the local network. You can test which DNS server you are using through the use of the NSLOOKUP command. The Cisco VPN Client creates a disabled Local Area Connection, to which it assigns null values until connected. When you connect using the client this connection profile becomes enabled and is set with the appropriate DNS, WINS, gateway and IP address from the other end of the VPN, usually by a DHCP server. By default when you install the client the priority of the Cisco VPN connection is higher than the default local connection assigned to your ethernet NIC or wireless card and it is this that causes two major problems for users:

  1. You cannot connect to local named servers, but you can access them by IP. The only common workaround suggested for this (see Google Groups) is to manually add them to your HOSTS file. This is not a solution that you could widely roll out to a network of users, and is a dirty hack.
  2. Your DNS resolution is SLOW. This is because your request has to go to the DNS server at the other end of the VPN, before being returned to you locally, whereby it sends you out over your local LAN to the internet as normal via your broadband router.

To test which DNS server you are using by default when connected normally, first disconnect from the VPN client and pop open a command window:

  • Start -> Run -> type “cmd”
  • type “nslookup”.

You’ll see something along the lines of:

Type “exit” and then open up your Cisco VPN Client, connect via VPN, and repeat the NSLOOKUP command. You’ll see the change to your default DNS server:

Now all DNS requests will go through the VPN, and not your local router. Slow and pointless (security caveats aside). Why does the Cisco VPN Client change this, and can we alter it at the client level? We don’t really want to bother our over worked Cisco technician back in the office, and often he’s an expensive contract resource anyway.

Most importantly why does the Cisco VPN Client connection always seem to have a higher priority than the standard local ethernet connection or wireless connection under Windows XP? My initial thought was that Cisco designed it to be this way, and there was no way to change it, but now I believe that the simple answer is one of installation order. Hence, as the connections are installed, the last one to be installed seems to be given the highest priority. Someone more knowledgeable with XP networking might be able to clarify this.
Whether or not this is true or not, the fix is to change the priority of the connections. A bit of digging around gives you some advanced settings to network connections:

  • Start -> Control Panel -> Network Connections
  • Then under the menu option Advanced -> Advanced Settings
  • Change the priority of your default local connection, to be above that of the Cisco VPN Client. The Cisco VPN Client often installs for most people as “Local Area Connection 2”.

Now try the NSLOOKUP command again. You’ll see something along the lines of:

You’re back to using your local DNS server, but still connected to the VPN. Problem solved. Nice! You should now be able to see your local servers inside your LAN by name, plus general browsing should be faster.
Some caveats:

  1. There may be security considerations to allowing DNS requests via the local LAN rather than the VPN. DNS works so that it rolls down the list of DNS servers, so the local LAN will ask the world for an internal DNS name first. That could give information away in terms of your local private LAN set up.
  2. I’m using an up-to-date-patched version of Windows XP Professional SP2
  3. I’m using the Cisco Client 4.0.4. Newer versions have given me grief.
  4. In the properties of the VPN profile in question (Cisco VPN Client -> Connection Entry -> Modify) the Transport tab has the option “Allow Locale LAN Access” checked.
  5. This may also be a solution for other VPN clients, but I haven’t tried it.