The author says that “the thing that lured me in” was PF, and mentions “The Book of PF”.
I like the idea of OpenBSD. However I have been burned many times over the years as they have decided repeatedly that it is okay to make breaking changes to PF’s rule syntax. This means if you’ve installed a dozen PF firewalls for customers, you get to go around reconfiguring all of them. The nature of these types of fixes is particularly problematic and often requires on-site work where out-of-band access is not available.
It also means innumerable copies of “The Book of PF” mentioned are now paperweights, along with hundreds of articles. Readers of such articles get to play a game of “guess whether the advice in this article works or breaks PF”.
I have many problems with Microsoft, but their support for backward compatibility is something they’ve gotten right. I am hesitant to criticize volunteer programmers, but they should take a page from Microsoft’s playbook here.
I no longer use PF because I can’t worry that any day they’ll roll out yet another update that breaks my configurations.
do you have some concrete examples? i have used pf since it was turned on in openbsd (i think around 2001ish) for simple rulesets, and there were certainly some changes that needed config file changes but i don't remember anything hugely painful, actually the changes were for the better.
When they happened, they were always well documented in the "how to upgrade" document and blindly upgrading without reading that is not good practice in any OS, not just openbsd... Then it's just a question of automating it, and there are ways to roll back pf rules with simple scripting...
Regarding the book, they are bound to go out of date, but I think their basic premise stays useful over time: it explains the basic terminology, notions, etc and gives some ideas about how to solve problems with the syntax at the time of writing. The man page can fill in the rest (which is excellent quality).
How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
> How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
I'd argue that it's iptables, and has been for the last 20 years.
In Linux 1.1 (1994) there was a port of FreeBSD's ipfw. ipfw was replaced by ipchains in Linux 2.2 (1999). However, ipchains was quickly replaced by iptables in Linux 2.4 (2001). And now since Linux 3.13 (2014) iptables is slowly being replaced by nftables, but most of its use is the iptables userland being ported to use the nftables kernel interface; the nftables native userland (`nft`) only just hit 1.0.0 this month.
Other higher level "more user friendly" wrappers have come and gone; Ubuntu's ufw (which wraps iptables), RedHat's firewalld (which wraps nftables), and uh one for each finger of my hand. But at the end of the day, they're iptables/nftables under the hood, and when you want to configure things they way you would with pf, you skip those layers and go straight for iptables.
FreeBSD’s PF avoided this. The downside is obviously the lack of nice new things like ‘rdr-to’ rules, but FreeBSD PF is also SMP-capable as of FreeBSD 10.0 (a long time ago) so its a fair trade imo
Controlling the narrative, to grow Microsoft in the minds of people and easily skip the massive issues around telemetry and backdoor agreements for any three letter agency. The enemy seems to be independent firewalls that do not contain binary blobs to allow covert snooping. To avoid these they attack the mindset and influence the decision making processes. Architects have there heads in thin air 1) to stay connected with upper management which tells them to only use well known, kickback fee inducing, brands 2) keep the job.
They made breaking changes as recently as 6.9 (May 2021). Major breaking changes go farther back, but the threat of new breaking changes is ever present since this is, as another commenter mentioned, just the philosophy of the project. That makes it unusable for me in anything beyond a home lab, but others may have different scenarios.
It makes me pretty sad to read this. I always liked their no compromise approach with regards to security. Seems they took Haskells' "Avoid success at any cost" literally.
The release notes describe the change and you have a full six months of supported security patches to make the change given their support / release schedule.
If you aren't looking at your pf.conf every six months, I would be concerned.
This is kind of OpenBSD's vibe. They tend to be ok with breaking backwards compatibility in favor of their idea of forward progress.
It's pretty counter to Microsoft's incredible investment in backwards compatibility. Or Linus' "don't break user land" philosophy.
I'd think if we had a spectrum of backwards compatibility, with the most being on the right it might look something like this:
OpenBSD ---> macOS/iOS ---> Linux ---> Microsoft
I think in the OpenBSD case, due to limited developer resources, and a cultural bias towards simplicity, this is the tradeoff they decided to make. Even at the cost of more users.
>and a cultural bias towards simplicity, this is the tradeoff they decided to make
Literally the only point of an operating system is to be a stable API for other people to write software on top of. If you're not doing that, then why make an OS?
I don't think people are using PF to write software on top of -- they use OpenBSD specifically to run PF. You should look at upgrading OpenBSD in this use case to upgrading the firewall software.
It's a different case than mere "I compiled this application 6 months ago and I want to run it today", which is the "stable API" part of an OS that you mention.
Just a hint, HardenedBSD and with that FreeBSD the base of OPNsense had no change in the PF-syntax since years..just additions. I think that's why pfsense and opnsense chose freebsd and not openbsd....well and smp.
One thing I find appealing about OpenBSD is the simplicity. There are almost no daemons running on a default install. There's a greater sense of being able to figure out how the whole thing works compared to, obviously, Linux.
It used to be part of the kernel back in the day. It was called devfs. It was dropped because a userkspace implementaton is more flexible and easier to extend and tweak. udev also isn't the only choice, mdev also exists and works without running an actual daemon (there is a file in /sys or /proc which specifies a program to run on hardware events, mdev handles the event, then quits).
Of course, nowadays devtmpfs is also a thing, fully kernel space, but not at all configurable. Mostly meant for early user space like initrd and such. But if you don't need anything special it might work for you during regular use, too.
The file system layout, configuration file syntax, and man pages are just far more coherent. Using Linux a lot then trying OpenBSD, after getting familiar with the general layout, it's clear OpenBSD is more rigorous with where files go and the system as a whole.
I had some trouble setting up a network connection with my ISP. My ISP does not share technical connection details favouring you just plug in their provided router. Never doing Kernel dev or C before, I was able to go into the OpenBSD kernel code, spot the logline I was seeing in the logs, see why my config was failing by checking the logic and fix my config. This was only just after trying OpenBSD for the first time and being extremely unfamiliar.
The sad thing is outside of my router, I've not found an opportunity to run OpenBSD. On servers, I mainly use NixOs for declarative setup. Also, with Docker being ubiquitous today, I need to be able to run containers natively serverside.
The same for the desktop, if I switch from OSX to OpenBSD, I'm making a few sacrifices with not much advantage as a desktop user, but if I switched to Linux, at least I'd get native Docker support to compensate for some of the things I'd lose not using OSX anymore.
39 comments
[ 2.7 ms ] story [ 84.5 ms ] threadI like the idea of OpenBSD. However I have been burned many times over the years as they have decided repeatedly that it is okay to make breaking changes to PF’s rule syntax. This means if you’ve installed a dozen PF firewalls for customers, you get to go around reconfiguring all of them. The nature of these types of fixes is particularly problematic and often requires on-site work where out-of-band access is not available.
It also means innumerable copies of “The Book of PF” mentioned are now paperweights, along with hundreds of articles. Readers of such articles get to play a game of “guess whether the advice in this article works or breaks PF”.
I have many problems with Microsoft, but their support for backward compatibility is something they’ve gotten right. I am hesitant to criticize volunteer programmers, but they should take a page from Microsoft’s playbook here.
I no longer use PF because I can’t worry that any day they’ll roll out yet another update that breaks my configurations.
When they happened, they were always well documented in the "how to upgrade" document and blindly upgrading without reading that is not good practice in any OS, not just openbsd... Then it's just a question of automating it, and there are ways to roll back pf rules with simple scripting...
Regarding the book, they are bound to go out of date, but I think their basic premise stays useful over time: it explains the basic terminology, notions, etc and gives some ideas about how to solve problems with the syntax at the time of writing. The man page can fill in the rest (which is excellent quality).
How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
I'd argue that it's iptables, and has been for the last 20 years.
In Linux 1.1 (1994) there was a port of FreeBSD's ipfw. ipfw was replaced by ipchains in Linux 2.2 (1999). However, ipchains was quickly replaced by iptables in Linux 2.4 (2001). And now since Linux 3.13 (2014) iptables is slowly being replaced by nftables, but most of its use is the iptables userland being ported to use the nftables kernel interface; the nftables native userland (`nft`) only just hit 1.0.0 this month.
Other higher level "more user friendly" wrappers have come and gone; Ubuntu's ufw (which wraps iptables), RedHat's firewalld (which wraps nftables), and uh one for each finger of my hand. But at the end of the day, they're iptables/nftables under the hood, and when you want to configure things they way you would with pf, you skip those layers and go straight for iptables.
Why do you mention Microsoft: "I have many problems with Microsoft"
Because of the backward compatibility, Solaris/illumos is maybe comparable.
If you aren't looking at your pf.conf every six months, I would be concerned.
It's pretty counter to Microsoft's incredible investment in backwards compatibility. Or Linus' "don't break user land" philosophy.
I'd think if we had a spectrum of backwards compatibility, with the most being on the right it might look something like this:
OpenBSD ---> macOS/iOS ---> Linux ---> Microsoft
I think in the OpenBSD case, due to limited developer resources, and a cultural bias towards simplicity, this is the tradeoff they decided to make. Even at the cost of more users.
Literally the only point of an operating system is to be a stable API for other people to write software on top of. If you're not doing that, then why make an OS?
It's a different case than mere "I compiled this application 6 months ago and I want to run it today", which is the "stable API" part of an OS that you mention.
Surely there are other considerations beyond stability to be had when choosing an operating system?
Linus want's that the OracleDB's of the World can run on his system...that's is fine i think ;)
FreeBSD is also compatible down to FreeBSD 4 (March 2000)
macOS deprecated a lot of kernel APIs from Catalina to Big Sur, but there were tons that were around for a decade before.
Which firewall did you transition to? I am on the edge between continuing on PF on NetBSD or converting to NPF.
Excuse me, I meant ipchains.
Oh, silly me, iptables.
In my opinion the dream is to have a system with literally just a kernel running, ready for user interaction.
Of course, nowadays devtmpfs is also a thing, fully kernel space, but not at all configurable. Mostly meant for early user space like initrd and such. But if you don't need anything special it might work for you during regular use, too.
The file system layout, configuration file syntax, and man pages are just far more coherent. Using Linux a lot then trying OpenBSD, after getting familiar with the general layout, it's clear OpenBSD is more rigorous with where files go and the system as a whole.
I had some trouble setting up a network connection with my ISP. My ISP does not share technical connection details favouring you just plug in their provided router. Never doing Kernel dev or C before, I was able to go into the OpenBSD kernel code, spot the logline I was seeing in the logs, see why my config was failing by checking the logic and fix my config. This was only just after trying OpenBSD for the first time and being extremely unfamiliar.
The sad thing is outside of my router, I've not found an opportunity to run OpenBSD. On servers, I mainly use NixOs for declarative setup. Also, with Docker being ubiquitous today, I need to be able to run containers natively serverside.
The same for the desktop, if I switch from OSX to OpenBSD, I'm making a few sacrifices with not much advantage as a desktop user, but if I switched to Linux, at least I'd get native Docker support to compensate for some of the things I'd lose not using OSX anymore.