I wish Linux’s firewalls were so easy to configure. The closest I’ve found there is with ufw, which isn’t nearly so comprehensive or straightforward, but at least goes in the right direction.
I wish Linux’s firewalls were so easy to configure. The closest I’ve found there is with ufw, which isn’t nearly so comprehensive or straightforward, but at least goes in the right direction.
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. :(
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.
Sorry again! I really did just make this up.
nft (nftables) is easy and has a similar pf-like 'feel' while offering way more functionality. After decades of `iptables` (and `ipchains` before) nft(ables) is a breath of fresh air.
The scenario is like the cgroup v1 and v2 change.
The clearest example of this was the megaraid command for lsi raid cards. It's commands are documented in the getopt style but I accidentally found out that the dashes were optional. And while the syntax was still sort of ass, my scripts were much easier to read.
FWIW I have the previous edition of the Book of PF on my bookshelf but I rarely reference it after reading through it a couple years back. Standard homelab-grade rulesets are pretty straightforward to setup.
I was hoping it was like a nice programming language whose internal structure made sense to an experienced developer. Where I can incrementally build things up and log things to the console as I go along and troubleshoot. But it turns out that setting up a vpn involves a big bang config with a dozen lines and it’s unclear which of them is broken.
It’s a DSL and not a programming language and often there is very little you can do to troubleshoot that’s short of reading the source code, the protocol spec, and firing up wireshark.
I found various configs on random websites or in the openbsd manual, but none seemed to do the trick. I gave up and installed Tailscale.
This isn’t a knock on PF. But years of reading glowing comments like this gave me some false hope that I could finally grok this stuff and maybe do some creative projects with it.