Firewall log
-
This is filling up my firewall log. I can make it stop by unchecking block private networks under interfaces but is it a bad idea to uncheck this? BTW the ip in the log is the 1st hop on the ISP network after my Cable modem and pfSense. Node maybe?
I also tried to make a block rule that would take care of this but was unable to make it work. -
I have the same thing in my log. It didn't occur to me that I would actually be able to find out where this device is with the IP, until you mentioned trace route. So I did one and came up with that internal 10 net IP that I was seeing in my log. Looks to be the cable modem NATing.
You can most likely disregard it.
traceroute to google.com (173.194.64.106), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.158 ms 0.196 ms 0.241 ms
2 10.52.160.1 (10.52.160.1) 8.657 ms 9.586 ms 9.689 ms
3 ip68-2-2-33.ph.ph.cox.net (68.2.2.33) 9.716 ms 9.740 ms 9.764 ms
4 70.169.73.43 (70.169.73.43) 10.495 ms 14.362 ms 14.389 ms
5 chnddsrj01-ae2.0.rd.ph.cox.net (70.169.76.229) 13.244 ms 14.227 ms *
6 langbprj02-ae2.rd.la.cox.net (68.1.1.19) 25.098 ms 22.814 ms 21.742 ms
7 209.85.248.185 (209.85.248.185) 22.691 ms 20.493 ms 26.046 ms
8 64.233.174.186 (64.233.174.186) 25.983 ms 64.233.174.192 (64.233.174.192) 26.134 ms 64.233.174.186 (64.233.174.186) 25.001 ms
9 64.233.174.143 (64.233.174.143) 60.294 ms 64.233.174.141 (64.233.174.141) 59.271 ms 64.233.174.143 (64.233.174.143) 60.206 ms
10 216.239.47.121 (216.239.47.121) 79.740 ms 209.85.243.178 (209.85.243.178) 72.758 ms *
11 * 216.239.46.61 (216.239.46.61) 66.870 ms 216.239.46.63 (216.239.46.63) 64.176 ms
12 * * *
13 173.194.64.106 (173.194.64.106) 69.216 ms 69.130 ms 69.080 ms -
10.168.0.1:67 (10.52.160.1) is a device, one up in your WAN that broadcast DHCP (255.255.255.255:68) requests.
If this device is your modem (pppoe device, or whatever you use to connect yourself to the wall outlet of your ISP), hook a PC to it directly, see if it has a IP on his "LAN" side, connect yourself to the web interface (or telnet, or SSH), and tell it to shut up (give it a static IP).
If the device can't be administred by you, a firewell rule on the WAN interface CAN block DHCP requests.
Block ports 67 and 67, protocol UDP, from any source. -
"I also tried to make a block rule that would take care of this but was unable to make it work."
And what rule was that, there are quite a few ways to right a rule not to log that traffic. For example anything to port 68, or anything from port 67, or if you want to be specific anything from that 10 IP port 67 to 68
etc.. etc..
I just not seeing how you could of messed up writing a rule not to log that traffic?
Currently my pfsense box is not the dhcp server, and I didn't want to see the dhcp traffic on my lan in the logs.. So I wrote a sim rule not to see traffic to 67..
But that traffic is either dhcp offer or dhcpack – And yeah from your trace looks like your doing a double nat.. So that is your ISP or your device? What do you have connected to your pfsense box? It looks like it could be your device and your double natting??? Why??
Ok got confused -- the guy posting his traceroute is not the OP ;)
But as stated already stated if your device at that address, then fix it -- if your ISP just normal traffic, you could sniff to see if normal or client or sever messed up creating extra traffic?? Its clearly ack or offer since its source 67 to dest 68, but writing a rule is pretty basic -- please post the rule you say is not working.
-
I had this problem some years ago. I never worked out why but, I assume because it's broadcast, I was seeing all the DHCP traffic on my segment of the cable network.
Sorry if this is obvious but have you unchecked Log packets blocked by the default rule under Status > System Logs > Settings?
Biggsy
-
Well in my case I have a COX which I use an SB6120 DOCS3 cable modem, that connects to my pfsense box which is my NAT and DHCP server that has 5 Ethernet ports all together. One of which is obviously my WAN interface and the other four I have set up in a bridge which I made into an interface that is the DHCP server. To make things more complicated I have a dual band NetGear router to which I did disabled it from being a DHCP server so it just forwards DHCP leases.
To my knowledge the SB6120 has a DHCP capabilities built in but the internal IP is 192.168.100.1 for the device not a 10 net… But from the trace route this is not the case? I can not make a connection to the 10.52.160.1 IP and I am able to connect to the SB6120 with the 192.168.100.1. So I am not sure where that 10 net IP is coming from ???
-
I have a Motorola SB5100 (still only DOCSIS 2.0 here).
If I turn on Log packets blocked by the default rule, I see exactly the same sort of traffic you're seeing. My logs are also forwarded to a syslog server and in there I also see a breakdown of the DHCP contents:
Nov 6 20:55:05 pf: 00:00:56.401926 rule 24/0(match): block in on em0: (tos 0x0, ttl 255, id 15465, offset 0, flags [none], proto UDP (17), length 340) Nov 6 20:55:05 pf: [b]10.236.192.1.67[/b] > 255.255.255.255.68: BOOTP/DHCP, Reply, length 312, xid 0xb6deb078, Flags [Broadcast] Nov 6 20:55:05 pf: <009> Client-IP 121.209.165.111 Nov 6 20:55:05 pf: <009> Gateway-IP 121.209.160.1 Nov 6 20:55:05 pf: <009> Client-Ethernet-Address 00:1e:8c:de:91:55 Nov 6 20:55:05 pf: <009> file "cable_t3_motorola" [|bootp]
I can get dozens of these in a fairly short time.
Note the source is in a 10. network.
The address of the web server in my SB5100 is 192.168.100.1 as well. I guess Motorola didn't see any reason to change that.
-
Just out of curiosity I am going to do some packet inspection just to see where this is originating from. I'm not worried about it as I am sure its the SB6120 or possibly an upstream server that is creating them. I am sure if I called COX support they would have no idea what I am talking about if I asked.
-
I think the cable modem acts like a DHCP helper/relay to get the assigned IP address to the device that's attached to its LAN port. That device only wants the offer that has its own MAC address imbedded but it pretty much has to see them all to work out which is intended for it.
If all you're seeing in your logs are these packets you're lucky! I had to dig that one above out of a logs of couple of port scans and a bunch of NetBIOS crap.
-
Yea well I get a few random attempts from external machines to connect to my WAN IP. Realistically there should be no external host trying to connect to my network from outside the WAN. I work for an large domain/hosting company and I see servers get rooted all the time and then turned into attack platforms that try and root other hosts so I am aware of the randomness that can occur. Which is why I also use the Country Block package to most block cough China cough
So I did a simple packet capture from PFSense and here is what turned up. At this time the only thing showing in the Firewall log was that internal 10 net IP:
02:47:51.443166 00:15:f9:2a:b2:db (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 337: (tos 0x0, ttl 255, id 19774, offset 0, flags [none], proto UDP (17), length 323)
10.52.160.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 295, hops 1, xid 0x32f993e4, secs 1024, Flags [Broadcast] (0x8000)
Your-IP ip70-171-198-117.tc.ph.cox.net
Server-IP 172.19.73.40
Gateway-IP 10.52.160.1
Client-Ethernet-Address 64:31:50:27:3e:6f (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.19.73.40
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "ph.cox.net^@"
Default-Gateway Option 3, length 4: ip70-171-198-1.tc.ph.cox.net
Domain-Name-Server Option 6, length 12: cdns2.cox.net,cdns7.cox.net,cdns1.cox.net
02:47:52.061562 00:15:f9:2a:b2:db (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 337: (tos 0x0, ttl 255, id 19778, offset 0, flags [none], proto UDP (17), length 323)
10.52.160.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 295, hops 1, xid 0xdea5ee19, Flags [Broadcast] (0x8000)
Your-IP ip70-171-197-46.tc.ph.cox.net
Server-IP 172.19.73.40
Gateway-IP 10.52.160.1
Client-Ethernet-Address 00:1d:09:87:48:f4 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.19.73.40
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "ph.cox.net^@"
Default-Gateway Option 3, length 4: ip70-171-197-1.tc.ph.cox.net
Domain-Name-Server Option 6, length 12: cdns2.cox.net,cdns7.cox.net,cdns1.cox.net
02:49:45.836892 00:15:f9:2a:b2:db (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 337: (tos 0x0, ttl 255, id 19920, offset 0, flags [none], proto UDP (17), length 323)
10.52.160.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 295, hops 1, xid 0x3ead1c50, Flags [Broadcast] (0x8000)
Your-IP ip68-3-27-237.ph.ph.cox.net
Server-IP 172.19.73.40
Gateway-IP 10.52.160.1
Client-Ethernet-Address 00:1d:92:b3:db:96 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.19.73.40
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.248.0
Domain-Name Option 15, length 11: "ph.cox.net^@"
Default-Gateway Option 3, length 4: ip68-3-24-1.ph.ph.cox.net
Domain-Name-Server Option 6, length 12: cdns2.cox.net,cdns7.cox.net,cdns1.cox.net
02:50:31.882012 00:15:f9:2a:b2:db (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 337: (tos 0x0, ttl 255, id 19966, offset 0, flags [none], proto UDP (17), length 323)
10.52.160.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 295, hops 1, xid 0xb5b9ef04, Flags [Broadcast] (0x8000)
Your-IP ip72-201-168-119.ph.ph.cox.net
Server-IP 172.19.73.40
Gateway-IP 10.52.160.1
Client-Ethernet-Address 00:1d:09:94:62:bc (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.19.73.40
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "ph.cox.net^@"
Default-Gateway Option 3, length 4: ip72-201-168-1.ph.ph.cox.net
Domain-Name-Server Option 6, length 12: cdns2.cox.net,cdns7.cox.net,cdns1.cox.net
02:52:31.876560 00:15:f9:2a:b2:db (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 337: (tos 0x0, ttl 255, id 20133, offset 0, flags [none], proto UDP (17), length 323)
10.52.160.1.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 295, hops 1, xid 0x7fdf267a, Flags [Broadcast] (0x8000)
Your-IP ip72-201-168-119.ph.ph.cox.net
Server-IP 172.19.73.40
Gateway-IP 10.52.160.1
Client-Ethernet-Address 00:1d:09:94:62:bc (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.19.73.40
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Domain-Name Option 15, length 11: "ph.cox.net^@"
Default-Gateway Option 3, length 4: ip72-201-168-1.ph.ph.cox.net
Domain-Name-Server Option 6, length 12: cdns2.cox.net,cdns7.cox.net,cdns1.cox.netSo maybe COX has this device set up to be "transparent" switch or something searching for DHCP leases?
-
Cox has the device setup???
Those are just DHCP ACKS, from Server-IP 172.19.73.40
Yeah your going to see that traffic for everyone on your ISP segment
I see it too, just not logging it!
[2.1-DEVELOPMENT][root@pfsense.local.lan]/root(16): tcpdump -i 3 -vvv -n port 67 and port 68 tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes 07:27:28.925500 IP (tos 0x0, ttl 64, id 58680, offset 0, flags [none], proto UDP (17), length 328) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, hops 1, xid 0x401d9044, Flags [Broadcast] (0x8000) Client-IP 68.60.236.249 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:1d:09:92:28:c0 [|bootp] 07:27:38.687022 IP (tos 0x0, ttl 64, id 59610, offset 0, flags [none], proto UDP (17), length 332) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304, hops 1, xid 0xd2d3092, Flags [Broadcast] (0x8000) Your-IP 24.13.179.126 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:1d:09:79:0a:23 [|bootp] 07:27:54.968929 IP (tos 0x0, ttl 64, id 60711, offset 0, flags [none], proto UDP (17), length 336) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 308, hops 1, xid 0x9578e01b, Flags [Broadcast] (0x8000) Your-IP 24.13.177.168 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:26:f3:e6:1a:46 [|bootp] 07:27:55.036359 IP (tos 0x0, ttl 64, id 60732, offset 0, flags [none], proto UDP (17), length 336) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 308, hops 1, xid 0x9578e01b, Flags [Broadcast] (0x8000) Your-IP 24.13.177.168 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:26:f3:e6:1a:46 [|bootp] 07:28:09.311423 IP (tos 0x0, ttl 64, id 62024, offset 0, flags [none], proto UDP (17), length 328) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, hops 1, xid 0x3c424d81, Flags [Broadcast] (0x8000) Client-IP 76.16.241.154 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:25:64:02:d5:d6 [|bootp] 07:28:17.144524 IP (tos 0x0, ttl 64, id 62632, offset 0, flags [none], proto UDP (17), length 328) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, hops 1, xid 0xafcfdd21, Flags [Broadcast] (0x8000) Client-IP 24.13.178.220 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:26:2d:40:0e:02 [|bootp] 07:28:20.445409 IP (tos 0x0, ttl 64, id 63055, offset 0, flags [none], proto UDP (17), length 332) 96.143.144.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304, hops 1, xid 0x37a6846d, Flags [Broadcast] (0x8000) Your-IP 98.228.240.255 Gateway-IP 96.143.144.1 Client-Ethernet-Address 00:1a:a0:8f:57:01 [|bootp]
My guess reason your seeing it is the private IP it says its from?? But looks like normal ISP dhcp traffic to me – if you don't want to see it then create a rule to not log it.. You have the source IP, you have the source port and the dest port.. Take you 2 seconds to write a rule not to log that traffic.
-
Oh I already did :) All this was to show redpanther that I too see that kind of traffic and it appears to be originating from within the COX network.
-
If you don't want that log to show up.
In the settings tab disable "Log packets blocked by the default rule"
Hint: packets that are blocked by the implicit default block rule will not be logged anymore if you uncheck this option. Per-rule logging options are not affected.All the 255.255.255.255:68 messages will not fill the firewall log anymore.