Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Synopsis

I can ping and see the http config page on my cable modem at its fixed address of 192.168.100.1 from computers on the local network behind my Linux internet gateway. That gateway is the default route for machines on the network. netstat does not indicate any route to 192.168.*, but the gateway must be routing packets to 192.168.100.1 because I can reach the modem at that address from machines behind the gateway and from the gateway itself.

How does the gateway know to send those packets to the internet interface instead of saying that the network is unreachable? Is there some way to monitor/view/control other routes set up like this?

I'm using Shorewall to configure firewall rules by interface. Could hosts on the internet segment spoof other private addresses and cause internal packets to be routed outside? I'm thinking no since the rules are specified by interface, but I don't understand the mechanism here.

Details

  • ISP<=>Modem<=>Gateway<=>Lan switch
  • ISP is Comcast
  • Modem is a Motorola SB6121
  • Gatway is a Ubuntu 12.04.1 (precise) with stock kernel 3.2.0-29-generic #46-Ubuntu SMP x86_64
  • Gateway provides firewall, NAT and VPN services
  • traceroute does not indicate any hops between the gateway and the modem at 192.168.100.1.
  • The gateway does not have an address on 192.168.*
  • ip neighbor show also does not indiciate a route to any 192.168.*

netstat -rn output:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         71.205.176.1    0.0.0.0         UG        0 0          0 eth1
10.88.8.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.88.9.0       0.0.0.0         255.255.255.0   U         0 0          0 eth3
10.88.10.0      10.88.10.2      255.255.255.128 UG        0 0          0 tun0
10.88.10.2      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.88.10.128    10.88.10.130    255.255.255.128 UG        0 0          0 tun1
10.88.10.130    0.0.0.0         255.255.255.255 UH        0 0          0 tun1
71.205.176.0    0.0.0.0         255.255.252.0   U         0 0          0 eth1
  • The default gateway is provided by the ISP.
  • eth1 is connected to the modem's ethernet jack.
  • eth0 10.88.8.0/24 is the wired network.
  • eth1 10.88.9.0/24 is the wireless network.
  • tun0,tun1 10.88.10.0/24 covers the OpenVPN TUN clients. It looks odd, but that setup is required to support Windows TUN clients. I have two to support both UDP and TCP.
share|improve this question

2 Answers 2

up vote 4 down vote accepted

You have a default route, so anything not specified in the routing table goes to the default route.

share|improve this answer
    
Yes, I know. Are you saying the ISP's default route for reaching Internet hosts somehow knows to direct 192.168.100.1 back to my own cable modem, and without appearing as a routing hop? How would that work for a neighbor with their own modem also at 192.168.100.1? 192.168/16 is a private subnet that shouldn't be routable from the Internet. –  Chris Smith Sep 18 '12 at 18:39
    
It's not the ISP's default route, it's your default route. –  Michael Hampton Sep 18 '12 at 18:43
    
My default route goes to the ISP's router at 71.205.176.1. Where does 192.168 enter into it? –  Chris Smith Sep 18 '12 at 18:48
1  
Ok, so the modem is intercepting the packets even though they are being directed at the default gateway at 71.205.176.1? Wouldn't the linux box be addressing the 192.168.100.1 frames through the default gateway's hardware address, not the cable modem's hardware address? I only see an entry in ip neighbor for the ISP gateway, not the modem. –  Chris Smith Sep 18 '12 at 19:04
2  
The cable modem is a router in his own right, by pinging the public IP you're merely pinging one interface of the device (the WAN). The modem can tell what you're trying to do and tries to save resources by letting the interface closest to you answer in place of the one you pinged. This is the default behaviour on many cisco routers. –  ItsGC Oct 5 '12 at 21:02

To follow up on Michael's answer:

There are also hosts out there on the internet that appear to be answering pings for RFC1918 addresses. This isn't really supposed to be happening.

I briefly had one of my VPN routers (inadvertently) not set to blackhole the 192.168/16 networks that we weren't using. The traceroutes that were coming back from those hosts were somewhere in the US Midwest and were successfully routing ICMP Ping responses back to my network.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.