Moving Beyond a Single Internet Connection
Six months ago, our office hit a breaking point. Every time our primary fiber line flinched during a peak-hour Zoom call, the whole team went dark. One cable between your business and a total shutdown is a risk you shouldn’t take. While enterprise SD-WAN solutions from big-name vendors promise 99.99% uptime, their $2,000 annual licensing fees are a tough pill for small teams to swallow.
I decided to build a custom SD-WAN alternative using pfSense and Policy-Based Routing (PBR). After running this in production for two quarters, the stability has been rock solid. By pairing two affordable business fiber lines—a 500Mbps primary and a 200Mbps secondary—we gained higher total throughput and, more importantly, seamless failover. This setup mimics the heavy-hitting features of SD-WAN without the recurring subscription trap.
Hardware and the Initial Environment
Your hardware needs at least three physical network interfaces: one for the LAN and two for your separate WAN providers. I used a fanless mini-PC equipped with four Intel i226-V 2.5GbE NICs. This specific chip is a favorite for pfSense builds because it handles high-speed routing without the driver instability found in cheaper Realtek cards.
Pro tip: Call your ISPs and demand they put their modems in bridge mode. This prevents the nightmare of double NAT, which breaks VPNs and VoIP. If they refuse, assign your pfSense WAN interfaces static private IPs and shove those IPs into the modem’s DMZ. It’s not ideal, but it works.
Configuring Gateways and Monitoring
The system needs to know exactly when a connection dies. Head over to System > Routing > Gateways. You’ll see your two WANs listed there, but the default monitoring is lazy. It only pings the ISP’s local gateway. Often, that gateway stays up even when the actual internet connection is dead.
I prefer using public DNS servers as “canaries in the coal mine.” For WAN1, use 8.8.8.8 (Google). For WAN2, use 1.1.1.1 (Cloudflare). If pfSense can’t reach these specific IPs, it knows the path is truly broken.
# Recommended Monitoring Settings
WAN1 (Fiber A): Monitor 8.8.8.8
WAN2 (Fiber B): Monitor 1.1.1.1Don’t stick with the default sensitivity. Under Advanced, I set the latency threshold to 250ms and packet loss to 10%. If my fiber line starts dropping 1 out of every 10 packets, I want the system to ditch that connection immediately rather than letting my users suffer through a laggy experience.
Creating Gateway Groups: The Brain of the SD-WAN
This is where the magic happens. Navigate to System > Routing > Gateway Groups. You’ll want to build two scenarios depending on your needs.
1. The Load Balance Group
Set both WAN1 and WAN2 to Tier 1. When both share the same tier, pfSense spreads the load. If you have two 500Mbps lines, your office essentially gains a 1Gbps pipe. If one line gets cut by a backhoe, the other Tier 1 line instantly takes over 100% of the traffic.
2. The Failover Group
Use this if your second line is a slow, metered 4G/5G backup. Set your fast fiber to Tier 1 and the cellular modem to Tier 2. pfSense will only touch that expensive cellular data if the fiber goes completely dark.
Policy-Based Routing: Directing Traffic
Defining the groups is only half the battle. You have to force pfSense to actually use them. Go to Firewall > Rules > LAN and edit your primary “Allow” rule. Scroll down to Gateway under the Advanced Options and swap “Default” for your new LoadBalanceGroup.
Secure sites like banks hate it when your IP flips mid-session. They’ll log you out instantly for “security reasons.” To fix this, head to System > Advanced > Miscellaneous and enable Sticky Connections. This ensures a single device stays on one WAN until its current session ends, preventing those annoying login loops.
Handling DNS in a Multi-WAN Environment
DNS is the silent killer of many multi-WAN setups. If your primary WAN dies and your DNS is tied to it, your internet will “feel” broken even if the backup line is fine. Go to System > General Setup and explicitly map DNS servers to specific gateways:
- 8.8.8.8 -> WAN1_Gateway
- 1.1.1.1 -> WAN2_Gateway
This simple step ensures that as long as one provider is alive, your team can still resolve domain names.
The Results After 6 Months
The Status > Gateways page is now my most-visited dashboard. It shows real-time RTT (latency) and jitter. When a staff member complains about a “slow” connection, I can usually see that ISP-B is spiking to 150ms latency and manually pull the plug to force everyone onto the cleaner line.
In my failover tests, I physically yanked the primary WAN cable during a 4K video stream. The video buffered for exactly 3 seconds before resuming. Most VoIP calls stuttered briefly but didn’t drop. That’s the kind of performance that saves a Friday afternoon deadline.
For deeper insights, install the ntopng package. It lets you see exactly which workstations are hogging the bandwidth on each WAN. Building this didn’t just save us thousands in licensing; it gave us total visibility into our network. If you have two internet drops in your building, you’re leaving performance on the table by not using both.
