Building Redundant Firewalls with pfSense HA Using CARP and pfsync

The problem: a single firewall is a single point of failure

When a firewall goes down, all traffic stops until it is restored. For many networks even a brief outage can disrupt services, cause lost productivity, or violate SLAs. The goal is to have a standby unit take over instantly, preserving existing connections.

Why CARP and pfsync are the engineering choice

pfSense provides High Availability (HA) through two complementary mechanisms:

• CARP (Common Address Redundancy Protocol) creates a shared virtual IP (VIP) that floats between a primary and a backup firewall. When the primary stops sending CARP advertisements, the backup assumes the VIP and begins forwarding traffic.
• pfsync replicates the firewall’s state table (NAT entries, firewall rules, VPN tunnels) over a dedicated interface. After a failover, the backup already knows about active sessions, so ongoing connections are not reset.

Together they give sub‑second failover for most traffic types without user interruption.

Worked example: two‑node HA pair

Assume two identical pfSense appliances running the same version (e.g., 2.7.0).

• LAN: 192.168.1.0/24
• WAN: DHCP from ISP
• Virtual IP (VIP) on LAN: 192.168.1.254
• CARP VHID: 1
• CARP authentication password: mycarpsecret
• Dedicated pfsync interface: OPT1
• pfsync IPs: primary 10.0.0.1/24, backup 10.0.0.2/24

Configuration steps (GUI)

1. On both firewalls: Interfaces → Assignments → add OPT1 if not present, then Interfaces → OPT1 → enable, set static IP as above.
2. On both firewalls: Virtual IPs → VIPs → add:
   • Type: CARP
   • Interface: LAN
   • Virtual IP: 192.168.1.254
   • VRID/VHID: 1
   • Password: mycarpsecret
   • AdvSkew: 0 (primary), 100 (backup) – this makes the primary win the election.
3. On both firewalls: System → High Availability Sync → configure:
   • Synchronize States: pfsync
   • pfsync Interface: OPT1
   • pfsync Peer IP: the other node’s OPT1 address (e.g., primary puts 10.0.0.2, backup puts 10.0.0.1)
   • Enable: check.
4. Save and apply changes. The primary should now show CARP state MASTER and the backup BACKUP.

Verification

1. Check Status → CARP on each node; verify MASTER/BACKUP roles for VHID 1.
2. From a LAN host, ping the VIP (192.168.1.254) – it should reply.
3. Simulate a failure: disconnect the primary’s WAN interface (or power it off).
4. Observe the backup’s CARP status change to MASTER and the VIP respond to ping.
5. On the new master, run pfsyncctl -i opt1 -s (via Diagnostics → Command) to see sent/received packets and ensure no errors.
6. Inspect Status → System Logs → Firewall for pfsync or CARP warnings.

Trade‑offs and limitations

While HA adds resilience, it introduces operational complexity:

• Multicast‑capable switches are required because CARP uses IP multicast (224.0.0.18). If the switch blocks or filters this traffic, failover will not work.
• Version drift breaks pfsync; both nodes must run identical pfSense versions and preferably the same hardware model to avoid state‑table mismatches.
• Split‑brain risk occurs if CARP advertisements are lost but the pfsync link stays up, or vice‑versa, causing both nodes to think they are MASTER. Proper monitoring and a reliable inter‑connect mitigate this.
• Asymmetric routing that bypasses one firewall can cause stale state entries, because pfsync only sees traffic that passes through both nodes.

Practical checks: regularly review CARP and pfsync logs, monitor the pfsync interface for dropped packets, and schedule a failover test during a maintenance window.

Actionable closing

To deploy pfSense HA successfully:

1. Validate that your LAN/WAN switches forward CARP multicast.
2. Keep firmware identical across all nodes; use a version‑control process for upgrades.
3. Configure a dedicated, isolated interface for pfsync and verify connectivity before enabling CARP.
4. Test failover by pulling the primary’s WAN cable; confirm the backup takes the VIP and that active SSH or HTTP sessions survive.
5. Set up alerts for CARP state changes and pfsync error counters so you can react before users notice an issue.

When these steps are followed, the HA pair provides transparent, sub‑second failover that keeps your network running even when a firewall disappears.