I've written firewall rules in many dialects, include Linux with ipchains and iptables, FreeBSD with ipfw and pf.
I will say, they all pretty much work, until you get into more esoteric stuff; do you want to drop syns where the last 16-bits of seq match the client's port number? Do you want to drop UDP RTP packets for a specific SSRC? If so, that need may guide your firewall choice. If you need to sync states between two stateful firewalls, that pushes you to pf with pfsync. Etc.
I guess I didn't see a big difference in perceived happiness between any of the rules systems? pf.conf is maybe more picky and checks everything at once, which is nice so you don't end up with a half baked ruleset.
Otoh, pf has the feature that OpenBSD changed the rule syntax, and the ported versions didn't; I'm not sure a forced migration of rule config would have sparked joy for OpenBSD users anyway, but it certainly doesn't spark joy when I read current documentation for the OpenBSD pf and can't apply it directly, and have to translate the config language to the original language.
Pf also has the extra special feature that Apple ported pf to MacOs but some things don't work properly for a host firewall (synproxy in mac os pf only works if the mac is operating as a router, not as a host... And mac os's tcp stack has no syn flood mitigation, beyond having a small listen backlog or not accepting syns directly from the internet). That's an Apple failing, not really a pf failing, but still, frustrating.
I'll have to look again and see if FreeBSD pf has gotten the features I need from ipfw, so maybe I don't have to run two firewalls at the same time. :(
> do you want to drop syns where the last 16-bits of seq match the client's port number?
I'm guessing this is something about a vulnerability in client sequence number selection? I'm curious about the details here for what would motivate this.
Oh I'm really sorry, this wasn't a real filter I've used. It was just an off the cuff weird, but doable request. Speculatively you want to block abusive syn floods and your abuser made a weird choice in their packet generator.
I will say, they all pretty much work, until you get into more esoteric stuff; do you want to drop syns where the last 16-bits of seq match the client's port number? Do you want to drop UDP RTP packets for a specific SSRC? If so, that need may guide your firewall choice. If you need to sync states between two stateful firewalls, that pushes you to pf with pfsync. Etc.
I guess I didn't see a big difference in perceived happiness between any of the rules systems? pf.conf is maybe more picky and checks everything at once, which is nice so you don't end up with a half baked ruleset.
Otoh, pf has the feature that OpenBSD changed the rule syntax, and the ported versions didn't; I'm not sure a forced migration of rule config would have sparked joy for OpenBSD users anyway, but it certainly doesn't spark joy when I read current documentation for the OpenBSD pf and can't apply it directly, and have to translate the config language to the original language.
Pf also has the extra special feature that Apple ported pf to MacOs but some things don't work properly for a host firewall (synproxy in mac os pf only works if the mac is operating as a router, not as a host... And mac os's tcp stack has no syn flood mitigation, beyond having a small listen backlog or not accepting syns directly from the internet). That's an Apple failing, not really a pf failing, but still, frustrating.
I'll have to look again and see if FreeBSD pf has gotten the features I need from ipfw, so maybe I don't have to run two firewalls at the same time. :(