What's everyone's experience with modern PF in production? Also, not to start a holy war, but what people think about modern PF vs nftables? I've only ever used nftables (and only in fairly simple scenarios) but I've always been curious about the PF side of the world.
In my experience, PF operates a LOT more like commercial firewalls in how you think about filtering and NAT.
In Linux, even with nftables you still have the concepts of "chains" which goes all the way back to the ipchains days. IME this isn't a particularly helpful way of viewing things. With PF you can simply make your policy decisions on in or out and on which interface(s). Also I'm not sure I ever saw a useful application of why you'd apply a policy on the pre/post-routing chains that wasn't achievable elsewhere in PF and in a simpler way.
Also I've never been a fan of having a command that just inserted or deleted a policy instead of working from a configuration file. (nft "config" files are really just scripts that run the command successively.) I get why some folks would want that (it probably makes programmatic work a lot easier) but for me it was never a benefit.
Anyhow it's been a long time since I've had to do this kind of thing so maybe I'm out of touch on the details. Happy to hear about how I'm wrong lol.
I manage a pf.conf with about 400 rules across a dozen VLANs, I find it intuitive and even enjoyable to work on. It feels kinda like editing source code - there are some host, network, and port declarations at the top, a section for NAT and egress, then a section for each VLAN that contains the pass in/pass out rules.
I tail the pflog0 interface in a tmux session so I can keep an eye on pass/block, and also keep a handy function in my .profile to make it easy to edit the ruleset and reload:
I haven't used Linux as a gateway in years, so I can only compare pf to iptables. The two biggest differences are the way the rules are applied and the logging.
pf rules work a little backwards compared to iptables. A packet traverses the entire ruleset and the last rule to match wins. You can short-circuit this with a "quick" directive. It takes a bit of getting used to coming from iptables.
The logging on pf doesn't integrate with syslog automatically like iptables does. You're expected to set up a logging system for your particular use case. There are several ways to do it, and for production you'd be doing it regardless, but for honelab setups it's an extra thing you need to worry about.
I prefer pf, but I don't recommend it to people new to firewalls.
It's fine if all you need is a packet filter, but in 2026 I question that many production use cases can get away with just packet filter.
As a host firewall, it's obviously fine, I assume your question is about using pf as a network firewall. Given the threat landscape, you usually want threat protection. At the very least that means close-to-real-time updates from reputation lists. You can script that with pf, but it's not fun. Really, you want protocol dissection and - quite possibly - the ability to decrypt on the box and do payload analysis. Just doing packet filtering doesn't buy you all that much anymore these days, and anything production that requires compliance or that you genuinely care about should be behind what you might also call IPS or layer 7 firewall capabilities.
pf doesn't do any of that. You don't have to use Palo Alto or Cisco for this, either.
If all you need is packet filtering, it's a good option, though.
I'm just glad we don't have to deal with iptables anymore. That said, due to iptables -A crap being embedded in countless tutorials and LLM FFN-head weights, we'll end up needing to keep it fresh in mind for decades to come.
Their BDFL thinks BC breaks are great “we’ll be in a better place” I remember him saying, and has blessed breaking pf multiple times by changing the rule syntax, whereas prior versions of this book are suddenly obsolete along with countless tutorials, forum posts, etc.
This is one thing M$ gets right, in business environments you don’t do that. I wouldn’t use pf for anything outside a home lab.
Per Dr. Marshall Kirk McKusick (as announced in one of the recent BSD conferences), No Starch Press will be publishing the third edition of the Design and Implementation of the FreeBSD Operating System book sometime later this year.
Chapter 1, config files don’t go in /etc. Well they do, but also /var. And also here and also there. It’s like linux you get a free treasure hunt built in when you need to update something. Some services get local_ attached even though all the services are local. Somehow NetBSD is able to avoid all of this. But do you want working drivers or not? End of chapter 1.
Actually FreeBSD is great and for a modern OS better than linux in all ways but ecosystem and even there it’s fine. But also the design while it makes sense in some way kind of sucks, it’s messy.
Yeah. My favorite are books that guide you through implementing complex systems projects from scratch, like Nora Sandler's "Writing a C compiler", or Sy Brand's "Building a Debugger". I wish they produced A LOT more of them.
The central point behind this type of books isn't so much to build an enterprise-grade production-ready thing, but rather to bridge the delta between zero and having a working thing of sufficiently large complexity, which inevitably exists for someone who had never been there before. Having that in mind, I think these books are very valuable.
I buy ebooks straight from publishers like Nostarch and Leanpub. (In fact, I have an older edition of this book). There are a few books that are sold directly by the authors too. All of them DRM-free.
I actively avoid publishers and sellers who don't respect me as a consumer/reader. People need to start demanding better deals, or else we'll end up with monopolies that won't think twice about deleting books in your custody that you purchased from them.
I wish I had more of them. I maintain a modest library made out of real paper and I'm so glad No Starch still has good quality paper and excellent binding. I have a few of the more recent print on demand O'Reilly books but they feel more like cheap print outs I could have done myself. Unfortunately they are just so expensive so I do have to be very selective.
It's a great book, I used to have some edition of it and it helped me a lot professionally with setting up firewalls, load balancing, traffic shaping and more.
I also had a book on Designing FreeBSD rootkits that was very educational.
Unfortunately I've given away all my books for more minimalistic living where I am instead dependent on digital information. Not sure how to feel about it.
I almost did the same and still think about doing it! I also have an older edition of this book somewhere in a small stack of OpenBSD books I purchased when I was first learning the system. These days I never reference them. But they do make for a neat OpenBSD area on my bookshelf.
I started listening to audiobooks a few years ago, even re-listened to a lot of classics I read, but in audio format. And at some point when I was ready to move to a new apartment I realized my bookshelves were just a burden. They were never used, and only gathered dust.
So I donated all my books.
I'm not saying I've learned everything, but I am senior now so all those old computer books are just collecting dust. Combined with the fact that I use search engines for everything I need to know.
I realize that if the internet goes out, I'm fucked, but I don't care.
I'd love something similarly scoped centered around nftables. Does anyone have a suggestion? I see No Starch has a Linux Firewall book, but it's from 2008 and is thus iptables-based.
In Linux, even with nftables you still have the concepts of "chains" which goes all the way back to the ipchains days. IME this isn't a particularly helpful way of viewing things. With PF you can simply make your policy decisions on in or out and on which interface(s). Also I'm not sure I ever saw a useful application of why you'd apply a policy on the pre/post-routing chains that wasn't achievable elsewhere in PF and in a simpler way.
Also I've never been a fan of having a command that just inserted or deleted a policy instead of working from a configuration file. (nft "config" files are really just scripts that run the command successively.) I get why some folks would want that (it probably makes programmatic work a lot easier) but for me it was never a benefit.
Anyhow it's been a long time since I've had to do this kind of thing so maybe I'm out of touch on the details. Happy to hear about how I'm wrong lol.
I tail the pflog0 interface in a tmux session so I can keep an eye on pass/block, and also keep a handy function in my .profile to make it easy to edit the ruleset and reload:
This opens the file for editing, reloads the ruleset (which also validates it), then returns the rule count if successful.pf rules work a little backwards compared to iptables. A packet traverses the entire ruleset and the last rule to match wins. You can short-circuit this with a "quick" directive. It takes a bit of getting used to coming from iptables.
The logging on pf doesn't integrate with syslog automatically like iptables does. You're expected to set up a logging system for your particular use case. There are several ways to do it, and for production you'd be doing it regardless, but for honelab setups it's an extra thing you need to worry about.
I prefer pf, but I don't recommend it to people new to firewalls.
As a host firewall, it's obviously fine, I assume your question is about using pf as a network firewall. Given the threat landscape, you usually want threat protection. At the very least that means close-to-real-time updates from reputation lists. You can script that with pf, but it's not fun. Really, you want protocol dissection and - quite possibly - the ability to decrypt on the box and do payload analysis. Just doing packet filtering doesn't buy you all that much anymore these days, and anything production that requires compliance or that you genuinely care about should be behind what you might also call IPS or layer 7 firewall capabilities.
pf doesn't do any of that. You don't have to use Palo Alto or Cisco for this, either.
If all you need is packet filtering, it's a good option, though.
This is one thing M$ gets right, in business environments you don’t do that. I wouldn’t use pf for anything outside a home lab.
Actually FreeBSD is great and for a modern OS better than linux in all ways but ecosystem and even there it’s fine. But also the design while it makes sense in some way kind of sucks, it’s messy.
This one is my favorite.
I actively avoid publishers and sellers who don't respect me as a consumer/reader. People need to start demanding better deals, or else we'll end up with monopolies that won't think twice about deleting books in your custody that you purchased from them.
In all seriousness, how has DRM not yet been recognized as the failure it is?
I also had a book on Designing FreeBSD rootkits that was very educational.
Unfortunately I've given away all my books for more minimalistic living where I am instead dependent on digital information. Not sure how to feel about it.
So I donated all my books.
I'm not saying I've learned everything, but I am senior now so all those old computer books are just collecting dust. Combined with the fact that I use search engines for everything I need to know.
I realize that if the internet goes out, I'm fucked, but I don't care.