Windows – Understanding Windows Routing Tables and Default Gateways

gatewayinternetnetworkingroutingwindows

Note:This is my home computer lab and not a business/production environment. I'm more than happy to break it and fix it again, so any suggestions are welcome!

SUMMARY

I've added this quick summary because this question is getting rather long. If you want further details on routing tables, IP configs, etc, look below.

I have a few NICs on a computer. One NIC is 172.16.200.1 / 24. When I try to ping 172.16.200.2 (a host which exists on the network), I get a reply. So far, so good.

When I try to connect to 172.16.200.5 (or any other host which doesn't exist), the computer will fall back to my default route (0.0.0.0 via my default gateway 192.168.0.1) – this will then be sent out by my home router where it then gets lost in a routing loop in my ISPs network. A lot more details are given below if needed, but I'm guessing there's a guru out there who can answer this already…

My question is:

How do I stop my computer falling back to the default gateway for a private network when there is no response from a host on that network. These private networks already have explicit routes with lower metrics.

I have tested this on a few machines (Server 2008 R2, Windows 7, Hyper-V Server 2012 R2, Windows Server 2012) and they all behave the same way. I'm beginning to accept that this is 'normal behaviour' for Windows machines, but I'm curious if it can be stopped.

I've created a Ubuntu VM with the same configuration as my Windows VMs – the Ubuntu VM does not fall back to the default route like the Windows VMs do. I've added the routing tables and results for the Ubuntu VM and Windows 8.1 VM at the bottom of this post.

FURTHER DETAILS

I've done extensive searching on this subject and the closest question I've seen is here: Routing loop: TTL expired in transit, but unfortunately it doesn't answer how to stop the problem or alter the behaviour on the computer. The answer suggests fixing the routing. I can change my router to drop everything destined for private IP addresses (or forward it to my housemates' IPs, hehehe), but that won't change my computer's behaviour. (I've also read the great subnetting guide that was reference in the original answer, which can be found at https://serverfault.com/questions/49765/how-does-ipv4-subnetting-work)

I'm having troubles understanding why my computers will attempt to connect to private IP addresses over the internet once they've tried using their internal adapters (for a short period) then failed – for example, in trying to ping a host that I know doesn't exist on my network…

Pinging 172.16.200.32 with 32 bytes of data:
Reply from 172.16.200.1: Destination host unreachable.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.
Reply from 203.29.XXX.YY: TTL expired in transit.

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

But pinging a host which does exist works…

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

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

OK, so the reply from 172.16.200.1 is my computer saying no response was received… but then, why does it even attempt to connect over my internet connection? I've got 4 NICs and I'm on the 172.16.200.0 / 24 network on one of them…

Ethernet adapter HyperV External (built in):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::582c:97
   IPv4 Address. . . . . . . . . . . : 172.16.1.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Expansion-2 (middle) HomeNetwork:

   Connection-specific DNS Suffix  . : Home
   IPv4 Address. . . . . . . . . . . : 192.168.0.117
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.0.1

Ethernet adapter Expansion-3 (bottom) iSCSI-1 :

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 172.16.100.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter Expansion-1 (top) iSCSI-2:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 172.16.200.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

So, at this point, it'd make sense to look at the routing table…

===========================================================================
Interface List
 16...64 70 02 00 1f 03 ......Gigabit PCI Express Network Adapter #2
 15...64 70 02 00 40 48 ......Gigabit PCI Express Network Adapter
 23...00 24 1d 1d f8 35 ......TST Onboard
 17...64 70 02 00 32 c1 ......Gigabit PCI Express Network Adapter #3
  1...........................Software Loopback Interface 1
 28...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 26...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
 29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.117    410
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       172.16.1.0    255.255.255.0         On-link        172.16.1.1    266
       172.16.1.1  255.255.255.255         On-link        172.16.1.1    261
     172.16.1.255  255.255.255.255         On-link        172.16.1.1    261
     172.16.100.0    255.255.255.0         On-link      172.16.100.1    266
     172.16.100.1  255.255.255.255         On-link      172.16.100.1    266
   172.16.100.255  255.255.255.255         On-link      172.16.100.1    266
     172.16.200.0    255.255.255.0         On-link      172.16.200.1    266
     172.16.200.1  255.255.255.255         On-link      172.16.200.1    266
   172.16.200.255  255.255.255.255         On-link      172.16.200.1    266
      192.168.0.0    255.255.255.0         On-link     192.168.0.117    266
    192.168.0.117  255.255.255.255         On-link     192.168.0.117    266
    192.168.0.255  255.255.255.255         On-link     192.168.0.117    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.0.117    266
        224.0.0.0        240.0.0.0         On-link      172.16.100.1    266
        224.0.0.0        240.0.0.0         On-link      172.16.200.1    266
        224.0.0.0        240.0.0.0         On-link        172.16.1.1    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.0.117    266
  255.255.255.255  255.255.255.255         On-link      172.16.100.1    266
  255.255.255.255  255.255.255.255         On-link      172.16.200.1    266
  255.255.255.255  255.255.255.255         On-link        172.16.1.1    261
===========================================================================
Persistent Routes:
  None

I first thought the 0.0.0.0 route's metric was the culprit – it was originally 6, so I tried changing it to 410 which hasn't changed the behaviour. (By the way, I've never messed with the routing table on this machine before). I then compared it to a Hyper-V 2012 R2 machine I have on 3 of the same networks (172.16.1.0, 172.16.100.0 and 172.16.200.0) and I noticed the Hyper-V machine also has a metric of 6 for the 0.0.0.0 route, so I'm guessing this is normal and correct…

I then tried changing the 172.16.200.0 to be a persistent route, as below, but it still didn't work.

===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
       172.16.200.0  255.255.255.0       172.16.1.1       1
===========================================================================

I also tried to increase the metric (I know lower is more preferred, but just incase, eh?)… of course, no luck.

In the "Advanced Settings" in the Network Connections Window, I've confirmed that the 192.168.0.117 adapter is the lowest in the Adapters and Bindings order…

So, after banging my head about a bit, I'm stumped. Obviously deleting the 0.0.0.0 route stops it, but of course it'll stop my internet too…

How on earth can I stop my machine from trying to go through my default gateway 192.168.0.1 when it attempts to reach a host on 172.16.200.0…

http://technet.microsoft.com/en-us/library/cc779122%28v=ws.10%29.aspx ("The IP Routing table: TCP/IP") seems to suggest that "The default route typically forwards an IP datagram (for which there is no matching or explicit local route) to a default gateway address for a router on the local subnet." How much more explicit can I get with that route!

The answer here Windows persistent route gateway unavailable so default route used suggests that this is normal behaviour – when a persistent route is added, it will try to use that route if possible, but then fall back to the default route when that fails. Surely that could present some pretty serious traffic problems, not to mention security issues (private information leaking out into the internet, or at least your ISPs private networks…)

Some additional info: This server runs NPS/RRAS usually – disabling it, and even removing it didn't do anything. In addition, I created a brand new 2008 R2 VM, gave it two NICs, one directly on the 192.168.0.0 network, and the other on the 172.16.200.0 network and it did the same thing… I hope you can tell I've spent a bit of time on this.

I've set my home router to forward all 172.16.X.X stuff back to my own computer, but that's a workaround…

Is there anything I'm missing? Something obvious, perhaps? Am I asking the impossible?

[UPDATE #1 AND #2]

I've dug through every configuration bit on my router and it doesn't seem to handle any proxy ARP requests – it doesn't even have any settings for it that I can see.

I used MS Network Monitor 3.4 to test whether ARP requests are being answered by the router, and they aren't. I can see the ARP request being sent out when I try to ping a non-existant host and I don't receive any ARP responses. Pinging a host which does exist, naturally gives me an ARP response. Is it safe to assume at this point that my router isn't handling proxy ARP requests?

The routing table on the router WAS as follows:

 > route show
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.20.21.36     *               255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     *               255.255.255.0   U     0      0        0 br0
default         *               0.0.0.0         U     0      0        0 ppp0

I added these entries below as a temporary stop-gap measure – it stops my poor "lost" packets from going to my ISP:

172.16.1.0      192.168.0.117   255.255.255.0   UG    1      0        0 br0
172.16.100.0    192.168.0.117   255.255.255.0   UG    1      0        0 br0
172.16.200.0    192.168.0.117   255.255.255.0   UG    1      0        0 br0

[UPDATE #3 – Added Ubuntu and Win8.1 VMs routing tables]

OK, so I created a brand new Ubuntu VM and a brand new Windows 8.1 VM. The Ubuntu VM doesn't try to fall back to it's 0.0.0.0 route, but the Windows 8.1 does. I tried the old ping-a-non-existant-host and watched the traffic on the 172.16.1.1 router. It receives the ICMP requests from the Windows 8.1 VM and passes them on, but it doesn't ever see any ICMP traffic from the Ubuntu VM.

The Ubuntu VM table is below:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface    MSS   Window irtt
0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 eth0     0     0      0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth1     0     0      0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0     0     0      0
172.16.200.0    0.0.0.0         255.255.255.0   U     1      0        0 eth1     0     0      0

The Windows 8.1 table is below:

===========================================================================
Interface List
  9...00 15 5d 01 4c 1c ......Microsoft Hyper-V Network Adapter #2
  3...00 15 5d 01 4c 08 ......Microsoft Hyper-V Network Adapter
  1...........................Software Loopback Interface 1
  4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.1.1     172.16.1.101      5
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       172.16.1.0    255.255.255.0         On-link      172.16.1.101    261
     172.16.1.101  255.255.255.255         On-link      172.16.1.101    261
     172.16.1.255  255.255.255.255         On-link      172.16.1.101    261
     172.16.200.0    255.255.255.0         On-link      172.16.200.1    261
     172.16.200.1  255.255.255.255         On-link      172.16.200.1    261
   172.16.200.255  255.255.255.255         On-link      172.16.200.1    261
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      172.16.1.101    261
        224.0.0.0        240.0.0.0         On-link      172.16.200.1    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      172.16.1.101    261
  255.255.255.255  255.255.255.255         On-link      172.16.200.1    261
===========================================================================
Persistent Routes:
  None

Best Answer

Failback to default route is normal behaviour since Vista, you can read about this in the following article: Source IP address selection on a Multi-Homed Windows Computer.

Loop issue caused by misconfigured router, which sends packets back using different subnet, instead of dropping them.

Related Question