pfSense Multi-WAN Setup: Failover vs Load Balancing

Multi-WAN is one of the highest-impact configurations you can add to a pfSense edge router: a second internet uplink means a dead ISP no longer takes the whole house or office offline, and — if you size it right — you can use both links simultaneously for outbound throughput. pfSense implements this through gateway groups, a layered abstraction over individual gateways that lets you express “use WAN1 normally, fall back to WAN2 if WAN1 dies,” or “balance new outbound flows across both links round-robin.” This guide builds both modes end to end and covers the few quiet gotchas that bite people on first attempt.

A useful framing before we touch a setting: pfSense does not aggregate WAN bandwidth into a single fat pipe. Load balancing is per-flow, not per-packet — a single TCP connection rides one WAN. A 500 Mbps line plus a 500 Mbps line will not give you a 1 Gbps file download; it gives two simultaneous downloads a chance to use one WAN each. If you need true link aggregation, that is a different (and far more complex) BGP/MLPPP conversation. Failover, by contrast, is exactly what it sounds like and is the workhorse use case for almost everyone.

Failover vs load balancing: which do you want?

Both are built from the same object — a gateway group — and the only difference is how you assign tiers. Decide before you configure, because the two behave very differently in daily use.

Pick failover if the goal is “the internet should not go down.” This is most homes and most small offices, and it is the safer default: your public IP stays stable, so nothing gets logged out mid-session.

Pick load balancing if you have two links of broadly similar quality, you regularly run many simultaneous connections, and you can tolerate the odd site that objects to a shifting source IP. You can also have both: put latency-sensitive or IP-sensitive traffic on a failover group and bulk traffic on a balanced group, using separate firewall rules.

A common third answer is “both, but weighted.” A tiered group with the same tier for two WANs and a higher weight on the faster link balances proportionally rather than evenly — useful when a 1 Gbps fibre line is paired with a 100 Mbps LTE backup.

The build below covers failover first, then the one-field change that turns it into load balancing.

Prerequisites

• Two physical WAN interfaces (two NICs), each with its own modem/ONT/ISP handoff. A single ISP feeding two ports on the same modem is not multi-WAN — it is one upstream failure away from total outage. This is the requirement that catches people on two-port appliances: a second WAN consumes a port you were probably using for LAN, and sealed fanless boxes cannot take an add-in card, so plan port count before you buy (the pfSense hardware requirements guide covers the arithmetic, and the best hardware for pfSense guide lists boxes with four or more ports).
• Each WAN configured as a normal pfSense interface with its own gateway. Status → Gateways should list both as Online before you touch anything else.
• A baseline pfctl/firewall config that you know works on WAN1 alone, so you can isolate problems later.

If either WAN is not consistently Online, fix the per-WAN config first. Multi-WAN piles complexity on top of single-WAN; a flaky underlying link will look like a multi-WAN bug and waste hours. The pfSense Multi-WAN documentation is the authoritative companion to this guide.

Step 1: Tune gateway monitoring

System → Routing → Gateways → edit each WAN gateway. Netgate’s defaults are a probe every 500 ms, a 2000 ms loss interval, packet-loss thresholds of 10% (warning) and 20% (alert), and latency thresholds of 200 ms (warning) and 500 ms (alert). Faster failover comes from a shorter loss interval or lower thresholds, not from probing less often:

• Monitor IP: set this to a public IP you trust to be reachable via that specific WAN: 1.1.1.1 for one, 8.8.8.8 for the other is a reasonable default. Do not leave both gateways monitoring the same address; if that address goes down (or rate-limits you), both WANs falsely register as down.
• Probe interval: leave it at the 500 ms default. Raising it to 1000 ms halves the probe rate and slows detection.
• Loss interval: the time before an unanswered probe counts as lost, 2000 ms by default. A shorter value counts a missed reply as lost sooner, which speeds detection.
• Loss thresholds: the defaults (10% warning / 20% alert) are sane. Lower them for faster failover only if your ISP’s normal loss is consistently zero.
• Latency thresholds: the defaults are 200 ms and 500 ms. Raise them if your ISP routinely sits near that ceiling; otherwise leave alone.

These knobs are what dpinger (pfSense’s gateway monitor daemon) uses to decide a gateway is Down. The full reference for each field is on Netgate’s Gateway Settings page. Get these right and failover triggers in roughly the time it takes the loss/latency threshold to be crossed.

Step 2: Create the gateway group

System → Routing → Gateway Groups → Add.

For failover (use WAN1 normally, WAN2 only if WAN1 is down):

• Group Name: WANFailover
• Gateway Priority:
  • WAN1_DHCP → Tier 1
  • WAN2_DHCP → Tier 2
• Trigger Level: Member Down (fail over only when a member is fully down; Packet Loss, High Latency, or Packet Loss or High Latency are stricter triggers)
• Description: Primary WAN1, failover to WAN2

For load balancing (use both at once):

• Group Name: WANLoadBalance
• Gateway Priority: put both WANs on the same tier (e.g., both Tier 1)
• Trigger Level: Member Down
• Description: Round-robin across both WANs

Same-tier members are load-balanced; different-tier members are used in tier order for failover. You can mix both behaviors — three WANs with Tier 1: A+B (balanced) and Tier 2: C (failover) is a perfectly legal configuration. The mechanics are spelled out in Netgate’s Gateway Groups reference.

Step 3: Apply the group with a policy-routing rule

Creating a gateway group does nothing on its own. Traffic only uses it when a firewall rule sets the rule’s Gateway field to the group. This is the step new pfSense users most often miss.

Firewall → Rules → LAN. Edit the default “Default allow LAN to any rule” (or create a new rule above it, depending on your layout):

• Action: Pass
• Interface: LAN
• Source: LAN net
• Destination: any
• Expand Display Advanced and set Gateway to WANFailover (or WANLoadBalance).

Save and apply. From this point on, LAN clients’ outbound traffic uses the group instead of the system default gateway.

If you have multiple LAN-like interfaces (VLANs, guest, IoT), repeat for each — see the pfSense VLAN configuration guide for the underlying interface setup these rules sit on top of.

Why a policy rule and not the default gateway?

You can set a gateway group as the system default gateway in System → Routing → Gateways, and on a simple network that works. The reason most multi-WAN deployments use per-rule policy routing instead is that it composes cleanly with everything else: rules above the policy-routed rule can pin specific traffic to a specific WAN (e.g., “all VoIP egress goes out WAN1 only” or “this VPN client traffic exits only WAN2”), without disturbing the rest. The default-gateway approach gives up that flexibility.

Step 4: DNS — the single biggest gotcha

The Unbound resolver (default in pfSense) by default uses the system default gateway for upstream queries. In a multi-WAN setup, this means all DNS exits one WAN regardless of your policy routing — and if that WAN is the one that just died, DNS resolution dies with it even though the gateway group has cut traffic over to the surviving WAN.

Two fixes, pick one:

1. Outgoing Network Interfaces in Unbound: Services → DNS Resolver → General. Set the Outgoing Network Interfaces to include both WANs, and configure forwarders / root-server queries appropriately. Unbound will then resolve via whichever interface has a route. The full set of options is documented in the DNS Resolver configuration reference.
2. Per-server gateways in System → General Setup: define a DNS server per WAN (e.g., 1.1.1.1 via WAN1, 8.8.8.8 via WAN2) and assign each a gateway. pfSense then pins each upstream DNS query to its associated WAN, so the surviving WAN’s DNS still resolves when the other is down.

Both approaches work; the per-server gateway model is the more explicit one and easier to reason about when something breaks.

Step 5: NAT, VPN, and the connections that “lose their mind” at failover

A few subsystems need their own multi-WAN awareness:

• Outbound NAT: switch to Hybrid Outbound NAT so pfSense auto-generates per-WAN NAT rules. Manual mode will silently drop traffic out the wrong WAN if you forget a rule.
• Port forwards: a port forward is bound to one specific WAN. If you need an inbound service reachable from either ISP, you need two port-forward rules — one per WAN — and DNS on both public IPs (or a third-party failover DNS).
• Site-to-site VPNs: an IPsec/WireGuard tunnel terminates on a specific WAN address. Multi-WAN failover for VPN endpoints needs explicit handling (multiple peer addresses on the far side, or an overlay protocol on top). See the pfSense WireGuard setup guide and the OpenVPN vs WireGuard comparison for tunnel configuration, then layer multi-WAN considerations on top.
• Existing TCP connections at failover: a flow established via WAN1 will not survive a cut to WAN2 — it is sourced from WAN1’s IP, and the far end has no reason to accept the same socket from WAN2’s IP. New flows established after failover work fine. This is unavoidable and expected.

Verify the setup

1. Both gateways Online: Status → Gateways. Round-trip time and loss should be steady on both.
2. Group health: the gateway group itself should report Online with all members up.
3. Outbound test: from a LAN client, curl https://ifconfig.io repeatedly. With load balancing, you should see both public IPs over multiple requests. With failover, you should consistently see WAN1’s IP.
4. Forced failover: physically unplug WAN1, or in Status → Gateways select WAN1 → “Mark Gateway as Down.” Within the configured probe/loss threshold (a few seconds), curl ifconfig.io should now return WAN2’s IP. Reconnect WAN1, confirm it returns to Online, and confirm traffic shifts back.
5. DNS during failover: from a LAN client, query pfSense’s LAN interface address, for example dig @192.168.1.1 example.com (substitute your own LAN address). It must still resolve while WAN1 is down. If not, revisit Step 4.

When multi-WAN is the wrong call

If your second uplink is an LTE/5G backup with a tight data cap, load balancing is almost certainly wrong — you will burn through the cap fast and unevenly. Configure it as a Tier 2 failover only, and consider a more aggressive trigger (Member Down keeps the cellular link idle until the primary is genuinely dead). If both WANs are from the same physical provider sharing the same upstream feed, multi-WAN protects against in-house cable/CPE issues but not against the provider’s outage — be honest about what failure modes you’re actually covering. And if you only have a single static public IP and need it preserved across failover (because of inbound services), multi-WAN at the edge does not solve that; you need BGP-announced IP space or a third-party SD-WAN overlay, both of which are out of scope for a homelab gateway.

Multi-WAN also protects the link, not the box. A second uplink does nothing for you if the firewall itself dies, and surviving that is a different build: two nodes sharing a CARP virtual IP with pfsync replicating the state table, which the pfSense CARP high availability guide walks through end to end.

For most homelabs and small offices with two independent ISPs, a tier-based failover gateway group with tightened monitoring and proper DNS handling is the sweet spot: invisible most of the time, decisive when one ISP misbehaves, and unmodified for years afterward.

Want a side-by-side with how OPNsense handles the same problem? OPNsense’s multi-WAN approach uses the same FreeBSD building blocks but a different UI; firewallcompare.com has the comparison.

Related across the network

• OPNsense Multi-WAN Failover with Gateway Groups — opnsenselab.com