OPNsense CARP high availability: the failure modes that actually bite

The firewall is the one box nothing behind it can work without. So the second question after you deploy OPNsense — or migrate to it from pfSense — is how to stop it being a single point of failure. The answer is a CARP high-availability pair. The configuration is not long, but it has sharp edges that the happy-path guides skip, and every one of them surfaces at the worst possible moment: during an actual failover.

OPNsense HA is three separate mechanisms, and almost every HA problem is one of them misbehaving. Understand the three and the failure modes stop being mysterious.

The three parts of OPNsense HA

CARP — the virtual IPs

CARP (Common Address Redundancy Protocol) gives each interface a shared virtual IP that the master owns and the backup takes over if the master disappears. Clients and routes point at the CARP VIP, not at either firewall's real address. Master and backup are chosen by an advertising skew; the lower skew wins. This is the part users see: the gateway IP that keeps working when a box dies.

pfsync — the state table

A firewall tracks the state of every open connection. Without state synchronisation, a failover drops every established session and everyone reconnects. pfsync replicates the state table between the two nodes over a dedicated link, so connections survive the switch. It needs its own interface — do not run pfsync over a link that also carries CARP and heavy traffic.

XMLRPC — configuration sync

You configure the master; XMLRPC pushes the relevant config (firewall rules, NAT, aliases, certificates) to the backup so the two stay identical. It is one-directional by design: you never edit the backup directly. When people say “HA stopped working”, this is usually the part that quietly broke.

The failure modes that actually bite

Outbound NAT on the interface IP instead of the VIP

This is the classic one. If outbound NAT translates to a firewall's real interface address, return traffic comes back to that specific box. When it fails over, the other node is now active but return packets still head for the dead one, and sessions break even though CARP switched cleanly. Outbound NAT must use the CARP VIP as its translation address so the active node, whichever it is, owns the return path. Check this first on any HA pair that “fails over but loses connections”.

XMLRPC sync silently stops

Config sync breaks quietly and you only find out during a failover onto a stale backup. The usual causes: the two nodes drift to different OPNsense versions (XMLRPC refuses to sync across a version gap), a plugin is installed on the master but not the backup (its config has nowhere to land), or the sync user's credentials or permissions changed. Keep both nodes on the same version and the same plugin set, and after any change confirm the backup actually received it rather than assuming it did.

Asymmetric routing and multi-WAN

HA and multi-WAN together invite asymmetric paths: a flow leaves via one node or WAN and tries to return via another, where no matching state exists, so the firewall drops it. pfsync keeps state consistent between the HA pair, but it cannot fix a topology where forward and return legs genuinely diverge. Design the routing so a flow's return path lands on the node that owns its state, and test failover with real multi-WAN traffic, not just a ping.

CARP on a hypervisor

Running OPNsense virtual — on Proxmox or VMware — adds a trap: CARP relies on multicast and on a MAC address the VIP owns, and virtual switches block both by default. The CARP interface's vSwitch or Linux bridge needs promiscuous mode and MAC-spoofing/forged-transmits allowed, or the backup never sees the master's advertisements and both declare themselves master. If you also build redundant VPN links with MikroTik and OSPF in front of the pair, keep that failover independent of the firewall's.

Split-brain when the sync link dies

If the interface carrying CARP advertisements goes down but both firewalls stay up, each believes the other is dead and both claim the VIP — a MAC/IP conflict that is worse than a clean failover. Give CARP and pfsync a reliable, ideally dedicated path, watch the CARP status, and use the maintenance (persistent CARP maintenance) mode when you deliberately take the master down so the switch is controlled rather than a scramble.

Upgrades without an outage

Because XMLRPC will not sync across a version gap, upgrades are a sequence, not a button. Put the master into CARP maintenance so the backup takes over, upgrade the now-idle master, confirm it is healthy, fail back, then upgrade the other node. Never upgrade both at once, and never leave the pair on mismatched versions longer than the upgrade itself — a failover during that window lands on a node that has not received recent config.

A sane checklist

• •Outbound NAT translates to the CARP VIP, not an interface IP.
• •Dedicated pfsync interface; CARP advertisements on a reliable link.
• •Both nodes on identical OPNsense version and plugin set.
• •After every change, verify the backup actually received the sync.
• •On a hypervisor: promiscuous mode and MAC spoofing allowed on the CARP bridge.
• •Upgrade one node at a time via CARP maintenance mode.
• •Test failover with real traffic (and real multi-WAN), not a ping.

HA removes the firewall as a single point of failure; it does not remove the need for backups, monitoring or a tested config restore. A synchronised pair will happily replicate a bad rule to both nodes in seconds.

Bottom line

OPNsense CARP HA is reliable once the three mechanisms — CARP, pfsync and XMLRPC — are each set up and, crucially, tested under a real failover rather than a clean reboot. The outages we get called about are almost never CARP itself; they are NAT pointed at the wrong address, a backup running a different version, or a virtual switch eating CARP. Get those right and the pair does its job silently, which is the only job a firewall should do.

Want this run for you rather than built in-house? That is part of our managed firewall services in Cyprus.