For network engineers, SecOps architects, and infrastructure leads managing mission-critical enterprise boundaries or homelab environments, single-firewall architecture is an unacceptable operational risk. A single power supply failure, corrupted NVMe boot drive, or frozen kernel update on an edge router will instantly sever WAN connectivity, killing active IPsec tunnels, dropping VoIP sessions, and halting remote worker access. In the open-source firewall landscape, OPNsense provides enterprise-grade resilience through Common Address Redundancy Protocol (CARP) and pfsync state synchronization. But configuring a true active-passive high-availability (HA) cluster requires precise Layer 2 network engineering, dedicated sync interfaces, and surgical XMLRPC replication rules to avoid split-brain disasters.

What Is the Architecture of an OPNsense CARP HA Cluster?

To understand why CARP is vastly superior to crude DNS round-robin or simple gateway monitoring, one must inspect how CARP (RFC 3768 / 5798 derivative) operates at Layer 2 and Layer 3. CARP allows multiple physical hosts on the same network segment to share a common virtual IP and virtual MAC address (formatted as 00:00:5e:00:01:XX, where XX is the Virtual Host ID / VHID). The Master node continuously broadcasts CARP heartbeats at Layer 2 (IP protocol 112) at regular intervals (typically once per second). As long as the Backup node receives these advertisements, it remains silent.

However, floating IP failover alone is useless if the backup firewall knows nothing about active connections. If the Master dies and the Backup takes over without synchronized connection tables, every connected workstation, database query, and SSH session will have their TCP packets rejected with TCP RST flags because the backup node has no record of the TCP three-way handshake. This is where pfsync (Packet Filter State Synchronization) provides the critical second pillar. pfsync transmits state table creation, update, and deletion packets over a dedicated physical network interface. Both firewalls maintain an identical, live clone of every connection state. When failover occurs, the transition is completely transparent to end users.

OPNsense CARP High Availability: Architecture & Dimension Matrix

Evaluating the network prerequisites, synchronization protocols, and operational trade-offs of an HA deployment:

The Dedicated Sync Interface: Why You Must Never Share with LAN

The single most dangerous design flaw in beginner HA setups is running pfsync state synchronization over the general production LAN interface. pfsync transmits unencrypted, high-volume state update packets using IP protocol 240. Under heavy network traffic (such as multiple users running multi-gigabit file transfers or backup jobs), the LAN interface can experience micro-congestion or packet queue drops.

If pfsync heartbeat packets are dropped for more than three seconds, Node 2 will assume Node 1 has died and immediately transition its CARP interfaces from Backup to Master. Both firewalls will now broadcast CARP Master status and fight over the same virtual MAC address, causing catastrophic split-brain ARP flapping that brings down the entire network. Always assign a dedicated physical Ethernet port (or direct DAC cable) connecting Node 1 directly to Node 2 for pfsync and XMLRPC sync on an isolated subnet (e.g., 10.99.99.0/30).

XMLRPC Configuration Synchronization & The “Never Edit Node 2” Law

OPNsense features an automated configuration synchronization engine powered by XMLRPC over HTTPS. On the Master firewall, you navigate to System > High Availability > Settings and specify the sync peer IP (Node 2’s sync interface IP) along with the root credentials. You then select exactly which subsystems to replicate: firewall aliases, filter rules, NAT port forwards, DHCP leases, DNS unbound records, and VPN configurations.

Every time you click “Save” or “Apply” on Node 1, OPNsense pushes an XMLRPC payload to Node 2, updating its internal config.xml and triggering a silent reload of the PF filter engine. This leads to the fundamental rule of OPNsense HA: Never edit firewall rules directly on Node 2. Any manual changes made on the backup firewall will be ruthlessly overwritten the next time the master executes an XMLRPC sync.

Systems Checklist: Step-by-Step OPNsense HA Commissioning

Frequently Asked Questions About OPNsense High Availability

Can I run an OPNsense HA cluster with only one public WAN IP from my ISP?
Standard CARP requires 3 static public WAN IPs (one for Node 1, one for Node 2, one for the floating CARP VIP). If your ISP provides only a single dynamic or static public IP, you must place a cheap managed switch in front of the firewalls or deploy an upstream edge router running VRRP.

Will active WireGuard tunnels fail over automatically?
Yes, provided WireGuard is configured to listen on the CARP VIP and your remote peers connect to that VIP. The WireGuard handshake will re-establish seamlessly on the backup node within 2 to 5 seconds of failover.

What happens if the dedicated sync cable is disconnected?
If only the sync cable is cut, pfsync state updates stop, but CARP heartbeats on LAN and WAN continue. Node 2 remains in standby. However, if failover occurs while sync is severed, connection states will be lost, requiring clients to re-establish TCP handshakes.

Perimeter Inspection & Stateful Threat Filtering

High-availability clustering must be paired with deep packet inspection and intrusion detection. Review deep Layer 7 packet inspection in our benchmark on Zenarmor vs Suricata: OPNsense Layer 7 Filtering.