pfSense Multi-WAN: Failover-Only vs. Load-Balancing Decision Guide

The Decision: Failover-Only vs. Load-Balancing

When configuring Multi-WAN in pfSense 2.7.x or 24.03, the first decision is whether to use failover-only or load-balancing mode. This choice determines how traffic flows across your WAN connections and how pfSense reacts when a link degrades or fails. The short version: use failover-only for dissimilar links (fiber plus LTE) and load-balancing only for two links with similar latency and path characteristics.

How Gateway Groups Define Behavior

Gateway Groups (System > Routing > Gateway Groups) control Multi-WAN behavior through two settings:

• Tier: Gateways in the same tier are treated as equivalent. Tier 1 is highest priority; a Tier 2 gateway only activates when all Tier 1 members are down.
• Trigger Level: When a gateway leaves the group. Options are Member Down, Packet Loss, High Latency, or combinations of these.

For failover-only, put your primary WAN in Tier 1 and the backup in Tier 2 with a Member Down trigger. For load-balancing, put both WANs in the same tier with Latency or Packet Loss triggers; pfSense then round-robins new connections across healthy members.

Mode Comparison

Trade-offs

Failover-only is simpler to troubleshoot, behaves predictably, and works well with stateful services like VPNs and VoIP. Enable Sticky Connections (System > Advanced > Miscellaneous) so established states stay bound to their original gateway during failover, keeping banking, VPN, and VoIP sessions alive. Note that sticky connections do not migrate existing states back to the preferred gateway after failback; only new connections honor tier priority.

Load-balancing uses the aggregate bandwidth of both links, which helps high-throughput workloads. The catch: per-connection path changes can break streaming, gaming, and IPsec. pfSense gateway groups also do not support weighted round-robin, so a 1 Gbps fiber link and a 100 Mbps link in the same tier receive equal shares of new connections. For heterogeneous upstreams, prefer failover-only.

Monitoring IP Selection

Each WAN needs its own monitor IP. Sharing one monitor IP across WANs creates correlated false positives: a single upstream issue can flap both gateways at once. Good choices per WAN:

• The ISP's gateway IP (topologically closest, most reliable signal)
• 1.1.1.1 or 8.8.8.8 as a secondary option

Tune probe thresholds per link under System > Routing > Gateways > Edit > Advanced. The defaults (1s probe interval, roughly 500ms latency and 20% loss triggers) can flap on congested links like LTE; raise thresholds there.

Policy Routing: Actually Using the Group

A gateway group does nothing until a firewall rule sends traffic into it. Without a rule, traffic follows the default routing table's single default gateway. Create a rule under Firewall > Rules > LAN:

• Action: Pass
• Source: LAN net (or a specific test host while validating)
• Destination: Any
• Gateway (under Advanced): your gateway group

Policy routing bypasses the routing table entirely for matched traffic, so keep a catch-all rule using the default gateway below it for anything you do not want in the group (for example, locally destined or VPN-bound traffic).

Concrete Example: Fiber Primary, LTE Backup

A small office with a fiber primary and LTE backup wants zero-downtime failover without load-balancing risks:

1. System > Routing > Gateways: WAN_FIBER monitors the ISP gateway IP; WAN_LTE monitors 1.1.1.1 with relaxed latency/loss thresholds.
2. System > Routing > Gateway Groups: create "WAN_FAILOVER" with WAN_FIBER at Tier 1, WAN_LTE at Tier 2, trigger Member Down.
3. System > Advanced > Miscellaneous: enable Sticky Connections.
4. Firewall > Rules > LAN: add a pass rule with Gateway set to WAN_FAILOVER, above the default allow rule.

Validation

Run these from the pfSense shell (Diagnostics > Command Prompt, or SSH as admin/root):

1. Dashboard: add the Gateways widget and confirm WAN_FIBER shows Online and active.
2. Policy test: from a LAN host, run traceroute 8.8.8.8; the first hop beyond pfSense should be the fiber ISP's gateway.
3. Simulate failover: disconnect the fiber WAN or block its monitor IP, then check Status > Gateways for the tier transition.
4. Logs: clog /var/log/gateways.log | tail -20 shows probe results and transitions with timestamps.
5. State survival: open an SSH session out through WAN_FIBER, pull the link, and confirm the session persists via WAN_LTE in Diagnostics > States.

Do not treat these commands as guaranteed output; interface names and log formats vary by version, so confirm against your own system.

HA Pairs and IPv6 Caveats

For CARP/pfsync pairs, configure identical gateway groups on both nodes and enable gateway monitoring synchronization in the XMLRPC sync settings. On the secondary, pfctl -s sync confirms pfsync state flow. For IPv6 Multi-WAN, each WAN needs a stable delegated prefix; NPTv6 can map internal addresses to each WAN's prefix, but unstable delegation breaks the design.