Really odd results with IP Scanner

tom__w

Quick background:
I used to use my DECO as the router at home. It dished out 192.168.68.XXX addresses. I have since changed over to PfSense as my router and the DECO as just APs. The new range is 192.168.1.XXX

I had the whole house powered off for some electric work. When power came back on, everything powered up .. but I forgot to power up my mini PC running PS sense. So I connected my PC to the PfSense and started doing IP scanning.

To my surprise, I was seeing devices on the 192.168.68.XXX range. When I did my duh moment, I powered up my PfSense and all seemed well.

For the hell of it, I port scanned the other network. I still see devices (none of which are mine) on the XXX.XXX.68.XXX range.

How does one even do that??

Gertjan

@tom__w said in Really odd results with IP Scanner:

I still see devices (none of which are mine)

@tom__w said in Really odd results with IP Scanner:

the router at home.

@home and you see devices that are not 'yours'. Like : these devices should not be part of your ( ! ) network ? Clarification, please.

@tom__w said in Really odd results with IP Scanner:

I still see devices ~~(none of which are mine)~~ on the XXX.XXX.68.XXX range.

Maybe this : you've set up devices with a static IPv4 ?
Or : some other DHCP is active ? (maybe not yours )

stephenw10

Yes it sounds like the DECO came back up in router mode again after losing power. If you still see devices using it's subnet perhaps it still is. If there are not your devices (how do you know?) perhaps it came up without a wifi password set and any device in range was able to connect? That seems unlikely for any recent wifi hardware but....

johnpoz

@tom__w How exactly are you scanning.. here is theory..

So your pfsense network is say 192.168.100/24 and your client say 192.168.100.42 for example you say hey scan for 192.168.68.0/24 this traffic since not on the 192.168.100 network would be sent to pfsense say looking for 192.168.68.100 as one of the IPs..

Pfsense says well shoot, I don't have a 192.168.68 network attached to me, send it out my default gateway - your ISP.. Your isp may very well have devices on its network in this rfc1918 space 192.168.68, which could in turn answer say a ping..

So no they are not your devices - they are some devices out on your isp network.

edit: example of this... Somewhere in my ISP network 10.0.0.1 answers

C:\>ping 10.0.0.1

Pinging 10.0.0.1 with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=39ms TTL=249
Reply from 10.0.0.1: bytes=32 time=36ms TTL=249

If I traceroute to it

C:\>tracert -d 10.0.0.1

Tracing route to 10.0.0.1 over a maximum of 30 hops

  1     1 ms    <1 ms    <1 ms  192.168.9.253
  2    11 ms    11 ms    10 ms  209.122.32.1
  3    18 ms    12 ms    11 ms  216.80.79.9
  4    37 ms    36 ms    38 ms  207.172.18.134
  5    36 ms    36 ms    38 ms  207.172.19.124
  6    36 ms    37 ms    53 ms  207.172.19.91
  7    38 ms    36 ms    41 ms  10.0.0.1

it is somewhere on my isp network, or my ISP network is routing rfc1918 outside their network when they shouldn't

But looks to be connected in their network somewhere, if I resolve the IPs in my trace

  1    <1 ms     1 ms     1 ms  sg4860.local.lan [192.168.9.253]
  2    12 ms    13 ms    19 ms  c3-0.rol-e6k1.nape.il.cable.rcn.net [209.122.32.1]
  3    11 ms    11 ms    11 ms  static.rcn.com [216.80.79.9]
  4    40 ms    36 ms    38 ms  hge0-0-0-7.core2.chgo.il.rcn.net [207.172.18.134]
  5    36 ms    35 ms    35 ms  hge0-0-0-4.core1.lnh.md.rcn.net [207.172.19.124]
  6    56 ms    36 ms    38 ms  hge0-0-0-0.core1.phdl.pa.rcn.net [207.172.19.91]
  7    59 ms    35 ms    38 ms  10.0.0.1

Looks like the device is some core router in the Philadelphia PA location. or attached to it, could very well be say a loopback address on this device? It is not uncommon to see rfc1918 in a trace through your ISP network, when some devices is setup to answer from loopback. Or even actual interface IP in their network - nothing saying an ISP can't use rfc1918 space as transit networks in their network.

I normally run this rule as outbound floating rule to prevent such things. Just being a good netizen - there is little reason to send rfc1918 out to my isp.

I had to disable it to find something out on my isp that was rfc1918 and answered.

edit2: hints that is not on your network, if the response time is higher than just a few ms, its prob not on your network ;) Also see the ttl of that ping above its 249, that isn't a local or even 1 hop sort of ttl. If you ping something local the ttl should reflect that there was no hops to get there.

Reply from 192.168.9.10: bytes=32 time=1ms TTL=64

Notice when I ping something on another network attached to pfsense

Reply from 192.168.3.32: bytes=32 time=2ms TTL=63

See how the ttl has been reduced by 1, this tells me there was 1 hop to get to that device..