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
Advanced
>Advanced Settings
Adapter and Bindings
tab reorder the preferred connection to the topThen change the interface metrics, that your preferred route has a lower metric.
Ethernet adapter
>Properties
>TCP/IPv4
>Properties
General
>Advanced
Automatic metric
Interface metric
Flush the routing tables, do so by opening a
cmd
window and enter: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: