Before deploymentHA readiness

HA / CARP Readiness

17 items ·8 critical ·8 warn ·1 info

OPNsense HA is not “two firewalls in a cluster” — it is a disciplined configuration of CARP, pfsync, XMLRPC, and per-service redundancy that together make a single virtual firewall. Drift between the two nodes, mismatched firmware, or a sync interface on a busy network are the usual ways an HA pair becomes an HA liability.

When to use

Use this checklist before the first HA deployment goes live, before any change that affects the sync interface or the XMLRPC sync password, and quarterly as a regression check. It is also the right checklist after any incident where HA failed to behave as expected, or after a node replacement.

How to use

Walk the list, then schedule a maintenance window for the failover drill. Disable master, observe backup take over VIPs, validate application traffic, then re-enable master. Capture the failover time and the failback time and file both with the change record.

Critical8 items

Both nodes are on identical OPNsense firmware versions and identical plugin versions.
```
System > Firmware > Status; compare nodes.
```
A dedicated pfsync sync interface exists between the two nodes and is not on a production data VLAN.
```
Interfaces > OPT_SYNC; IP scheme documented.
```
XMLRPC sync is configured with a strong, unique sync password and only the required sections are selected.
```
System > High Availability > Settings.
```
CARP virtual IPs are defined for every interface that should fail over and use a unique VHID per segment, and the rules on each of those parent interfaces pass protocol CARP — that is where the advertisements travel, not on the sync link.
```
Interfaces > Virtual IPs > Settings; Firewall > Rules on each VIP parent interface.
```
pfsync is bound to the dedicated interface and the sync interface rules pass IP protocol pfsync (240) between the two sync addresses — pfsync has no TCP or UDP port, so there is no port to open.
```
ifconfig pfsync0 (check syncdev, syncpeer, syncok); Firewall > Rules on the sync interface.
```
Outbound NAT covers all CARP VIPs as well as the physical interface addresses.
Failover test: power off master and confirm backup takes over VIPs within the expected window; ping through VIP is restored.
Failback test: bring master back online and confirm it resumes master role (if preemption enabled) without session loss for allowed protocols.

Warning8 items

CARP skew and advertisement base are tuned: the master advertises with the lower skew and the backup with the higher, so the election is deterministic.
```
Interfaces > Virtual IPs > Settings; confirm advbase and advskew on both nodes.
```
Preemption is enabled so the intended primary resumes the master role after a fault recovers, and the demotion counter reads 0 on both nodes in steady state.
```
sysctl net.inet.carp.preempt; sysctl net.inet.carp.demotion on both nodes.
```
Planned work uses Enter Persistent CARP Maintenance Mode rather than a skew edit, and the runbook records that pressing it a second time subtracts the 240 it added — the demotion sysctl adjusts the counter, it does not assign it.
```
Interfaces > Virtual IPs > Status.
```
State table size on both nodes accounts for the doubled flow count of HA pairs.
```
sysctl net.inet.tcp.states; pfctl -ss | wc -l.
```
Configuration drift between nodes is monitored (XMLRPC status page shows no divergences).
Each node has independent monitoring; losing both is a single-pane-of-glass incident, not a silent failure.
Hardware (or VM) for each node is in different failure domains: power, network, hypervisor host.
Split-brain is understood and monitored: CARP has no quorum, so if the two nodes stop hearing each other on a VIP parent interface, both will become master for that VHID. The mitigation is redundant Layer 2 on the VIP parent segments plus an alert on two MASTERs for one VHID.

Info1 item

HA-aware services (Unbound, DHCP failover, NTP) are configured for redundancy, not just the firewall rule path.