VPN Connection causes DNS to use wrong DNS server
Solution 1:
OK, found a great resource here: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/
It's not perfect, but just might work.
The binding order is stored in the registry in the following location:
HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. The list includes all the device GUIDs for network adapters and active connections in the binding priority order.When working with the registry key, the following facts emerge:
Changing the order of the GUIDs in the registry does impact the binding order, including for VPN connections
- Any changes to the key take effect immediately
- When a VPN connection is completed, the GUID for the connection is added to the top of the bind order if it does not already exist
- When a VPN connection is closed, the GUID entry for the connection is removed
- If there are multiple GUID entries for the connection, only one is removed when the connection is closed
This mechanism creates the possibility of the following workaround:
- Examine the Bind registry key
- Connect to your VPN connection
- Check the Bind key again and copy the GUID that was added to the top of the list
- Paste the GUID entry at the bottom of the list 20 times
- Export the key and clean up the exported file to only include the bind key
The result is a key that will support the desired behavior. Every time a VPN connection is established, since the GUID is present, it will not be added. Since the GUID is at the bottom, DNS resolution will be done locally to the client. When the connection is disconnected, one GUID entry will be removed. After 20 VPN connections, the exported registry file can be used to reimport the key.
Of course, you can paste the GUID more times to reduce how often you have to reimport the key.
Also important to remember to redo this procedure if there are any changes to network adapters.
Solution 2:
It seems to me that the VPN tunnel somehow takes precedence over the local area interface directing DNS traffic to the VPN DNS servers (you could check the request on these servers to verify this behavior if you have access to them or someone can verify this behavior for you).
That I cannot, entirely, explain since the binding order indicates differently. According to this post here (see the higher scoring answer) Windows has a different perception when it comes to this, choosing a higher priority channel depending on the speed of the connection NOT on the adapter binding order. So for testing's sake try the following to change this automatic behavior: 1) go to Network connections and for each one do 2) IP v4 properties 3) Advanced 4) Disable "Automatic Metric" 5) Manually put a metric of 1 for your local connection and a metric of 2 on your VPN connection (PPP). That way it will sort of hard wire the path to the local DNS servers as preferred over the remote DNS.
Hope this helps!
Solution 3:
As stated, this is a split tunneling issue.
Three fixes, recommend #2 because it is easy and will have good performance if using a good box with VMware Workstation 8
1 - Enable split tunneling - insecure and may require work on the client's side. Not likely to happen, IT security gestapo going to shut you down.
2 - Virtualized desktop approach - P2V your existing desktop and turn it into a VM. Use the VM to VPN to the client. You keep your desktop, and can switch into it and out of it as needed.
3 - Virtualized server approach - P2V your existing desktop and turn it into a VM, then put it on a free version of ESXi. You keep your desktop, and can switch to the VM as needed via a console. This may be slow...
Solution 4:
Unfortunately, Windows VPN is not able to do "Split-DNS". You can however remove the DNS Server from the VPN connection after you have connected to the remote site.
You can do this by issuing:
netsh interface ipv4 delete dnsservers name="name of the VPN" address=all validate=no
You HAVE to do this every time you connect to the VPN Network.
Solution 5:
Your VPN tunnel is between the client and the client network. Sounds like it isn't using split tunnelling, which will stop you accessing resources on your own network while the tunnel is up.
So you (or your client) need to enable split tunneling, or you need an extra network connection and customised route table to access both networks at the same time.