Setting Up CARP-Based High Availability in pfSense for Seamless Failover

Problem: Need Zero‑Downtime Firewall Failover

When a single firewall appliance fails, all traffic passing through it drops until an administrator can manually replace the device or reconfigure routing. In environments where continuous connectivity is required—such as branch offices, retail sites, or any location that relies on VPN tunnels—this downtime translates to lost productivity and potential SLA violations. The goal is to have a standby unit take over the firewall’s IP address and state within seconds, without human intervention.

How CARP Provides Automatic Failover

CARP (Common Address Redundancy Protocol) lets two or more pfSense machines share a virtual IP address (VIP). One node acts as the master and answers ARP requests for the VIP; the backup nodes listen to CARP advertisements. If the master stops sending advertisements, the backup with the highest priority assumes the VIP, updates its ARP tables, and begins processing packets. Because pfSense synchronizes firewall rules, NAT tables, and VPN states over a dedicated XMLRPC link, the backup can continue existing connections almost immediately.

Prerequisites and Planning

• Two pfSense appliances running the identical version (e.g., 2.7.0) and the same hardware architecture (both AMD64 or both virtual).
• Matching interface names for the networks that will carry traffic (e.g., igb0 for LAN, igb1 for WAN).
• A dedicated interface for state synchronization (often a third NIC or a vSwitch port) that will carry XMLRPC traffic.
• Administrative access to both firewalls with permission to change system → high availability settings.
• Network planning: choose a VIP that sits in the same subnet as the real LAN IP addresses and is not used by any other host.

Step‑by‑Step Configuration

1. On each firewall, assign a static IP to the sync interface (e.g., 10.0.100.1/24 on primary, 10.0.100.2/24 on backup). Ensure the two IPs can ping each other.
2. Navigate to System → High Availability Sync. Enable XMLRPC Sync, set the Remote IP to the sync interface IP of the peer, and provide a username/password that exists on both systems (or use the admin account). Set the Synchronizable Items to the features you want to replicate (typically All or a custom list that includes Filter, NAT, IPsec, OpenVPN). Save.
3. Go to Virtual IP Addresses under Firewall → Virtual IPs. Add a new VIP:
   • Type: CARP
   • Interface: LAN (or whichever interface will serve clients)
   • Address: 192.168.10.1/24 (example VIP)
   • Virtual ID: 1 (must be identical on both nodes)
   • Password: mycarpsecret (shared secret)
   • AdvSkew: 0 on the primary, 100 on the backup (lower wins).
   • Disable Preempt if you want the former master to stay backup after recovery; enable it if you prefer automatic fallback.
4. Repeat the VIP entry on the second firewall, using the same Virtual ID, password, and AdvSkew values (swap primary/backup as appropriate).
5. After saving, check the Status → CARP page on each node. You should see one node reporting MASTER and the other BACKUP for the VIP.
6. Verify synchronization: on the primary, make a change (e.g., add a firewall rule). Within a few seconds, the same rule should appear on the backup under Diagnostics → XMLRPC Sync Status.

Verification and Expected Behaviour

To test failover:

1. From a host on the LAN, ping the CARP VIP (192.168.10.1) and note the response.
2. Shut down the primary pfSense VM or disconnect its power.
3. Observe that the backup node’s CARP state changes to MASTER (visible in the CARP status page or system logs). The VIP should now be answered by the backup.
4. Continue the ping; you should see only a brief interruption (typically a few seconds) as the backup takes over.
5. After confirming traffic flows, restore the primary node. Depending on the Preempt setting, it will either remain BACKUP or resume MASTER automatically.

Check the system logs for entries similar to carp: VIP changed to MASTER and XMLRPC sync: successful. The absence of error messages indicates that state tables were transferred correctly.

Trade‑offs and Limitations

• CARP provides active‑passive redundancy only; the backup does not share traffic load, so capacity planning must assume the full peak load on a single appliance.
• Both nodes must run the exact same pfSense version and hardware platform. Version mismatches can break XMLRPC sync or cause split‑brain scenarios where both nodes believe they are master.
• If the synchronization interface fails, state information becomes stale. During failover, active connections may be dropped because the backup lacks the latest NAT or session tables.
• CARP does not encrypt its advertisements; on an untrusted LAN you may want to place the CARP segment behind a separate VLAN or use physical isolation.

Actionable Closing

Implementing CARP‑based HA in pfSense is a straightforward way to achieve seamless firewall failover without additional hardware balancers. By matching versions, aligning interface names, configuring a reliable XMLRPC sync link, and carefully setting the CARP VIP parameters, you can reduce downtime to a few seconds and maintain continuous VPN and NAT services. After deployment, regularly monitor the CARP status page and XMLRPC sync logs to catch synchronization issues early, and test failover quarterly to verify that the backup node can assume traffic as expected.