pfSense Multi-WAN Failover: Steering Traffic Without Breaking Symmetric Routing

The Problem: When Your Backup WAN Doesn't Back Up Your Calls

When implementing Multi-WAN on pfSense, the goal is clear: automatically fail over to a backup ISP when the primary link dies. But there's a hidden trap that turns this safety net into a connectivity nightmare—asymmetric routing. This occurs when outbound traffic leaves via WAN1, but return traffic floods back through WAN2, causing stateful firewall packets to be dropped because they don't match the expected path.

The solution requires more than just creating gateway groups. You need to craft policy-based routing rules that not only direct traffic correctly but also ensure return paths follow the same route. Below is a battle-tested approach to configuring failover without the headaches.

Gateway Groups: Your Traffic's Decision Engine

Start by defining how pfSense should choose between your WAN links. Navigate to System > Routing > Gateway Groups and create your failover logic:

• Tier 1 = primary gateway (active when healthy)
• Tier 2 = backup gateway (used when Tier 1 fails)

For each gateway, configure the monitoring settings carefully:

• Monitor IP: Use a reliable external host like 1.1.1.1 or 8.8.8.8, not your ISP's gateway—this detects actual internet outages, not just local link failures
• Probe Interval: 1000ms (default) works for most environments
• Down: Set to 3-5 failures to avoid flapping during brief network hiccups

Key insight: pfSense 2.7+ allows per-gateway advanced dpinger settings in the GUI, giving you finer control over failover timing.

Policy-Based Routing: Steering Traffic with Precision

Firewall rules on the LAN tab are where you enforce your routing policy. The critical setting is the Gateway field—when set to a gateway group instead of 'default', traffic follows that group's failover logic.

Rules are evaluated top-down, so order matters. Here's a practical hierarchy:

1. VoIP/High-Priority Apps: Source = VoIP phone subnet, Gateway = primary ISP group
2. Guest Network: Source = guest VLAN, Gateway = secondary ISP group (cost-saving)
3. Default Allow: All other traffic, Gateway = primary ISP group

This ensures critical applications always use the faster primary link while guest traffic gracefully degrades to backup without consuming expensive bandwidth.

Worked Example: Dual WAN with Traffic Engineering

Consider a network with two WAN connections:

• WAN_DHCP: Primary cable connection (Tier 1)
• WAN2_STATIC: Backup fiber connection (Tier 2)

Configuration steps:

1. Create Gateway Group 'GWG_PRIMARY':
   • WAN_DHCP as Tier 1 gateway
   • WAN2_STATIC as Tier 2 gateway
   • Trigger level = Member Down
2. Create Policy Rules on LAN tab:
   • Rule 1: Source = VoIP_Phones alias, Gateway = GWG_PRIMARY
   • Rule 2: Source = Guest_Net alias, Gateway = GWG_SECONDARY (reverse tiers)
   • Rule 3: Default allow, Gateway = GWG_PRIMARY

Verification command (run on pfSense shell):

pfctl -sr | grep -A2 'block in quick'

This shows active firewall rules to confirm your policy rules are loaded.

The Sticky Connection Gotcha

When using same-tier gateways for load balancing, pfSense distributes connections via round-robin per-connection, not per-packet. This breaks applications that bind to a specific source IP—like some banking portals that reject traffic from unexpected addresses.

Solution: Enable System > Advanced > Miscellaneous > 'Use sticky connections'. This ensures all traffic from a single client uses the same gateway for the connection's lifetime.

Trade-off: Sticky connections reduce load balancing effectiveness but prevent connection failures. For mission-critical applications, this is usually the right choice.

Testing Your Failover Without Disruption

Before going live, validate your configuration:

1. Check gateway status: Status > Gateways should show all gateways as 'Online' with reasonable RTT values
2. Simulate failure: Temporarily disable the primary WAN interface and watch Status > System Logs > Gateways for failover events
3. Verify routing: Use Diagnostics > Packet Capture on LAN, filter for your test client IP, and confirm packets exit the correct WAN interface

Important: The 'Flush all states when a gateway goes down' option (System > Advanced > Miscellaneous) forces new connections to use the backup but drops existing sessions. For VoIP or persistent tunnels, consider disabling this and letting applications handle reconnection.

Actionable Checklist for Production

1. Set monitor IPs to external hosts (not ISP gateways) to detect real outages
2. Order firewall rules by priority—specific rules before general ones
3. Enable sticky connections for applications sensitive to source IP changes
4. Test failover during maintenance window—changes reload filter rules
5. Consider CARP sync carefully—gateway status is local, so ensure identical monitor IPs on HA pairs

The key takeaway: Multi-WAN failover isn't just about having backup links. It's about engineering traffic flow to use the right link at the right time while maintaining symmetric routing paths that your stateful firewall can handle.