pfsense-rule-order: script to keep firewall rules in the right order automatically
-
The actual issue I ran into was pfBlockerNG's cron job moving my "Block IoT" rule below some Allow rules every hour.
it was already in the right place, pfBlockerNG just kept pushing it down.
That's what the script is for.Regarding my version, yes, i know. i'm in the process of replacing the pfsense box.
-
There are package settings which address auto-added rule ordering. Do those not cover your situation?
-
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
There are package settings which address auto-added rule ordering. Do those not cover your situation?
I looked at the pfBlockerNG rule order settings but they control where pfBlockerNG places its own auto rules relative to manual ones, not the order of manual rules themselves.
my issue was specifically manual rules getting reordered relative to each other, so those settings didn't help in my case. -
my issue was specifically manual rules getting reordered relative to each other
This wouldn't be caused by pfBlockerNG's cron job. The order of non-pfBlockerNG auto-added rules (i.e., 'manual rules') could only be changed manually.
What do you have for that package setting—"
Firewall > pfBlockerNG > IP > IP Interface/Rules Configuration > Firewall 'Auto' Rule Order"? -
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Firewall 'Auto' Rule Order
-
Interesting. So those last two settings in the drop-down can and do affect 'manual rule' ordering.
So then why not use the default setting which leaves "All other rules" unaffected by pfBlockerNG?
-
@tinfoilmatt I was not aware that this setting also affects manual rule ordering.
i will change back to the default and disable the script temporarily to see if that alone solves the problem.
thank you very much. -
Additionally (and with the default setting there)—if for whatever reason you need a pass rule above pfBlockerNG's auto-added block rules, then the way to do that would be by way of the "Permit" feed group action options (i.e., actions "
Permit Inbound" for WAN interface/s, "Permit Outbound" for LAN interface/s, or "Permit Both"). This would be the cleanest and most automated way to "whitelist" any pfBlockerNG false positives. -
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Additionally (and with the default setting there)—if for whatever reason you need a pass rule above pfBlockerNG's auto-added block rules, then the way to do that would be by way of the "Permit" feed group action options (i.e., actions "Permit Inbound" for WAN interface/s, "Permit Outbound" for LAN interface/s, or "Permit Both"). This would be the cleanest and most automated way to "whitelist" any pfBlockerNG false positives.
Thanks, I'll check with the default setting.
If that solves the reordering problem, the script is still useful as a general safety net for rule ordering, but the main reason here was clearly misconfiguration on my part. -
At one point, I would've spent a lot of time parsing that blue infoblock in my own mind. I'm certain there are good use cases for the non-default options. But it either never occured to me, or I had forgotten that those last two do affect non-pfBlockerNG rule ordering. Thanks for the refresher.
By the way, I like what you're doing with your blocklist-manager tool.
-
@tinfoilmatt same here, i had no idea that setting affected manual rules until now, good to know.
thanks for the kind words on blocklist-manager, glad it's useful! -
A newer pfSense will also give you access to the latest version pfBlockerng.
Your issue might auto solve itself. -
@ngf I also wanted to add: Why rely on pfBlockerNG to push the rules at the location you want and not doing it yourself manually?
Just go into pfBlocker and change the type from "deny XY" to "alias deny". That way pfB created the aliases you already know (e.g. pfB_pri1_v4) and let's your rules alone. Then you do the rules you actually want/need, not some automatism, that can get it wrong. The auto-building is fine for simple use cases and homelabs often but when you're building a bit of a more complex policy ruleset, it's immensly easier to just use Alias deny/permit for deny/permit-lists and do the rules yourself.
Also you can do "outbound" blocking (e.g. block rules for your LANs/VLANs) much easier, when you create an interface group. E.g. create a group "Blocklist" and add all internal interfaces you want to protect. Then create rules like "reject from <grp_networks> to <pfB_pri1_v4" so you can easily turn on/off logging and reject stuff on the inside (faster drop on a client) and block (silent drop) it on WAN. That way you only manage the rules on WAN(s) and the blocklist group and as the targets in those blocklists are external IPs anyways, it's not that bad to block them in a group ahead of the rule processing on the interface as you can't accidentally block something on the inside with it. We do so in many cases even with customers with great success :)
Cheers :)
PS: Although great job on the blocklist manager, I don't really get the problem. The intro says IPs slipped through that FireHOL would've catched. Yeah, add their blocklist and be done. Or add Q-Feeds, too, etc. etc. Where's the problem on having duplicates? Even the pfBlocker feeds have duplicates, it's completely normal with blocklists depending on which source lists you build your lists about. I simply don't understand the need to deduplicate that hard on something as simple as a blocklist. Besides, pfB already ca do that, so perhaps there's something I don't understand here?
And if all you wanted was one big list to block anything, then you can already use pfBlockers Override in the Feeds to make every list PRI1 so everything is in PRI1 (or something else) and you have one big list with sublists that gets merged, deduplicated and loaded. Multiple tiers of lists is only really neccessary if you want to use them differently on various interfaces. E.g. use stuff like Firehol3 (with false positives) or others that can have overblocking on a separate tier list to enable on networks like guest wifi or kids or protecting special usergroups while e.g. only blocking relatively safe one on server subnets etc. so they won't have to deal with overblocking and somehow breaking a software update or stuff :) -
@JeGr Thanks, really appreciate the detailed response. The alias deny approach is something I wasn't aware of, good to know. That said, my setup is pretty stable at this point, and I'm not looking to redo the rule set.
The script works, and honestly the numbered rules are something I'd want to keep regardless it just makes things much cleaner to look at and easier to manage.
Knowing that the order didn't change without me touching anything helps my peace of mind.
