4G failover is often sold as a simple safety net: plug in a modem, add a second WAN, and let the firewall take over when the primary internet connection drops.
In practice, the messy part is rarely the concept. It is the hand-off between the USB modem, Windows, Hyper-V, and the firewall VM. A recent TekOnline troubleshooting session showed exactly how one small change in Windows device enumeration can quietly break the whole failover path.
This article walks through what happened, what we found, and the checks we recommend before trusting a 4G dongle as a pfSense failover link in a Hyper-V environment.
The Setup
The environment used:
- A Windows Hyper-V host.
- A pfSense virtual machine acting as the main router/firewall.
- A D-Link DWM-222 class 4G USB dongle.
- A replacement 4G USB dongle purchased after the first unit failed to initialise reliably.
- A Hyper-V external virtual switch connected to the dongle’s Windows RNDIS network adapter.
- A dedicated pfSense virtual NIC intended to use that switch as a secondary WAN.
The design was sound:
4G USB dongle
-> Windows RNDIS network adapter
-> Hyper-V external switch
-> pfSense virtual NIC
-> pfSense 4G gateway / failover group
The primary WAN was working. The Windows host could reach the internet through pfSense, and pfSense had a live primary WAN gateway. The issue was isolated to the 4G path.
The Symptoms
The 4G connection looked half-alive, which made it easy to chase the wrong problem.
The dongle was present on the Windows host. Hyper-V still had a virtual switch named for the 4G connection. pfSense still had a virtual NIC attached for 4G. Nothing obvious had been deleted.
But the path was not working end to end:
- The pfSense 4G interface was up at layer 2 but had no usable IPv4 lease.
- The host-side adapter for the old 4G switch had only a link-local
169.254.x.xaddress. - The modem web interface was not reachable from the expected path.
- Old pfSense lease data showed that the dongle had previously worked on a private modem subnet.
- The modem had appeared on more than one subnet over time, which suggested mode or device-state changes.
The important clue was that Windows could still see the USB modem, but Hyper-V was not necessarily connected to the current Windows adapter instance.
What Actually Broke
The USB dongle had re-enumerated in Windows.
Before being unplugged and replugged, the modem appeared as one Windows RNDIS adapter instance:
Remote NDIS based Internet Sharing Device #3
After replugging, Windows created a new live adapter instance:
Remote NDIS based Internet Sharing Device #4
The existing Hyper-V switch did not automatically follow that change. It remained bound to the old RNDIS adapter instance.
That left the system in a misleading state:
- The dongle was plugged in.
- Windows had a live RNDIS adapter.
- Hyper-V still had a 4G switch.
- pfSense still had a 4G virtual NIC.
- But the pfSense NIC was connected to a stale Hyper-V backing adapter.
From pfSense’s point of view, the cable was effectively plugged into the wrong place.
The Hardware Finding
There was also a separate hardware issue: the first D-Link 4G dongle was no good. It did not initialise properly or consistently enough to trust as a failover device.
That matters because it is easy to assume every fault is in pfSense or Hyper-V once the networking gets complicated. In this case, the software path did have a real problem, but the original USB modem was also unreliable.
The dongle was replaced with a new 4G USB modem purchased from Amazon Australia:
Replacement 4G USB dongle on Amazon Australia
The replacement unit was tested and working. From that point onward, the remaining troubleshooting could focus on Windows adapter enumeration, Hyper-V switch binding, pfSense DHCP, and failover policy instead of an unreliable modem.
The Fix On The Hyper-V Side
The immediate Hyper-V fix was to create a new external virtual switch and bind it to the currently live RNDIS adapter.
In this case, the new switch was named:
4g dongle
It was bound to:
Remote NDIS based Internet Sharing Device #4
After that, the host-side adapter for the new switch came up on the modem network and received a DHCP address from the dongle. That confirmed the dongle was alive and handing out network configuration.
The pfSense VM adapter was then confirmed as attached to the new switch:
Hyper-V adapter: 4G-Dongle
Hyper-V switch: 4g dongle
pfSense interface: hn7
That moved the investigation forward. The original stale Hyper-V switch binding was no longer the main blocker.
What Still Needed Checking
Fixing the Hyper-V switch binding does not automatically mean failover is production-ready.
At the time of review, pfSense still did not show a current usable IPv4 lease on the 4G interface. That means the remaining work was inside the firewall and failover configuration:
- Confirm the pfSense 4G interface receives DHCP from the modem.
- Confirm the modem gateway is reachable from pfSense.
- Confirm outbound internet access works through the 4G interface.
- Add the 4G gateway to the pfSense failover group.
- Test failover from the primary WAN to 4G.
- Test failback when the primary WAN returns.
Until those checks pass, the 4G dongle should be treated as detected, not proven.
A Separate pfSense Issue: The Gateway Group
The pfSense audit also found that the failover group was not yet a complete failover policy.
The configured group contained only the primary WAN gateway. It did not include the 4G gateway, and the primary WAN was not set as a clean Tier 1 member.
A working pfSense failover group should be built intentionally:
| Gateway | Role | Tier |
|---|---|---|
| Primary WAN | Normal internet path | Tier 1 |
| 4G WAN | Backup internet path | Tier 2 |
The group should then be applied only to firewall rules that are meant to fail over. For many sites, that means LAN outbound traffic, not management or special-purpose networks.
This should be done after the 4G interface is stable. Adding an unproven gateway to a failover group can make troubleshooting harder because routing policy and link health problems get mixed together.
Another Trap: Windows Default Routes
There was also a Windows host routing risk.
The host had a normal default route through pfSense, plus another default route learned from the USB 4G adapter. The pfSense route had the preferred metric at the time, so host internet traffic still used pfSense.
But this is fragile. Adapter reconnects, driver changes, DHCP renewals, or metric changes can cause Windows to prefer the 4G adapter directly.
That can create two problems:
- The Hyper-V host may bypass pfSense without anyone noticing.
- Troubleshooting becomes confusing because the host and the rest of the network may use different internet paths.
Once the 4G path is stable, decide whether the Windows host itself should ever use the dongle as a default gateway. If pfSense should control all egress, keep the RNDIS default route out of the host routing table or give it a deliberately high metric.
Recommended Checklist
For Hyper-V and pfSense 4G failover, we recommend checking the path in layers.
1. Confirm The USB Modem In Windows
Check which RNDIS adapter is currently live. Do not rely on the old adapter name from memory.
Look for signs like:
- A new
Remote NDIS based Internet Sharing Device #xinstance. - A DHCP address from the modem.
- A reachable modem web interface.
- A default gateway from the modem, if expected.
2. Confirm The Hyper-V Switch Binding
Make sure the external switch is bound to the current live RNDIS adapter, not an old device instance.
If the dongle was unplugged, moved to another USB port, or reinstalled, assume this needs to be checked again.
3. Confirm The pfSense VM Adapter
Check that the pfSense virtual NIC is attached to the right Hyper-V switch.
Clear adapter names help. A label such as 4G-Dongle is much safer than several adapters all named Network Adapter.
For router VMs with many NICs, static MAC addresses are also recommended during a maintenance window. pfSense interface mapping is easier to reason about when MAC addresses are stable and documented.
4. Confirm DHCP On The pfSense 4G Interface
Inside pfSense, confirm the 4G interface receives:
- An IPv4 address.
- The modem gateway.
- DNS information, if supplied.
- A working monitor target.
Do not assume the modem subnet will always be the same. Some USB LTE devices expose different private subnets depending on mode, firmware, carrier state, or reset history.
5. Build The Gateway Group Last
Only after the 4G interface is proven should you update the failover group.
Use a simple policy:
- Primary WAN: Tier 1.
- 4G WAN: Tier 2.
- Trigger: packet loss or high latency, depending on how sensitive the site is.
Then test with a controlled primary WAN outage.
Lessons Learned
The main lesson is that USB network devices are not stable infrastructure unless you treat their quirks as part of the design.
A USB 4G dongle can come back as a different Windows adapter instance after a reconnect. Hyper-V external switches are bound to a specific adapter instance, so they may continue pointing at stale hardware even when a newer live adapter exists.
For production use, document the whole path:
Modem model
Windows adapter instance
Hyper-V switch name
pfSense VM adapter name
pfSense interface name
pfSense gateway name
Failover group membership
Also keep a rollback plan before changing router VM networking. In this case, Hyper-V checkpoints and read-only inventory captures were used before making low-risk changes. For any firewall interface reassignment, gateway group change, or route-metric change, schedule a maintenance window and make sure console access or a tested restore path is available.
Final Takeaway
The 4G dongle was not the only thing to test. The real failure was in the chain between Windows device enumeration and Hyper-V switch binding.
Once that was found, the fix was straightforward: bind a new Hyper-V external switch to the current live RNDIS adapter, attach the pfSense 4G NIC to that switch, then continue testing DHCP, gateway health, and failover policy inside pfSense.
For small business networks, 4G failover is worth having. Just do not stop at “the dongle is plugged in.” Prove every layer from USB device to firewall gateway before calling it ready.
Leave a Reply