Windows Remote VPN no DNS

VPN no 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. They would connect fine but I could not resolve any FQDNs for my domain?

VPN no DNS 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. 

VPN no DNS

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 VPN no DNS?

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;

VPN no DNS 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

27 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
  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?
    Thanks
    Nas

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

    Post a Reply
  19. Hi Pete

    Great article that pointed me in the right direction,

    For my situation I had all VPN users in the company with this problem if they were wired into their home router!

    In my particular situation (Always on VPN, but would apply to other types of VPN created through Windows built in VPN functionality) I found you can use a Group Policy INI File setting to edit the “%appdata%\microsoft\network\connections\Pbk\rasphone.pbk” file and set the option “IpInterfaceMetric” to 10 which will fix the issue in a more automated manner, the only real issue I can see is that all your users will need to be using a VPN Connection with the same name (As the INI file setting uses the section name to locate where it needs to edit) but in our case that was fine as our AOVPN is deployed using a script with the same name for all users

    Hope this helps someone

    Post a Reply
  20. Hi all,
    We have the same problem but the metric of the VPN card is on 1 and that of the wifi or ethernet are in automatic.
    We always have the IP records of the home routers in the DNS as well as that of the VPN connection and the stations respond randomly on one or the other.
    Do you have any other solutions to explore knowing that we will be turning off IPV6 as well?

    thank you for your feedback

    Regards

    Post a Reply
  21. doh, I think what your doing is sending all traffic over the VPN, which includes DNS. The proper solution, with split tunnel, would be to just send DNS queries, for select domains to your internal DNS.

    To do this: running this from elevated power shell. Put in your own domain and DNS servers.

    Add-DnsClientNrptRule -namespace “.my.internal.domain” -NameServers “01.02.03.04”

    I use it to route azure database traffic via on prem, so it goes via the Express Route and whitelisted IP’s

    Add-DnsClientNrptRule -namespace “.database.windows.net” -NameServers “01.02.03.04”

    Post a Reply
    • nice idea with the NRPT, but does not work in my case:

      i set a DNS search list with “Set-VpnConnectionTriggerDnsConfiguration -DnsSuffixSearchList @(“dom1.com”, “dom2,com”)”
      when doing a “ping hostin1” it resolves fine to hostin1.dom1.com, but “ping hostin2” fails, no resolution to hostin2.dom2.com. more precise: dom1.com is also the DnsSuffix of the connection and that is the reason it works for dom1. the search list is completely ignored.

      i noticed running “Get-DnsClient” that the “SearchList” is empty for the vpn, maybe that is a problem? how could i fill it with powershell? i don’t see a way to set it with set-dnsclient for a specific connection.

      When applying the vpn interface metric the problem is solved, though. the search list works.

      i checked with tracert and in browser which external IP i am using, the traffic does not seem to be routed through the VPN.

      Post a Reply
  22. since making this change, when I don’t go though my VPN (and not even logged into the VPN), I get errors of couldn’t find DNS. Is there a way to fix this, or should I just redo the settings back to what they were???

    Post a Reply

Leave a Reply to Michael Martin Cancel reply

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