I can ping and see the http config page on my cable modem at its fixed address of 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 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.


  • 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
  • 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         UG        0 0          0 eth1   U         0 0          0 eth0   U         0 0          0 eth3 UG        0 0          0 tun0 UH        0 0          0 tun0 UG        0 0          0 tun1 UH        0 0          0 tun1   U         0 0          0 eth1
  • The default gateway is provided by the ISP.
  • eth1 is connected to the modem's ethernet jack.
  • eth0 is the wired network.
  • eth1 is the wireless network.
  • tun0,tun1 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.

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

  • Yes, I know. Are you saying the ISP's default route for reaching Internet hosts somehow knows to direct 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/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 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 Wouldn't the linux box be addressing the 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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