Setting Up Multi-WAN Failover in OPNsense

Setting up multi-WAN failover in OPNsense takes four steps: assign the second WAN interface, define a gateway on each WAN, put both gateways into a gateway group with tiers, and point your LAN firewall rule at that group. Done in order, failover becomes automatic — the firewall switches to your backup in seconds when the primary dies, and switches back on its own when it recovers.

I run this exact configuration on OPNsense at home, with fiber on WAN1 and a 5G modem on WAN2. The whole thing took me maybe twenty minutes the first time I understood the tier model — and about two frustrated evenings the time before that, when I skipped the one step everyone skips. That step is the LAN rule, and I will not let you make the same mistake I did.

This is the hands-on companion to the broader multi-WAN and internet failover overview. If you already have OPNsense running on real hardware, you are ready. If you are still on an ISP box, start with a proper install first — the OPNsense setup guide gets you there, because a second WAN is not something you bolt onto a consumer router.

What Do You Need Before You Start?

You need OPNsense already installed on hardware with at least three network ports, plus a second internet source physically plugged into a free NIC. One port is your LAN or trunk, one is your existing WAN, and the third becomes WAN2. That third NIC is the non-negotiable requirement — you cannot do real failover on a two-port box without VLAN gymnastics you do not want.

My firewall is a fanless quad-i226 appliance, so I have four ports and room to spare. The second WAN source in my case is a 5G modem in bridge mode, handing my firewall an address directly. Before you touch the OPNsense config, confirm that second source actually gives your WAN2 interface an IP — plug it in, and if the modem insists on doing its own NAT, put it in bridge or pass-through mode first. Skip that and you inherit a double-NAT problem that will haunt your port forwards and your VPN later. One physical check now saves an hour of confusion after.

Step 1: Assign the Second WAN Interface

Go to Interfaces then Assignments, pick the physical NIC your backup line is plugged into, add it, and it appears as a new interface — typically OPT1. Rename it to something honest like WAN2 or WAN_LTE, enable it, and set its IPv4 configuration to match what the backup hands you: DHCP for most cellular modems, static if your second ISP gave you a fixed address.

Naming matters more than it looks. Six months from now, staring at a rule at 11pm, “WAN_LTE” tells you instantly which line it governs; “OPT1” tells you nothing. I label mine by medium — WAN_FIBER and WAN_LTE — the same way I label the physical patch runs in the rack, because the network you can read is the network you can fix. Once assigned and enabled, OPNsense should pull an IP on WAN2 within a few seconds. If it stays blank, the problem is upstream at the modem, not in OPNsense — go back and confirm bridge mode.

Step 2: Create a Gateway for Each WAN

Under System then Gateways then Configuration, you will already have a gateway for your primary WAN. Add a second one bound to WAN2, give it a clear name, and set the monitor IP to a stable public address — not the ISP’s own gateway, which can answer while the path behind it is dead. This is where failover detection actually lives.

The monitor IP is the single most important field on this screen. OPNsense runs the dpinger daemon against it continuously, watching latency and packet loss to decide whether the link is healthy. Point it at something rock-solid and neutral — a well-known public DNS resolver like 1.1.1.1 or 9.9.9.9 works because it is always up and not owned by your ISP. Do not point both WANs at the same monitor IP if you can avoid it; give each its own so a failure on one is unambiguous. The full logic behind these thresholds — why the loss trigger and the timers matter so much — is worth understanding deeply, and the OPNsense gateways documentation lays out every field. I cover the specific loss and latency numbers, probe interval, and down timers in the gateway monitoring and dpinger guide. Set the monitor IPs now; we will tune the sensitivity separately.

Step 3: Build the Gateway Group With Tiers

Under System then Gateways then Group, create a new group — call it “Failover” — and add both gateways. Give your primary WAN Tier 1 and your backup WAN Tier 2. Set “Trigger Level” to “Packet Loss or High Latency.” That tier difference is the entire behavior: traffic uses Tier 1 until every Tier 1 member is down, then falls to Tier 2.

Here is the fork in the road, and it is worth stopping on. If you put both gateways on the same tier, you have built load balancing, not failover — traffic spreads across both lines simultaneously. Different tiers means failover: one line carries everything, the other waits in reserve. Same screen, opposite outcome. For a home that wants a backup rather than aggregate throughput, you want different tiers, primary on 1, backup on 2. The trigger level tells the group what counts as “down” — packet loss, high latency, or either. I run “packet loss or high latency” because a line that is technically up but crawling at 3-second ping times is useless for a video call, and I would rather fail over than sit on a zombie connection.

Step 4: Point Your LAN Rule at the Gateway Group

This is the step that quietly breaks more failover setups than everything else combined. Go to Firewall then Rules then LAN, open your main allow rule, expand the Advanced options, and set the Gateway field to your new “Failover” group instead of leaving it on default. Without this, your traffic ignores the group entirely and pins to the primary WAN no matter what the monitor reports.

I lost two evenings to this exact thing. I had a beautiful gateway group, correct tiers, working monitors — and when I unplugged the fiber to test, everything went dark and stayed dark. Failover “didn’t work.” The problem was that my LAN rule still used the default gateway, so the group was never consulted; the firewall dutifully tried to route out a dead WAN. The moment I changed that one dropdown, unplugging the primary produced exactly what I wanted: a few seconds of pause, then cellular carrying the house. If you have per-VLAN rules rather than one flat LAN rule, each rule that should fail over needs its gateway set to the group. Rule order and gateway assignment are the whole game here — the same discipline covered in the OPNsense firewall rules guide applies directly.

How Do You Test Failover Without Waiting for a Real Outage?

Pull the primary WAN cable and watch. Within roughly 5 to 15 seconds, dpinger marks the primary down, the gateway group promotes Tier 2, and new connections start flowing over the backup. Then plug the primary back in and confirm it returns to Tier 1 on its own. That physical unplug test is the only way to know it truly works — configuration that looks right on screen means nothing until you have watched it switch.

Do the test deliberately, not during something important. Open the dashboard’s Gateways widget so you can see the status flip in real time — the primary goes red, the group’s active member changes, the backup goes green. Have a continuous ping running from a LAN device to something public while you do it; you will see a short gap, then replies resume. On my rig the gap is usually well under fifteen seconds, and existing long-lived connections like an SSH session may drop while brand-new connections come up instantly on the backup. That is expected: failover reroutes new traffic, it does not seamlessly migrate live sessions. When you plug the fiber back in, watch it reclaim Tier 1 — if it does not, your primary gateway’s monitor is misconfigured.

What Happens to DNS When You Fail Over?

DNS is the sneaky failure that makes a “working” failover feel broken. If your firewall’s DNS resolver is configured to send queries out only the primary WAN, failing over the data path does nothing for name resolution — pages hang because lookups still try the dead line. The fix is making sure your resolver can use whichever WAN is currently active.

I run Unbound on the firewall for recursive resolution, and the key setting is not binding its outbound queries to a single gateway. In OPNsense, leaving Unbound’s outgoing interface unrestricted lets it follow the active route, so when the group promotes the backup, DNS rides the backup too — the Unbound documentation covers the outgoing-interface setting in detail. If you use conditional forwarding or upstream DoT, point it at resolvers reachable over either line. This is exactly the kind of detail the Unbound recursive DNS guide gets into, and it is worth getting right — a failover that swaps your data path but strands your DNS is a failover that fails the one time you need it. Test it by doing your unplug test and then loading a site you have never visited, forcing a fresh lookup.

Does This Work the Same on pfSense?

Nearly identically. pfSense uses the same core concepts — gateways, gateway groups with tiers, and a LAN rule whose gateway field points at the group. The menu paths differ slightly and the labels are not word-for-word, but if you understand the OPNsense model you can configure pfSense multi-WAN failover from memory. Both use dpinger under the hood for monitoring.

I treat OPNsense and pfSense as two boxes worth knowing rather than a rivalry to pick a side in, and multi-WAN is a good example of why — the mental model transfers completely. The OPNsense versus pfSense comparison covers where they genuinely diverge, but failover is not one of those places. If you are coming from a pfSense background, the only adjustment is finding where each setting lives; the tier logic and the all-important LAN-rule gateway step are the same on both. That consistency is a feature, not a coincidence — both projects inherited the approach from the same lineage.

Further Reading

• Multi-WAN & Internet Failover: A Home Network Guide
• OPNsense Setup Guide
• OPNsense Firewall Rules Explained
• Double NAT Problems Explained
• OPNsense vs pfSense in 2026