Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

enter image description here

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.

share|improve this question
    
You never mentioned which firewall you're using? That's a pretty important factor IMO, as I think that's where you're going to potentially find the answer to this question. –  Hanny Jun 20 '12 at 13:14
    
@hanny the firewall is provided by network address translation on the ADSL modems at both sites. I can probably supply model numbers if really needed, but they will just be bog standard ADSL NATing modems. Given that we are talking about AD with integrated DNS, I don't consider these devices to be relevant, as the issues are purely DNS. –  Bryan Jun 20 '12 at 14:30
    
If the VPN is not being handled by the firewall but Windows then that presents a different sent of parameters to work within, as Windows VPN is fairly limited in my experience. For example with a ASA 5505 - split tunneling is something really easy to troubleshoot and there is a good deal of configuration that can be done, especially with regards to DNS issues and assigning DNS. That was why I asked, thank you for clarifying. –  Hanny Jun 20 '12 at 16:36
    
Could you please add a route print (from the vpn-connection) to the post? –  florianb Jun 20 '12 at 21:59
    
There's nothing wrong with routing, as he is able to connect trough IP, but not trough DNS –  MichelZ Jun 21 '12 at 7:04

7 Answers 7

up vote 5 down vote accepted
+150

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:

  1. Examine the Bind registry key
  2. Connect to your VPN connection
  3. Check the Bind key again and copy the GUID that was added to the top of the list
  4. Paste the GUID entry at the bottom of the list 20 times
  5. 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.

share|improve this answer
    
Good find. That works very well, coupled with a computer start up script to reset the value of the registry key each boot, that should be a great workaround to what shouldn't be a problem in the first place. Many thanks. I'll give that some further testing. –  Bryan Jun 26 '12 at 7:04
1  
I'd recommend to create a scheduled task. Monitor the event ID 20226, which correspond to the VPN disconnect event. Then fire a small powershell script (powershell -File c:\scripts\fixdnsbind.ps1) that contains: $val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind; $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}"; Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind. (don't forget to adapt the adapter ID). You also run this script once before connecting to the VPN. –  Steve B Aug 12 '13 at 11:06

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...

share|improve this answer
1  
I agree with @Brennan –  Fergus Jun 24 '12 at 3:19
    
+1; I like the idea of having a dedicated virtualised system for the task, however I don't see that working well here at this point in time for various reasons. This will definitely be a good solution in the future though. Thanks. –  Bryan Jun 26 '12 at 7:26

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.

share|improve this answer
    
For info, I can access network resources whilst the tunnel is up, it's just DNS resolution that seems to break. I wasn't familiar with the term split tunnelling to be honest, but as far as I can tell, that just involves ensuring that I'm not using the default gateway at the remote site, which despite me not specifying, I am already doing. Thanks for the response, I'll edit my question to reflect this. –  Bryan Feb 2 '12 at 13:06
1  
In that case, it sounds like the customer's VPN is not set up for split DNS. With split DNS, the VPN concentrator gives your VPN client a list of DNS servers (as it currently does), and also a list of domains that are the only domains that should be used with those DNS servers; all others would use your system's default DNS. –  James Sneeringer Jun 21 '12 at 15:52

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.

share|improve this answer
    
FYI... this stops you from using the Remote (VPN) DNS. –  MichelZ Jun 20 '12 at 13:13
    
The problem is, as soon as the tunnel is up, I'm already suffering from the problem desscribed in my question, so the command will be too late. Also, having experimented with this, the command doesn't actually appear to make any difference (nslookup still uses the remote DNS server, plus ipconfig still lists the remote DNS server). I've also edited the DNS settings for the VPN tunnel connection to use my own internal DNS settings, but this is ignored, all my DNS traffic still appears to be heading to the remote DNS server. –  Bryan Jun 20 '12 at 14:45
1  
I had tried this as i had the same problem, and it worked here. Have you adjusted the "name of the VPN"? Additionally, if you are mostly concerned about this one server where your drives are connected to, add it in your hosts file, and nothing will be able to override it –  MichelZ Jun 20 '12 at 15:01
    
Thanks, I did try changing the name (cut and paste from the ipconfig output, and when I got it wrong, I got the error The filename, directory name, or volume label syntax is incorrect), so I'm pretty sure I got the command right. It might be something on the remote PPTP server not allowing me to override the DNS setting. I'll investigate, but I do like the hosts file entry idea. I'll give that a go to. Also see my edit to the question. –  Bryan Jun 20 '12 at 15:21
    
I just tried the command again, and it did remove the DNS Server from the PPP connection. Could you verify with ipconfig /all? I think however the hosts entry should be the easiest fix for this for you. –  MichelZ Jun 20 '12 at 15:29

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!

share|improve this answer
    
Interesting, looking at my routing table above, the metric on the LAN interface is the lowest (20), the VPN connection has a metric of 21. Having said that, this problem can be somewhat intermittent, and with the routing table as displayed above, everything is currently working correctly. I'll try and recreate the problem and re-check the routing table. –  Bryan Jun 21 '12 at 15:27
    
Update, just reopened the tunnel, and all my connections to drives have dropped, but the routing table is no different to above. i.e. Metric 20 for LAN, Metric 21 for VPN. –  Bryan Jun 21 '12 at 15:32
1  
@Bryan, this Microsoft article (support.microsoft.com/kb/299540), sort of, verifies what I said above. It would be interesting to see what happens if you go through the procedure I wrote above when you have time. Others have reported the exact intermittent problems you see and solved it by hard-wiring the metrics (serverfault.com/questions/70792/…). Unfortunately I currently do not have a similar setup to do some tests. –  ank Jun 22 '12 at 15:09
    
Many thanks for that @ank, I'll certainly give it a go later next week when I'm back in the office. Interesting article BTW. Thanks. –  Bryan Jun 22 '12 at 20:21

Why do you think its DNS?

If you lose access to your network shares when you connect to the VPN - it seems almost certainly like your machine is having difficulty with WINS/NETBIOS.

Define a WINS server and test again.

share|improve this answer
    
I don't know for certain that this is the cause of my problems, but what I do know is that AD clients should be using the DNS servers that are used to host AD, and this is not the case. As the problem only surfaces when I make a VPN connection, and my DNS resolution goes screwy at the same time, it seems like DNS is the likely candidate. Regardless, I don't want to use the remote DNS server when I connect to another network using VPN. –  Bryan Jun 21 '12 at 7:18
    
Did you define a WINS server as per my suggestion? It isn't typical of Windows to use the DNS server on a VPN unless use one is defined or "Use remote gateway is set", which you said is disabled. Also you are using a static IP on the VPN tunnel, so why have you set DNS entries at all? Remove those DNS servers (192.168.0.16-17) or set a WINS server. –  MageStackDay Needs You ... Jun 21 '12 at 7:31
    
No, I haven't tried that as we don't have a WINS server to point the clients to. I'm not convinced WINS will help to be honest, so I'm not keen on installing a WINS server on our network because it might help. I'll certainly bear the idea in mind though, so thanks. The IP is assigned by the VPN server and is dynamic. If I don't assign a DNS server for the VPN connection, it is dynamically assigned by the server. I've even hard coded my own DNS servers in the VPN connection properties, yet it still uses the DNS servers at the remote site. –  Bryan Jun 21 '12 at 14:35
    
I don't need nor want to use the remote DNS server, ever, I always want DNS resolution to be performed on the local server, this will fix my problem, hence my question focusing on DNS. I could probably use a firewall rule to block access to the remote DNS server, but this doesn't fix the underlying misconfiguration problem. –  Bryan Jun 21 '12 at 14:42
    
@Bryan - well, the information you provided isn't accurate then. For the PPP adapter DHCP Enabled. . . . . . . . . . . : No - yet you are saying DHCP is enabled? How do you expect anyone to help fix your issue if you are providing conflicting information. By default - Windows will not use remote DNS servers unless you have ticked the box to use the remote gateway or put the adapter higher in the binding order. –  MageStackDay Needs You ... Jun 21 '12 at 16:04

Yay something I have experience with!

Set the VPN connection with the local DNS server and connect to the VPN used nslookup to query the VPN domain name. You should get a response with an IP that is local to the VPN LAN. This means you used the VPN DNS servers to resolve the query.

Now open your LAN connection and manually set the DNS to your local or ISP DNS. an Volia!!! use the arrow key and repeat the nslookup query. You will receive a public IP meaning you used your local/ISP DNS server to resolve the query of the VPN domain. Bam!!!!

I'll upload a vid for confirmation. Tomorrow lol Too late tonight lol. Email me graham.fraser@2nditeration.ca

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.