Block private networks - something from cable-modem is blocked, but what is it?
-
Hi guys,
I had "Block private networks and loopback addresses" enabled on WAN (100.65.132.36) and noticed, that something from my "cable-modem" (in bridge mode) was blocked, talking to my WAN-Port. Everything seems to be fine anyway, but I do wonder what this is in the first place. I made a packet capture and maybe someone can tell my, if it is of any importance or what is going on.
-
192.168.100.1 is very common IP of cable modems. That is where you access its status from..
example here is mine
Looks like its trying to answer back to you.. Those are all syn,ack..
Stop trying to talk to it and it will stop sending those back.. But what is odd is don't see any syn in your sniff? How exactly did you capture that traffic? Did you only catch the 1 direction.. syn,ack is answer to syn... So your 100.65 address should be seen sending a syn..
Your using a cgnat address.. So its possible I guess there is some sort of mix up and what your seeing is something from your ISP network, and not actually from your cablemodem? Or its seeing syn from spoofed IP from your ISP? With source of your address? I would expect to see the syn in the capture if you sniffed and tried to talk to it... And then even with a block of rfc1918 on your wan you should get answer through?
The mac of the 100.1 address shows to be 00:01:5c CADANT INC. - Arris bought them back in 2001 or something like that. And your 100.65.132.65 06:bc:5d is Apple, inc.. I assume your running pfsense on an apple?
-
@johnpoz I didn't talk to it in the sense of going to that IP or similar. But I also could block outgoing RFC1918 traffic on WAN.
I hope that won't make problems and technically I am NATed on WAN. But doing a traceroute to google I can see even with my neighbors internet, which is not CG-NATed, that there come up some private IP space, so I guess that's ok.I did the capture like so, should I have included the WAN-IP also? I don't want to capture everything on WAN... and that traffic only comes up after some hours.
-
Yes its possible to see rfc1918 inside your ISP network.. Not really good setup - but sure your ISP can do that..
Something clearly talked to it.. Or it wouldn't send back syn,ack
Its odd that your not seeing any syn in the capture..
Even when you only capture 1 IP you would see it the SYN, sent to that IP..
I guess its possible you missed the syn on the first part of the sniff. But the other times in the sniff are minutes latter 2528 and 3329 seconds.. And are to different source ports. 2901 is first conv, then 6129 and then 6911.. You should be seeing the syn in those sniffs. Unless they didn't flow through your wan.. I would validate that is actually your cable modem.. You should be able to access its status page of yours and look to what the mac is..
Here see where I send syn, and it sends back syn.ack.. I shows from 100.2 since I have a vip on my wan for talking to the cable modem specifically.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
I would validate that is actually your cable modem.. You should be able to access its status page of yours and look to what the mac is..
According to my modems gui, all the MACs start with 54.
But what you say is way above what I can cope with knowledge wise.
I also found that in the modem log:
Wed Nov 04 10:17:46 2020 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:10:42 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:10:42 2020 Warning (5) MDD message timeout;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:10:49 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:10:49 2020 Warning (5) MDD message timeout;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:13:36 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:13:36 2020 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:03 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:03 2020 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:31 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:31 2020 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:39 2020 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:51 2020 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:14:51 2020 Notice (6) TLV-11 - unrecognized OID;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:20:17 2020 Notice (6) TLV-11 - unrecognized OID;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:20:17 2020 Critical (3) TLV-11 - Illegal Set operation failed;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:21:17 2020 Notice (6) TLV-11 - unrecognized OID;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:25:30 2020 Notice (6) SW Download INIT - Via NMS Wed Nov 04 13:27:24 2020 Notice (6) SW download Successful - Via NMS Time Not Established Critical (3) No Ranging Response received - T3 time-out Time Not Established Notice (6) Honoring MDD; IP provisioning mode = IPv4 Wed Nov 04 13:28:23 2020 Warning (5) DHCP WARNING - Non-critical field invalid in response ;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:28:23 2020 Warning (5) Missing BP Configuration Setting TLV Type: 17.8;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:28:23 2020 Warning (5) Missing BP Configuration Setting TLV Type: 17.9;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Wed Nov 04 13:28:25 2020 Notice (6) TLV-11 - unrecognized OID;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Thu Nov 05 04:26:03 2020 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Thu Nov 05 04:38:49 2020 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; Thu Nov 05 14:17:48 2020 Critical (3) SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=54:67:51:3a:30:64;CMTS-MAC=00:01:5c:a4:ca:58;CM-QOS=1.1;CM-VER=3.0; -
@Bob-Dig said in Block private networks - something from cable-modem is blocked, but what is it?:
CMTS-MAC=00:01:5c:a4:ca:58
And then there is this in the log..
CM-MAC=54:67:51:3a:30
Ok I have set this blocked on mine, and setup logging of it - lets see if see any odd traffic in mine... I didn't have blocking on before.. I don't see the need too.. If a stray rfc1918 hits one of my port forwards - who cares.. It could only be someone on my local ISP network ;) Its not best practice sure - but don't like seeing it in my rule listing ;)
The only thing open to public that is not locked down to specific source IPs in my ntp server..
edit: This sort of noise is why I had it turned off ;)
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
rfc1918
There is another thread ongoing right now that discusses an Apple product (a HDTV ?) using typical 192.168.a.b IP's while this IP/network doesn't even exist locally.
Like if some HDTV process uses hard coded local IP's ... and your modem is answering back ?
(ok, this is a wild shot ) -
But why wouldn't he see the syn?
The only curious thing I see in his sniff is why no syn? Doesn't make any sense that the CM would continue to try an answer something from long time ago.. It should just stop after a few retries after it sees a syn.. And doesn't get an answer back from its syn,ack..
And he is not in promiscuous mode - so its not like he would see stuff not sent to his specific IP and mac..
Its a strange sniff - but tell you what after a few minutes of that block being enabled (with logging) I remember why I had turned it off - just freaking noise..
-
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
If a stray rfc1918 hits one of my port forwards - who cares.. It could only be someone on my local ISP network ;)
My e-mail-server has less security, if the host is local and also I am behind CG-NAT. So I think I better block it.
So I will block and see if aynthing happens.
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
And your 100.65.132.65 06:bc:5d is Apple, inc.. I assume your running pfsense on an apple?
It is an used intel Fujitsu Siemens D3045-A11 GS 1 Quad Port Full Profile.
Edit: Sry, the MAC is a spoofed one (for getting a new internet-IP from my ISP). -
@Bob-Dig said in Block private networks - something from cable-modem is blocked, but what is it?:
the MAC is a spoofed one (for getting a new internet-IP from my ISP).
Yeah that normally works.. Guess it doesn't matter what vendor you use when you spoof it..
-
@johnpoz I used https://www.hellion.org.uk/cgi-bin/randmac.pl so had no clue.
-
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
Yes its possible to see rfc1918 inside your ISP network.. Not really good setup - but sure your ISP can do that..
There's no technical reason why not, so long as they don't let it escape. I have seen the 10.x.x.x block used in the past with my ISP, though not lately. Also, one of the reasons Comcast was moving to IPv6 is they were running out of rfc1918 addresses to use for internal networks and management. One advantage is it makes it harder for someone to attach their network. It also conserves public addresses for customers to use.
-
Yeah "technically" you can do it - doesn't mean its "good" idea ;)
If you don't have enough IPv4 for your ROUTING devices, that route traffic to and from the public internet - you prob shouldn't be in the ISP business ;) hehehee
-
An ISP has more than just routing to worry about. I have a cable modem, which has an address, I used to have a separate telephone terminal and 3 TV boxes. They were all, at least initially, using IPv4, so that's 5 separate device addresses, before even getting to my own public address. I doubt I was the only customer with only 1 device. As of last week, I have a new IPTV system, where the phone and Internet are in one box and the 3 TVs are on my network behind pfsense, but now everything uses IPv6.
-
They can give your TV an rfc1918 IPv4 address.. or a CGnat address. Not talking about the other shit devices on their network or their customers devices. I'm talking about their routers inline with routing traffic from their customers to the public internet..
If they are so tight on public IPv4 space.. Saving the small amount of IPv4 while they give their customer a public seems pointless.
I could see if your on CGnat already - then sure as you route through the isp network, all of those IPs might be non public.. But nothing sucks more than seeing public, and then rfc1918, then public again when tracing trying to figure out what is going on ;)
Technically you can do it sure - but not good idea.. Could see it as a idea to make a few bucks I guess.. Some guy said hey we can stop using this /X public space we are using on our internal routers and sell those IPs to the customer at $X an ip per month ;) Hope he got a good bonus for doing that ;)
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@Bob-Dig: do you have either Snort or Suricata installed on your box with an instance configured on your WAN interface? If so, the default setup of both of those packages will enable promiscuous mode on the NIC.
Still, the traffic is curious if the other non-RFC1918 address is your assigned WAN IP.
-
@johnpoz said in Block private networks - something from cable-modem is blocked, but what is it?:
They can give your TV an rfc1918 IPv4 address.. or a CGnat address.
I don't know what addresses they used on the cable side of those devices, as it wasn't visible to me. However, the TVs all have a GUA IPv6 address within my prefix. I don't recall them ever using NAT for customers on the cable network, though it was used on the cell network. These days, they use 464XLAT to provide IPv4 on an IPv6 only network. My ISP is one that has provided IPv6 for years, initially with 6to4 and 6rd tunnels, but about 5 years native.
-
@bmeeks said in Block private networks - something from cable-modem is blocked, but what is it?:
@Bob-Dig: do you have either Snort or Suricata installed on your box with an instance configured on your WAN interface?
Have Suricata installed but not running on WAN.
-
My comment about rfc1918 in the trace was to his comment that his friend with a public IPv4 address not cgnat address seeing rfc1918 in traceroute.
While yes you can see that - it not all that common.. Other than maybe in small ma and pop type isps in my opinion.. Worked for major ISP/MSP for 10+ years.. All public facing devices have public IPs on them.. We use rfc1918 internally..
Customers would notice I would think if when tracing to stuff we host in the DC for them from the public if when they enter the DC they saw rfc1918 before their IP ;)
-
my ISP to google.de
1 * * * 2 172.17.128.30 (172.17.128.30) 7.073 ms 9.381 ms 5.628 ms 3 192.168.230.64 (192.168.230.64) 7.865 ms 10.381 ms 8.171 ms 4 172.17.77.44 (172.17.77.44) 7.353 ms 9.464 ms 7.554 ms 5 cable-62-117-4-10.cust.telecolumbus.net (62.117.4.10) 8.846 ms 15.413 ms 9.344 ms 6 google.bcix.de (193.178.185.100) 22.072 ms 30.275 ms 23.219 ms 7 108.170.241.173 (108.170.241.173) 25.980 ms 108.170.241.204 (108.170.241.204) 23.059 ms 108.170.241.140 (108.170.241.140) 25.443 ms 8 209.85.255.214 (209.85.255.214) 25.016 ms 209.85.254.157 (209.85.254.157) 22.981 ms * 9 108.170.234.11 (108.170.234.11) 28.215 ms 209.85.244.159 (209.85.244.159) 29.941 ms 30.650 ms 10 108.170.236.248 (108.170.236.248) 28.514 ms 24.873 ms 28.758 ms 11 108.170.251.129 (108.170.251.129) 27.836 ms 108.170.252.1 (108.170.252.1) 30.410 ms 108.170.251.129 (108.170.251.129) 29.376 ms 12 66.249.94.245 (66.249.94.245) 29.435 ms 66.249.95.169 (66.249.95.169) 29.522 ms 28.633 ms 13 zrh04s06-in-f131.1e100.net (172.217.16.131) 27.943 ms 28.008 ms 28.338 msmy neighbors ISP to google.de
1 192.168.178.1 (192.168.178.1) 39.613 ms 2.098 ms 2.508 ms 2 192.0.0.1 (192.0.0.1) 7.509 ms 7.649 ms 8.196 ms 3 62.214.39.49 (62.214.39.49) 11.928 ms 7.572 ms 7.818 ms 4 62.214.37.158 (62.214.37.158) 13.972 ms 62.214.37.134 (62.214.37.134) 25.504 ms 62.214.37.158 (62.214.37.158) 14.496 ms 5 72.14.222.28 (72.14.222.28) 14.041 ms 15.752 ms 89.246.109.250 (89.246.109.250) 27.607 ms 6 108.170.253.68 (108.170.253.68) 15.083 ms 108.170.253.50 (108.170.253.50) 16.507 ms 108.170.253.34 (108.170.253.34) 15.434 ms 7 66.249.95.169 (66.249.95.169) 18.556 ms 108.170.226.49 (108.170.226.49) 15.644 ms 15.429 ms 8 172.253.50.100 (172.253.50.100) 19.143 ms zrh04s06-in-f131.1e100.net (172.217.16.131) 27.156 ms 172.253.50.100 (172.253.50.100) 18.900 msOops, 192.0.0.1 is not RFC 1918 (192.168.178.1 is my neighbors local LAN) so I was wrong.
