Win 10: DNS resolution of remote network via VPN connection not working

Hello,

when you created a new VPN connection with Windows 7, 8 and 8.1 and connected it you was abel to resolve DNS names of the remote network.

With Windows 10 this does not work anymore.

I compared the VPN connection/adapter settings of both Win 8.1 and Win 10, they looks equal.

Also the status page of the connected VPN connection lists the remote DNS servers.

I could no compare the IPv4 and IPv6 settings due this problem:

http://answers.microsoft.com/thread/211c9745-f07b-4910-b94a-ba636cfe63f7

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

You sir are correct, I had not tried that.  I just tested it and it works, while allowing IPv6 to continue to function.  I just updated my post.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Thank you ECC-Dan.

Changing the metric to 15 for TCP/IP v4 && v6 works. After ipconfig /flushdns, nslookup is pointing to the remote DNS server (it is DHCP scope setting for VPN clients) as opposed to local DNS server. So, from the angle of nslookup, it works ... 

Additionally, I discovered another messy area on W10 is the Edge browser. I have a simple web page on the remote network for testing purpose. Edge DOES NOT work when I tried to open www.mydomain.local (it works in W7/8/8.1. I have to open it in IE !!

Nice to share my troubleshooting experience here.

Ben

I have fixed this problem permanently by manually setting the metric of my LAN connection to be higher (15) than the one windows assigns to my VPN (11).

This can be done two ways: 

  • Through the GUI: Network connections, Properties, TCP/IP v4 Properties, Advanced, Set Metric to 15;
  • Command line: netsh int ip set interface interface="LAN CONNECTION NAME" metric=15

The effect is immediate and DNS lookups now go through my VPN as expected.

This works with Split Tunneling and is a permanent fix across reconnections and reboots.

Note that you could also change the metric of the VPN instead of the LAN connection, but this wouldn't be permanent as Windows resets the metric when the connection is established.

Depending on your environment, you may have a different default metric for your LAN and VPN connection. Simply adjust accordingly so that your VPN has a lower metric than your LAN connection.

I've cross-posted the answer to this problem on SuperUser: http://superuser.com/questions/966832/windows-10-dns-resolution-via-vpn-connection-not-working

3 people were helped by this reply

·

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Set the DNS suffix of the VPN connection to the of the remote network. In my case it was "lan". dc.office.lan is my domain controller. End of story.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Set the DNS suffix of the VPN connection to the of the remote network. In my case it was "lan". dc.office.lan is my domain controller. End of story.

If you had actually read the thread you would have understood that what you have done does not apply to the situations here and does not help. Kindly do not drive by and take a blind shot at this problem.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I have not seen that solution. It helped me. Can`t say more.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Same problem as all of you guys. And as a early adopter of Win10 we kept running into this. problem (see the TL:DR belowfor a quick write-up of our fix.)

We noticed early that the issue stemmed from the fact that the client refuses to access the DNS on the VPN so we rolled out a dirty fix.

We created a script that added the VPN dns to the local network adapter and remove it when the VPN disconnected. Suffice to say it did not work very well, and caused some problems with clients not being able to access the internet due to incorrectly closing their systems. (Rule number 1: even if the fix works, expect users to find a way to break it...)

Fix number 2 is the one we are using now and it has worked without giving our developers and normal users any problems.

We noticed that the VPN worked correctly over wireless and gave problems on a wired connection. (From the top of my head) This was due to the fact that the metric value of the VPN was always lower then those of the Wireless connection. On the wire this was different, the wired connection like ECC-Dan noted, contained a lower metric then the IPv4 one. Not a problem as the VPN would adjust this. But when the VPN connected only the IPv4 one changed in terms of metrics. The IPv6 is still lower then the VPN connection and somehow they decided to use the IPv6 metric to decide the interface for the IPv4 traffic...

We then set the following registry key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"DisableSmartNameResolution"=dword:00000001

This fixed our corporate network name resolution. Recources that require people to go to the internet also worked so everything seemed fine.

But some of our resources are resolvable from the internet, and due to the fact that IPv6 metric throws all lookups at the local DNS server as well.

Changing the IPv6 metric fixes everything like ECC-Dan stated. but we did not want to change stuff like that as this would require us to change all metrics from all possible adapters ourselves.

Disabling IPv6 on the interface fixed this problem as well.

TL:DR

3 domains:

Contoso.com (Corporate)

Corp.contoso.com (Internal zone containing all our resources, cant access zone from internet)

Contoso.com (External zone, accessible from the internet.)

Fabricam.com (Development)

Corp.fabricam.com (Both internal and external zone, Zone is accessible from internet and contains a wildcard causing everything to be resolvable)

adatum.corp (development)

Adatum.corp (Internal zone, cant access zone from internet)

Fixing our DNS resolvement for corp.contoso.com and Adatum.corp

Registry edit: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"DisableSmartNameResolution"=dword:00000001

Fix can be deployed without user having admin rights by deploying it through GPO Preference

Fixing Fabricam.com

Disable IPv6 (ECC-DAN fix also works) Both fixes require Administrative rights.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I am using Private Internet Access (PIA) on Windows 10 and was having the exact same issue described here. My DNS lookups were taking a long time and actually failing when using nslookup. Setting the metric value of the physical network interface, for both IPv4 and IPv6, to a value higher than that of the TAP interface resolved the issue for me.

Thank you, Keenans and ECC-Dan.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

I am having issue with this. Specifying these Metrics do not have an effect on Windows 10 for me. Even after a reboot. What does seem to work for me is specifying a static route. The issue I have is setting a persistent route could be a problem for me as I am on a lot of networks and do not ALWAYS want to route from (for Example 192.168.2.X to my VPN 10.0.2.X). 

So the solution I have found is to set a persitsent Static Route but ONLY on the specific VPN interface. I cannot seem to find the interface of the VPN. When I view the route, I see the metrics listed in route print, but whenever I specify that static route on one of those metrics, it never works. I MUST specify the static route WITHOUT the Interface. Perhaps I am getting the interface wrong? IS there a way to find the Virtual Interface of my VPN connection?

Thanks

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

This worked for me. Changed the TCP/IP v4 Properties on my LAN connection.  I also changed to Metric to 11 on my VPN connection (which doesn't seem to get reset when connection is established)

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Hi,

thanks for this post. I searched for the solution for at least 10 ours. With your help I've managed to find out (by comparing with my other norebook's setting) that HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\ServerPriorityTimeLimit was missing. I've set it up: [REG_DWORD 0]

Its solved my DNS options for good.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

 
 

Question Info


Last updated August 12, 2020 Views 156,274 Applies to: