The first node that `tracert` reports is not on my LAN

My laptop is connected directly to the ethernet cable that comes from my ISP, which mandates me to have a static IP on the 10.192.20.1/255.255.252.0 network. When I run tracert, I expect the first node to belong to that network. However, it does not.

$ ipconfig | grep -i -e subnet -e gateway
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.192.20.1
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

(it's Cygwin on Windows; please, ignore the second network)

$ tracert 8.8.8.8 | head -5

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1     3 ms     5 ms     2 ms  172.31.254.38

I am pretty sure that I did see 10.192.20.1 as the first node in the tracert output before, but somehow it is no longer the case.

Could it be that my ISP's router is answering with its "external" IP instead of "internal" for some reason? Or maybe, is that router now configured to simply ignore the TTL and just pass the packets through? I cannot seem to find a definitive answer anywhere as to what is going on exactly (if it is possible to figure that out at all). Thanks.

Konstantin.V

Posted 2016-08-25T12:37:29.257

Reputation: 21

What does a traceroute to another IP shows? – Doezer – 2016-08-25T12:54:26.453

Any other? Trace-routing any public IP's that I've tried (for instance, the one that google.com resolves to) gives the same 1-st node. – Konstantin.V – 2016-08-25T13:37:04.210

Trace-routing my gateway 10.192.20.1 returns exactly it, right on the first hop. – Konstantin.V – 2016-08-25T13:37:42.990

Trace-routing 10.192.20.2 is what somewhat puzzles me, for it consistently gives, first 1 * * * Request timed out. Then, 2 1 ms 1 ms 1 ms 10.192.20.2. And finally, 3 10.192.20.2 reports: Destination host unreachable. But this is probably a different issue altogether. – Konstantin.V – 2016-08-25T13:38:43.803

I'm guessing like you said, that the intermediary equipment is configured so it doesn't respond to traceroute requests. I know it's possible using iptables so I see no problem in the technical feasibility. As to why it would be done this way... No idea without the full network context. – Doezer – 2016-08-25T13:41:59.807

The full network context that I'm not likely to be able to figure out from my workstation, right? – Konstantin.V – 2016-08-25T13:48:05.747

Indeed. I'm not giving up, someone with more experience might know how it usually works behind the scenes, but given what we know, that's the best hypothesis I can come up with. – Doezer – 2016-08-25T13:53:39.913

OK, thanks. FWIW, the 2-nd node that is reported on trace-routing 8.8.8.8 and any other public IPs that I've tried is also a public IP and (naturally) does not belong to 10.*.*.* nor 172.*.*.* ranges. – Konstantin.V – 2016-08-25T13:59:15.327

The first node that `tracert` reports is not on my LAN

No answers