How to Add a Wi-Fi Backup WAN to pfSense

A second internet connection can keep a home lab or small office online when its primary service fails. A nearby Wi-Fi hotspot can serve as an inexpensive emergency WAN, provided it is connected to pfSense as a separate interface and tested with a safe recovery plan.

This tutorial walks through the design, pfSense configuration, and a controlled failover test. It uses generic names and documentation-only addresses. Replace them with values from your own network, and keep router management reachable over a trusted LAN or VPN throughout the work.

How the fallback path fits together

Primary internet ───────────────┐
                               ├─ pfSense ── trusted LAN and clients
Wi-Fi hotspot / travel router ─┘

In a virtualized setup:
Wi-Fi adapter → host external virtual switch → pfSense VM interface

The Wi-Fi connection is a separate WAN path. The hypervisor’s virtual switch carries that connection to a dedicated pfSense virtual NIC. The host’s management connection stays on its own adapter or LAN path. This keeps a WAN test from cutting off the host or the router’s management interface.

A Wi-Fi hotspot is best treated as a recovery link. It may have a data cap, carrier-grade NAT, higher latency, or a changing address. Incoming connections that work on the primary WAN may not work over the hotspot.

1. Prepare the Wi-Fi uplink

• Use a dedicated Wi-Fi adapter that the router VM can access through a supported host virtual switch or hardware passthrough method.
• Join it to a hotspot or travel router intended for this purpose. Prefer a private WPA2 or WPA3 network.
• Confirm that the adapter receives an address and can reach the internet before changing pfSense.
• Record the adapter’s current virtual-switch binding and the router VM’s current network-adapter connections. Keep a rollback command or script ready.
• Verify that a separate host management path and pfSense LAN access remain available if the Wi-Fi uplink is disconnected.

Do not test by disabling the host’s management NIC, the LAN switch, or a shared virtual switch. Disconnect only the specific WAN virtual adapters you intend to simulate as failed.

2. Assign and configure the interface in pfSense

1. Open Interfaces → Assignments and add the new virtual NIC as an interface.
2. Open that interface, enable it, and give it a clear description such as WiFi_WAN. Use a simple name with letters, numbers, and underscores; punctuation in interface labels can cause confusing rule-generation errors in some configurations.
3. Set IPv4 configuration to DHCP if the hotspot or travel router provides addresses automatically. Leave IPv6 disabled unless it is deliberately configured end to end.
4. Save and apply changes. Confirm the interface has an address and that the upstream gateway is detected.
5. Set a gateway monitor address that is reliably reachable through this link. Avoid using only the hotspot’s local gateway as the health check: the hotspot can respond locally while its internet connection is down.

Under System → Routing → Gateways, verify the new gateway is online and has the expected monitor address. If pfSense detects the wrong gateway or reports it down, correct that before creating the failover group.

3. Create a gateway group

1. Go to System → Routing → Gateway Groups and add a group.
2. Place the primary WAN in Tier 1.
3. Place any other intended backup service in a later tier. Put the Wi-Fi gateway in the tier where you want it to take over; a last-resort link usually belongs in a lower-priority tier.
4. Choose trigger levels appropriate for the service, such as packet loss or high latency. Use a monitor target that tests upstream reachability, not only the local next hop.
5. Save, then select the group as the IPv4 default gateway under System → Routing → Gateways. Apply changes and check the routing status.

Tier ordering matters: a lower-numbered tier is preferred. Do not give the backup Wi-Fi link a higher priority on a production network unless you intend it to carry normal traffic. For a planned test, temporarily adjusting tiers can be safer than repeatedly disconnecting links, but restore the intended production order afterwards.

4. Check outbound NAT and DNS

With automatic outbound NAT, pfSense normally creates translations for assigned WAN interfaces. After adding a WAN, inspect Firewall → NAT → Outbound and confirm the Wi-Fi interface has a translation rule for the internal networks that should use it. If outbound NAT is manual or hybrid, add the required rule explicitly.

If the DNS Resolver is configured with a specific list of outgoing interfaces, include the new WAN there as well. Otherwise DNS queries may continue trying to leave through a failed primary link. Save the resolver settings, apply them, and check the service log or resolver diagnostics.

Also review firewall rules and policy-routing settings. A LAN rule that pins traffic to one gateway can bypass the system default gateway group. Create exceptions only where a device or service intentionally needs a fixed path.

5. Test failover with a rollback plan

Do the first test when you have local or out-of-band access. Before the test, save a pfSense configuration backup and record the virtual-switch connections for every VM adapter you may touch. Prepare and syntax-check a timed disconnect script that restores each adapter in a finally block, even if the test encounters an error.

1. Confirm the primary gateway is active and the Wi-Fi gateway is online.
2. Start a continuous ping from a LAN client to a stable public address, and note the current route.
3. Run the timed test from the hypervisor, disconnecting only the primary WAN adapter for a short, predefined interval. If remote access may drop, schedule the job locally so its reconnect action does not depend on the management session.
4. Watch pfSense gateway status and confirm the default route moves to the Wi-Fi tier.
5. While on backup, start fresh checks: ping a public IP, resolve a new DNS name, and load a new web page. A long-lived connection or ping flow may retain old routing state, so it alone does not prove that new traffic failed.
6. Let the script restore the original adapter connections. Confirm the primary gateway returns, the route moves back, and the LAN client can browse again.

Test the rollback script separately in a lab or with a harmless no-change mode before relying on it. A good recovery script captures the original virtual-switch binding, changes only named WAN adapters, uses a guaranteed cleanup block, and reports the final binding after restoration. Keep a second way to reach the hypervisor available.

What the test can and cannot prove

A successful test shows that the selected gateway group, NAT rules, DNS path, and client routing can use the backup link for new traffic. It does not guarantee that every existing TCP session will survive. A changed public address and stateful firewall tracking commonly cause active sessions to reconnect.

Record the failover delay, packet loss, DNS result, web request result, and time to return to the primary link. Repeat the test after changes to gateway monitoring, NAT, DNS, firewall policy, or virtual-switch wiring.

Security and maintenance

• Keep the pfSense web configurator on a trusted management network or VPN; do not expose it directly to the internet.
• Review WAN firewall rules and port forwards. A backup WAN should not create a new path to the management interface.
• Use a strong, unique hotspot password and keep router firmware and pfSense packages current.
• Back up the pfSense configuration before interface or routing changes, and store the backup securely because it can contain sensitive settings.
• Do not publish real SSIDs, public addresses, private subnets, device identifiers, credentials, or screenshots containing them.

A Wi-Fi WAN is a useful last-resort path when its limits are understood. The key is keeping the backup interface separate, ensuring NAT and DNS can follow it, and proving both failover and restoration with a timed test that has a tested rollback.