How to configure OPNsense multi-WAN failover

Home internet has always been important to me — and these days, it’s basically a production environment.

I use OPNsense as my firewall. It’s open source, wildly capable, and flexible enough to run on anything from a mini PC to a rack-mounted box. With two ISPs and a few smart rules, I built out per-VLAN WAN failover: every VLAN gets a preferred WAN and a fallback, with automatic switching if one link goes down.

The result? Failover in seconds. No more dropped video calls. No more disconnects during a disaster recovery exercise. No more “sorry, my internet died.”

This guide walks through the setup — from gateway groups and NAT rules to real-time monitoring — so you can build your own zero-drama network.

Why this matters

Remote work and hybrid setups turned many employees’ home setups into production-adjacent systems.¹ In Q1 2025, 4 in 10 jobs allow some amount of remote work, with nearly half of job seekers preferring hybrid roles and over a quarter seeking fully remote positions.¹ Even brief downtime can interrupt or derail critical tasks.

Enterprise networks are built around this. Our home networks should be too.

How the setup works

We’re using:

• Fiber (1 Gbps): handles general network traffic, streaming, and personal devices
• Cable (600 Mbps): dedicated to work-only VLAN for complete network isolation

Traffic splits by VLAN:

• VLAN 10 (work): uses cable, falls back to fiber for business continuity
• VLAN 20 (general): uses fiber, falls back to cable

This approach provides complete network segmentation: when both links are working, work traffic is fully isolated from personal network activity. If the cable connection fails, work traffic can still continue over fiber while maintaining the same level of network isolation.

Why per-VLAN failover?

Why not just use one global failover policy? In practice, different devices and workloads have different tolerances for latency, jitter, and brief outages. By assigning each VLAN its own gateway group, you can:

• Keep work traffic completely isolated from personal network activity when both links are working
• Maintain business continuity with automatic failover if the primary work link goes down
• Set distinct alerting or monitoring policies per network segment
• Maximize your investment by actively using both WAN connections instead of letting one sit idle

Prerequisites

You’ll need:

• OPNsense with three or more network interfaces
• Two active WAN links
• VLANs already configured
• Some experience with OPNsense routing, NAT, and rules

Step 1: Configure WAN interfaces

In Interfaces → Assignments, scroll to the bottom under “Assign a new interface” and:

1. Select your first physical WAN device from the dropdown
2. Give it a description (e.g., “WAN_FIBER”)
3. Click “Add”
4. Configure the interface:
   • Enable
   • IPv4: DHCP or static
   • Block bogon networks
   • Block private networks
5. Save and repeat for your second WAN device with description “WAN_CABLE”
6. Configure the second interface with the same settings

Step 2: Create gateways

In System → Gateways → Configuration, click the plus button and create two gateways:

WAN_FIBER_GW

• Name: WAN_FIBER_GW
• Interface: WAN_FIBER
• Address Family: IPv4
• Priority: 253 (higher priority - lower numbers are preferred)
• IP Address: (leave blank)
• Upstream gateway: ✓ (checked)
• Monitor IP: 1.1.1.1
• Description: Fiber WAN Gateway

WAN_CABLE_GW

• Name: WAN_CABLE_GW
• Interface: WAN_CABLE
• Address Family: IPv4
• Priority: 254 (lower priority - higher numbers are less preferred)
• IP Address: (leave blank)
• Upstream gateway: ✓ (checked)
• Monitor IP: 8.8.8.8
• Description: Cable WAN Gateway

Gateway priority only matters for the default gateway when no specific routing is defined. Since we’ll be using policy-based routing with VLAN firewall rules, the actual traffic routing will be determined by those rules, not the gateway priority. However, it’s important to set this up as a fallback.

Gateway ‘priority’ in Step 2 affects only the system default gateway, whereas gateway group ’tiers’ in Step 3 determine routing when using policy-based rules. The priority numbers (253 for fiber, 254 for cable) don’t determine which WAN your VLANs use - that’s controlled by the firewall rules. These priorities only matter if traffic doesn’t match any specific rules and falls back to the default gateway.

You can customize the latency thresholds, packet loss thresholds, probe intervals, and other advanced settings by clicking “Advanced settings.” To start, it is best to leave these at the defaults.

Important: Make sure “Disable gateway monitoring” is unchecked for both gateways. Gateway monitoring is critical for WAN failover ². OPNsense uses DPinger (ICMP ping) to track connection health and automatically switches between WANs when packet loss or latency is detected ³. When your primary link recovers, routing returns to it automatically.

Step 3: Set up gateway groups

In System → Gateways → Groups, click the plus button and create two groups:

FIBER_PRIORITY

• Group name: FIBER_PRIORITY
• Gateway priority: WAN_FIBER_GW / Tier 1, WAN_CABLE_GW / Tier 2
• Trigger level: Packet loss or high latency
• Description: Fiber primary, Cable failover (for general traffic)

CABLE_PRIORITY

• Group name: CABLE_PRIORITY
• Gateway priority: WAN_CABLE_GW / Tier 1, WAN_FIBER_GW / Tier 2
• Trigger level: Packet loss or high latency
• Description: Cable primary, Fiber failover (for work traffic isolation)

Gateway groups use a tier system where lower numbers indicate higher priority.² When no usable gateways are present within a tier, the next tier is considered. The trigger level determines when a gateway is considered offline: either when it’s fully down, has packet loss, or increased latency.²

Trigger level options explained:

• Member down: Triggers when the gateway has 100% packet loss
• Packet loss: Triggers when packet loss exceeds the defined threshold
• High latency: Triggers when latency exceeds the defined threshold
• Packet loss or high latency: Triggers for either condition (recommended for most setups)

Avoid the ‘member down’ trigger unless you only want failover when the WAN link goes completely offline. ‘Packet loss or high latency’ catches more subtle performance drops and usually results in smoother transitions.

Enable sticky connections under Firewall → Settings → Advanced. This prevents individual TCP/UDP sessions from switching between WANs during failover, which is crucial for maintaining stable video calls, banking sessions, and other sensitive connections.³

You will also need to enable “Default gateway switching” under System → Settings → General. This allows the default gateway of the firewall to change when a failover happens, which is necessary for the failover and failback of states to trigger correctly.

Step 4: Add VLAN firewall rules

Go to Firewall → Rules and create pass rules per VLAN:

VLAN 10 (work)

• Action: pass
• Interface: VLAN10
• Source: VLAN10_net
• Destination: any
• Gateway: CABLE_PRIORITY

VLAN 20 (general)

• Action: pass
• Interface: VLAN20
• Source: VLAN20_net
• Destination: any
• Gateway: FIBER_PRIORITY

Note: If you’ve named the interface differently in OPNsense, select that name instead of ‘VLAN10’ or ‘VLAN20’.

This ensures each VLAN uses its assigned primary and backup gateway path.

Step 5: Set up failover notifications

OPNsense uses Monit for monitoring services and sending notifications.⁴ To get notified when WAN failover events occur, configure Monit in Services → Monit → Settings:

1. General settings: Enable Monit and configure your SMTP server details
2. Alert settings: Add your email address as a recipient (this sets up who gets alerted)
3. Service settings: Add a “gateway_alert” service with:
   • Path: /usr/local/opnsense/scripts/OPNsense/Monit/gateway_alert
   • Tests: NonZeroStatus or ChangedStatus
   • Type: Custom

This uses OPNsense’s built-in gateway monitoring script to automatically alert you when gateways go down or change status.⁵

Step 6: Test failover

Test each scenario:

1. Check gateway status in Status → Gateways
2. Disconnect cable — VLAN 10 (work) should fail over to fiber
3. Reconnect cable — work traffic should return to isolated cable link
4. Repeat with VLAN 20 (general) and fiber

If failover feels sluggish, revisit your monitoring intervals and NAT rules.

Monitor and maintain

• Watch gateway status under Status → System Logs
• Review traffic patterns with Reporting → Netflow
• Check Interfaces → Overview for live stats
• Schedule failover tests monthly

Troubleshooting

Failover not working

• Check gateway settings in firewall rules
• Verify that monitoring IPs are reachable
• Confirm that NAT rules match each VLAN’s outbound traffic

Failover too slow

• Lower monitoring interval
• Avoid packet loss triggers that are too forgiving

Unexpected routing behavior

• Double-check rule order
• Make sure each VLAN has only one matching pass rule
• Add exemption rules for local traffic (VLAN to firewall, inter-VLAN) before gateway group rules
• DNS traffic to firewall: Add a rule above your default LAN allow rule to route DNS traffic (port 53) to the firewall itself using the default gateway, not the gateway group
• If using Unbound DNS, add a rule allowing VLAN traffic to firewall on port 53 (no gateway specified)

Best practices

• Enable notifications under System → Settings → Notifications
• Use reliable external IPs for WAN monitoring: 1.1.1.1 (Cloudflare) for Fiber and 8.8.8.8 (Google) for Cable³
• Enable sticky connections to maintain session stability³
• Configure DNS resolver with custom forwarding to prevent DNS leakage or loopback issues³
• Enable “Default gateway switching” under System → Settings → General so firewall traffic (DNS, NTP, updates) follows failover²

Conclusion

You don’t need enterprise gear to get real redundancy. With good defaults, smart rules, and regular testing, OPNsense can keep your traffic flowing — even when your ISP doesn’t.

Try it out! Yank an ethernet port and see what happens. If your connection keeps flowing, you’re ready for the next time your fiber line meets the hedge trimmer.