Windows 10: Remote VPN Client Cannot Resolve Domain DNS

KB ID 0001402

Problem

I’ve been setting up a VPN solution on the test bench as I’m looking at Always On VPN. When I noticed that I had a problem with my remote VPN connections on Windows 10. They would connect fine but I could not resolve any FQDNs for my domain?

Solution

By default, all (Windows) VPN connections are ‘Force Tunnel’ (this means they have the option ‘Use default gateway on remote network’ selected). This also means that, (unless your RAS server is the default Gateway for your network,) you usually don’t have internet access when connected to the VPN. 

Now I connected fine, and I could ping IP addresses on my corporate network, but I could not ping my servers by their domain name, in fact Windows was trying to resolve my domain name to a public IP?

Google this problem and you’re simply told to ‘Disable IPv6 on your network card, and this works, (if you want to keep your remote users Force-Tunnelled). But disabling IPv6 is hardly a fix is it?

Also If you want internet access for your remote clients, (Commonly referred to as ‘Split Tunnel’), then even with IPv6 disabled, the problem comes back!

Why is this happening? Well even with Force Tunnel enabled, you can still use your local LAN (Connect to your VPN, and ping your home gateway, or printer or wireless access point if you don’t believe me!) This connection takes precedence over your remote VPN connection, to prove it run a netstat -rn command. 

Windows Connection metrics

From the above you can see my Ethernet Adaptor has a metric of 6, and my VPN connector, (in this case called Connection Template) has metric of 23. AND THE LOWEST ONE WINS, so your DNS queries are going out of your local internet connection NOT down the VPN tunnel!

How Do I Fix this?

Well until Microsoft fixes this in Windows 10, (it’s fine on Windows 8 and earlier), you have to manipulate the metrics yourself, like so;

On Your Physical Adapter;

Start > ncpa.cpl {enter}  > Right click your NIC > Properties > Internet Protocol Version 4 > Properties.

Physical NIC Properties

Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 20 > OK > OK >OK.

Physical NIC Metric

On Your VPN Connector;

Start > ncpa.cpl {enter}  > Right click your VPN Connector > Properties > Internet Protocol Version 4 > Properties.

VPN Connection IPv4

Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 10 > OK > OK >OK. 

VPN Connection Metric

Now your DNS look-ups should behave!

Related Articles, References, Credits, or External Links

NA

Author: PeteLong

Share This Post On

10 Comments

  1. Hi Pete,

    Good info, still not fixed on 1803 (not sure which you tested on).

    Weirdest thing is that the bug is resolved in our case just by only setting the metric from Automatic to 10. Wifi adapter and local NIC still have higher priority (2 and 7). Could it be that DNS requires a metric of a specific weight to consider it viable route?

    Post a Reply
  2. Pete,
    This worked!! Thank you!! We had some static costs set (by a previous tech) in the 4000’s but the VPN interface was set to ‘automatic’. We set VPN interface to 10 and then went into the other interfaces and set to ‘automatic’ and she works!! We’ve been fighting this particular issue w/ this particular user for months…I hate computers. 😉

    Thanks for the help and especially the feedback from Yannick.

    Merry Christmas, amigos!
    KG

    Post a Reply
  3. Had this issue and found your post. Thanks, you saved my day! I sent the link to our IT guy.

    Post a Reply
  4. The Interface List in the ‘netstat -nr’ output does not specify the metric for the interface. If you look at the route entries in the netstat output, the metric for each route is at the end of that line.

    This didn’t work for me. The metric for my VPN connection is set to 1, but the Windows application still sends the DNS request through the physical interface to the VPN client’s address. The VPN client is passing the request on and getting a response back, but it does not get passed back to the application.

    Post a Reply
    • any help on pats comment, mine is the same and still not working. SONIC WALL VPM

      Post a Reply
  5. A life saver as always. We set the metric on the vpn and all is good. Our exact issue was that name resolution for our domain members were successful (ie. serverx.mydomain.local). However resources where the records were hosted on our internal dns servers under a different name (ie publicname.company.com) did not resolve successfully. Also setting the metric only on the vpn adapter is probably working because using a value of 10 is lower than the value windows 10 sets automatically on the Ethernet adapter. A useful powershell command for this

    get-netipinterface -ConnectionState Connected -addressFamily ipv4 | select InterfaceAlias, InterfaceMetric, addressFamily

    Post a Reply
  6. This worked for me. So maddening, I could see that the IP on my servers was an external one, not an internal, but could not understand why. And some servers were okay and others were not.

    Post a Reply
  7. Worked flawlessly! Thank you so much.

    Post a Reply
  8. Thanks . WORKS like CHAAAAAARRRRRRMMMMMM

    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *