Michael Hanney

Here’s a little problem for which I could not find an elegant solution. I found a solution, but it’s hacky and I don’t particularly like it.

In my Windows Server 2003 virtual machine I have one ‘physical’ network adapter, and one Sonic Wall virtual network adapter for VPN. (I say physical because the whole machine is virtual. The physical adapter in this case is a VMware network adapter in NAT mode). I think this problem would be the same if the machine was physical.

The ‘physical’ adapter is configured to get its IP address, default gateway and DNS server addresses from the DHCP server on my home LAN.

The virtual Sonic Wall VPN adapter is configured to get its IP address, default gateway and DNS server addresses from the DHCP server on the intranet side of the office LAN.

The metric for the virtual adapter is set higher (40) than the physical adapter (30) so when both network adapters are ‘up’ Windows considers the VPN to be more ‘expensive’ when deciding which adapter to use to route my regular internet requests, unless the host I’m requesting is in the range of the addresses on the VPN intranet. Normal web page requests go through my LAN router and office traffic goes through the VPN. This is fine. Almost exactly what I want, except I want to use my office’s intranet DNS servers when my VPN adapter is up, and I don’t want to route all my TCP/IP traffic through the office intranet.

Our intranet DNS server is not a real Internet host. It resolves internal development machine names only; I cannot use Internet DNS servers to resolve names inside our intranet.

I tried setting the nameserver manually on the VPN adapter to the address of the office DNS server, and I could see it would resolve our intranet names if I used nslookup <machine.client.mycompany.domain> <the address of the intranet nameserver on my intranet VPN>.

The problem is that Windows does not know to use the VPN adapter’s DNS server to resolve hostnames ending with mycompany.domain - hosts on the VPN. Its a chicken and egg situation, almost - once the name is resolved to an IP address, and the IP address is in the range of the VPN network, then the routing is all fine. But how would Windows networking know to use the VPN adapter if the host name hasn’t been resolved yet?

My solution was to manually set the primary nameserver IP address on the ‘physical’ network adapter to the IP address of the office intranet DNS server on the VPN, and the secondary nameserver IP address to the IP address of my LAN gateway. (This is why workers who use laptops in the office have not had a problem using the intranet DNS when working remotely over VPN - because their primary network adapter still has the intranet DNS as the primary nameserver.)

When the VPN is up, host names and get resolved using the intranet DNS server on the VPN LAN. When the VPN is down, the primary DNS appears to be unreachable and Windows falls back on the secondary DNS. That’s the part I don’t like - knowing that the primary DNS server address - the intranet DNS server - is unreachable when I am NOT on VPN.

This entry was posted on Sunday, March 30th, 2008 at 21:48 and is filed under TCP/IP, VMware.You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.