Windows – On a host with multiple network interfaces, which interface resp. DNS server is used to resolve the hostname of the local machine (Windows)

domain-name-systemnetworkingwindows

I am trying to answer the following question:
What happens if a machine that has multiple network interfaces, gateways, and DNS servers (for example an interface for an Ethernet adapter and one for a VPN connection) tries to communicate with itself, but not via "localhost"; but through its own (local or qualified) host name. Which interface (or rather, which interface's IP address) is going to be used?

Background of the question is that in such a scenario, sometimes the wrong interface (usually, VPN is the "wrong" one) is used, which causes problems with our software if, e.g., the VPN connection is interrupted. For these scenarios, I would like to know how can I influence the name resolution so that the IP of the Ethernet adapter is preferred.

I have played around with changing the metrics of the routes for the different interfaces, but this really didn't give me any clearly observable behavior. One the laptop machine (which is part of an AD) where I did that experiment, the metric for the route to the link-local IP of VPN interface and the route for the Ethernet adapter's IP initially had the same metric, e.g., "route print" would show these two routes (and of course many more):

Active Routes:
Network Destination    Netmask          Gateway     Interface  Metric


      1.2.3.4          255.255.255.255  On-link     1.2.3.4    276 
      2.3.4.5          255.255.255.255  On-link     2.3.4.5    276

Assume that 1.2.3.4 is the IP of the VPN interface, 2.3.4.5 the one for the network adapter.
When I pinged the machine with its local or qualified hostname, it would initially resolve the VPN adapters's IP. So I played around with lowering or increasing the metrics for one or the other interface.
Unfortunately, I didn't get a clearly observable behavior, but what I suddenly did get was errors. If the VPN IP was resolved, ping would fail with an error, and the error message would indicate that the host 2.3.4.5 (the Ethernet IP!) responded with "destination host not reachable":

C:\Users\me>ping myhost

Pinging myhost.my.company.domain [1.2.3.4] with 32 bytes of data:
Reply from 2.3.4.5: Destination host unreachable 

So my guess is that since the VPN IP was resolved, the gateway of the VPN is used, and the VPN of course doesn't know about the other IP.

The next ping would then always resolve the ethernet adapter's IP and would work fine

C:\Users\me>ping myhost

Pinging myhost.my.company.domain [1.2.3.4] with 32 bytes of data:
Reply from 1.2.3.4: bytes=32 time<1ms TTL=128
[...]

This happened even after setting back the metrics to their original (identical) values.
It occurred to me that I was probably on the wrong track with changing the routes to my local IPs, but I should probably change the routes to the DNS servers (or in some other way change DNS server precedence), but at this point I decided to stop experimenting and start reading first, before I mess up my config. Seems my Google foo was bad today, so I ended up posting here.

Any help (or pointers to the right piece of documentation) appreciated.
Changing the hosts file could probably give me what I want, but I would prefer a more portable solution (and most importantly, I would like to understand what is going on!).

Best Answer

In addition to routing metric, Windows has a setting for network connection priority.

To change the connection priority:

  • Network and Sharing Center > Adapter Settings
  • Press Alt and choose from the menu Advanced > Advanced Settings
  • In the Adapter and Bindings tab reorder the preferred connection to the top

Then change the interface metrics, that your preferred route has a lower metric.

  • Ethernet adapter > Properties > TCP/IPv4 > Properties
  • General > Advanced
  • Uncheck Automatic metric
  • Add value for Interface metric

Flush the routing tables, do so by opening a cmd window and enter:

route /f

Then reboot Windows, to be sure the metrics take effect. The routing tables should be rebuilt and metrics assigned to the routes.

At this point, if you still have issues, check your IPv6 metrics.

In the case that an interface reverts to automatic on reboots, you may have to add a persistent route:

route add -p [destination] [mask] [gateway] [metric] if [interface]