VPN Connection causes DNS to use wrong DNS server
I have a Windows 7 PC on our company network (which is a member of our Active Directory). Everything works fine until I open a VPN connection to a customer's site.
When I do connect, I lose network access to shares on the network, including directories such as 'Application Data' that we have a folder redirection policy for. As you can imagine, this makes working on the PC very difficult, as desktop shortcuts stop working, software stops working properly due to having 'Application Data' pulled from under it.
Our network is routed (10.58.5.0/24), with other local subnets existing within the scope of 10.58.0.0/16. The remote network is on 192.168.0.0/24.
I've tracked the issue down to being DNS related. As soon as I open the VPN tunnel, all my DNS traffic goes via the remote network, which explains the loss of local resources, but my question is, how can I force local DNS queries to go to our local DNS servers rather than our customers?
The output of ipconfig /all when not connected to the VPN is below:
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
This is the output of the same command with the VPN tunnel connected:
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : mydomain.local
PPP adapter Customer Domain:
Connection-specific DNS Suffix . : customerdomain.com
Description . . . . . . . . . . . : CustomerDomain
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.0.16
192.168.0.17
Primary WINS Server . . . . . . . : 192.168.0.17
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
Default Gateway . . . . . . . . . : 10.58.5.1
DHCP Server . . . . . . . . . . . : 10.58.3.32
DHCPv6 IAID . . . . . . . . . . . : 250629538
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA
DNS Servers . . . . . . . . . . . : 10.58.3.32
10.58.3.33
NetBIOS over Tcpip. . . . . . . . : Enabled
Routing table
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.58.5.1 10.58.5.89 20
10.58.5.0 255.255.255.0 On-link 10.58.5.89 276
10.58.5.89 255.255.255.255 On-link 10.58.5.89 276
10.58.5.255 255.255.255.255 On-link 10.58.5.89 276
91.194.153.42 255.255.255.255 10.58.5.1 10.58.5.89 21
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 192.168.0.95 192.168.0.85 21
192.168.0.85 255.255.255.255 On-link 192.168.0.85 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 10.58.5.89 276
224.0.0.0 240.0.0.0 On-link 192.168.0.85 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 10.58.5.89 276
255.255.255.255 255.255.255.255 On-link 192.168.0.85 276
The binding order for the interfaces is as follows:
I've not configured the VPN tunnel to use the default gateway at the remote end, and network comms to nodes on both networks are fine. (i.e. I can ping any node on our network or the remote network).
I've modified the PPTP connection properties to use the DNS servers 10.58.3.32 followed by 192.168.0.16, yet the query still goes to 192.168.0.16.
Edit:
The local resources that disappear are hosted on domain DFS roots, which might (or might not) be relevant.
Further Edit:
This only seems to be affecting domain DFS roots. If I reference the share via the server name (i.e. \\server\share instead of \\dfsroot\share), I can access the shares.
As per my comment against this answer, I've found I can add the DNS name of the domain to my hosts file which stops my (DFS) network drives from disappearing, but I'd still like the bold part of my question (above) answering if anyone has any ideas.
Solution 1:
OK, found a great resource here
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.