Home / server / Questions / 356115
Accepted
Bryan
Asked: 2012-02-03 02:31:31 +0800 CST

VPN Connection causes DNS to use wrong DNS server

  • 772

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.

vpn domain-name-system active-directory windows-7

10 Answers

  1. Best Answer

    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.

    • 12

  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!

    • 6

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

    • 4

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

    • 4

  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.

    • 2

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

    • 0

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

    • 0

  8. I simply remove this option from the client VPN config

    setenv opt block-outside-dns

    It resolved the issue

    • 0

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

    • 0

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

    • -1