Routing issue for windows with multiple NICs

I have a routing issue on a windows box. The windows box has three NIC's with ip's:

1. 10.87.6.27 (no gateway set)
2. 10.87.11.27 (no gateway set)
3. 10.87.60.51 (gateway = 10.87.60.254)

When I contact a host in 10.87.11.0/24 (for example 10.87.11.212) the windows machine sends the traffic to 10.87.60.254, which routes it to 10.87.11.212. Because the windows box has a NIC directly in 10.87.11.0/24 (i.e. 10.87.11.27), i want it to send the traffic directly to that host instead of going over 10.87.60.254.

I changed the metric on the routing table. From inspecting the routing table I would expect the windows box to send the traffic directly to 10.87.11.212. What am I overlooking here?

The "route print" command gives the following output: Output route print

The "tracert" command gives the following: Output trace route

Solution 1:

This will get a bit technical and dry, sorry.

This is because of the host model design in modern operating systems. Which you can change, but should only carefully consider. More on that later.

What?

A "host model" is a way of designing the internals of a TCP/IP stack. For example, when a unicast packet arrives at a host, the IP(-Stack) must determine at first, whether the packet is locally destined. If the IP stack is implemented with a weak host model, it accepts any locally destined packets, regardless of the network interface on which the packet was received.

But if the IP stack is implemented with a strong host model, it only accepts packets if the destination address in the packet matches an IP address assigned to the NIC on which the packet was received. Which is technically more correct.

Why?

The weak host model provides (naturally speaking) a "better" network connectivity. For example, its very easy to find packets arriving at the host or easy to send packets to locally bound networks. But it also makes hosts very susceptible to multihome-based network attacks.

In many configurations when a system is running the weak host model and it is connecting to a VPN, other systems on the same subnet are able to compromise the security of the VPN connection. IP-Stacks running the strong host model are immune by design to this type of attack.

Okay ... but ...

The IP (v4) implementation in Windows prior to Vista uses the weak host model. The good old days. The Vista and 2008 TCP/IP stacks defaults where changed to the strong host model for both IPv4 and IPv6. More on how to go back in time later.

The IPv4 implementation in Linux defaults to the weak host model. Personal note: As of my understanding, this is mostly because of backwards compatibility stuff and a "when you need more security, just enable it" philosophy (some distos enable the strong model by default, too).

Source validation by reversed path is specified in RFC 1812 and arp_ignore and arp_announce can be used to tweak the kernels behaviour.

But ... seperation!!

What a interesting time to write about seperation and why this is a good idea for network packets - as they are all created equal. Back in the days it was, and still is, a perfectly good idea to seperate management- from prod traffic. The problem with weak host models is, that anybody on the same segment could potentially benefit from your (mostly) loose management traffic security rules.

So today much more thinking goes into seperating it "right" (HOST traffic vs GUEST traffic) or traffic roles (BBMC vs OS traffic) and - most of all - strong and secure authentication.

Disable all the good stuff!!1

The weak host model can be disabled through the command line:

netsh interface ipv4 set interface [INDEX] weakhostsend=enabled

netsh interface ipv4 set interface [INDEX] weakhostreceive=enabled