Firewall Rules, States, Bootup Potential Hole
NOYB last edited by
A couple of things to beware of.
I. When adding a block rule to the firewall existing session states are retained (not removed). Thus the rule will not be effective against traffic associated with a pre-existing session state.
II. When booting pfSense any session states established prior to applying the users firewall settings will remain after bootup is completed. Thus block rules will not be effective against traffic associated with those session states.
Seems as though it would be prudent for the boot process to include clearing/resetting the states after the users firewall settings have been loaded. Or even better if possible keep the interfaces inactive until the users firewall settings have been loaded.
mer last edited by
On 1, isn't there something under diagnostics to reset/clear states that is suggested for when you add new block rules? Could it be done automatically? Probably, but then you slam existing connections which is not desirable.
On 2, this would apply to traffic coming in from LAN or OPT ports, not traffic generated by the pfSense box itself? Something like "default deny inbound on all interfaces except for lo"? It's likely there are services started during boot of the pfSense box (DNS, NTP) that may be started earlier than pf.
Another thought (second cup of coffee hitting). Startup: what if your ruleset completely borks the system? You're mandating a direct console connection to fix it. Another way of looking at it would be "what default ruleset should pf be using before we load all the rules"? You want to be able to fix it.
Just asking questions.