Moving from OpenBSD to FreeBSD for firewalls

Original Article ↗ Hacker News Discussion ↗

Motivation for Moving from OpenBSD to FreeBSD

  • Main driver is performance, especially for 10G firewalls. OpenBSD’s PF and network stack are seen as lagging in SMP scaling and CPU affinity support.
  • FreeBSD offers better multi-core performance, more tunability, and 5‑year support cycles for major releases, which aligns better with long-lived firewall deployments.
  • Existing PF rulesets make staying with PF (via FreeBSD) more attractive than moving to Linux firewall stacks.

OpenBSD Release Model and Corporate Fit

  • Lack of LTS (6‑month release cadence, ~1 year support) is viewed as a serious drawback for large corporate environments with many hosts.
  • Some note that OpenBSD’s modern update tools (syspatch/sysupgrade) make upgrades relatively painless now, in contrast to older, source-based update workflows.
  • Others argue that OpenBSD explicitly doesn’t aim to provide LTS; if you need that, you should choose another OS.

PF vs Linux Firewalling (iptables/nftables/ipfw)

  • PF is repeatedly praised as intuitive, expressive, stable, and very well documented; many consider it vastly nicer than iptables and still preferable to nftables.
  • Linux nftables narrows the gap; some have successfully migrated to nftables-based firewalls and are satisfied, especially when combined with features like flowtables.
  • FreeBSD’s PF diverged from OpenBSD’s; historically more performance-focused vs OpenBSD’s feature/ergonomics focus, but recent work in FreeBSD aims to resync features without breaking compatibility.

10G+ Performance and SMP Concerns

  • Experiences vary: some report big recent OpenBSD TCP performance gains and doubled throughput after upgrades; others still see OpenBSD as “shockingly sluggish.”
  • FreeBSD firewalls in the thread reach ~8 Gbit/s on 10G links with stateful filtering—better than OpenBSD but not wirespeed, and NIC/driver choice matters.
  • Discussion of deep optimizations: per-core queues, lockless/finely locked data structures, CPU affinity, and how OpenBSD deprioritizes such complexity due to security/maintenance concerns.
  • For very high packet rates, some move to ASIC-based gear (e.g., Juniper SRX, Mikrotik ARM boxes) as simpler and more cost-effective than heavily tuned x86 software routers.

Filesystems and Reliability

  • FreeBSD’s root-on-ZFS is a strong selling point to some: snapshots, resilience, and journaling/COW semantics for critical infrastructure.
  • OpenBSD’s FFS/UFS (no journaling, soft updates recently removed) draws criticism as “ancient” and fragile under power loss; others counter that it’s simple, heavily audited, and robust, just slow and lacking modern conveniences.
  • Debate over whether ZFS is overkill or exactly the “just use it everywhere” pragmatic choice; anecdotal reports span from “bulletproof for years” to “only serious issues I’ve ever had.”

Linux vs BSD for Firewalls

  • Some ask why not Linux; answers emphasize PF, OpenBSD’s cohesive base system (DHCP, RA, NTP, SSH, etc.), and the relative stability and consistency of BSD userland and documentation.
  • Counterpoints: Linux offers higher performance, better hardware support, and familiar tooling for many operators; nftables is “pretty nice” and traffic shaping under Linux, while arcane (tc), can be very capable.
  • One view: BSDs make better “set-and-forget” single-purpose appliances; Linux evolves faster but can feel fiddly (interface naming changes, multiple firewall frameworks, container interactions with firewalling).

Culture, Documentation, and Ecosystem

  • OpenBSD is characterized as small, opinionated, security- and correctness-first, with features only added when they solve problems for core developers.
  • Its documentation (especially man pages and FAQs) is widely praised, and the ecosystem is relatively free of low-quality SEO/AI content; the downside is a steeper learning curve and weaker desktop/laptop polish.
  • OpenBSD community is seen as less responsive to “customer-style” feature requests; expectation is to “scratch your own itch.”

Stack/Driver Portability Discussions

  • Some imagine interchangeable TCP/IP stacks and drivers across OSes; related projects mentioned include NDISWrapper, DPDK, and NetBSD’s rump kernel (seen as largely stalled).
  • General sense that deep kernel coupling (as with PF and BSD network stacks) both enables high performance and hinders portability and feature parity across OSes.