In Windows 10, when connected to a VPN with Split Tunneling enabled (Gateway disabled), DNS resolution always uses the LAN DNS servers, ignoring the DNS servers and the DNS Suffix set on the VPN connection.

The expected behavior is to use the VPN's DNS servers, otherwise it becomes impossible to resolve DNS entries on the remote network (such as domain computers).

This was working properly in previous version of Windows.

This was widely discussed on this microsoft answers thread.

  • It's not clear from your question what is your problem (do you want it to use DNS server specified by the VPN?), please edit it. Commented Sep 3, 2015 at 14:05
  • Edited as suggested.
    – CB-Dan
    Commented Sep 3, 2015 at 16:04
  • tbh: Then there is something wrong with your servers. The first DNS request should ALWAYS hit the local servers. Only if the host is unresolvable the system should attempt to query the Remote-DNS. Your issue might be, that local and remote networks are running on the same subnets, thus the local one is claiming "to be able to resolve the query", but delivers "host not found"? (If a Server configured to server the subnet a.b.c.d cannot resolve a host, no further dns-server for this subnet is queried, unless primary is offline, since they SHOULD be in sync - hence it assumes the host is unknown)
    – dognose
    Commented Jun 29, 2016 at 23:22

6 Answers 6


I have fixed this problem permanently by manually setting the metric of my LAN connection to a higher value than the metric of the VPN connection.

This can be done two ways:

  • Through the GUI: Network connections > Properties > double click IPv4 > Advanced > Uncheck Automatic Metric > Enter 15 for interface metric > OK > OK.
  • Command line: netsh int ip set interface interface="LAN CONNECTION NAME" metric=15

The effect is immediate (at least when using the command line) 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 for IPv6 users, you will need to change the metric in your LAN IPv6 properties as well.

Depending on your environment, you may have a different default metric for your VPN connection. Simply adjust your LAN metric to a higher number than your VPN's.

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.

Furthermore, if you find that you cannot edit your VPN's TCP/IP properties because that was also broken in an early Windows 10 build, you can set most properties through Powershell:

1. Get-VpnConnection
2. Set-VpnConnection -Name "myVPN" -SplitTunneling $True
3. Set-VpnConnection -Name "myVPN" -DnsSuffix yourdomain.local

Alternatively, see this answer below for a way to solve this permanently for a given VPN tunnel with PowerShell.

  • 2
    For me this not work... I have two machine with windows 10 , one works all fine other is problematic with VPN. I able to resolve the default gateway enabling the SplitTunneling, but the DNS of VPN still not recognize either when I change the metric...
    – ceinmart
    Commented Oct 28, 2015 at 1:04
  • 4
    This fixed the issue for us (and we've been battling it for some time), with one important additional step -- disabling IPv6. Our VPN does not do IPv6 but my understanding is any IPv6 resolver will take precedent over IPv4 ones. Once we disabled IPv6 on the adapters then adjusted the metrics split-tunnel DNS resumed working. If your VPN supports IPv6 this is likely not needed and if the metric adjustment by itself fixes DNS for you keep IPv6 enabled on your adapter. Commented Jan 30, 2016 at 11:32
  • Fun fact: For me the issue was "vice versa" - When connected to VPN, Windows was unable to resolve local FQDNs... It was setting up the default Metric for the "VPN-Connection" to 1 - so I gave the local connection a lower number which resolved my issue. (My local servers are configured correctly, so any unresolvable name will be queried on the connection of "second preference" - which makes now both: local and remote dns to work as expected while VPN is established.)
    – dognose
    Commented Jun 29, 2016 at 23:13
  • 1
    @ECC-Dan I found a way to script the setting of the metric in a persistent way based on the mentioned MS forum answer.
    – ceztko
    Commented Oct 25, 2021 at 20:29
  • 1
    @CB-Dan you literally save me from a certain job losing. thanks a lot. hope you find what you want in your life :D Commented May 15, 2023 at 20:47

I spun up a fresh install of Windows 10 in a VM to test on after seeing this issue on every physical Win10 machine I have. I tested all of the answers in this thread and none of them worked. I discovered that the solution is to combine the answers posted here by "Keenans" and "ECC-Dan":


Control Panel > Network and Sharing Center > Change adapter settings > Right click your Ethernet or Wifi adapter > Properties > double click IPv4 > Advanced > Uncheck Automatic Metric > Enter 15 for interface metric > OK > OK.

On that same Properties page, double click IPv6 > Advanced > Uncheck Automatic Metric > Enter 15 for interface metric > OK > OK.

Only after changing both of those settings is the issue resolved. I tested changing either one back and it breaks again. After changing both I ran nslookup from command line and it returned the DNS server on the remote network where the VPN is connected to, where as otherwise it would return the local DNS server. I then used Wireshark capturing on the Ethernet interface, did some pings to random websites, and verified that there were no DNS packets captured. This proves that after making the changes, DNS queries are being sent ONLY over the VPN connection, and not simultaneously over all connections (which is known as the Win10 DNS leak). So this is also part of the solution for the Win10 DNS leak:


Note that fix the DNS leak, you first need to do the steps above. Then you need to set two registry values. The linked articles only list one, which by itself, does not fix the issue in newer builds of Win10. Set these registry values:

Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient
Value:  DisableSmartNameResolution
Data:  1

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Value: DisableParallelAandAAAA
Data:  1

Only after doing all of that, will your DNS client behavior be back to the way it was in Win7. You have to wonder how this got through QA at Microsoft.

  • 1
    Note that if you seek a solution via GPO, use the Policies "Turn off smart multi-homed name resolution" and "Turn off smart protocol reordering" under Computer Configuration / Policies / Administrative Templates / Network / DNS Client. Commented Mar 22, 2020 at 16:59
  • You have to wonder how this got through QA at Microsoft - What you're told it's "feature", and not a "bug"!
    – KhoPhi
    Commented Sep 11, 2021 at 23:14

Find out the Network Index:

Get-NetIPInterface | select ifindex,*int*

ifIndex InterfaceAlias              InterfaceIndex InterfaceMetric
------- --------------              -------------- ---------------
     26 vEthernet (Default Switch)              26            5000
     11 VPN - VPN Client                        11              30
      7 Ethernet                                 7              25
      1 Loopback Pseudo-Interface 1              1              75

Mine was the VPN with index 11. Changing the VPN "interfaceMetric" from 30 to 1:

Get-NetIPInterface -InterfaceIndex 11 | Set-NetIPInterface -InterfaceMetric 30

Verifying the change:

Get-NetIPInterface | select ifindex,*int*

ifIndex InterfaceAlias              InterfaceIndex InterfaceMetric
------- --------------              -------------- ---------------
     26 vEthernet (Default Switch)              26            5000
     11 VPN - VPN Client                        11              1
      7 Ethernet                                 7              25
      1 Loopback Pseudo-Interface 1              1              75
  • This answer is useful but setting the metric of the VPN higher than the one of the ethernet is exactly the opposite of what the OP is asking. To have the VPN dns servers to be higher priority than the LAN ones, the VPN metric must be lower than the LAN one. Please, fix the answer and I will upvote.
    – ceztko
    Commented Oct 24, 2021 at 22:31
  • I actually suggested the change to the answer that inverts the 1 <-> 30 metric.
    – ceztko
    Commented Oct 25, 2021 at 7:43
  • 1
    @ceztko Updated Commented Jun 12, 2023 at 16:01

In my case, I found that browsers and pings could not resolve DNS when I was connected to VPN, but nslookups could. This link helped resolve my issue: https://windowsreport.com/nslookup-works-but-ping-fails/

The part that worked for me was running these 5 commands in a command prompt with Administrator rights:

netsh winsock reset catalog
netsh int ip reset reset.log
ipconfig /flushdns
ipconfig /registerdns
route /f
  • 1
    This fixed the problem for me too! Don't forget to reconnect both the internet and VPN after running above commands.
    – Mo Beigi
    Commented Jun 13, 2022 at 7:45

As mentioned by other answers, the solution to the OP question is to set the VPN interface metric lower than the metric of all the regular network interface, with a reasonable default to be 1. This setting can be persisted by accessing the UI:

enter image description here

All the given answer have limited scripting support. @ECC-Dan answer is dependent on finding the network adapter of the system and tweaking the metric value to be higher than the VPN interface. Instead @JoseOrtega answer tweaks the VPN connection with Set-NetIPInterface but that value will be lost at reconnection in case of L2TP/IPSec connections. The issue with such VPN connections is that they are not permanent network interfaces, but they are created on the fly based on a configuration setting that is called the "RASPhone" (the old dialup connection store). VPN connections can be created with powershell cmdlet Add-VpnConnection but that misses a specific option to set the metric of the interface. Until this is not sorted (how to report the missing feature to Microsof?) the solution is manually tweaking the RASphone store which can be found in C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk. This is performed by the following script function, based on this forum post:

function PushVpnConnection(
    Remove-VpnConnection -AllUserConnection -Name $connName -Force 2> $null
    Add-VpnConnection -AllUserConnection -Name $connName -ServerAddress $connUrl `
        -TunnelType L2TP -L2tpPsk $sharedKey -Force -AuthenticationMethod MSChapv2,Chap `
        -SplitTunneling $True -EncryptionLevel 'Optional'

    # Tweak the rasphone to change the IpInterfaceMetric setting to 1
    $rasphonepath = 'C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk'
    $rasphone = Get-Content $rasphonepath -Raw
    $regex = "^([\s\S]*\[${connName}\][\s\S]*IpInterfaceMetric=)(\d+)([\s\S]*)$"
    $match = [Regex]::Match($rasphone, $regex)
    $rasphone = $match.Groups[1].Value + '1' + $match.Groups[3].Value
    $rasphone | Set-Content $rasphonepath

This will create a L2TP/IPSec VPN connection with split tunneling enabled and metric 1. It must be run with administrator privileges. It can be run like the following:

PushVpnConnection 'ConnectionName' 'connectionurl.com' 'presharedkey'
  • Wish I could upvote more than once.
    – xofz
    Commented Oct 25, 2021 at 22:19

It does not work even I changed metrics on both IPv4 and IPv6 and used registry DisableSmartNameResolution and DisableParallelAandAAAA with current Windows 10 Edu (as of December 2018) when the client is connected by UTP cable and IPv6 protocol is supported on the local LAN (ie. client has public/global IPv6 address).

It is sufficient to disable IPv6 protocol on UTP/LAN interface used for VPN to make it work (to remove/not_use global IPv6 address on the client).

It works with no problem when the client is connected to the Internet by Wi-Fi and IPv6 is available (client has global IPv6 address and has no UTP/LAN connection).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .