Configure pfSense High‑Availability with CARP and pfsync – A Practical Guide

Why CARP with pfsync? The Quick Takeaway

CARP (Common Address Redundancy Protocol) lets two pfSense boxes share a single virtual IP. When the master fails, the backup takes over the virtual IP within seconds, and pfsync keeps active TCP/UDP connections alive by replicating state tables. The result: seamless failover for clients without re‑configuring routes or NAT.

Mechanism Overview

CARP works on Layer‑2 by sending multicast packets on 224.0.0.18. Each node advertises a VHID (virtual host ID) and a password. The node with the lowest advskew value is the master; others are backups. When a master stops sending adverts, the backup that has the next lowest advskew becomes master after the deadtime (default 3 s).

pfsync runs on a dedicated interface between the two pfSense boxes. It uses protocol 240 to push firewall rules, NAT tables, and connection state. With state sync enabled, a backup can continue forwarding packets for an existing TCP/UDP session immediately after takeover, preventing dropped connections.

Worked Configuration Example

Assumptions

• Two pfSense nodes: pf1 (192.168.1.1/24) and pf2 (192.168.1.2/24) on LAN interface em1.
• Dedicated pfsync interface em2 with IPs 192.168.2.1/24 (pf1) and 192.168.2.2/24 (pf2).
• Same firewall rules, NAT, and interfaces on both nodes.

CARP Settings (UI or /etc/rc.conf)

# On pf1
ifconfig_em1="inet 192.168.1.1/24"
ifconfig_em1_carp1="inet 192.168.1.254/24"  # Virtual IP
ifconfig_em1_carp1_vhid="1"
ifconfig_em1_carp1_password="carrp"
ifconfig_em1_carp1_advskew="10"   # Master

# On pf2
ifconfig_em1="inet 192.168.1.2/24"
ifconfig_em1_carp1="inet 192.168.1.254/24"
ifconfig_em1_carp1_vhid="1"
ifconfig_em1_carp1_password="carrp"
ifconfig_em1_carp1_advskew="20"   # Backup

pfsync Settings

# On both nodes
ifconfig_em2="inet 192.168.2./24"
ifconfig_em2_pfsync="inet 192.168.2./24"  # Peer IP
pfsync_enable="YES"

In the pfSense UI, enable CARP on em1, set the same VHID, password, and virtual IP on both nodes, and adjust advskew as shown. Then enable Synchronize state tables on the firewall rules you want to keep alive during failover.

Verify the Setup

1. Client ping test: From a host on 192.168.1.0/24, ping 192.168.1.254. You should see continuous replies.
2. Power off master: Shut down pf1. After ~3 s, ping should continue without interruption, indicating pf2 has taken over.
3. Check CARP status in pfSense UI: Status > CARP shows MASTER or BACKUP and the advskew values.
4. Inspect pfsync traffic: On either node, run tcpdump -i em2 -n -s0 port 240. You should see continuous pfsync packets during normal operation.

Limits and Common Mistakes

• Layer‑2 requirement: CARP relies on multicast 224.0.0.18. If switches or routers block multicast, failover will never occur.
• Advskew mismatch: If both nodes have the same advskew, they will both try to be master, causing an IP conflict. Always set distinct values.
• VHID collision: The VHID must be unique per CARP group on an interface. Reusing a VHID on the same interface will break redundancy.
• pfsync interface failure: If the dedicated pfsync interface goes down, failover still happens but existing connections are reset. Use a robust link or redundant pfsync paths if uptime is critical.
• Firewall rule sync: Rules that are not marked for state sync will not be replicated. Ensure Synchronize state tables is checked on every rule you need to preserve.
• Client ARP cache: Clients may keep an ARP entry for the virtual IP pointing to the master for up to 1 minute. After failover, the ARP entry will update automatically, but some legacy clients may need a manual ARP flush.
• Deadtime tuning: The default 3 s deadtime may be too long for some environments. Adjust deadtime in the CARP configuration if you need faster takeover.

Practical Checklist Before Going Live

• Verify that CARP and pfsync services start on boot.
• Confirm that the virtual IP is not assigned to any other device.
• Test failover by simulating a master crash and monitoring client connectivity.
• Ensure that NAT and routing rules reference the virtual IP, not the physical IPs.
• Document the advskew values and keep a copy of the configuration on both nodes.

By following this guide, you can set up a robust active‑passive firewall pair that keeps your network up even if one pfSense box fails, all while preserving active connections thanks to pfsync.