pfSense Multi-WAN: Failover and Load Balancing with Gateway Groups

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.

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.
• 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. The defaults are conservative; for a snappy failover you want tighter values:

• 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: 1000 ms is reasonable for home use; lower if you genuinely need sub-second detection and your link can tolerate the extra ICMP.
• Loss thresholds: the defaults (10% warning / 20% alert) are sane. Tighten only if your ISP’s normal loss is consistently zero.
• Latency thresholds: raise above the default if your ISP routinely sits near the default 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 documented in the gateway monitoring section ↗. 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 the gateway groups configuration 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: dig @127.0.0.1 example.com from a LAN client 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.

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.