
pfSense Plus provides Multi-WAN capabilities through gateway groups. A primary gateway can be assigned a higher priority than a backup, allowing traffic to move to the secondary connection when the preferred path is considered unavailable. The same framework can also be used to distribute connections across multiple active WANs.
The technical capability is already there. The more important question is how the failover should be designed around the network.
Planning should begin with the impact of losing the primary Internet connection rather than with the configuration of the firewall.
For some businesses, the priority may simply be keeping employees online. In another environment, Internet connectivity may support access to cloud applications while site-to-site VPNs carry operational traffic between locations. The consequences of an outage can therefore vary considerably even when two organizations have similar Internet connections.
That affects what the backup service needs to provide.
A 1 Gbps primary fibre connection paired with a much smaller backup circuit may be perfectly adequate if the objective is to maintain access to essential applications during an outage. A business expecting normal operating capacity after failover may need the secondary connection sized much closer to the primary service.
The operating model also needs to be decided. Some organizations want one ISP carrying traffic during normal operation while the second remains available for failover. Others may prefer to use both connections while they are healthy.
pfSense Plus supports both approaches through gateway tiers. Gateways assigned to different tiers can operate in a preferred-and-backup arrangement, while gateways placed in the same tier can participate in load balancing. If one of those gateways becomes unavailable, pfSense removes it from active use.
The architecture should therefore start with the required business outcome: what level of connectivity should remain when the preferred ISP is unavailable?
An Internet connection does not always fail cleanly.
A disconnected cable is easy for a firewall to detect. Real ISP problems can be less obvious. The WAN interface may remain up while connectivity beyond the provider's local equipment has disappeared. A circuit can also remain technically online while degraded performance makes it unsuitable for important applications.
pfSense Plus uses gateway monitoring to assess the health of WAN connections. The monitoring process can track packet loss and latency and gateway groups can be configured to react according to the failure conditions selected by the administrator. Disabling gateway monitoring prevents Multi-WAN from detecting failures correctly.
The monitoring target matters as well.
If the firewall monitors an address on the ISP's local equipment, that address may continue responding even after upstream Internet connectivity has failed. pfSense can then continue treating the WAN as available despite users being unable to reach the wider Internet. Netgate specifically identifies inappropriate monitor addresses as a common reason for Multi-WAN failover not working as expected.
Good failover design therefore requires a useful definition of failure.
It should also account for what happens when traffic changes paths.
When a connection is established through the primary ISP, its state is associated with that path and usually with the public IP address presented by that WAN. Moving to another ISP can change the source address seen by remote systems. Some applications will establish a new connection quickly, while existing sessions may be interrupted.
That is an important distinction when discussing “seamless” Internet failover. The firewall may redirect new traffic almost immediately while a user still notices that an active application session has to reconnect.
The objective should be predictable recovery, rather than assuming that attaching a second WAN makes every outage invisible.

General Internet access is only one traffic flow through a business firewall.
If branches communicate with headquarters over IPsec, moving outbound Internet traffic to the backup WAN does not by itself guarantee that those tunnels will continue operating correctly.
pfSense Plus supports IPsec in Multi-WAN environments, including failover using gateway groups. One approach combines the gateway group with Dynamic DNS so that the remote peer can follow the active WAN address. Netgate notes that DNS-dependent IPsec failover can take several minutes while the change propagates and the tunnel is re-established.
Networks requiring faster convergence can use a different architecture. Netgate documents routed IPsec using separate VTI tunnels and dynamic routing, which can allow traffic to move between paths much more quickly when designed appropriately.
The important design lesson is that VPN resilience needs to be considered alongside WAN resilience.
DNS also deserves attention. A firewall may successfully move users onto the secondary Internet connection while name resolution remains dependent on a DNS path affected by the failed WAN. To the user, the Internet still appears to be down even though routing is working.
Netgate's Multi-WAN guidance includes specific considerations for DNS services and Dynamic DNS when more than one WAN is involved.
The failover plan should consequently extend beyond the physical links. The services that make business connectivity useful must continue functioning on the alternate path.
A Multi-WAN configuration should not receive its first meaningful test during an actual ISP outage.
Netgate recommends testing failover in a controlled environment immediately after configuration. Its guidance includes deliberately creating WAN failures and confirming that the gateways change state as expected.
A useful test should reflect more than one failure condition.
Physically disconnecting the primary WAN confirms that the firewall can react when the interface disappears. A separate test can simulate a situation in which the ISP equipment remains connected while the upstream service becomes unavailable.
Recovery should also be observed.
When the preferred ISP returns, the business needs to understand how traffic moves back to it and what that transition means for active connections. Critical VPN connectivity should be verified as part of the same exercise.
Testing may reveal that the firewall configuration is operating exactly as intended while an application behaves differently from what the business expected. Finding that out during commissioning gives the network team an opportunity to adjust the design before availability genuinely depends on it.
Two ISP connections provide the raw ingredients for Internet redundancy. Turning them into a reliable failover solution requires more thought.
The design has to establish what the business needs to keep operating and determine how pfSense Plus should identify an unhealthy connection. The behaviour of dependent network services also has to be understood before the deployment can be considered resilient.
Netgate appliances running pfSense Plus provide the Multi-WAN capabilities needed to build that architecture. The appliance itself must also have the interface capacity and performance required for both the normal workload and the traffic it will carry during failover.
As an Authorized Netgate Value-Added Reseller, Optace Networks can design the Netgate deployment around those requirements rather than treating Internet redundancy as simply adding another WAN cable to the firewall.
For businesses planning dual-ISP connectivity or reviewing an existing failover setup, Optace Networks can help design and deploy a Netgate and pfSense Plus architecture around the availability requirements of the network.
.jpg)
-(1).png)


In this article, we delve into the principles of OFDMA, the defining principle of the 802.11ax standard, its applications, and its impact on wireless broadband.

© 2026 PoweredbyOptace Networks Limited. All Rights Reserved.