OPNsense Multi-WAN Failover with Gateway Groups

A second ISP uplink is one of the highest-leverage upgrades you can make to a home or small-office network. Cable goes down on Tuesday afternoon — fiber keeps you online. The hard part is not plugging in the second line; it’s getting OPNsense to actually use both connections sensibly without breaking DNS, NAT, or long-lived sessions every time a gateway hiccups. This guide walks the full setup using OPNsense’s gateway groups feature, plus the failure modes that quietly burn weekends.

Decide what you actually want first. Multi-WAN comes in two shapes: failover (one link active, the second takes over on failure) and load balancing (both links carry traffic concurrently, per-connection). Failover is simpler and what most homelabs want. Load balancing breaks anything requiring a stable source IP — picky CDNs, VPN tunnels, video calls — because consecutive connections may exit different WANs. Default to failover only unless you have a specific bandwidth-aggregation need.

Prerequisites

• OPNsense with at least three usable interfaces (WAN1, WAN2, LAN). A second physical NIC is strongly preferred over a VLAN-trunked WAN — fewer failure modes.
• Two independent ISP uplinks. “Independent” matters: two circuits from the same cable provider on the same node fail together. The point of multi-WAN is path diversity (e.g., cable + cellular, fiber + DSL).
• A monitor IP for each WAN that is not the upstream gateway. The default gateway IP can answer ICMP even when the path beyond it is broken — using a public anchor like 8.8.8.8 or 1.1.1.1 per WAN catches real outages.

Step 1: Assign and configure the second WAN

Interfaces → Assignments → add the second NIC as OPT1, then rename it WAN2 under Interfaces → [OPT1].

Set the IP configuration per ISP (DHCP for most consumer links, static for business). Critically, leave “Block private networks” and “Block bogons” enabled on real internet WANs — the same rule that applies to WAN1 applies here.

Step 2: Define gateways with realistic monitoring

System → Gateways → Configuration. You should see two auto-created gateways (WAN_DHCP and WAN2_DHCP or named variants). Edit each:

• Monitor IP: set to a stable public IP on that ISP’s path. Use 8.8.8.8 for one and 1.1.1.1 for the other so a single anycast outage doesn’t flap both gateways simultaneously.
• Mark Gateway as Down: enable.
• Latency thresholds: start with defaults (200 ms / 500 ms). Tighten only if you have specific latency-sensitive workloads — aggressive thresholds cause false failovers on busy links.
• Packet Loss thresholds: defaults (10% / 20%) are sane for cable and fiber. Cellular WANs often baseline at 2–5% loss; raise the warning threshold on those or you’ll see constant flapping.
• Probe interval / Time period: longer windows (e.g., 2 s probe, 60 s period) reduce false positives. Shorter windows fail over faster but flap more.

OPNsense uses dpinger to monitor each gateway with these parameters — review the gateway documentation if you need to tune averaging windows or alert behavior precisely (OPNsense gateways manual ↗).

Step 3: Create the gateway group

System → Gateways → Group → Add:

• Group Name: WAN_FAILOVER
• Gateway Priority:
  • WAN_DHCP → Tier 1
  • WAN2_DHCP → Tier 2
• Trigger Level: Packet Loss or High Latency (this is the key choice — “Member Down” only fails over on full outage and ignores brown-outs, which are the more common real-world failure)
• Description: “Primary WAN1 fiber; failover to WAN2 LTE”

For load balancing instead, set both gateways to the same tier — OPNsense will round-robin new connections across them. Stickiness can be approximated by enabling sticky connections in firewall settings, but it is not perfect; treat it as best-effort.

OPNsense’s multi-WAN how-to walks through the same group structure with screenshots (OPNsense multiwan how-to ↗).

Step 4: Point LAN traffic at the group

Firewall → Rules → LAN. Find the default “allow LAN to any” rule and edit it.

• Click Advanced features → scroll to Gateway → select WAN_FAILOVER.
• Save and apply.

Without this step, OPNsense uses the default system gateway for outbound traffic and never touches your group. This is the single most common reason “multi-WAN doesn’t work” — the group is configured but no rule references it. Internal-only LAN rules (e.g., LAN to a DMZ) must not set a gateway, or you’ll force internal traffic out the WAN. Set the gateway on the broad “to internet” rules only.

For more advanced setups (per-VLAN policy routing, separating IoT traffic to a metered cellular link, sending guest Wi-Fi exclusively out WAN2) duplicate this rule per source interface and choose the appropriate gateway group. That same pattern is what powers traffic segmentation in our VLAN configuration guide.

Step 5: Configure outbound NAT for both WANs

Firewall → NAT → Outbound. If you were in Automatic mode you can usually stay there — OPNsense generates rules for any interface marked as a gateway. Verify by switching to Hybrid mode and inspecting the auto rules: each LAN subnet should appear with a NAT rule for both WAN1 and WAN2. If a WAN is missing, outbound packets leaving that interface will use the firewall’s WAN IP correctly on one path but get dropped on the other — symptom: failover “works” but no traffic flows on the secondary.

Step 6: DNS — the part everyone gets wrong

DNS is where multi-WAN setups silently break. Two failure modes:

1. Unbound configured to use only WAN1’s ISP resolvers. When WAN1 dies, Unbound has no upstream and resolution stops even though packets could exit WAN2. Fix: System → Settings → General → set DNS servers manually to public resolvers (1.1.1.1, 9.9.9.9, 8.8.8.8) and assign each to a different gateway so each resolver only routes via its corresponding WAN. Uncheck “Allow DNS server list to be overridden by DHCP” so ISP-pushed resolvers don’t quietly replace yours.
2. Unbound running in DNSSEC-validating recursive mode is unaffected by upstream resolver outages (it talks directly to root/authoritative servers) but is sensitive to per-WAN connectivity. Confirm Unbound’s outbound interface is set to All so it can use whichever WAN is healthy — the configuration UI is covered in the OPNsense DNS menu reference (OPNsense DNS menu ↗).

Either way, test DNS resolution explicitly after a failover. A multi-WAN setup that fails over packets but stops resolving names looks like a “broken internet” to every user.

Step 7: Test the failover

Pull the WAN1 cable (or block its monitor IP at an upstream device). Watch System → Gateways → Status — the WAN1 gateway should transition to Offline within your configured window (typically 10–30 seconds). On a LAN client:

# Continuous connectivity check
ping -i 1 1.1.1.1

# Confirm the source IP actually changed
curl -s https://ifconfig.io

You should see a brief ping gap, then recovery; the second curl should return the WAN2 public IP. Reconnect WAN1 — within the recovery window the gateway returns to Online and existing connections may either preempt back to WAN1 (default) or stay on WAN2 until they close (sticky). Decide which behavior you want and configure consciously; flapping preemption mid-call is worse than a slightly suboptimal path.

Also test the realistic failure mode: not a cable pull but degradation — high loss without full outage. Use a traffic shaper to inject 30% loss on WAN1 and confirm the gateway transitions on the latency/loss trigger you configured. This is the failure mode “Member Down” misses entirely.

Common pitfalls

• Stateful sessions break on failover. TCP connections established on WAN1 cannot continue on WAN2 because the source IP changes — the remote end sees an unknown source and resets. This is fundamental, not a misconfiguration. New connections work fine; long-lived ones (SSH, VPN, video calls) drop and reconnect.
• VPN tunnels need pinning. WireGuard or IPsec tunnels should be pinned to a single WAN unless you actively want them to migrate, in which case you need a hostname-based endpoint plus dynamic DNS on both WANs. Our WireGuard road warrior guide covers single-WAN binding; multi-WAN tunnel migration is genuinely complex and rarely worth it for a homelab.
• Reply-to and asymmetric routing. OPNsense automatically applies reply-to so inbound connections on WAN2 reply via WAN2. If you’ve disabled this in firewall advanced settings (a common “performance tweak” that’s almost always a mistake), inbound services on the secondary WAN will accept packets and then reply out the primary, breaking the connection. Leave reply-to enabled.
• Monitor IP equals gateway IP. Defeats the point. Always use a public anchor on the far side of the upstream so a working router with a broken backhaul is correctly flagged as down.
• Cellular WAN baseline loss. Mobile networks routinely show 1–3% loss in normal operation. Defaults will flap; raise the warning and alarm thresholds, or use longer averaging windows for that gateway specifically.

When multi-WAN is not the right answer

If your uptime requirement is “an hour of downtime per year is fine,” a single reliable fiber line plus a tested HA pair for hardware redundancy is far simpler and addresses the more likely failure mode (your firewall hardware, not your ISP). Multi-WAN earns its complexity only when ISP outages are your dominant downtime cause — verify that with a few months of monitoring before adding a second uplink and the configuration surface that comes with it.

Done right, gateway groups give you genuine path diversity that survives a backhoe, a regional cable outage, or a single-ISP fiber cut. Done casually, they give you a network that works until the first time it fails over, then surfaces every DNS, NAT, and routing assumption you didn’t validate. Stage it, test the degradation mode, and document the expected failover behavior so the next person doesn’t mistake a healthy preemption for a fault.

Comparing platforms? FirewallCompare ↗ puts OPNsense gateway groups side-by-side with pfSense ↗ gateway groups and UniFi’s WAN failover.