This article explores practical routing strategies, focusing on metrics to prioritize routes/interfaces, whether on Windows or Linux. This situation typically arises when you are on a business trip or at school and do not “master” the network to which you are connected.
Imagine that you are currently connected to a network (Network 1) that limits your connection to the Internet using URL filters and a proxy.
To get around these restrictions, you have created tethering with your phone, thus establishing a Wi-Fi connection to a second network (Network 2). Now, you are connected to both networks simultaneously, with the wired network as the primary connection (Network 1) and WiFi as the secondary connection (Network 2).
However, Internet traffic is not routed correctly to the correct network interface due to the configuration of your primary network interface (Network 1). This prevents you from accessing specific sites. Unfortunately, you cannot disconnect from any of the networks, as this will disrupt your activities.
The goal is to maintain a connection to both networks, allowing you to access your internal resources while having unrestricted Internet connectivity.
It’s not a bad word, but depending on your current activity, you might not have used this term since your suitable old networking classes (hello devs). As a reminder, the metric is a convenient way to prioritize different routes and control the path network traffic should take when faced with multiple options. This can be particularly useful in advanced configurations where multiple network interfaces are used, and it is necessary to determine how traffic should be routed.
Lower Metric = Higher Priority: A route with a lower metric is considered better. For example, a route with a metric of 5 would be preferred to a route with a metric of 10. Default Routes: When you define a default route (a route used for all traffic that does not match any other route), you can specify a metric. This means the system will choose the one with the lowest metric if you have multiple default routes.
OK, so whether it’s on Linux or Windows, it should work the same? Well no! Otherwise, it would be too simple… I will detail this point in the section of this article dedicated to Windows.
In each of the cases presented below, I am connected to the same two networks each time:
Network 1: 192.168.1.0/24 – Home sweet home Network 2: 192.168.157.0/26 – Tethering
A. For Linux
First, you should list the default routes currently active on your system. Remember this: One default route per network IP route | grep default # or the actual “command” IP route shows default. In my case, I have two default routes: one route for each of my networks.
I will check my egress IP address concerning traffic going out on the default route (the one with a lower metric: 192.168.1.1 and therefore preempts the second default route).
curl -4 icanhazip.com
Now that I’ve seen that the public IPv4 is .117, I will make the necessary changes to allow my second default route (default via 192.168.51.157…) to be prioritized. To do this, I will first delete this default route:
sudois necessary to modify a route on Linux due to security concerns, as this temporarily grants admins privileges, ensuring that only authorized users can make system changes that affect connectivity and data routing.
sudo ip route del default via 192.168.51.157 dev wlx7cc2c613b1c0 proto dhcp metric 601
Then add it again, but this time with a lower metric. Here, the metric will be 400. The number doesn’t matter as long as it is less than the metric of the predominant default route.
sudo ip route add default via 192.168.51.157 dev wlx7cc2c613b1c0 proto dhcp metric 400
After performing this operation, check whether the settings have been considered.
ip route | grep default
To ensure that “outgoing” network traffic to the Internet has been redirected, you can again:
- Use tracepath, to verify that the first gateway has changed from when the command was first executed
- Check if your public IP address has been changed
tracepath -4 -b t.co curl -4 icanhazip.com
B. For Windows
Variations in managing route and interface metrics between Windows and Linux can be explained by the disparities inherent in the network management specific to each operating system.
On Linux, a route’s metric specifies the route’s priority over other routes for a given destination. Adjusting the route metric affects all routes associated with that destination, regardless of the interface. Linux treats each route independently of the interface. It doesn’t care about the interface; it prefers to look only at its routing table.
In contrast, the route metric (RouteMetric) and interface metric (IfMetric) play distinct roles in selecting the default route on Windows. The route metric affects the priority of routes to a given destination, while the interface metric influences the selection of the interface to reach that destination. Even if a default route with a lower metric is detected on a network interface “2”, it is still the network interface “1” that is prioritized if and only if its metric is strictly lower than the metric of network interface “2”.
I prefer the Linux approach, although the Windows design allows finer-grained and more specific management by adjusting the interface metric and the default route metric. This provides additional flexibility to prioritize the destination and the particular interface (physical communication channel) to reach that destination.
So, we start by listing the default routes like this:
Get-NetRoute -DestinationPrefix 0.0.0.0/0
As with Linux, the need to be a local administrator to modify the routing table on Windows arises from security considerations. The actions below will be performed in a privileged PowerShell terminal for convenience, although some commands like Get-NetRoute do not require such privileges.
Currently, we see with the tracert command (equivalent to traceroute/tracepath on Linux) that traffic is routed via interface “4” (ifIndex) using the following gateway: 192.168.1.1
tracert -4 t.co
I will initially lower the default route metric to confirm my words. I’m going to set this value to 30.
Set-NetRoute -DestinationPrefix 0.0.0.0/0 -RouteMetric 30 -InterfaceIndex 26 Get-NetRoute -DestinationPrefix 0.0.0.0/0
Notwithstanding the changes, our default route is still not prioritized because the interface “4” metric is always higher.
Alright. It is therefore necessary to change the metric of network interface “26”.
Set-NetIPInterface -InterfaceIndex 26 -InterfaceMetric 25 Get-NetRoute -DestinationPrefix 0.0.0.0/0
By performing a tracert again, I noticed that this time, I no longer go through the gateway 192.168.1.1 of my network interface “4” but through the gateway 192.168.51.157 of my network interface labeled “26”!
You will notice I had an internet outage during the tracert. Hence, the 6 “Waiting time exceeded” messages.
I hope you enjoyed this article! With all this explanation, no more excuses to put off this task. You are ready to manage the routing of your default routes without fear of disrupting the connectivity of your network. You will, therefore, be able to continue working in a “controlled” environment while freely browsing the internet to conduct your various searches.