pfSense High Availability - Clustering and Failover
High availability (HA) in pfSense relies on three complementary technologies working in concert: CARP for IP address failover, pfsync for connection state table synchronization, and XMLRPC for configuration replication between cluster nodes. This architecture enables transparent traffic failover to a standby node when the primary fails, preserving established sessions without manual intervention.
pfSense supports two-node clusters in an active/passive configuration. The primary node (master) handles all traffic destined for CARP virtual IP addresses. The secondary node (backup) continuously receives state table updates via pfsync and configuration changes via XMLRPC. When heartbeat signals from the primary node are lost, the secondary automatically assumes the master role and begins processing traffic.
CARP was developed by the OpenBSD team as a patent-free alternative to Cisco HSRP and VRRP. Within pfSense, CARP provides IP-level failover - network clients communicate with a virtual address that is automatically served by whichever cluster node currently holds the master role.
In This Section
- CARP and Virtual IPs - CARP protocol configuration, virtual IP address creation, addressing requirements, and cluster health verification
- Configuration Synchronization - XMLRPC setup for replicating firewall rules, NAT, VPN, and other settings between cluster nodes
- Failover Scenarios - failover testing, outage planning, cluster state monitoring, and disaster recovery procedures
Cluster Architecture
A standard pfSense HA cluster consists of the following components:
| Component | Purpose | Protocol |
|---|---|---|
| CARP VIP | Virtual IP addresses for network clients | CARP (multicast/unicast) |
| pfsync | Connection state table synchronization | pfsync over dedicated interface |
| XMLRPC | Configuration replication from primary to secondary | HTTPS (TCP 443) |
| Sync interface | Dedicated link between cluster nodes | Separate subnet |
Each interface running CARP requires a minimum of three IP addresses within the same subnet: one for the primary node, one for the secondary node, and one shared CARP VIP. The sync interface uses a separate subnet and does not require a CARP VIP.
Warning:
CARP VIPs must not be used for administrative access to cluster nodes (web GUI, SSH). Always use each node’s dedicated interface IP address for management purposes.
Related Sections
- pfSense NAT - outbound NAT rules must reference CARP VIPs as translation addresses in HA deployments
- Firewall Rules - the sync interface requires rules permitting XMLRPC and pfsync traffic
- pfSense VPN - IPsec and OpenVPN tunnels must bind to CARP VIPs for correct failover behavior