2

I have a computer with 2 network adapters, each on its own subnet. One is our private LAN, 192.168.1.0/24, the other is for the internet. The internet subnet is 10.251.85.161/27.

When I ping-scanned the LAN, I received replies from some addresses that I knew didn't exist. These computers had no MAC address associated with them in the ARP table. I ran a traceroute and this is the result:

Tracing route to 192.168.1.208 over a maximum of 30 hops

  1     1 ms     1 ms     2 ms  10.251.85.161 <--router gateway
  2   580 ms   617 ms   527 ms  10.250.120.25 <--satellite
  3   529 ms   536 ms   552 ms  10.250.120.2 
  4   556 ms   587 ms   628 ms  10.250.6.145 
  5   526 ms   539 ms   547 ms  10.250.6.146 
  6   529 ms   517 ms   530 ms  10.250.6.137 
  7   789 ms   759 ms   749 ms  192.168.1.194 <--sudden jump to other private network?
  8   716 ms   759 ms   720 ms  192.168.1.208 

Trace complete.

Notice the IP I traced is on my LAN's subnet. Instead it pinged it through the internet adapter, seems to have bounced around a few computers at the ISP, and I got a reply from something.

Shouldn't subnetting prevent this? I am not a network admin so it may be a failure of my understanding, but I thought it was impossible to initiate a connection to a private IP from outside its subnet, otherwise chaos would ensue.

What might cause this to happen?

Although I am not a network admin, I am tasked with solving our company's networking problems. We all share one internet connection but different departments have their own private networks to keep everything isolated. I'm trying to figure out why my ping request was sent through an adapter assigned to a different subnet than the address I pinged (maybe that's normal) and was answered by some random computer presumably owned by my ISP (I don't think that's normal).

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
HypnoToad
  • 21
  • 3
  • 2
    10.x.x.x. is also a [private network](https://en.wikipedia.org/wiki/Private_network), not a public address. – Sven Jan 01 '18 at 21:03
  • "_Shouldn't subnetting prevent this? [...] I thought it was impossible to initiate a connection to a private IP_" - There's NOTHING preventing --from a technical point of view-- the "routing" of IP packets whose destination addresses are RFC1918 (so called "private IP addresses"). So delivering a packet to 10.0.0.99 or 192.168.10.20 is exactly the same as delivering a packet to 8.8.8.8. Actually, large ISP heavily rely on RFC1918 subnets _INSIDE_ their own network. And if you are _INSIDE_ such a network you can definitely reach them (unless ISP-enforced firewalling policies are in place). – Damiano Verzulli Jan 01 '18 at 21:35
  • What RFC1918 require is that such addresses are kept PRIVATE, TO YOUR ISP. So such packets should be DROPPED at the border of its (very large) network. But --again-- as you are one of its CUSTOMER, you're INSIDE its network, so you (technically can) reach your ISP RFC1918 subnets. This, again, wrt firwealling policy (that could drop your packets. But this is a firewalling issue. Not a routing one). - BTW: I think this point should deserve a proper answer, as... it looks to me quite "inline" with ServerFault topics (...at least the last couple of paragraphs of the OP). – Damiano Verzulli Jan 01 '18 at 21:40
  • This does not seem to be in a home environment at all... I would answer the question, but since it is on hold... well, let's just note that the IP shown in the traceroute is the IP that the router sending the TTL Exceeded decided was the most appropriate. – Law29 Jan 01 '18 at 21:57
  • Thanks for the info @Damiano... I have never seen a jump from one private network to another like this... I guess what you say makes sense, it's just crazy that some random computer at the ISP would be responding to my ping. I actually thought the ping would go ONLY through the local network adapter, not the internet adapter, because it was in the local network (all our 192.168 IPs are static and we use switches, there are no routers on the local network, maybe I should have mentioned that). – HypnoToad Jan 01 '18 at 22:01
  • Thank you @Law, no it is a work environment. I did notice the TTL was 247, instead of the usual 128, but me not being a network guy I don't know what to make of that. It seems like really strange behavior. – HypnoToad Jan 01 '18 at 22:05
  • The only thing that seems bizarre to me is that your packets leave the network. They should be routed to your private 192.168.1.0/24 network and stay there. I think your networks are not isolated (i.e. they are on the same layer 2) and that your internet router is not configured to know about the 192.168.1.0/24 network, so that when it somehow receives a packet for one of those addresses it dutifully forwards it outside. – Law29 Jan 01 '18 at 22:31
  • I agree, they should be going to the 192.168 network and not the 10.251 network. The networks are on separate ethernet adapters, with no connection sharing. The router does not know about the 192.168 network, but I assumed it being a private range that the router wouldn't forward it but according to @Damiano that's not the case. But there must be tens or hundreds of other 192.168 networks under our ISP, aren't their routers supposed to hide their IP addresses? – HypnoToad Jan 01 '18 at 22:56
  • Your ISP is doing it wrong. They should be using RFC 6598 addresses rather than RFC 1918 addresses. (And of course deploying IPv6, but that's another issue...) But that your traceroute went to the ISP at all indicates a local issue. Check the routing table on your router. – Michael Hampton Jan 02 '18 at 00:41
  • @HypnoToad, could you also print out your routing list, or have a look at it to ensure that your 192.168.1.0/24 subnet is actually set up to go out of the right NIC? – adalal Jan 02 '18 at 00:43
  • What was the exact command you used to make the IP scan? Maybe the program sent the ping requests via a socket bound to your Internet adapter and therefore the packets ended up elsewhere than your local network. – Tero Kilkanen Jan 02 '18 at 07:13
  • @Michael, I cannot view the router's routing table because the ISP owns the router and we are locked out of it. Last night I had them widen our subnet to /28 because we were running out of IP addresses, so things have changed somewhat but I'm still able to ping those computers from the other subnet. – HypnoToad Jan 02 '18 at 14:16
  • @adalal, I verified the 192 subnet is routed to the correct NIC. I also tried pinging 192.168.1.208 from another computer that only has 1 adapter on the 10.240 subnet and it was able to ping it, so it's not a problem with this computer. – HypnoToad Jan 02 '18 at 14:18
  • I'm now getting replies from our ISP on almost every IP in the 192.168.1 subnet (we only have about 20 computers on the LAN). Luckily the computers on our LAN respond more quickly, so there haven't been any IP conflicts yet, but it's still disconcerting. – HypnoToad Jan 02 '18 at 15:09

0 Answers0