Windows 10: Remote VPN Client Cannot Resolve Domain DNS

KB ID 0001402


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?


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


Author: PeteLong

Share This Post On


  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!

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

    Post a Reply
  9. Thank you very much!!

    Post a Reply
  10. I found that the latest version of Windows 10 also does this (1909 or 19H2). Once you’ve PINGed an IP address on the remote LAN that doesn’t also exist on the local LAN, it suddenly ‘sees’ the DNS server of the VPN and FQDNs will now resolve.

    Post a Reply
  11. Hi, a bit of a weird one. I can connect to the network over the VPN, can ping, RDP no problem. However when I try to access network drives or a server drive via windows explorer I cannot.

    Any ideas?

    Post a Reply
  12. Hi, a bit of a problem. I can now access majority of resources over always on vpn, however I cannot access shared folders without having to put the domain suffix, so for example dfs namespace doesnt work and the corresponding server without the domain suffix doesnt work either. Any ideas?

    Post a Reply
  13. I seem to have a different problem. Windows 10 assigns 11 to my VPN and 4325 to my local connection but I still can’t ping anything on the remote network by name.

    Post a Reply
  14. I found that this works if you go crazy with the metrics – I kept looking at the routing table and increasing the metric on the physical interface until it worked. Ended up at 500 on the physical and 1 on the virtual. So far it’s worked on everyone that’s tried it.

    Post a Reply
  15. Have you had luck with these metric settings sticking after reboots, re-connections, etc?

    Post a Reply
  16. Hello,

    Thanks for this good info. Today Solved my problem.

    Post a Reply
  17. If you reboot the laptop it goes back to original metric. Is there a way we can permanent metric. In other words when roaming clients reboot their laptop’s metric stays same?

    Post a Reply
  18. Thanks a lot for a thorough explanation!
    It saved my day.

    Post a Reply

Submit a Comment

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