OSS routers

Open-source network operating systems — the software layer that turns a commodity box (or VM) into a router/firewall: stateful filtering, NAT, VPN termination, dynamic routing, VLANs. The genre’s defining split: control plane (how you define config — web UI, CLI, API) vs data plane (what moves packets — kernel stack, nftables, eBPF/XDP, userspace VPP). The 2020s question is whether the BSD lineage’s “one integrated appliance” model survives against the Linux lineage’s pluggable data planes and API-first control planes.

The field (all captured)

• pfsense (OSS) (5.7k★, PHP, Apache-2.0) — the incumbent: m0n0wall fork (2004), FreeBSD foundation, pf packet filter. The homelab/SMB default for two decades; NETGATE’s commercial hardware funds CE development. The KRZ connection: the MikroTik-at-home + pfSense research lane (~/projects/pfsense — Ansible playbooks, API-driven rule management).
• OPNsense (4.7k★, PHP, BSD-2) — the fork-with-principles: 2014 fork of pfSense itself (the Deciso/bsdperimeter licensing dispute), also FreeBSD/pf. Deciso funds it sustainably, refuses CLA-encumbered contribution, moved to its own licensing, ships a real REST API early. Proof a governance fork can out-engineer its parent on API/automation while sharing the same data plane.
• VyOS (496★ on vyos-1x, Python config engine, GPL) — the config-as-language lineage: descendant of Vyatta; Juniper-style hierarchical CLI (set/delete/show tree), commit-confirm, config sessions. No web UI in core — the CLI is the product, which is why it’s the automation favorite (everything is set commands, instantly Ansible-able). Longevity crisis story: the 1.x rewrite from Perl to this Python engine took years — the Working with legacy code narrative at OS scale.
• nfSensei (nfsensei.org, captured → clippings/nfsensei-org.md; announced by Scott Ullrich — pfSense’s original lead developer — clippings/x-2106634337882141016.md, “Hello world! public early beta”) — the Rust rewrite thesis: Rust core on a Linux foundation, API-first (REST + structured Nushell CLI + web UI as one control plane), and — the distinctive move — three swappable data planes: nftables (kernel), eBPF/XDP (driver fast path), VPP/DPDK (userspace). Candidate-config staging with diff, validate, confirmed commits with rollback; NFPacks extension system (declarative YAML + sandboxed Lua). Early beta — watch, don’t deploy.

The pattern map

• Lineage is a tree, not a list: m0n0wall → pfSense → OPNsense (fork); Vyatta → VyOS → vyos-1x rewrite; now pfSense’s founding developer starts nfSensei on a different foundation (FreeBSD→Linux, PHP→Rust). Each fork encodes a disagreement: OPNsense = governance/licensing; nfSensei = the whole substrate.
• The API divide is the live one: pfSense added REST late (CE lags plus), OPNsense ships it, VyOS is CLI-native (and thus automation-native), nfSensei is API-first. For the ~/projects/pfsense Ansible lane and the Rewriting Ansible roles from K8s operators thesis, the control plane’s API quality is the product.
• Confirm-rollback is converging everywhere (VyOS commit-confirm, nfSensei staged candidates): network config is finally admitting it’s infrastructure-as-code — the same converge/validate/rollback loop as Kubernetes Operators, applied to routing tables.
• Data-plane pluggability is the new axis: the BSD duo ship exactly one (pf); nfSensei offers three. Choice of packet engine per hardware/workload is the “choose your storage backend” move from the DB world arriving in networking.

Related: Kubernetes Operators (reconciliation kin) · Rewriting Ansible roles from K8s operators (the API-first thesis applied) · High Availability (router HA = the hardest failover) · the homelab lane (MikroTik + pfSense research)