Windows 10 uses wrong NIC to reach certain IP addresses

Question

I have two servers running Windows 10 Enterprise 2016 LTSB that seem to be using the wrong NICs.

The network consists of 2 subnets. So each server has one NIC on the "main" network with Internet access, 10.1.10.0/24. Then each server has another NIC on the "IoT" network with no Internet, 192.168.2.0/24. The NICs on the main network use DHCP; the NICs on the IoT network use static IP addresses. The IoT subnet is sort of makeshift. The router doesn't "know" about it. I just set the IoT devices and the IoT NICs to use a different IP scheme, but all of that subnet is in the same switch as the rest of the network.

Naturally, I supposed that if I pinged devices on the IoT network, Windows would use NIC that is directly connected. But it isn't always. For certain IP addresses, Windows will use the IoT NIC, for others Windows will use the main NIC. (I verified which NIC was being used through WireShark, but for the record, every ping goes through when I use ping -S [address of the IoT NIC].)

C:\Users\***>ping 192.168.2.102

Pinging 192.168.2.102 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.2.102:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\***>ping -S 192.168.2.10 192.168.2.102

Pinging 192.168.2.102 from 192.168.2.10 with 32 bytes of data:
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.2.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

What's really strange is that Windows doesn't use the same NIC to talk to every IoT IP address. Every time the server gets restarted, it's almost like it blindly draws to decide which NIC it will use to talk to each address, and it will continue to use that NIC for that address until the next time the server is restarted.

The routing table is below. Remember, 192.168.2.0 is the IoT network, 10.1.10.0 is the main network.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.1.10.1      10.1.10.117     11
        10.1.10.0    255.255.255.0         On-link       10.1.10.117    257
      10.1.10.117  255.255.255.255         On-link       10.1.10.117    257
      10.1.10.255  255.255.255.255         On-link       10.1.10.117    257
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      169.254.0.0    255.255.255.0         On-link       169.254.0.2    266
      169.254.0.2  255.255.255.255         On-link       169.254.0.2    266
    169.254.0.255  255.255.255.255         On-link       169.254.0.2    266
      192.168.2.0    255.255.255.0         On-link      192.168.2.10    266
     192.168.2.10  255.255.255.255         On-link      192.168.2.10    266
    192.168.2.255  255.255.255.255         On-link      192.168.2.10    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       10.1.10.117    257
        224.0.0.0        240.0.0.0         On-link       169.254.0.2    266
        224.0.0.0        240.0.0.0         On-link      192.168.2.10    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       10.1.10.117    257
  255.255.255.255  255.255.255.255         On-link       169.254.0.2    266
  255.255.255.255  255.255.255.255         On-link      192.168.2.10    266

Here are a few things I've looked at so far:

None of these so far has presented an answer. I tried disabling SMB MultiPath, but that had no effect, even after restarting the servers. Changing metrics didn't appear to do anything, either.

At this point, my best guess is that Windows is doing some load-balancing behind the scenes to send traffic out the wrong NIC. But why would it do that if the route to 192.168.2.0/24 clearly goes through the one interface? To be clear, the router connected to the main NIC does not have a route for 192.168.2.0/24.

Why does Windows choose the wrong NIC and how do I fix it?

(Out of curiosity: why two "servers" are running Windows 10?) — Massimo, Mar 30 '20 at 20:11
@Massimo The physical topology has been changed around a lot since I asked this, so the error can't even occur anymore. I really wish I could have figured it out what was causing the issue at the time because it was so weird. Should I delete this question or do you think somebody will go "Aha, I bet that's a bug that was fixed in update KB12345"? — Andrew Myers, Mar 30 '20 at 21:06
@Massimo The servers are NVRs from [Seneca Data](https://www.senecadata.com/industry-solutions/surveillance/network-video-recorders/). That's the way the build them. Now if you want to know about licensing... I haven't a clue. — Andrew Myers, Mar 30 '20 at 21:10
I don't really have any clue about the possible cause of the issue, the network config and routing table seemed to be ok; that's why I asked for more details. I'd however tend to exclude such a serious bug in the networking stack, much more likely something was wrong and nobody figured out exactly what. — Massimo, Mar 30 '20 at 21:22

score 0 · Answer 1 · answered Apr 29 '22 at 02:23

I've seen this behaviour too. In my case, if 192.168.2.102 doesn't exist (no arp response), windows should say 'Destination host unreachable' or 'Request timed out' (not sure which is more correct). Instead, it sends a ping request via the gateway in the other interface. I'd love to know if the IP addresses that are incorrect in the case of the poster appear in the output of 'arp -a'.

In some networks this might matter a bit more than others; for example, now data inside packets which should be internal (your IoT LAN) is available to any packet captures running external (your "main" LAN). This might include secrets, and with SNMP v2 it will. I don't think older versions of windows will do this, it's basically ignoring the manual routing config and trying the default gateway anyway.

Even when I added: route add 192.168.2.102 mask 255.255.255.255 192.168.2.10 metric 1 The darn thing still sends packets out the wrong interface.

I hope I've added some value for someone. I'm at the point where I do get a single 'destination unreachable' from the correct interface, then windows "helps" by using the other one instead at that point.

This does not provide an answer to the question. Once you have sufficient [reputation](https://serverfault.com/help/whats-reputation) you will be able to [comment on any post](https://serverfault.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/late-answers/519300) — Dave M, Apr 29 '22 at 16:56

Windows 10 uses wrong NIC to reach certain IP addresses

Why does Windows choose the wrong NIC and how do I fix it?

1 Answers1