Windows 10 VPN DNS resolution fails with split tunneling due to interface metric priority
On Windows 10 VPN clients with split tunneling enabled, DNS queries are routed to the LAN DNS servers instead of the VPN-assigned DNS servers, breaking name resolution for internal/remote hosts. Windows automatic interface metric assignment gives the LAN adapter a lower (preferred) metric than the VPN adapter; resolution is to set the LAN interface metric higher than the VPN's so DNS queries prefer the VPN interface.
Indicators
- Cannot resolve internal/domain hostnames over VPN (e.g. nslookup returns NXDOMAIN or external IPs)
- nslookup shows queries going to the local LAN DNS server, not the VPN-assigned DNS
- DNS suffix configured on the VPN connection is ignored
- Domain resources (file shares, intranet, DCs) unreachable by name but reachable by IP
- Issue only occurs when 'Use default gateway on remote network' is unchecked (split tunneling)
- Same VPN profile worked correctly on earlier Windows versions
Likely causes
- Windows 10 automatic interface metric gives the physical LAN/Wi-Fi adapter a lower (more preferred) metric than the VPN adapter
- DNS resolver prefers the interface with the lowest metric, sending queries to LAN DNS servers
- Split tunneling removes the default-gateway override that previously forced traffic and DNS via the VPN
- VPN interface metric is reset by Windows on each reconnect, so changes to the VPN side do not persist
Diagnostic steps
-
Confirm split tunneling is enabled: VPN adapter properties > IPv4 > Advanced > 'Use default gateway on remote network' is unchecked.
-
Run 'Get-NetIPInterface' (PowerShell) or 'route print' and compare InterfaceMetric values for the LAN/Wi-Fi adapter and the VPN adapter while connected.
-
Run 'nslookup <internal-hostname>' and confirm the Server line shows the LAN DNS server rather than the VPN-assigned DNS.
-
Run 'Get-VpnConnection -Name <vpn>' to verify DnsSuffix and any configured DNS servers on the VPN profile are correct.
-
Temporarily raise the LAN interface metric above the VPN metric and retest DNS resolution to confirm root cause.
Resolution path
- Open ncpa.cpl on the affected client and open the LAN/Wi-Fi adapter Properties.
- Select Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced, uncheck 'Automatic metric', and set Interface metric to a value higher than the VPN's metric (e.g. 15).
- Alternatively, from elevated CMD run: netsh int ip set interface interface="<LAN connection name>" metric=15
- Repeat the metric change on the IPv6 properties of the LAN adapter if IPv6 is in use.
- Ensure the VPN profile has the correct DNS suffix: Set-VpnConnection -Name "<VPN>" -DnsSuffix yourdomain.local -SplitTunneling $True
- Disconnect and reconnect the VPN, then verify with 'nslookup <internal-host>' that queries now use the VPN DNS server and resolve correctly.
Prevention
- Standardise a static, higher LAN interface metric (e.g. 15) on devices that regularly use split-tunnel VPNs
- Modify the LAN adapter metric (persistent) rather than the VPN metric, which Windows resets on each reconnect
- Apply the metric change to both IPv4 and IPv6 to avoid protocol-specific resolution issues
- Document interface-metric configuration as a standard step in the VPN client build/onboarding procedure
- Where possible, deploy the VPN profile via PowerShell or Intune with DnsSuffix and SplitTunneling values defined explicitly
Tools
- PowerShell (Get-NetIPInterface, Set-NetIPInterface, Get-VpnConnection, Set-VpnConnection)
- netsh
- Network Connections control panel (ncpa.cpl)
- nslookup
- route print