Dual-WAN OPNsense deployment guide
OPNsense Dual-WAN Hardware Guide: Ports, Failover & Power
Dual-WAN reliability comes from two independent paths that OPNsense can monitor and route through, not merely from plugging two cables into the firewall. The hardware plan should account for two provider handoffs, enough physical interfaces, switch or modem placement, different link speeds, power protection, and what happens to active sessions when the primary circuit fails and later returns. A second WAN that shares the same local failure domain may add bandwidth without adding much resilience.
Quick answer
Use separate physical WAN paths and gateway groups deliberately
For straightforward failover, the common pattern is a preferred gateway in a higher-priority tier and a backup in the next tier. For load balancing, gateways can share a tier. In both cases, choose monitoring targets that represent useful connectivity, give each circuit a physical path the firewall can actually reach, and preserve at least one LAN interface. Do not count aggregate ISP bandwidth as the speed of one TCP session.
Live Amazon hardware
Live hardware for multi-WAN OPNsense builds
The catalogue emphasizes multi-port firewall appliances, PCIe NICs and managed switches that can support deliberate WAN/LAN separation. USB Ethernet adapters and Wi-Fi routers are not substituted for PCIe or appliance classes.
Buying decision
The backup link is valuable only if the failure cannot take it too
If both WANs terminate on the same powered switch, the same modem, the same building carrier entrance or the same UPS, identify that dependency honestly. Some shared infrastructure is unavoidable, but knowing it lets you decide whether the second circuit is for capacity, provider diversity, or genuine business continuity. The most resilient design also protects both handoff devices from short power interruptions.
Interactive planner
OPNsense Dual-WAN Hardware Planner
Compare WAN speeds, routing mode, port availability and metered-backup behavior.
This tool plans ports and routing direction. It does not combine two ISP rates into a guaranteed single-session speed and does not know provider-specific modem, PPP or address restrictions.
Compatibility checkpoints
Dual-WAN hardware checkpoints
Independent handoffs
Confirm each provider has its own modem, ONT or Ethernet handoff and document any shared building or carrier dependency.
Enough physical ports
Reserve two WAN interfaces plus the LAN/trunk interfaces needed by the local network; avoid emergency USB NICs as a default design.
Gateway monitoring
Use meaningful monitor addresses and verify failure detection for both complete outages and degraded links.
Power continuity
Back up the firewall and both ISP handoff devices if short utility interruptions are expected to trigger unnecessary WAN failovers.
Decide whether the second WAN is for uptime or capacity
Failover and load balancing solve different problems. A failover circuit can be slower and still be valuable if it keeps essential services online when the primary provider fails. Load balancing aims to distribute sessions across available gateways and can use unequal weights when link capacities differ. Write the objective first because it influences link choice, data caps, gateway tiers and monitoring. A 5G backup with a small allowance may be excellent emergency connectivity but a poor candidate for equal-tier balancing with an unlimited fiber circuit.
Gateway groups depend on monitoring quality
OPNsense uses gateway monitoring and group tiers to decide when a path is usable. A monitor target should reveal the kind of failure that matters to users, not merely whether the local modem responds. Use different sensible monitor addresses for separate gateways and review latency/loss thresholds where required. Overly sensitive monitoring can cause flapping; overly tolerant monitoring can leave users on a broken path. During commissioning, simulate both hard link loss and upstream reachability loss so the gateway state reflects real service conditions.
Failover is not the same as bandwidth bonding
When two gateways are placed in the same tier, OPNsense can distribute connections between them, but that does not turn two independent ISPs into one larger pipe for a single ordinary TCP flow. Session stickiness, source addresses and remote services still matter. Plan the network around per-session behavior and the aggregate number of users rather than advertising the arithmetic sum as guaranteed speed. Applications that require one stable public IP may need policy routing or to remain pinned to a particular circuit even while general browsing is balanced.
Reserve physical interface count before buying the appliance
A dual-WAN firewall commonly needs at least two WAN ports plus one LAN or trunk port, and HA or dedicated management can raise the count further. Four-port appliances give useful breathing room for many small deployments. If the platform has an accessible PCIe slot, a well-supported Intel NIC can add ports cleanly. Avoid designing around a pile of USB Ethernet dongles unless the use case is temporary or explicitly tested. Physical port labels should map clearly to WAN1, WAN2 and LAN roles to reduce mistakes during provider troubleshooting.
Provider handoffs determine the cabling topology
One circuit may arrive as Ethernet from an ONT while another requires a cable modem, LTE router or PPP session. Document bridge mode, DHCP, static addressing, VLAN tags and MAC restrictions for each service. If provider devices must remain routers, double NAT may affect inbound services and VPNs. If both handoffs connect through a shared managed switch, isolate them into appropriate VLANs and understand that the switch becomes a common dependency. Direct firewall connections are simpler when port count and physical placement allow them.
Policy routing needs exceptions for local and private destinations
OPNsense multi-WAN guidance notes that policy-based routing can send traffic toward a gateway group even when the destination is an internal network or the firewall itself, unless earlier rules handle those cases. VPN subnets, local services and DNS often need explicit thought. Hardware cannot fix a policy route that points private traffic at an ISP, but a clean interface layout and documented VLANs make the rule design easier to verify. Test local management and site-to-site paths while both gateways are healthy and again during failover.
Metered backups need deliberate failback behavior
A cellular or satellite backup can accumulate cost after the primary returns if old firewall states continue using the backup path. Current OPNsense guidance includes failover and failback state controls for scenarios where sessions should be killed and rebuilt on the preferred gateway. Decide whether rapid return is more important than preserving sessions. Monitor data usage separately from link status, and avoid putting bulk backup jobs or software updates on a metered circuit unless policies explicitly allow them.
DNS should survive a gateway transition
If resolver reachability depends on one ISP, users can perceive a full outage even when the firewall successfully moves traffic to the other circuit. OPNsense multi-WAN examples associate DNS servers with gateways and also require rules that keep traffic destined for the firewall itself from being misrouted by a broad gateway-group rule. Whether you use Unbound locally, provider resolvers or external DNS, test name resolution after each WAN transition. Include the firewall’s own update and monitoring traffic, not only client browsing.
VPN and inbound services may need a preferred WAN
Site-to-site VPNs, remote-access listeners and port-forwarded services often depend on a public address. A second ISP does not automatically make those services redundant because remote peers and DNS may still point at the primary. Consider dynamic DNS, multiple VPN endpoints, peer failover or application-level mechanisms. If the backup WAN is behind carrier-grade NAT, inbound connections may be impossible even though outbound browsing works. Document which services are expected to survive a WAN failure rather than assuming gateway-group failover covers every application.
Protect both ISP devices from short power events
A UPS that powers the firewall but not the modem or ONT can cause both gateways to disappear during a local outage. Include the handoff devices and any small WAN switch in the protected-load calculation. Cellular backup equipment may have its own battery, but verify its behavior under prolonged loss. If the two circuits are intended to provide genuine diversity, consider whether they share the same UPS, circuit or physical path. Power continuity is part of WAN redundancy because a carrier link is useless when its local termination has no electricity.
Monitor link quality, not just binary status
A primary circuit can remain technically online while suffering severe loss or latency. Gateway trigger levels can respond to those conditions, but aggressive thresholds may move traffic back and forth. Establish baseline latency for each circuit and choose monitor targets that are stable and representative. Log transitions so intermittent provider faults can be distinguished from firewall or switch problems. In a business environment, external monitoring from the internet can add another perspective by confirming whether inbound services remained reachable through the intended path.
Test failover and failback with real sessions
Unplug or disable the primary path in a controlled maintenance window and observe gateway status, active sessions, DNS, VPNs, VoIP and important applications. Confirm the backup carries the expected traffic and that monitoring alerts reach administrators. Restore the primary and verify the chosen failback policy, especially on a metered secondary link. Repeat for the secondary circuit. The resulting runbook should describe what normal failover looks like, how long detection takes, and which services are expected to reconnect rather than remain seamless.
Questions people ask
Dual-WAN OPNsense questions
How many NIC ports are needed for dual WAN?
At minimum, two WAN interfaces plus a LAN path. VLAN trunks, HA synchronization, dedicated management or additional LAN segments can raise the required count.
Does OPNsense combine two WAN speeds?
It can load-balance sessions across gateways, but ordinary single flows are not automatically bonded into the sum of both ISP rates.
How does OPNsense WAN failover work?
Gateway monitoring feeds gateway groups. Different tiers can make one gateway preferred and another a fallback when the higher-priority path is considered unavailable.
Can I use one fast and one slow ISP?
Yes. A slower link can be a useful failover circuit, and unequal load-balancing weights can be used when balancing links of different capacities.
Can the backup WAN be cellular?
Yes for many outbound failover scenarios, but data caps, latency, carrier-grade NAT and inbound-service limitations should be planned explicitly.
Should both WAN modems be on a UPS?
If you expect connectivity through a local power outage, protect the firewall and the handoff device for each WAN that should remain available.
Do I need a managed switch for dual WAN?
Not when both provider handoffs connect directly to dedicated firewall ports. A managed switch becomes useful when WAN circuits are intentionally carried on separate VLANs through shared switching.
Why do VPNs sometimes break during failover?
VPN endpoints and remote peers may depend on a specific public IP, policy route or NAT path. WAN failover does not automatically reconfigure the remote side.
What are sticky connections?
They help keep subsequent traffic from the same client/session relationship on the same gateway, which can prevent websites from reacting badly to frequent source-IP changes during load balancing.
How should dual WAN be tested?
Test primary loss, secondary loss, upstream reachability failure, DNS, VPNs, metered failback behavior and restoration while monitoring gateway states and real client sessions.
Official references and methodology
Verify the live topology and hardware before deployment
This guide uses current OPNsense multi-WAN concepts for gateway monitoring, tiered groups, load balancing, sticky connections, policy routing and failover/failback states. Hardware recommendations focus on ports and failure domains rather than claiming that two links create a bonded single-flow speed. Production behavior depends on ISP addressing and handoff equipment, which must be verified directly.
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, firmware, UPS runtime, battery condition, NIC revisions, SSD variants, appliance configurations and seller terms can change. Verify the exact delivered hardware and current OPNsense documentation before production deployment.