pfSense Multi-WAN: Failover Works, Load Balancing Has Limits

The Problem: Redundancy Without Surprises

You have two internet connections — cable and fiber — and you want pfSense to use both. The typical goal: automatic failover when the primary link dies, plus some load sharing when both are up. The reality: pfSense Gateway Groups handle failover cleanly, but load balancing is per-connection round-robin, not per-packet bonding. A single large download will never span both WANs. If you need true aggregation, you need MLVPN, OpenMPTCProuter, or ISP-supported link aggregation — not pfSense alone.

How Gateway Groups Actually Work

A Gateway Group is an ordered list of gateways with tier numbers. Tier 1 gateways are active; Tier 2 and higher are backups. When all Tier 1 gateways are down, the group fails over to Tier 2. You create the group at System > Routing > Gateway Groups. Each gateway in the group must have monitoring enabled (ICMP echo to a monitor IP) so pfSense knows when the link is healthy.

Monitoring uses dpinger under the hood. Default probe interval is 1 second; a gateway is marked down after 10% loss over the probe window. You can tune these in the gateway's Advanced settings. Pick monitor IPs that actually respond to ICMP — your ISP gateway, 1.1.1.1, 9.9.9.9 — and avoid endpoints that rate-limit or block pings.

Policy Routing: The Rule That Makes It Happen

Gateway Groups do nothing until a firewall rule references them. On your LAN interface (Firewall > Rules > LAN), create or edit the default allow rule and set Gateway to your Gateway Group (e.g., WAN_Failover). Rules evaluate top-down, so specific policy routes (VoIP to a dedicated WAN, guest network to the cheaper link) must sit above the catch-all rule that uses the group.

If you need a fallback for management traffic that must follow the system routing table, add a rule below the group rule with Gateway set to default (or leave it unset).

Worked Example: Cable Primary, Fiber Backup

Assume two WAN interfaces: WAN_CABLE (DHCP, gateway 192.168.10.1) and WAN_FIBER (PPPoE, gateway 10.0.0.1).

1. Edit each gateway (System > Routing > Gateways): enable monitoring, set monitor IP (e.g., 1.1.1.1 for cable, 9.9.9.9 for fiber).
2. Create Gateway Group WAN_Failover: WAN_CABLE Tier 1, WAN_FIBER Tier 2.
3. On LAN rules, set the default IPv4 allow rule's Gateway to WAN_Failover.
4. Enable Flush all states when a gateway goes down (System > Advanced > Miscellaneous) for rapid failover.

Now pull the cable modem. dpinger reports loss, gateway status flips to Offline, states are flushed (if enabled), and new connections route via fiber. Check Status > Gateways for the transition and Status > System Logs > Routing for dpinger alerts.

State Killing: The Trade-Off You Must Choose

Flush all states when a gateway goes down drops every existing connection — SSH, VPN, VoIP calls — forcing them to re-establish on the backup WAN. Failover is fast (seconds), but sessions break. Disable it, and sessions persist until they time out naturally (TCP keepalives, application retries), but failover feels slower because the firewall keeps trying the dead gateway for established flows.

For a small office with mostly web browsing, enable state killing. For a site with IPsec tunnels or softphones, disable it and accept longer failover. You can test: run pfctl -ss on the pfSense shell (Diagnostics > Command Prompt or SSH as root) before and after pulling the primary WAN to see state table changes.

Load Balancing Is Not Bonding

If you put both WANs in Tier 1, pfSense round-robins new connections across them. Connection A goes to cable, Connection B to fiber. A single HTTP download, SCP transfer, or VPN tunnel stays on one WAN. There is no per-packet splitting, no stripe across links. Throughput for any single flow is capped at one WAN's speed.

If you need a 500 Mbps download across two 300 Mbps links, pfSense Multi-WAN won't do it. Look at MLVPN (userspace bonding), OpenMPTCProuter (MPTCP proxy), or a router that supports LACP/MLAG with ISP cooperation.

QoS With Multi-WAN: Duplicate Your Queues

Traffic shaping (HFSC, FAIRQ, PRIQ) lives on interfaces. With two WANs, you must define matching queues on both WAN interfaces and use floating rules (Firewall > Rules > Floating) with Match on the queue name to tag traffic regardless of which gateway carries it. If you only shape on the primary WAN, backup traffic runs unshaped.

CARP HA: Gateway Status Runs Per Node

In a CARP pair, Gateway Group config syncs via XMLRPC, but dpinger runs independently on each node. If monitor IPs differ or one node's path to the monitor IP is congested, you can get asymmetric failover — primary thinks WAN is down, secondary thinks it's up. Use identical monitor IPs on both nodes and verify gateway status on both (Status > Gateways) after any change.

Practical Verification Checklist

• Gateway status: Status > Gateways shows Online/Offline with RTT and loss graphs.
• Rule evaluation: Firewall > Rules > LAN — confirm the Gateway column shows your group name on the catch-all rule.
• Failover test: Physically disconnect primary WAN; watch gateway status flip and traffic shift (monitor via iftop on WAN interfaces or firewall logs).
• State killing test: Establish SSH through primary, trigger failover, run pfctl -ss to see if states vanish (enabled) or linger (disabled).
• CARP sync: On both nodes, Status > CARP shows VIPs MASTER/BACKUP; Status > Gateways shows identical gateway states.

Limitations to Keep in Mind

• No sticky connections across WANs without sticky firewall rules (source IP hash) — not enabled by default.
• Monitor IP false positives: if 1.1.1.1 blocks ICMP or congests, gateway flaps. Use multiple monitor IPs per gateway (pfSense 2.7+ supports this) and widen loss thresholds.
• CARP VIPs on WAN require ISP to pass CARP multicast (VRRP/NDP). Most residential ISPs don't; you need a routed subnet or a VLAN handoff.
• Policy routing bypasses the system routing table. Traffic without a matching rule (or with Gateway=default) uses the system default route, which may not be what you expect.

Closing: Start Simple, Verify, Then Add Complexity

Build the failover group first. Test it by unplugging the primary WAN. Confirm states flush (or not) per your choice. Only then add load balancing, QoS, or CARP. The most common production issue isn't configuration syntax — it's a monitor IP that stops responding, or a state-killing setting that breaks the CEO's VoIP call. Pick your monitor IPs carefully, document the state-killing decision, and run the verification checklist after every change.