Moving from OpenBSD to FreeBSD for firewalls
utcc.utoronto.ca129 points by zdw 5 days ago
129 points by zdw 5 days ago
Root on ZFS is an easy sell for me. OpenBSD's ancient filesystem is notoriously flaky, and they have no interest in replacing it anytime soon.
I can't be worried that critical parts of my network won't come back up because the box spontaneously rebooted or the UPS battery ran out (yes it happens — do you load test your batteries — probably not) and their bubblegum-and-string filesystem has corruption and / and /usr won't mount and I gotta visit the console like Sam Jackson in Jurassic Park to fsck the damn thing.
Firewalls are critical infra — by definition they can't be the least reliable device in the network.
I once wrote a similar post to an DVD industry centric mailing list (remember those?) regarding switching to FCP7 from Adobe Premiere with a huge difference in how FCP7 would allow capturing of discrete audio channels vs Premiere forcing an interleaved audio stream. Eventually, a rep from Adobe contacted me through my company's PR team (a first for me) to go over the list of complaints. At the end, he agreed these were all valid complaints, and then asked "if Premiere added these changes would I be willing to switch back"? At that point, I said probably not as we'd now be fully switched to FCP7 in all departments. So I understand that sentiment as well. Honestly, I was shocked that someone actually read my missive and actually paid any mind to it. So maybe someone at OpenBSD will be as receptive if not equally unable to do anything about it.
As noted, recent changes to OpenBSD TCP handling[1] may improve performance.
On a 4 core machine I see between 12% to 22% improvement with 10 parallel TCP streams. When testing only with a single TCP stream, throughput increases between 38% to 100%.
I'm not sure that directly translates to better pf performance, and four cores is hardly remarkable these days but might be typical on a small low-power router?
Would be interesting if someone had a recent benchmark comparison of OpenBSD 7.8 PF vs. FreeBSD's latest.
[1] https://undeadly.org/cgi?action=article;sid=20250508122430
That particular change improves throughput received locally. Though over the past few years there's been a ton of work on unlocking the network layer generally to support more parallelism.
For a firewall I guess the critical question is the degree of parallelism supported by OpenBSD's PF stack, especially as it relates to common features like connection statefulness, NAT, etc.
Thanks. Yes after I posted that I started wondering if it was really relevant to pf.
Can confirm. Lots of performance improvements lately in OpenBSD. Our Load Balancers basically doubled throughput after updating from 7.6 to 7.7
I am not very familiar with FreeBSD's pf but my understanding is that fbsd integrated it from OpenBSD and then proceeded to put a fair amount of work in making it more performant(multi core) while OpenBSD put most of it's work into improving pf's features, At this point the two pf's are different enough that they are not really compatible. OpenBSD can't really use much of fbsds multi core work and FreeBSD is A. Is a lot more hesitant about breaking backwards compatibility and B. would need get the queuing structures to work with their kernel.
In fact if you asked me to explain the difference between obsd and fbsd it is exactly this. fbsd focuses on performance and obsd focuses on ergonomics.
So you don't like OpenBSD, but you do like Ubuntu?
This person seems like they know wht they are talking about and given it serious thought, but I cannot fathom how you could make such a conclusion today.
If they're concerned about performance, yeah. OpenBSD doesn't do the basics that you need to get the most out of your SMP hardware; there's no way to set cpu affinity at least from userland, and it's clear that this sort of work is not a priority for OpenBSD; it's not easy work, but FreeBSD has done it. Beyond CPU affinity, you also need your network structures setup to reduce lock contention, things like fine grained locks, hashed subtables and/or "lockless" tables, configuring the NICs as close as possible to one queue per core and keeping flows on the same queue which is pinned to a single core so that the per flow locks never contend and don't bounce between cores.
Ubuntu/Linux do have reasonable performance, but I think they prefer PF firewalls, so that makes Linux a non-option for firewalls.
Personally, I don't really care for PF, but it offers pfsync, which I do care for, so I use it and ipfw... but I need to check in, I think FreeBSD PF may have added the hooks I use ipfw for (bandwidth limits/shaping/queue discipline).
It's not necessarily that OpenBSD can't implement the basics, it's that they don't want to. A lot of the high-performance features introduce potential security vulnerabilities. Their main focus is security and correctness. Not speed.
> A lot of the high-performance features introduce potential security vulnerabilities.
I am particularly-reminded of speculative execution optimizations allowing attacks like Spectre and Meltdown in 2017.
https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...
> "there's no way to set cpu affinity at least from userland"
How is that even possible. What's the excuse?
On Windows, setting process affinity has been around since the Windows NT days.
The gp already answered you, "this sort of work is not a priority for OpenBSD."
OpenBSD is a small, niche operating system, and it really only gets support for something if it solves a problem for someone who writes OpenBSD code. In a way, this is nice, because you never get half-assed features that kinda-sorta work sometimes, maybe. Everything either works exactly as you'd expect, or it's just not there.
I love OpenBSD, but there are some tasks it's just not suited for, and that's fine, too.
I was pretty sure I had seen a mailing list post from Theo about it, but I can't find it now. The only relevant thread I can find is this one [1], which pretty much just says "we don't do it for userland"; but does say it is available inside the kernel, and I have seen some mentions in recent release notes for OpenBSD of binding PF things by toeplitz hash, which indicates the right progression for that ... but it's still hard to get max performance from a simple network daemon without binding the userland threads to same core that the kernel processes the flow with. Once your daemon starts doing substantial work, binding cpus isn't as important, but if it's something like an authoritative DNS server or HAProxy with plain sockets, the performance benefit from eliminating cross-core communication can be tremendous.
It's the OS's job to manage resources.
The OS doesn't always know everything about workloads to be able to make the right decisions.
It appears they have different requirements for those machines. They state the Ubuntu machines are for non-firewall applications. Ubuntu and Debian can configured relatively easily for a number of workstation and server roles.
Also many IT professionals that have used Linux will be familiar with a Debian or a Debian derivative such as Ubuntu. That simply isn't the case with OpenBSD.
I recently installed OpenBSD on my old laptop to try it out and I found it difficult even though I used to use it at University back in the late 2000s.
It's actually pretty shocking how poorly and sluggish OpenBSD performs, and it's not meaningfully more secure than a properly-configured Linux or freebsd box.
I'm honestly not sure what its use case is in 2025, beyond as a research OS.
I find it a bit odd that they seem to have gone from having OpenBSD as the standard and are not moving to FreeBSD and Ubuntu.
I an not sure what role these computers that may transition to Ubuntu do, there are probably good reasons, I wish he had expanded on it.
The computers that moved from OpenBSD to Ubuntu were our local resolving DNS servers. These don't use PF and we also wanted to switch from our previous OpenBSD setup to Bind, where we were already running Bind on Ubuntu for our DNS master servers. The gory details were written up here: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UsingBindN...
We may at some point switch our remaining OpenBSD DHCP server to Ubuntu (instead of to FreeBSD); like our DNS resolvers, it doesn't use PF, and we already operate a couple of Ubuntu DHCP servers. In general Ubuntu is our default choice for a Unix OS because we already run a lot of Ubuntu servers. But we have lots of PF firewall rules and no interest in trying to convert them to Linux firewall rules, so anything significant involving them is a natural environment for FreeBSD.
(I'm the author of the linked-to article.)
Why do you say OpenBSD stopped "supporting bind"? You mean they don't include it in the base system anymore since the switch to unbound?
I mean.. It's one pkg_add away. It's a weird constraint to give yourself if that was the problem, considering you absolutely had to install it on your replacement ubuntu servers.
What's wrong with Linux for firewalls? Either openwrt, or any distro really.
Why would any BSD perform better?
(edit: genuinely curious why BSDs are such popular firewalls)
Compared to working with iptables, PF is like this haiku:
A breath of fresh air,
floating on white rose petals,
eating strawberries.
Now I'm getting carried away:
Hartmeier codes now,
Henning knows not why it fails,
fails only for n00b.
Tables load my lists,
tarpit for the asshole spammer,
death to his mail store.
CARP due to Cisco,
redundant blessed packets,
licensed free for me.
Nftables has improved the situation on Linux somewhat, but PF is incredibly intuitive and powerful. A league of its own when it comes to firewalling.
Has there ever been an effort to port PF over to linux, or to create an adaption layer that makes things compatible?
pf has been ported to Debian/kFreeBSD, but afaik no effort has been made to port it to the Linux kernel. A lot of networking gear already runs a BSD kernel, so my guess is the really high-level network devs don't bother because they already know BSD so well.
One thing I like about using OpenBSD for my home router is almost all the necessary daemons being developed and included with the OS. DHCPv4 server/client, DHCPv6 client, IPv6 RA server, NTP, and of course SSH are all impeccably documented, use consistent config file formats/command-line arg styles, and are privilege-separated with pledge.
I assume in this case they already had a bunch of firewall rules for PF and switching from OpenBSD -> FreeBSD is a much easier lift then going to linux because both the BSDs are using PF, although IIRC there are some differences between both implementations.
I've used both and the main advantage is PF/ipfw syntax.
But now with nftables I actually am going back to RHEL on Firewalls. I want something ultra-stable and long lived.
I've been using OpenBSD and PF for nearly 25 years (PF debuted December 2001). Over those years there have been syntax changes to pf.conf, but the most disruptive were early on, and I can't remember the last syntax change that effected my configs (mostly NAT, spamd, and connection rate limiting).
During that time the firewall tool du jour on Linux was ipchains, then iptables, and now nftables, and there have been at least some incompatible changes within the lifespan of each tool.
OpenBSD has an additional leg up in that incompatible changes between releases are concisely, clearly, and consistently documented, e.g. https://www.openbsd.org/faq/upgrade78.html The last incompatible pf.conf syntax change I could find was for 6.9, nearly 5 years ago, https://www.openbsd.org/faq/upgrade69.html
What's wrong with using any BSD? Can't people use whatever suits their needs?
Of course, I'm genuinely curious why BSDs are more popular as firewalls.
Because of pf[1]. It's just a very capable firewall with a pleasurable configuration language.
Agreed, `pf` is a delight to use.
Borrowing a demonstration from https://srobb.net/pf.html
tcp_pass = "{ 22 25 80 110 123 }"
udp_pass = "{ 110 631 }"
block all
pass out on fxp0 proto tcp to any port $tcp_pass keep state
pass out on fxp0 proto udp to any port $udp_pass keep state
<action> <direction> on <interface> proto <protocol> to <destination> port <port> <state instructions>
The documentation on BSDs, and in particular OpenBSD, are generally high quality
We migrated to a linux nftables based firewall.
I never liked iptables, but nftables is pretty nice to write and use.
And with one "flowtable" line added to your nftables.conf you can even in theory have faster routing when conntrack is active
https://thermalcircle.de/doku.php?id=blog:linux:flowtables_1...
PF is really nice. (Source: me. Cissp and a couple decades of professional experience with open source and proprietary firewalls).
And if they are already using it on openbsd, it’s almost certainly an easier lift to move from one BSD PF implementation to another versus migrating everything to Linux and iptables.
Agreed. Once you've gone pf you'll pine for it when working with anything else.
I've gotta me-too this. I've written any number of firewall rulesets on various OSes and appliances over the years, and pf is delightful. It was the first and only time I've seen a configuration file that was clearly The Way It Should Be.
The only configuration language I like more is Juniper. I picked that up and became fluent in it within about a day.
Because of PF or Packet Filter (the PF in pfSense FWIW): https://en.wikipedia.org/wiki/PF_(firewall)
Let me extend the question to what’s wrong with NFTables on Linux? It’s a different way to manage Netfilter, out of IPTables
> There are some things about FreeBSD that we're not entirely enthused about.
Damn I wish that they had expanded on this a bit (not to start a flame war, but to give readers a fuller picture, or even to prod the FreeBSD community into "fixing" those things)
edit: typo fix
For me, the only drawback for corporations is the 6 month upgrade. There is no LTS on OpenBSD.
I use OpenBSD as a workstation and it works great, but in a production environment I doubt I would use OpenBSD for critical items, mainly because no LTS.
It is a sad state of affairs because Companies do not want nor will want a system you need to upgrade so often even if its security very good.
On the other hand though, updates on OpenBSD are the most painless updates I have ever done. I am more concerned about it's usage of UFS instead of something more robust for drives.
I'm grossly generalizing here, but it seems like OpenBSD boxes seem to be commonly used for the sorts of things that don't write a lot of data to local drives, except maybe logfiles. You can obviously use it for fileservers and such but I don't recall ever seeing that in the wild. So in that situation, UFS is fine.
(IMO it's fine for heavier-write cases, too. It's just especially alright for the common deployment case where it's practically read-only anyway.)
I've used it as a mail server, a web server, and a database (postgres) server. It's also my main desktop OS. Did/does fine, but I never really stressed it. I would certainly welcome a more capable filesystem option, as well as something like logical volumes, but I can't say that ufs has ever failed me.
You'll definitely want to have it on a UPS to avoid some potentially long and sometimes manual intervention on fscks after a power failure. And of course, backups for anything important.
Yet companies insist on enabling unattended upgrades at least for "security" patches, which have introduced breakage or even their own vulnerabilities in the past (Crowdstrike was a recent dramatic example).
OpenBSD will just tell you that maintaining an LTS release is not one of their goals and if that's what you need you'll be better served by running another OS.
I don't understand why this has 29 points and no comments. What's so amazing about this?
I just like the reference to 10G ethernet. It can't become normal soon enough.
I imagine a near future where TCP/IP stacks, and device drivers are interchangeable between operating systems. In Linux, NDISWrapper [1] enables to use Windows drivers in Linux but it's a wrapper (with all due respect to this project).
Sorta, but only with ancient windows XP drivers. It was a useful stopgap of it's era but linux networking drivers have more than caught up in the meantime.
Microsoft started out with BSD's TCP/IP stack, but dropped it for their own (back in Windows 3.5 apparently - https://news.ycombinator.com/item?id=41495551)
Adam Barr, formerly with Microsoft, goes into some detail about it here: https://web.archive.org/web/20051114154320/http://www.kuro5h...
You mean like DPDK?
I'd think something like Rump Kernel's is a closer analogue: https://en.wikipedia.org/wiki/Rump_kernel
Just more navel-gazing from UTCC. I still don't understand why all of these submissions get upvoted so often. 10G performance just really isn't that interesting anymore, maybe around 2005 when it was the new kid on the block. If they were talking about squeezing firewall performance out of a box with a couple of 200g or 400g adapters and on run-of-the-mill CPUs and no offloading or something like Netflix publishes with their BSD work, I'd be more interested.
It reads a bit like someone LARP'ing a sysadmin. Perhaps they're students or something.