Firewall Log showing WAN port 67/68 DHCP entries - please help explain
-
Hi everyone. I'm new to PfSense and after reading on it this summer, I built a box and just put it into action nearly a week ago. Just a heads up, I'm not a networking expert by any stretch but (I think) I know the basics.
I started familiarizing myself with the logs and in the STATUS >> SYSTEM LOGS >> FIREWALL I am getting these entries:
Dec 5 22:49:42 WAN Block ULA networks from WAN block fc00::/7 (12000) 10.163.128.1:67 255.255.255.255:68 UDP
I get roughly 8 per minute. As you could imagine, it's cluttering my log.
To give an understanding of my setup, it's pretty basic and as follows:
ISP (Shaw (Canada)) >> Cable Modem (Bridged and provided by ISP) >> PfSense Box (DHCP, NTP, DNS, Firewall, etc.) >> LAN (including a switch, wirelessAP, and a couple unrelated servers)
I understand the entries are on port 67/68, which is DHCP. I also understand that 255.255.255.255 is the address associated with a DHCP Broadcast.
What I don't understand and need help with…
Should I be letting these in? Why or Why not?
Where exactly are they coming from? It's a private address (10.163.128.1) and hence it being blocked by that rule. But shouldn't anything coming in from the WAN side be a public IP, even if it's my ISP?
Are these related to or will they affect my ability to renew my lease with my ISP?
My gateway & Monitor IP are both 174.xxx.xxx.1 but my public IP is 174.xxx.xxx.59 Shouldn't my gateway be the same IP as my public IP? Should I change any of those values?
Should I change the monitor IP?I read some other similar posts about this but they often had conflicting information and none of them seemed to experience it coming from the WAN side and from a private address. Hope someone can help me understand this. Thank you!
-
How big is your network / client-base? Could it be that someone has plugged in a server / client into your WAN network that is requesting DHCP or has a DCHP server installed?
Also your ISP provided router could be looking or trying to hand out leases via DHCP, is this disabled?Your question: Should I be letting these in? Why or Why not?
The answer is no, you do not want to let these in as it could cause a DHCP conflict. -
So you created this rule?
"Block ULA networks from WAN block fc00::/7 "
Can you post up your wan rules please..
A dhcp discover would be from source of 0.0.0.0 to broadcast and it would be from source port 68 to dest port 67, what your seeing there is a dhcp offer, from the device offing the IP.. Ie that 10.163.128.1 IP is overing someone an IP.. You could sniff and get the details of the offer.
Its quite possible its your ISP dhcp server? And the offers its sending other clients. Or it could be some idiot customer that turned on their dhcp server on their wan interface.. ;) But you should not be seeing these in your logs, unless you create a rule specifically to log that? Did you create that rule with that description? That is clearly not a ipv6 ULA address, but that is what the rule says its suppose to block? If its some other customer offering up dhcp to on your isp network - then it could be a problem. But normally isp prevent this from happening on their network with simple rules. So I would guess its just your isp dhcp server doing its job, and you just create a rule that is showing you that traffic that you really shouldn't be logging.. Its just typical traffic on your wan is all..
-
How big is your network / client-base? Could it be that someone has plugged in a server / client into your WAN network that is requesting DHCP or has a DCHP server installed?
Also your ISP provided router could be looking or trying to hand out leases via DHCP, is this disabled?Your question: Should I be letting these in? Why or Why not?
The answer is no, you do not want to let these in as it could cause a DHCP conflict.Network is small. Roughly 10-15 clients, and no it's not possible one of them has plugged into the WAN side.
The ISP provided me with a Modem/Router combo box but it has been bridged so there should be no DHCP server or it or anything handing out leases. Not sure how I could test this either, when connected directly to the bridged modem/router box, you cannot access any webinterface because of the bridged mode being enabled.
I'm leaning more towards it having something to do with my ISP.And thanks, I'll keep blocking it.
So you created this rule?
"Block ULA networks from WAN block fc00::/7 "
Can you post up your wan rules please..
A dhcp discover would be from source of 0.0.0.0 to broadcast and it would be from source port 68 to dest port 67, what your seeing there is a dhcp offer, from the device offing the IP.. Ie that 10.163.128.1 IP is overing someone an IP.. You could sniff and get the details of the offer.
Its quite possible its your ISP dhcp server? And the offers its sending other clients. Or it could be some idiot customer that turned on their dhcp server on their wan interface.. ;) But you should not be seeing these in your logs, unless you create a rule specifically to log that? Did you create that rule with that description? That is clearly not a ipv6 ULA address, but that is what the rule says its suppose to block? If its some other customer offering up dhcp to on your isp network - then it could be a problem. But normally isp prevent this from happening on their network with simple rules. So I would guess its just your isp dhcp server doing its job, and you just create a rule that is showing you that traffic that you really shouldn't be logging.. Its just typical traffic on your wan is all..
I did not create that rule, I'm assuming the rule is from the "Block Private Networks" check box on the WAN side.
Here are my WAN rules:
Protocol Source Port Destination Port Gateway Queue Schedule Description
* RFC 1918 networks * * * * * Block private networks
* Reserved Not assigned by IANA * * * * * Block bogon networks
IPv4 TCP/UDP * * 192.168.1.3 64738 * none XXXX ServerThat's it. It's pretty small thus far.
I did not create any rule specific to log it and I'm assuming it's from the "Block Private Networks" rule from the check box on WAN, which to my understanding should be checked in my case.
How would I determine if this is from another client or the ISP itself?
Is it normal for it to show my WAN_DHCP address under System >> Routing >> Gateways as being 174.xxx.xxx.1 but my public IP is 174.xxx.xxx.59 ?Thanks
-
All sorts of shenanigans go on out on the ISP network and beyond. That's why we have firewalls.
Many ISPs do not use public IP addresses where they do not have to be publicly-addressed:
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 10.65.128.1 8.888 ms 10.157 ms 7.932 ms
… -
Well, that gave me an idea. I hadn't tried a traceroute yet.
Ran it from the PfSense WebGUI using the following:
Hostname: 174.xxx.xxx.1
IP Protocol: IPv4
Source Address: Anyresulted in:
1 10.163.128.1 9.102 ms * 7.635 ms
but if I enabled "Use ICMP", I get this result:
1 174.xxx.xxx.1 6.257 ms 6.712 ms 9.636 ms
If I try doing a traceroute to 8.8.8.8 or any other address the first entry just says 0.0.0.0
So are they the same box? Does this mean my ISP's box has that internal address and that's it's public IP? So those packets hitting me are from there?
Why would that be sending me a DHCP offer?
-
"Why would that be sending me a DHCP offer?"
Who says its sending it to you?? Its a BROADCAST.. So everyone on that isp layer 2 network would see that broadcast..
I would sniff the packets and look to see.. You will see the IP they offering, you will the mac address that is getting the offer, etc.
"Block ULA networks from WAN block fc00::/7 "
Is that what the block private rule says.. That is a HORRIFIC description or Comment on the block private rule.. How about "Blocked by Private Network Rule" - I just turned it on, and yeah that is the rule desc it shows in the logs… That is just bad coding.. Such a desc is very misleading. Going to check redmine to see if someone has logged this.
edit: Ok looks like someone already put it in
https://redmine.pfsense.org/issues/6030Seems like target is 2.4 to be fixed. Is just cosmetic so has low priority.. Have to see what happens when 2.4 releases.
To me, if you don't like seeing the spam in your logs.. Just turn of the logging of the block private, or just turn it off block private all together.. While sure its good practice to do so, its not really a effective rule. By default all unsolicited inbound traffic to your wan it blocked! So all this rule would do is block a rfc1918 or ULA for ipv6 from hitting any of the port forwards or allows you have on the wan firewall tab. These addresses do not route on the public internet. So the only possible place such traffic could come from would be the layer 2 your connected to on your ISP.. Is that something your concerned about? You opened up something the whole public internet via a port forward, but hey if some stray packet from your isp local layer 2 hits it - block it! ??
If anything its going to cause way more noise then any actual effective block.. Same with the bogon rule.. While yes in keeping with best practice such stuff should be blocked. From security standpoint, yes they should be blocked. But in reality they are pretty freaking pointless. And cause more issues than anything good, be it either in log spam or just plain issues with people that have rfc1918 on their wan side..
There is a hidden rule that will allow your wan IP to get its dhcp traffic when its set to dhcp. So yeah that is just log spam your seeing caused by a rule that to be honest is of very little value. To satisfy your curiosity do a packet capture on your wan, open it up in wireshark so you can see exactly the details.. Then to clear up your logs turn off the feature of logging the block rfc1918, or just plain don't block it - that is up to you.
-
"Why would that be sending me a DHCP offer?"
Who says its sending it to you?? Its a BROADCAST.. So everyone on that isp layer 2 network would see that broadcast..
I would sniff the packets and look to see.. You will see the IP they offering, you will the mac address that is getting the offer, etc.
"Block ULA networks from WAN block fc00::/7 "
Is that what the block private rule says.. That is a HORRIFIC description or Comment on the block private rule.. How about "Blocked by Private Network Rule" - I just turned it on, and yeah that is the rule desc it shows in the logs… That is just bad coding.. Such a desc is very misleading. Going to check redmine to see if someone has logged this.
edit: Ok looks like someone already put it in
https://redmine.pfsense.org/issues/6030Seems like target is 2.4 to be fixed. Is just cosmetic so has low priority.. Have to see what happens when 2.4 releases.
To me, if you don't like seeing the spam in your logs.. Just turn of the logging of the block private, or just turn it off block private all together.. While sure its good practice to do so, its not really a effective rule. By default all unsolicited inbound traffic to your wan it blocked! So all this rule would do is block a rfc1918 or ULA for ipv6 from hitting any of the port forwards or allows you have on the wan firewall tab. These addresses do not route on the public internet. So the only possible place such traffic could come from would be the layer 2 your connected to on your ISP.. Is that something your concerned about? You opened up something the whole public internet via a port forward, but hey if some stray packet from your isp local layer 2 hits it - block it! ??
If anything its going to cause way more noise then any actual effective block.. Same with the bogon rule.. While yes in keeping with best practice such stuff should be blocked. From security standpoint, yes they should be blocked. But in reality they are pretty freaking pointless. And cause more issues than anything good, be it either in log spam or just plain issues with people that have rfc1918 on their wan side..
There is a hidden rule that will allow your wan IP to get its dhcp traffic when its set to dhcp. So yeah that is just log spam your seeing caused by a rule that to be honest is of very little value. To satisfy your curiosity do a packet capture on your wan, open it up in wireshark so you can see exactly the details.. Then to clear up your logs turn off the feature of logging the block rfc1918, or just plain don't block it - that is up to you.
Thanks for clearing that up some for me! I went ahead and did a capture, these 2 were the most common related packets:
07:13:50.731642 IP (tos 0x0, ttl 255, id 2917, offset 0, flags [none], proto UDP (17), length 328)
10.163.128.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x448a59e6, Flags [Broadcast]
Your-IP 10.163.180.85
Server-IP 10.175.253.22
Gateway-IP 10.163.128.1
Client-Ethernet-Address 00:18:c0:d4:31:54 (oui Unknown)
file "0-18-c0-d4-31-54.bin"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.175.254.163
Lease-Time Option 51, length 4: 430956
Subnet-Mask Option 1, length 4: 255.255.192.0
Time-Zone Option 2, length 4: 0
Default-Gateway Option 3, length 4: 10.163.128.1
Time-Server Option 4, length 4: 10.175.253.22and
07:13:48.711144 IP (tos 0x0, ttl 255, id 2898, offset 0, flags [none], proto UDP (17), length 328)
10.163.128.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x448a59e6, Flags [Broadcast]
Your-IP 10.163.180.85
Server-IP 10.175.253.22
Gateway-IP 10.163.128.1
Client-Ethernet-Address 00:18:c0:d4:31:54 (oui Unknown)
file "0-18-c0-d4-31-54.bin"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.175.254.163
Lease-Time Option 51, length 4: 430958
Subnet-Mask Option 1, length 4: 255.255.192.0
Time-Zone Option 2, length 4: 0
Default-Gateway Option 3, length 4: 10.163.128.1
Time-Server Option 4, length 4: 10.175.253.22There are tons of packets matching the criteria and they almost all look pretty identical to those 2, which seem to be what the log is filling entries about.
So then this is just random DHCP traffic getting thrown around on the ISP's network that is hitting my firewall but I'm getting logs full of it because of the private network rule then?
-
Just wanted to update everyone, problem solved.
Created an alias for private networks and a WAN rule to block them. Unchecked the checkbox for blocking private networks in WAN interface.
Created another WAN rule above it and set it to block all UDP port 68 with destination 255.255.255.255 and set it to NOT log those entries.
While I was at it I also created a floating rule to block all private network out traffic, just for the sake of added security and figured it was good practice.
Network is running fine and no more of those annoying log entries. I don't think any of those rules should affect my DHCP lease renewal from ISP or any other settings. Should be good to go.
Thanks everyone for the clarifications and assistance! ;D
-
Well that mac is ARRIS Group, Inc. They make cable modems and such..
I take it that mac is not yours? Depending on your cable modem you might be able to view its stuff on 192.168.100.1
Looks like they are offering up some sort of pxe boot file
file "0-18-c0-d4-31-54.bin"There really is little reason to "block" them.. If its not needed by pfsense its just not going to do anything with that packet. And the default rule would block them anyway if not blocking rfc1918 and bogon.. I personally see really very little reason for those - the bogon has blocked stuff that it shouldn't in the past.
Really all those rules do is block bogon and rfc1918 from getting to any rules you might have open. Your rules would normally be allow direct traffic only to your wan IP.. So what are the odds that there would be directed traffic to your wan IP that you allow from a bogon or a rfc1918 address? ;)
Noise can get very log filling - I turn those rules off, and don't have them logging anyway and turn off logging of the default rule. I create a rule to log only syn packets on my wan. That way I see directed traffic, like bots looking for telnet, ssh, ftp, etc. All the other common ports.. But don't see all the what amounts to noise that is just blocked by the default deny anyway that I just tell it not to log.
