pfSense CARP High Availability: Failover Configuration

A pfSense CARP cluster gives you two firewalls sharing virtual addresses, synchronised state tables and one-way configuration replication - which together mean a firewall failure costs one or two ICMP packets instead of every TCP session on the network. The concept is simple, but the details are unforgiving: addresses must be planned before you start, outbound NAT must translate to the virtual address, and config synchronisation only works in one direction. This guide covers the whole build with the verification steps that catch the usual mistakes.

CARP, pfsync and XMLRPC: Three Separate Jobs

CARP shares virtual IPs between nodes and elects a master. pfsync replicates the firewall state table so established connections survive a takeover. XMLRPC copies configuration from primary to secondary so the two nodes never drift. All three are needed; a cluster with CARP but no pfsync will fail over and then drop every active session.

Address Planning Comes First

Each participating interface needs the primary's real address, the secondary's real address and the CARP VIP - three addresses per subnet. A dedicated sync interface is strongly recommended and does not need a VIP.

The CARP VIP must live in the same subnet as the node addresses on that interface. A VIP from another subnet silently fails to work, and the WAN needs at least a /29 to accommodate two node addresses, the VIP and the upstream gateway.

Create the CARP Virtual IPs on the Primary

Navigate to Firewall → Virtual IPs → Add. Key fields: type CARP, the interface, the VIP address and mask, a shared password that must match on both nodes, a unique VHID per VIP, and advertising frequency base 1 with skew 0 on the primary. Give the secondary a higher skew so the election reliably picks the primary. Each VIP uses a virtual MAC of 00:00:5e:00:01:XX, where XX is the VHID.

Because XMLRPC sync is enabled, the VIPs replicate to the secondary automatically once configuration sync is in place.

Enable State and Configuration Synchronisation

On the primary, go to System → High Availability Sync and configure:

• State Synchronization: enabled, sync interface set to SYNC, pfsync peer set to the secondary's sync IP.
• Configuration Synchronization: sync interface, Synchronize Config to IP = secondary sync IP, plus the secondary's admin credentials.
• Tick the sections to replicate - firewall rules, aliases, NAT, DHCP, VPN and so on.

Then confirm that the sync actually works: add a test alias on the primary and check that it appears on the secondary within a few seconds. Configuration sync is one-way by design, so always edit on the primary.

DHCP and Outbound NAT

Two settings cause most of the "failover worked but the network did not" reports. First, the DHCP scope must hand out the CARP VIP as gateway and DNS, never a node address. Second, outbound NAT must be switched to Manual or Hybrid mode with the translation address set to the WAN CARP VIP. If outbound NAT translates to the interface address instead, it works while the primary is master and stops the moment the secondary takes over.

Verifying Failover

# On pfSense: Status -> CARP (failover) shows the state per VIP
# Primary should be MASTER, secondary BACKUP
# If both show MASTER, the sync link is down (split brain)
ping -t 8.8.8.8        # from a LAN client while failing the primary
# Status -> System Logs -> Firewall shows state sync activity

Run a continuous ping from a LAN client, then reboot the primary or unplug its WAN. The secondary should claim the VIPs within about a second and the ping should lose at most one or two packets. An open SSH session to a host behind the firewall should survive - that proves pfsync is replicating states.

For planned maintenance, use Status → CARP and click Enter Persistent CARP Maintenance Mode on the primary. This demotes every VIP gracefully so the secondary takes over, which is far cleaner than pulling power during a patch window.

Virtualisation Gotchas

CARP relies on multicast and on MAC addresses the hypervisor does not own. On VMware, set the virtual switch or port group to accept promiscuous mode, forged transmits and MAC address changes. On Proxmox with a Linux bridge, verify multicast snooping does not filter the CARP advertisements. On Hyper-V, enable MAC address spoofing on the virtual adapter. Any of these blocking CARP produces a cluster where both nodes believe they are master. A comparison with router-based redundancy is useful here: keepalived VRRP with HAProxy virtual IP failover covers the VRRP equivalent, and OPNsense CARP and pfsync HA is the same design on the sister platform.

原文链接：https://opennix.org/en/docs/pfsense/high-availability/pfsense-carp-setup