pfSense runs on FreeBSD. CacheGuard runs on a custom Linux distribution. The OS choice has practical implications for packet filtering architecture, hardware support, and third-party integration.
Packet filtering: pf vs nftables / iptables
FreeBSD / pfSense: Uses pf (Packet Filter), originally from OpenBSD. pf uses a declarative rule syntax evaluated top-to-bottom with a "last matching rule wins" model:
# pf syntax
pass out on em0 proto tcp from any to any port 443
block in on em0 proto tcp from <blocklist> to any
pf has native support for traffic normalisation, scrubbing, and stateful tracking. Its rule model is elegant for network engineers familiar with OpenBSD tooling.
Linux / CacheGuard: Uses nftables (or iptables). nftables uses a chain-and-table model with explicit jumps:
# nftables syntax
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input ip saddr @blocklist drop
nftables provides better performance than legacy iptables through native sets and maps, and is the current standard in Linux networking. iptables remains supported but is a compatibility layer over nftables in modern kernels.
Performance: Both pf and nftables can saturate 10Gbps+ links on modern hardware for stateful forwarding. At lower traffic volumes (typical SMB), performance differences are not operationally significant.
NAT implementation
pfSense: NAT is part of the pf ruleset. Source NAT, destination NAT, and 1:1 NAT are configured via pf rules or the pfSense GUI which generates pf rules.
Linux: NAT uses the netfilter connection tracking subsystem (conntrack). SNAT, DNAT, and MASQUERADE are iptables/nftables targets in the nat table. The conntrack table tracks connection state for NAT translation.
Both approaches handle standard NAT scenarios equivalently. Linux conntrack has a configurable table size limit — relevant for high-connection-count environments (default 65536 entries, tunable via net.netfilter.nf_conntrack_max).
Hardware driver coverage
FreeBSD and Linux have different driver ecosystems. For network interface cards specifically:
- Intel NICs (e1000, igb, ixgbe, i40e): Well-supported on both
- Realtek NICs: Better Linux support; FreeBSD support has historically lagged for newer chipsets
- Broadcom NICs: Both have support, Linux generally broader
- SR-IOV / DPDK: Linux ecosystem is more mature for virtualised and high-performance networking
For new hardware purchases, both platforms support mainstream server NICs equivalently. For repurposed consumer hardware with Realtek NICs, Linux has a historical edge.
Package ecosystem and update model
pfSense: FreeBSD packages via pkg, plus pfSense-specific packages via the pfSense package manager. Package updates are managed separately from the base OS update. Version locking between base OS and packages is the operator's responsibility.
CacheGuard (LFS-based): No package manager — all components are compiled and integrated at build time. Updates are whole-system updates tested against the full component set. No per-package version management, no pkg commands.
This is the fundamental operational difference: pfSense gives you control over each component's version; CacheGuard removes that surface area entirely and manages it centrally. Neither is universally better — the right choice depends on whether you want per-component control or coordinated stability.
→ https://www.cacheguard.com/pfsense-alternative/
Originally published on the CacheGuard Blog. CacheGuard is free and open source — GitHub.
Top comments (0)