I've been running both pfSense CE and OPNsense on various appliances for years, primarily as perimeter firewalls for small to medium business deployments. My standard setup is a dual-NIC appliance, but I always architect for a temporary backup WAN connection for failover. This isn't for primary throughput; it's for survival—allowing critical services like site-to-site VPNs and management access to remain up when the primary fiber or cable circuit dies.
The built-in Realtek NICs on most mini PCs are notoriously unreliable under FreeBSD (the base for both distros), so I never use them for the backup WAN. A USB NIC is the logical fallback for hardware without spare internal slots. However, the driver support is a minefield. I've bricked failover groups more times than I care to admit because the USB NIC decided to disappear or throw a kernel panic during a real failover event.
Through brutal trial and error across about two dozen nodes, I've narrowed it down. You need a chipset with mature, stable `axge` or `cdce` driver support in FreeBSD. Forget anything else. Here is the only hardware I will now deploy for this specific purpose:
* **Recommended Chipset: ASIX AX88179** (1 GbE). This is the current gold standard. The `axge` driver is solid. I have units that have been plugged into OPNsense 23.7+ boxes for over 18 months without a single link drop.
* **Product Examples:** Plugable USB3.0 to Gigabit Ethernet (USB3-E1000), StarTech USB3GETHER, or the generic "Cable Matters" adapter. It's the chipset that matters.
* **Fallback Chipset: ASIX AX88178** (1 GbE). Slightly older, also uses the `axge` driver. Works reliably but can be harder to find now.
* **Avoid at All Costs:** Realtek RTL8153/RTL8156 (common in many "USB-C Ethernet" adapters). The `rue` driver is improving but is still prone to random resets under sustained load. I had an entire branch office fail to failover because the backup USB NIC locked up. Also avoid anything claiming "driverless" or "CDC Ethernet" support; the `cdce` driver can be flaky with certain hardware revisions.
Critical configuration steps on both platforms:
1. **Disable Hardware Checksum Offloading** for the USB interface. This is non-negotiable. The USB bus and these adapters handle it poorly, leading to corrupted packets.
* In OPNsense: Interfaces > [Your USB WAN] > Advanced > **Disable hardware checksum offload**.
* In pfSense: Interfaces > [Assignments] > Select the USB NIC > **Disable hardware checksum offload**.
2. **Set a conservative polling rate** in the gateway monitoring. A USB NIC is slower to respond. I use:
* Probe interval: 500ms (instead of default 1s)
* Loss threshold: 3 packets (instead of 10)
* This makes the system more sensitive to latency but prevents false failovers.
3. **Physically label the adapter and port.** When the primary circuit is down and you're on a stressful conference call, you don't want to be guessing which USB port has the backup link. I use a label maker: "BACKUP WAN - DO NOT REMOVE".
The performance ceiling for these on FreeBSD is about 850-900 Mbps, which is more than sufficient for a backup circuit meant for keeping VPNs and RDP sessions alive. Do not expect it to handle a 1 Gb/s backup internet line for user traffic; that's not its job. Its job is to be a dumb, reliable pipe that wakes up when called upon and doesn't crash the firewall. The AX88179-based adapters have passed that test in my environments.
You're not wrong on the AX88179, it's the default answer for a reason. But I've had a couple of those go unresponsive after months of idle standby, requiring a physical replug that defeats the whole "lights out" failover purpose.
My off-label, slightly heretical pick? The old **Apple USB-C Ethernet Adapter** (the one with the Broadcom BCM57765 chipset). The `cdce` driver grabs it, and in my experience, it's been more likely to just quietly renegotiate a link drop than to fully vanish. You pay the Apple tax for what is probably a ten dollar chipset, but for a backup WAN, reliability quirks trump pure cost.
Just don't expect any diagnostics beyond "link/no link" from the web interface.