Home / server / Questions / 1162735
Accepted
Martin
Asked: 2024-07-19 00:36:08 +0800 CST

Windows Server strange routing behaviour

  • 772

I have a virtual machine running Windows Server 2019, which is a terminal server with many network interfaces. It is actually a trunk, which is being configured for many vlan interfaces, leading to this many interfaces - but this shouldn't matter to my question. Now, coming to the strange part:

PS C:\Users\XXXX> netstat -n | findstr "192.168.4.80:445"
  TCP    10.0.200.90:49531      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49532      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49533      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49534      192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49528     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49529     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49530     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:55959     192.168.4.80:445       ESTABLISHED

Both interfaces in question here are configured with a /24 netmask - and the 10.0.200.90/24 interface holds the default gateway. The routing table is quite large, as there are many interfaces, but there is no conflicting route for the 192.168.4.0/24 subnet. Here are the relevant parts of it:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.0.200.250      10.0.200.90    271
       10.0.200.0    255.255.255.0         On-link       10.0.200.90    271
      10.0.200.90  255.255.255.255         On-link       10.0.200.90    271
     10.0.200.255  255.255.255.255         On-link       10.0.200.90    271
      192.168.4.0    255.255.255.0         On-link      192.168.4.90    271
     192.168.4.90  255.255.255.255         On-link      192.168.4.90    271
    192.168.4.255  255.255.255.255         On-link      192.168.4.90    271
===========================================================================

How is it possible that some connections are being sent via the default gateway, and some connections take the proper interface route? I noticed this on the firewall (the default gateway), inside the packet filter logging, so this is not just a display issue, some packets really are being sent over the default gateway - And I checked via the resource monitor, the connections belong to PID 4 (System), which is most likely the mapped network drives.

For all what I know about routing, the metric is only taken into account if there are two routes with the same subnet - in such a case, the route with the lower metric would win. But the default gateway route should never win over a interface route, no matter what metric is configured - correct?

My first thought was that this must be a bug inside windows - maybe a race condition between the process bringing the interface up and the process mapping the network drive. But this is pure speculation, I was hoping someone could enlighten me with a deeper insight...

networking

1 Answers

  1. Best Answer

    How is it possible that some connections are being sent via the default gateway, and some connections take the proper interface route?

    That totally depends on the connection. Connections can be valued in terms of link speed, hop count, or time delay. "Automatic Metric" is a new feature in Windows that automatically configures the metric for the local routes that are based on link speed.

    The Automatic Metric feature is enabled by default, and it can also be manually configured to assign a specific metric.

    Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 15

    For all what I know about routing, the metric is only taken into account if there are two routes with the same subnet

    In Windows Server 2016 and Windows 10, you can use the interface metric to configure the order of network interfaces.

    This is different from previous Windows Servers, which allowed you to configure the binding order of network adapters by using either the user interface or the commands INetCfgComponentBindings::MoveBefore (and [...]::MoveAfter). This is no longer the case (from Server 2016 on).

    Instead, you can (read "have to") configure the interface metric by using Set-NetIPInterface.

    When network traffic routes are chosen, the overall metric is used to determine the interface preference - which is the sum of the route metric and the interface metric. Typically, the interface metric gives preference to a particular interface, such as using wired if both wired and wireless are available.

    My first thought was that this must be a bug inside windows

    While this is totally possible, bugs in the well-hung microsoft IP-Stack are extremely rare these days. Think about it: in a systems that has to be deterministic under all circumstances (think of hyper-v) such a condition would be catastrophic from day one.

    • 2