Skip to content

Deprecated pfSense Flow-Control Plane

Status

Deprecated — pfSense was explored as the default firewall and flow-control plane, but it is not the current HybridOps baseline. The active operator path is the VyOS-based edge control plane.

Status note

Retain this ADR as a historical or customer-specific variant reference only. For the current supported operating path, follow:

Context

Earlier prototypes explored whether pfSense should become the primary flow-control layer across the platform. Since then, the implemented platform has converged on VyOS-based edge automation for the default WAN and site-extension path.

This ADR remains to record that pfSense was considered seriously, along with the trade-offs that made it appealing for some environments.

Earlier prototypes relied solely on CSR1000v or VyOS for both routing and firewalling.
This blurred responsibilities around:

  • Session state tracking
  • NAT and policy routing
  • Deep packet inspection and logging

Troubleshooting during failover and DR simulations became more complex and less auditable.

pfSense CE (and optionally pfSense Plus) brings:

  • Mature stateful inspection firewall engine
  • Granular inbound/outbound NAT and policy routing
  • Built-in CARP (Common Address Redundancy Protocol) for HA pairs
  • Integrated IPsec and OpenVPN support
  • Strong compatibility with monitoring and automation (XMLRPC API, emerging REST endpoints)

Separating routing (CSR/VyOS) from flow-control and security (pfSense) improves clarity and auditability across hybrid boundaries.

Decision

Do not treat pfSense as the default HybridOps flow-control plane for new deployments.

pfSense may still be used deliberately as a historical, lab, or customer-specific variant where its stateful firewall and CARP model are desired, but it is not the baseline operator path.

Design Principles

  • Layered defence:
  • Proxmox / routers provide intra-site routing and VLAN gateways (ADR-0102)
  • pfSense appliances enforce perimeter and policy controls
  • HA pairing:
  • Use CARP for virtual IPs and XMLRPC for configuration sync between fw-01 and fw-02
  • Policy routing:
  • Use gateway groups for steering traffic across dual ISPs (ADR-0106)
  • Distinguish internet, IPsec, and DR paths
  • Telemetry:
  • pfTop, netflow, and SNMP integration with Prometheus/ELK stack
  • DR support:
  • Reuse configuration patterns for cloud pfSense instances (e.g., pfSense+ in Azure)

Consequences

Positive

  • Clear demarcation between routing (CSR/VyOS), firewalling (pfSense), and applications
  • Native HA through CARP and automatic config synchronisation
  • Transparent traffic shaping and NAT tracking during DR cutover
  • Strong story for “enterprise-style” firewalling layered onto your core/edge design

Negative

  • Adds at least one extra VM per site for HA (acceptable trade-off)
  • Automation APIs are more limited than pure network OS; Ansible roles rely on SSH/XMLRPC

Neutral

  • pfSense can be combined with other firewalls (e.g., cloud-native firewalls) in future ADRs
  • Migration to pfSense Plus or alternative firewalls remains possible without redesigning the overall pattern

References

Maintainer: HybridOps License: MIT-0 for code, CC-BY-4.0 for documentation unless otherwise stated.