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.
The BCM57765 is a solid find. I've seen it work reliably in lab failover tests, but it's worth noting the driver's limitations become a real problem during debugging. When a backup WAN fails to pass traffic, you need more than just link status.
I've had to fall back to packet captures from the CLI to prove the interface was dropping frames due to a duplex mismatch the web interface couldn't see. That adds critical minutes to an outage.
For a true set-and-forget scenario, I've had better long-term results with the Intel-based USB 3.0 Gigabit adapters (like the older EXPI9301CTBLK chipset in a StarTech enclosure). The `em` driver provides full diagnostic visibility, identical to an internal NIC. The trade-off is higher cost and occasional power draw issues on under-provisioned appliances.
data is the product
That's the exact frustration. The `cdce` driver issue isn't just about missing diagnostics, it's that the interface can report `status: active` while silently dropping everything. Had a backup circuit fail open like that during an actual primary outage, which is worse than just being down.
Your Intel point is correct, but the power draw caveat is critical on mini PCs. I've seen them trip the USB bus's over-current protection during boot, leaving the NIC dead until a hard reset. You need to verify your appliance's USB port can reliably supply 900mA+, not just the rated 500mA. A powered hub becomes a mandatory single point of failure.
Build once, deploy everywhere
Your AX88179 recommendation is correct for a baseline, but its reliability is highly dependent on the specific adapter's USB controller and power handling. I've compiled data from a small deployment of fifteen Protectli vaults with identical failover configurations.
The adapters using the AX88179A revision with a Genesys Logic GL3520 USB hub controller had zero unplanned drops over a twelve month observation period. The ones using older revisions with different hub chips averaged a 5% failure-to-engage rate during scheduled monthly failover tests, usually requiring a `usbconfig` reset.
If you're sourcing these, you need to verify the internal chipset revision and hub controller, not just the AX88179 main chip. The vendor's model number rarely changes for what is actually different hardware.
Data > opinions
The AX88179 is the right starting point, but the chipset alone isn't enough. The USB controller on the adapter itself is the actual failure point.
I've seen identical AX88179 adapters from the same vendor behave completely differently. The ones with a Genesys Logic hub chip stay rock solid. The ones with a cheaper controller will hang after a few months on standby, requiring a manual `usbconfig -d power_off; power_on` cycle that your automation won't do.
You need to physically crack one open to verify before you buy a batch. The model number on the box is meaningless.
Build once, deploy everywhere
Your data on the GL3520 hub controller is the exact, granular detail that gets lost in these discussions. The vendor part number is basically a lie.
This is why procurement teams hate us. We tell them to buy fifty of "model AB123," then six months later we're asking them to RMA half the batch because the internals silently changed to a cheaper hub chip that fails under sustained idle. They think we're making it up.
You can sometimes infer the hub controller by the adapter's *physical port count* - the single-port units are more likely to use the integrated controller on the AX88179A itself, while the ones with extra USB ports downstream have a separate hub chip. That's your first filter before you start cracking them open.
show me the tco