DHCP Broadcasts cluttering up log from LAN

badon

I noticed this problem too, after I added an explicit "block everything" rule that could log what was getting blocked instead of letting them go invisibly discarded. There are several special IP's, like DHCP broadcasts in this case, that don't need to go through the firewall (from LAN to WAN), so there is no point in logging each time the firewall blocks them. One easy way to remove them from your logs is to add explicit block rules for each of the IP's you want to "go away", and just don't check the box for logging the matches to the rule. Also, be sure to put the explicit IP blocks before the "block everything" rule ("block everything" should be last). If you don't, they will get logged.

I just sorted all this out in the last few minutes, so I might have overlooked something, but I think this will work for you. I attached a screenshot of what my rules look like at the bottom of the list of rules. I assume you're familiar with how to use the logging checkbox for each rule (or you can figure it out easily), so I didn't bother to make a screenshot of that.

I'm a little late in the discussion, but I just found this. On this page:

Status: System logs: Settings
https://192.168.1.1/diag_logs_settings.php

There is this option:

Log Firewall Default Blocks > Log packets blocked by the default rule
Hint: packets that are blocked by the implicit default block rule will not be logged if you uncheck this option. Per-rule logging options are still respected.

So, it wasn't even necessary for me to add a block everything rule to get logs. It's interesting how unintended clumsy abuse of features can reveal unexpected behavior, bugs, and security problems. In this case, there might be a security problem if it is indeed a bug that DHCP is getting through pfSense when it should not. There could be a circumstance when DHCP should be blocked, like if all hosts are supposed to have self-assigned static IP's. An attacker could run his own DHCP server to gain control over the network traffic of hosts that do not have static IP's configured properly.

I'm not sure what an attacker would be able to gain by that, but if something like that is plausible, it's still a major bug of higher-than-usual importance for pfSense, which specializes in preventing such things from happening, when configured to do so as we have done here.

johnpoz

Here is the thing about your attack scenario.. When you enable dhcp server, pfsense puts in the rules to allow dhcp. if your not running dhcp then that rule is not there - and even it was no harm no foul since pfsense is not listening.

As to someone running a dhcp server on your network - that is not something pfsense can control anyway - pfsense has no interaction with traffic between devices on the same segment.. Only when you leave that segment would pfsense be able to firewall traffic.

Ie this statement is somewhat true.
"LAN side" packets never even touch pfSense if there is a managed switch or router in the network"

But pfsense is going to see a broadcast 255.255.255.255 and if its a dhcp discover then the pfsense dhcp server would answer.

" blocking bogon networks on the LAN side may not even be effective"
"If so, then that may motivate us to question why such a feature exists in pfSense"

In a normal setup yes, where your rule is that source has to be "lan net" then no it wouldn't be effective because all bogons would by that rule would be blocked anyway - since source is not valid lan net address anyway. But you don't know what the owner of the firewall might want to do, maybe they have lots of sub network that connect to that interface what source would not be lan net. So they leave it as any, but don't want any funny stuff going on so they block invalid traffic.

It makes great sense on the wan side where you have no idea what the source IP might be on the internet - but your sure its not suppose to be an invalid IP that not in use, etc.

0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network. Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network [RFC1700, page 4].

That by definition would not be routed on the public internet. Again goes to blocking bogon on your "lan" interface normally would never be done - but sure if you were running dhcp server on that you could have problems. You should be smart enough to know that if your wanting to block bogon on your lan for some reason

You would never see legit 0.0.0.0 traffic inbound on your wan that I can think of - why would you be running a dhcp on your wan interface? Now you would send out from 0.0.0.0 on your wan, and that answer would be allowed in by the state when you sent out the request.

While agree clicking on shit you don't understand can cause you grief ;) If you block bogon on your LAN that your running a dhcp server on for example - but not sure why its listed as block when clearly its not. But this scenario should never really come up.

Maybe I am missing something in the rules. But from what I see if you enable bogon on your lan – and 0.0.0.0/8 is in the list and the rule says drop quick on stuff in the list, and it does log it as the rule also says. Not sure how it actually did not get blocked?

edit:
To me if I am reading the rules right if you turned on bogon blocking you should break your dhcp server ability to hand out leases because it shouldn't see the discover and wouldn't know any clients are even asking for one.

badon

Once again, thank you very much for the clarification.

A Former User

@badon:

P3R, thanks for chiming in with excellent info that helps us make progress on figuring all this out. I think I had reached my limit on how much I could help here.

johnpoz, correct me if I'm wrong, but I think another thing to consider is the possibility that "LAN side" packets never even touch pfSense if there is a managed switch or router in the network somewhere that can route packets to the correct LAN port immediately without needing to spam the other devices and network segments with packets that are not intended for them. In other words, blocking bogon networks on the LAN side may not even be effective, even if there were some good reason to do that, which we aren't aware of at the moment.

A switch, managed, unmanaged or otherwise will not broadcast traffic to all ports, unless it's specifically broadcast traffic. Traffic only flows from the source to the destination (unless it's broadcast, as stated) on all unmanaged, lvl2 managed, lvl3 managed (technically speaking a router) and (if $pocket_depth permits) higher switches.

An unmanaged switch is NOT a hub.