Configure and Test Dual-WAN Failover in pfSense

This guide prefers WAN1 and uses WAN2 when WAN1 fails. It covers one pfSense CE or pfSense Plus firewall with two working Internet connections. This is WAN failover, not failover between two firewall appliances. Gateway groups route new matching connections; existing sessions may need to reconnect when the public source address changes.

Illustration: A gateway group with WAN1 at Tier 1 and WAN2 at Tier 2. Choose the trigger level from the behavior your site needs.

Test on a controlled connection

Changing gateways, default routes, or policy-routing rules can interrupt traffic, VPNs, DNS, and administrator access. Capture the current configuration and keep console access. Disconnect a WAN cable only in a lab or approved maintenance window with an application owner present.

01

Verify Both WANs Work Independently

Baseline

Confirm WAN1 and WAN2 each have a usable IP address, gateway, and upstream path. If WAN2 is new, assign and enable it under Interfaces > Assignments, then set its provider’s address type. Check Status > Gateways and test outbound connectivity on each path before building failover. A gateway group cannot repair an unusable second circuit.

Interfaces > Assignments: WAN1 and WAN2 are assigned and enabled
Status > Gateways: both gateways Online with expected addresses
Diagnostics > Ping: test an approved public endpoint via each WAN

❯ What to Verify

Both Internet connections work on their own and the administrator
can still reach the firewall if either path changes.

02

Choose Reliable Monitor Addresses

Health Check

Under System > Routing > Gateways, inspect each gateway’s monitor IP and gateway monitoring settings. A monitor address must answer reliably through the intended WAN and represent reachability beyond a local modem when Internet failure detection is required. Use distinct, approved monitor targets for the two circuits. Do not disable monitoring: the group needs status to decide when a path failed.

System > Routing > Gateways > edit WAN1 and WAN2
Confirm: monitor address, monitoring enabled, expected gateway IP
Status > Gateways: RTT/loss and Online state are sensible

❯ What to Verify

Both gateways report a meaningful Online state and a WAN1 outage
will not leave its monitor reachable through only the local modem.

Gateway health is more than one ping

Gateway groups can trigger on member down, packet loss, latency, or a combination. Choose the trigger to match the service objective and observe normal link behavior before tightening thresholds; an overly sensitive monitor causes avoidable failovers.

03

Create a Tiered Failover Group

Gateway Group

Open System > Routing > Gateway Groups. Create WAN_FAILOVER with WAN1 at Tier 1 and WAN2 at Tier 2. Select an approved trigger level, add a description, and save. Different tiers mean failover; putting both gateways at Tier 1 would load-balance connections instead.

System > Routing > Gateway Groups > Add
Name: WAN_FAILOVER
WAN1 gateway: Tier 1
WAN2 gateway: Tier 2
Trigger Level: chosen from observed loss/latency requirements

❯ What to Verify

The group lists WAN1 before WAN2 and Status > Gateways shows both members.

04

Route Firewall and Client Traffic Correctly

Policy Routing

For the firewall’s own traffic, set the IPv4 default gateway to the failover group in System > Routing > Gateways. For LAN client traffic, edit or add a LAN pass rule and choose WAN_FAILOVER in its advanced Gateway field. Place a rule for local and VPN destinations above that policy-routed rule with the Gateway left at default, so internal traffic follows the routing table. Apply changes and check rule order. Repeat for IPv6 only if both WANs and the policy are ready for it.

System > Routing > Gateways > Default Gateway: WAN_FAILOVER (IPv4)
Firewall > Rules > LAN (top to bottom):
1. Pass LAN -> local/VPN networks; Gateway: default
2. Pass approved LAN -> Internet; Gateway: WAN_FAILOVER

❯ What to Verify

Firewall-originated traffic has a failover default route, client Internet
traffic matches the group, and local/VPN traffic is not sent toward a WAN.

DNS must survive a WAN1 outage

If firewall or client DNS depends only on a server reachable through WAN1, failover can look broken even while WAN2 routes packets. Review the DNS Resolver or forwarding mode and the firewall’s System > General DNS settings for a path that remains available through WAN2.

Check outbound NAT when using manual mode

Automatic outbound NAT normally creates rules for assigned WAN interfaces. If this firewall uses manual or hybrid outbound NAT, verify that the LAN subnet has an appropriate translation rule on WAN2 before the failover test. A healthy gateway alone does not guarantee that return traffic reaches the client.

05

Establish a Before-Failure Baseline

Validation

From a LAN test client, open a new connection to an approved external IP-check service and record the observed public IP. Confirm it belongs to WAN1. Review Status > Gateways, the group members, DNS resolution, and a representative application. For multi-WAN, use new connections when comparing paths; existing states can preserve the old route.

Before failure: WAN1 Online, WAN2 Online
New client connection: public source address belongs to WAN1
DNS and a representative application succeed

❯ What to Verify

The preferred path is proven before any outage simulation.

06

Simulate and Observe Failover

Controlled Test

During the approved test, disconnect WAN1 at a point that actually makes its monitor fail. Watch Status > Gateways move WAN1 to a failed state, then start a fresh client connection and verify its public IP belongs to WAN2. Test DNS and the application again. If WAN1 remains Online, the monitor is still reachable; fix the monitor design before claiming the failover works. A live call or VPN may reconnect because its source address changed.

Expected after WAN1 failure:
Status > Gateways: WAN1 down, WAN2 Online
New client connection: public source address belongs to WAN2
DNS and approved application remain usable

❯ What to Verify

The measured failover time and any interrupted sessions are recorded.

07

Restore WAN1 and Record the Result

Closeout

Reconnect WAN1 and wait for its health status to recover. Start another new client connection and confirm the intended preferred path returns. Review gateway logs and any application exceptions. Document monitor IPs, trigger level, rule order, DNS behavior, observed failover time, and whether existing sessions survived. Export an encrypted backup of the working configuration.

After recovery: WAN1 Online, WAN2 Online
New client connection: preferred WAN1 path restored
Document: time to fail over, time to recover, failed services, backup

❯ What to Verify

Both failure and recovery paths are observed and documented.

Primary references

See Netgate’s gateway groups, default gateway behavior, policy routing, DNS considerations, and failover testing.