The issue is the routing design, not just NIC priority.
Windows decides whether traffic is local or remote by comparing the destination IP with the local IP and subnet mask. For hosts on the same subnet, traffic is sent directly on-link and does not need a gateway. For remote networks, traffic is sent to a default gateway.
In this setup, 192.168.1.x/24 traffic should stay on the 192.168.1.x NIC and should not be routed through 192.168.1.1 as a gateway. The route on the desktop:
192.168.1.0 255.255.255.0 192.168.1.1 192.168.1.3
is wrong for a directly connected subnet. That subnet should be on-link through the 192.168.1.x interface, not via the router.
Also, having two default routes:
-
0.0.0.0 -> 192.168.1.1 -
0.0.0.0 -> 192.168.0.254
causes Windows to prefer the lower-metric default route for non-local traffic. That affects which NIC is chosen for replies and can make the behavior look inconsistent.
Use this configuration instead:
- On the
192.168.0.xNIC only, keep the default gateway192.168.0.254for Internet access. - On the
192.168.1.xNIC, remove the default gateway. - Do not add a route for
192.168.1.0/24through192.168.1.1. Since that subnet is directly attached, Windows should use the on-link route automatically. - Verify both machines have a direct route like this for the local NIC:
192.168.1.0 255.255.255.0 On-link 192.168.1.x - If a wrong persistent route was added, delete it and recheck with
route print.
Expected result:
- Access to local devices on
192.168.1.0/24uses the 1 Gb NIC directly. - Internet traffic uses the 10 Gb NIC through
192.168.0.254. - Replies to
192.168.1.xpeers should come from the192.168.1.xaddress, not the192.168.0.xaddress.
One more important point: Windows behavior with multiple adapters can be unexpected, especially when routing is nonstandard. Microsoft also notes that multiple adapters do not provide load balancing by themselves, and routing table order determines which adapter is used.
References: