Block private networks - something from cable-modem is blocked, but what is it?

Bob.Dig · Nov 5, 2020, 1:50 PM

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.

johnpoz · Nov 5, 2020, 2:02 PM

192.168.100.1 is very common IP of cable modems. That is where you access its status from..

example here is mine

login-to-view

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?

Bob.Dig · Nov 5, 2020, 2:06 PM

@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.

johnpoz · Nov 5, 2020, 2:14 PM

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.

login-to-view

Bob.Dig · Nov 5, 2020, 3:49 PM

@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;

johnpoz · Nov 5, 2020, 3:14 PM

@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 ;)
login-to-view

Gertjan · Nov 5, 2020, 3:40 PM

@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 )

johnpoz · Nov 5, 2020, 3:46 PM

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..

login-to-view

Bob.Dig · Nov 5, 2020, 4:05 PM

@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).

johnpoz · Nov 5, 2020, 4:18 PM

@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..

Bob.Dig · Nov 5, 2020, 4:19 PM

@johnpoz I used https://www.hellion.org.uk/cgi-bin/randmac.pl so had no clue.

JKnott · Nov 5, 2020, 4:27 PM

@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.

johnpoz · Nov 5, 2020, 4:37 PM

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

JKnott · Nov 5, 2020, 4:44 PM

@johnpoz

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.

johnpoz · Nov 5, 2020, 4:56 PM

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 ;)

bmeeks · Nov 5, 2020, 4:59 PM

@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.

JKnott · Nov 5, 2020, 5:02 PM

@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.

Bob.Dig · Nov 5, 2020, 5:02 PM

@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.

johnpoz · Nov 5, 2020, 5:22 PM

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 ;)

Bob.Dig · Nov 5, 2020, 5:41 PM

@johnpoz

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 ms

my 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 ms

Oops, 192.0.0.1 is not RFC 1918 (192.168.178.1 is my neighbors local LAN) so I was wrong.