22

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.

Improve this question
8
  • 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, 2012 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, 2012 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, 2012 at 16:36
  • Could you please add a route print (from the vpn-connection) to the post?
    – Florian Neumann
    Jun 20, 2012 at 21:59
  • There's nothing wrong with routing, as he is able to connect trough IP, but not trough DNS
    – MichelZ
    Jun 21, 2012 at 7:04

10 Answers 10

Reset to default
12
+150

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:

  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.

Improve this answer
3
  • 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, 2012 at 7:04
  • 3
    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, 2013 at 11:06
  • In my situation JVM and only JVM was picking a wrong DNS server that was received by DHCP for local connection. It's impossible to delete via netsh but only via registry: This answer helped in my situation superuser.com/questions/392269/…
    – Puterdo Borato
    Aug 6, 2020 at 20:10
6

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!

Improve this answer
5
  • 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, 2012 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, 2012 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, 2012 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, 2012 at 20:21
  • 1
    It did the trick for me! The metrix in the IPv4 settings for the NIC doesn't seem to have anything to do with the metrix in the routing table! Changing the GUID order in HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind as ZnArK wrote about didn't change anything in regards to which NIC/DNS is used. This is tested on Windows 10
    – MrCalvin
    Jan 31, 2017 at 0:14
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.

Improve this answer
11
  • 1
    FYI... this stops you from using the Remote (VPN) DNS.
    – MichelZ
    Jun 20, 2012 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, 2012 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, 2012 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, 2012 at 15:21
  • 1
    Bryan - Cool! Would you mind trying my solution again and checking with ipconfig /all ? It 100% worked here :)
    – MichelZ
    Jun 21, 2012 at 15:48
4

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

Improve this answer
1
  • +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, 2012 at 7:26
2

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.

Improve this answer
2
  • 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, 2012 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, 2012 at 15:52
0

Though this question was asked long back but posting this answer as this may help others. I had the same issue with VPN where when users used to connect to remote vpn their external dns used to stop for eg. google.com only company domains used to work which were listed on split-dns.

Problem was when local machine used do dns query traffic goes to vpn tunnel and if the dns is permitted in tunnel it falls-back. When it fallback it then used to pick ipv6 as resolution first and then never return to ipv4.

So to test the results we first disabled the ipv6 on local machine it started working. To permanently fix it for all users we enabled client-bypass-protocol command on ASA firewall which ignored IPv6 if its not configured on vpn pools.

so if you can't control the firewall and know the split tunnel and split dns are in place yet it is failing you can try disabling ipv6 on local machine and if you can control it then you can enable above command as long as you dont use ipv6 in your remote network.

This has helped me, hope this helps others :)

Improve this answer
0

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

Improve this answer
0

I simply remove this option from the client VPN config

setenv opt block-outside-dns

It resolved the issue

Improve this answer
0

I had this problem few years ago and fixed by editing VPN connection file just make a vpn.pbk file (you can find it in google )open that file via text editor like notepad and change UseRasCredentials value to zero and you problem is solved. but the only issue is you local area connections DNS priority become higher than VPN DNS and name resolution take more time (if VPN is used to connect to internet).

Improve this answer
-1

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.

Improve this answer
6
  • 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, 2012 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.
    – Ben Lessani
    Jun 21, 2012 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, 2012 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, 2012 at 14:42
  • 1
    your interpretation of this is incorrect. The IP address is assigned by the PPTP server, which doesn't actually use DHCP. The PPTP server has a pool that it can allocate from, but this is not DHCP. I do get a different IP each time I connect however. Furthermore, I have not ticked the box to use the remote gateway either, as you can clearly see from the routing table.
    – Bryan
    Jun 21, 2012 at 16:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .