Configure a pfSense Box on a Netgate 4100 for Dual-WAN Failover

Two circuits do not create redundancy on their own. A Netgate 4100 running pfSense CE 2.7.2 or Plus 24.03 treats each physical WAN as an independent gateway, and until you assemble those gateways into a tiered group with working monitor targets, a dead primary link will strand every LAN client even though the secondary is fully live. The 4100’s igc0 through igc3 interfaces are the raw material here: assign igc0 to the primary ISP, igc2 to a Starlink or LTE backup, keep igc1 as LAN, and reserve igc3 for an OPT port you may want for a management VLAN later.

Monitor IPs decide when a link is actually dead

The single most common failover failure is a monitor IP that answers even when the circuit is broken. By default pfSense pings the gateway address itself, which is frequently the ISP’s own CPE. When the fibre upstream of that CPE drops, the modem keeps answering ICMP on the LAN-facing side, so pfSense sees the gateway as online and never fails over. The circuit is dead; the monitor says otherwise.

Set an explicit, external monitor IP per gateway under System, Routing, Gateways. Point the primary WAN at 1.1.1.1 (Cloudflare) and the backup at 9.9.9.9 (Quad9) so a single anycast outage cannot mark both down at once. On a Starlink secondary, avoid pinging anything inside the 100.64.0.0/10 CGNAT range, because that path stays up while the satellite backhaul is congested or handing off. Under the gateway’s advanced settings, a Probe Interval of 500ms with a Loss Interval of 2000ms and Alert Interval of 1000ms gives detection inside roughly two seconds without flapping on normal jitter. Set Latency thresholds to 200ms high-water and Packet Loss to 10 percent warning, 20 percent down, so a degraded but usable link is not yanked prematurely.

The gateway group is where tiers do the work

Under System, Routing, Gateway Groups, create a group named WANFailover. Assign the primary gateway to Tier 1 and the backup to Tier 2. Leave Trigger Level at Member Down, not Packet Loss or High Latency, unless you have a specific reason to fail on degradation. A tiered group sends all traffic through Tier 1 while it is up and switches to Tier 2 only when every Tier 1 member is marked down. Two members in the same tier would load-balance instead, splitting sessions across both circuits, which breaks any service that pins to a source IP.

The group does nothing until a firewall rule references it. Edit the default LAN pass rule under Firewall, Rules, LAN, open Advanced Options, and set Gateway to WANFailover. This is the policy route that forces LAN egress through the group rather than the system default gateway. Skip this step and traffic follows the static default route, which never fails over regardless of how well your monitors work. Verify the live state under Status, Gateways: the primary should read Online with sub-20ms latency, the backup Online with its own figure, and the group entry should show the active tier.

DNS and state handling break failover more than the WAN links do

A failover that routes packets correctly can still leave the network unreachable because of DNS. The Unbound resolver in pfSense, configured under Services, DNS Resolver, uses Outgoing Network Interfaces that default to All. That is correct for failover, but the DNS Server list under System, General Setup must not bind each server to a specific gateway. If you pin 1.1.1.1 to WAN1 in that table, resolution stops the instant WAN1 goes down, even though your data path has moved to WAN2. Leave the gateway column set to none for every entry.

Existing connection states are the second silent killer. When pfSense fails from Tier 1 to Tier 2, established TCP sessions still carry the old WAN’s source address in the state table and continue trying to egress a dead interface. Under System, Advanced, Miscellaneous, enable State Killing on Gateway Failure so pfSense flushes states tied to the failed gateway at the moment it goes down. Without this, users watch existing sessions hang for the full TCP timeout while brand-new connections work fine, which produces the maddening report that the internet is half-broken. VoIP registrations and long-lived SSH sessions are the usual casualties.

Sticky connections deserve one deliberate choice. Enabling Use Sticky Connections keeps a client’s sessions on the same gateway for the duration, which matters if you later add a second tier member for load balancing, but for pure failover it is irrelevant and can be left off.

A worked timing example

Suppose the fibre primary drops at 14:02:00. With a 500ms probe interval and a 2000ms loss interval, pfSense records four consecutive missed probes and marks WAN1 down at roughly 14:02:02. The gateway group promotes Tier 2, State Killing flushes the WAN1 states, and the LAN rule’s next packet egresses igc2. New sessions establish on the backup within about a second of the down mark, so total user-visible outage lands near three seconds. When fibre returns, the monitor sees WAN1 online again after its first successful probe window and the group reverts to Tier 1, killing WAN2 states in turn.

Do not forget outbound NAT

Under Firewall, NAT, Outbound, switch from Automatic to Hybrid mode and confirm that a rule exists mapping your LAN subnet to each WAN interface. Automatic mode usually generates both, but a manual gateway assignment made earlier can leave the backup without a matching NAT rule, so traffic fails over and then gets dropped for lack of translation.

What this setup still will not survive

Dual-WAN failover on the 4100 protects against the loss of one physical circuit. It does nothing for a resolver outage that hits both anycast targets, a route hijack upstream of both ISPs, or a power cut that takes the appliance itself offline alongside the modems. The three-second convergence figure also assumes both links terminate on the same appliance; if your Starlink backup sits behind its own NAT with a 60-second dish reboot window after a cable reseat, real recovery time is governed by that dish, not by pfSense.

The open question most home setups never test is whether the backup circuit can actually carry the load it inherits. A 1Gbps fibre primary failing to a 40Mbps LTE stick will fail over flawlessly and then collapse under the same traffic the group happily routes, and no monitor IP will tell you that until the calls start dropping.