5G at home.
Your network, your way.

If the priority is experimenting with your US Mobile line cheaply

Start with:

US Mobile Unlimited Premium — Light Speed
                 |
        actual 5G Android phone
                 |
             PdaNet USB
                 |
        dedicated Windows PC
       PdaNet Broadband Adapter
                 |
   Connectify Wired Router — Routed mode
                 |
             Ethernet
                 |
      existing router's WAN port
                 |
       household Wi-Fi / Ethernet

Why this is the first experiment: the cellular radio is already inside a real phone. You do not first need a stand-alone modem to impersonate a handset. PdaNet supplies the phone-to-PC connection; Connectify supplies the PC-to-home-router sharing layer.

The software combination and Ethernet sharing are documented by Connectify. Whether this avoids US Mobile Light Speed hotspot accounting on your exact Android/software/line combination is not verified. PdaNet's own hotspot-avoidance claims are vendor claims, not carrier-independent guarantees.

Sources: PdaNet, PdaNet USB setup, PdaNet with Connectify, PC-to-router Ethernet sharing.

If the priority is a clean, always-on direct-SIM appliance

A North American GL.iNet Spitz AX GL-X3000 is a strong first shortlist entry. It has a proper 5G modem, external cellular antennas, Ethernet, a useful cellular GUI, and an OpenWrt-derived platform.

With a US Mobile SIM, the unresolved questions are network admission/provisioning and whether forwarded traffic is treated as ordinary device data or hotspot data. Those need testing. Installing OpenWrt or changing TTL does not independently settle them.

A particularly useful fallback is Calyx Sprout BYOD: it explicitly supplies an unlocked-to-device SIM for compatible third-party hardware, uses T-Mobile 4G/5G, and advertises uncapped data. It costs $500/year, equivalent to $41.67/month, or $150/three months, equivalent to $50/month. The monthly figures are arithmetic equivalents, not monthly-payment offers. Calyx has specifically tested the Spitz AX with Sprout.

Important for your several-terabyte requirement: Calyx and its underlying provider Mobile Citizen say congestion-related deprioritization can occur after 100 GB. They do not describe that as a 100 GB hard cap or a fixed post-quota speed. No off-network roaming is included. Unlimited volume does not mean guaranteed busy-hour throughput.

Sources: Calyx pricing and device-lock distinction, Sprout 4G/5G service, tested Sprout devices, Calyx data management, Mobile Citizen broadband facts.

If the priority is maximum PC-based control

Use a Quectel RM520N-GL-class modem in a powered USB enclosure, connected to a dedicated Linux mini-PC running NetworkManager + ModemManager, or OpenWrt x86.

Alternatively, put the modem behind an Ethernet modem/router and feed that into OPNsense/pfSense. This is usually the less frustrating FreeBSD-based approach: the firewall sees Ethernet rather than having to support an arbitrary modern USB 5G module directly.

Recommendation: get the connection working in a simple topology first. Add advanced firewalling, VLANs, shaping, and failover only after the radio and accounting behavior are understood.

There is no single universal “phone mode.” Several layers can reveal different things.

Modem identity versus PC operating system

A PC running Linux, OpenWrt, Windows, or Android-x86 can route packets. The cellular network sees the modem, not a promise made by the operating system that it is a phone.

Putting Android on an ordinary PC does not add a cellular modem. Installing a phone-like user agent does not change the modem's cellular identity. LAN MAC cloning is not cellular IMEI modification. Physical SIM versus eSIM does not itself decide whether traffic is handset or hotspot traffic.

Identity modification is not a universal, documented feature of the routers in this guide. If a seller advertises “magic,” “IMEI repair,” or “phone mode,” ask what exact modem and firmware support it, what survives a reboot/update, and whether the claimed outcome has been tested on your exact network. Do not treat an AT-command textbox as proof that every identity-writing command is supported. Identifier duplication, blacklisting, firmware corruption, and legal implications are separate risks.

Also distinguish two meanings of “TAC”: the modem IMEI has a Type Allocation Code; cellular status screens can show a Tracking Area Code. These are not the same thing.

TTL / IPv6 hop-limit normalization

Every IP routing hop normally decrements TTL or hop limit. A simplified example:

Client starts with TTL 64
          |
   phone routes packet
          |
network-side packet can have TTL 63

If an implementation sets the packet to 65 before that additional hop, the packet could arrive with 64. That explains the commonly discussed “65” setting. It is an example, not a universal optimum: the placement of the rule, extra gateways, router firmware, and tunnel behavior all matter.

GL.iNet's firmware 4.10 documentation explicitly exposes TTL and HL and suggests trying TTL 65 in some circumstances. It also exposes these settings on supported USB-tethering interfaces. This verifies the controls exist; it does not verify that 65 bypasses US Mobile accounting or any particular equipment restriction.

Use a systematic experiment: record defaults, change one setting, compare actual carrier counters, and restore the default if it makes no difference. IPv6 is a separate path; an IPv4-only rule does not normalize IPv6 hop limit. A VPN on the PC does not automatically change how the cellular subscription classifies the underlying connection.

Sources: GL.iNet cellular controls, firmware 4.10, GL.iNet USB tethering.

Why keeping the SIM in a real phone is a useful alternative

The phone-based approach avoids the initial stand-alone-modem identity problem. A phone-side tunnel or proxy then addresses the traffic-sharing path instead. It still needs reliability and accounting tests, but it is a different engineering problem from rewriting a modem identity.

These are architectural options, not fourteen promises of unlimited carrier data.

A supplied T-Mobile gateway feeding your own Ethernet router is an additional practical fallback if your objection is its Wi-Fi/firewall rather than the cellular radio itself. That does not replace the supplied radio hardware. T-Mobile documents third-party Ethernet router connections and says its gateways do not expose bridge mode. T-Mobile connection guide.

Hardware

• A dedicated, unlocked, T-Mobile-compatible 5G Android phone.
• A Windows PC; reuse one for testing before buying a dedicated mini-PC.
• A reliable USB data cable, not a charge-only cable.
• One Ethernet interface for the home-network output.
• Your existing home router/AP or mesh system.
• Adequate phone cooling and a manufacturer-supported charging arrangement.

A USB-attached cellular source plus one Ethernet LAN port can be enough. You only need two Ethernet ports when the WAN is also Ethernet, or when your chosen topology requires another separate network.

Software

• PdaNet Android app and matching Windows desktop client.
• Connectify Hotspot with the edition/features required for Wired Router mode; verify current licensing before purchase.
• Optionally the built-in Windows sharing features as an experiment, but do not assume they behave identically with every virtual adapter. Connectify specifically documents the PdaNet path.

Setup sequence

1. Establish a handset baseline. Put the SIM in the phone, confirm cellular data works, turn off unrelated Wi-Fi WAN fallback, and record handset/hotspot usage counters.
2. Install only the official PdaNet app/client. Match versions. PdaNet USB mode uses Android USB debugging; trust only the dedicated PC. Keep its debugging interface off untrusted computers.
3. Enable USB mode inside PdaNet. This is not automatically the same as the phone's built-in native USB-tether switch. Follow PdaNet's mode-specific instructions.
4. Connect from the Windows PdaNet client using Connect USB. First verify internet from the PC itself.
5. Inspect available PdaNet tether-hiding settings. The publisher documents “Hide Tether Usage” for certain circumstances, but parts of its compatibility guide refer to very old Android versions. Treat current-device effectiveness as a test, not a proven result.
6. In Connectify, choose Wired Router. Select the PdaNet Broadband Adapter under Internet to Share, choose Routed network access, and select the physical Ethernet adapter under Share Over.
7. Connect Ethernet to the existing router's WAN port. This preserves the router's current home LAN and is easy to test, though it adds a local NAT layer. Alternatively, use AP mode and a suitable LAN connection if the PC is to supply DHCP/routing directly.
8. Keep subnets distinct. Do not give the PC-sharing segment and home LAN the same subnet. Do not enable multiple DHCP servers on the same broadcast segment.
9. Test from a separate household device. The PC browser working is not proof the home LAN is forwarded correctly.
10. Measure carrier counters after normal downloads. Allow for reporting lag. Repeat after disconnect/reconnect, phone reboot, PC reboot, and enough normal usage to expose any quota behavior.

Connectify explicitly says PdaNet does not work with its Bridged mode. Use Routed. Its Ethernet guide confirms sharing to a home router. Its warning about needing simultaneous Wi-Fi connections applies to Wi-Fi-in/Wi-Fi-out topologies, not a mandatory requirement for USB-in/Ethernet-out.

Sources: USB setup, PdaNet sharing modes, Wired Router setup, PdaNet USB troubleshooting, PdaNet compatibility guide.

Strengths

• Low initial cost if you already own the equipment.
• The radio remains a genuine phone.
• A documented path from phone software through PC to household router.
• Easy to compare the same SIM/device in handset, native-tether, and PdaNet modes.

Limitations

• Free PdaNet service deliberately interrupts usage; assess the paid version for an always-on trial.
• Windows updates/reboots and USB/ADB conflicts can disconnect the house.
• Phone modem heat, charging limits, and battery condition matter during long downloads.
• USB-C does not guarantee USB 3 data rates. Phone models differ.
• A tunnel/proxy-based path can affect applications differently. Test UDP games, console downloads, DNS, streaming apps, video calls, and work VPNs.
• One successful speed test proves neither multi-terabyte stability nor sustained hotspot-meter avoidance.

Recommendation: this is my first inexpensive experiment for your US Mobile preference, but I would not retire your existing internet before a long stability/accounting test.

PairVPN: phone server, PC client

The publisher documents this direction:

Internet / phone cellular data
             |
     PairVPN server on phone
             |
 local hotspot or USB connection
             |
      PairVPN client on PC

Its hotspot page claims that a local tunnel passes client traffic through the phone's normal data connection rather than native hotspot usage. That is a vendor claim, not independently verified US Mobile Light Speed behavior.

Important documented limitations:

• You must first be able to establish the phone's hotspot or USB-tether connection.
• Server mode runs on the phone; client mode runs on the PC, not the opposite.
• The hotspot guide says to check for Tunnel: local. Remote/relayed is not the intended local hotspot path.
• Only one client connection is supported at a time in the documented guide.
• An iPhone server must stay active; its guide says not to turn the screen off because of background-app restrictions.
• The guide says not to combine it with PdaNet. Treat them as separate experiments.

One PC client could potentially be the household gateway, but forwarding the whole LAN through its tunnel is a separate integration question. Verify that its adapter and route/firewall behavior accept forwarded traffic, not just PC-originated connections. Do not assume every generic Windows sharing method will work.

Sources: PairVPN hotspot guide, PairVPN FAQ.

NetShare: useful proxy experiment, not a transparent replacement for a router

NetShare's official documentation says it uses a local proxy because of Android's routing limitations without root. Its Linux guide documents manual HTTP/HTTPS proxy settings and notes that some apps ignore system proxy settings.

This is useful for browser traffic and selected applications. It is not proof that game consoles, IoT gadgets, arbitrary UDP, QUIC, or every streaming app can be transparently forwarded. A Linux gateway configured with an http_proxy environment variable does not thereby proxy the packets of all Ethernet clients.

A proxy-to-TUN or transparent-redirection layer can broaden coverage, but adds another software component and protocol-compatibility problem. Do not start with it if the requirement is effortless whole-house compatibility.

Sources: NetShare, NetShare Linux proxy guide.

Rooted Android + VPN Hotspot

The open-source VPN Hotspot project explicitly requires root and can share a phone's VPN connection over hotspot/repeater interfaces. Its README discusses tethering-limit workarounds.

This is a technically interesting advanced route if your handset is bootloader-unlockable, compatible with your chosen Android version, and recoverable. Rooting is not universally available, can disrupt other apps/security assumptions, and can make firmware updates more complicated.

Critically, merely turning on a commercial VPN app on Android does not prove native hotspot clients use that VPN. Phone-originated traffic and forwarded traffic can follow different routes; VPN Hotspot exists to address that sharing issue.

Source: VPN Hotspot project.

Other leads, with lower verification confidence

• EasyTether: a historical Android/desktop tethering product, including Linux support in older documentation. Its official site was not reachable for verification during this research; treat current OS support as unresolved, not a purchase recommendation.
• ROOTer / GoldenOrb: a modem-focused OpenWrt derivative/community project. Potentially useful for supported USB/M.2 modem hardware, but its official site was not reachable here. Verify current release, security updates, and exact supported board/modem before flashing.
• Android-x86 / Android containers: research projects, not a magic solution. They still need a modem and working drivers, and do not turn its radio identity into a handset's identity by themselves.
• Reverse-tethering tools: many share PC internet to a phone. That is the wrong direction for this goal; do not confuse them with cellular-WAN sharing.

Recommended first shortlist: Spitz AX

physical SIM
    |
North American 5G modem in GL-X3000
    |
router/firewall/DHCP
    |
Ethernet switch + access points / mesh in AP mode

This is cleaner than a phone/Windows chain and provides useful radio diagnostics. You can also keep your existing router downstream while testing.

Current US Mobile APN detail that matters

US Mobile's official APN page differentiates:

• Upgraded Light Speed: wholesale
• Legacy GSM: pwg

Do not copy fast.t-mobile.com from a direct T-Mobile tutorial and assume it is correct for an MVNO line. Do not automatically transplant phone-only MMS/IMS configuration into a data modem. The router typically needs the packet-data APN, authentication, and supported IP/PDP type.

Source: US Mobile APN list.

Setup and controlled experiments

1. Verify the exact North American model and its modem/bands.
2. Activate the subscription normally if it is not already active; confirm data in a known-working phone.
3. Power down before inserting the physical SIM where the device manual requires it.
4. Start with automatic cellular network/band selection.
5. Configure the correct APN and supported IPv4/IPv6 session type. Keep authentication at the provider's specified setting.
6. Record registration state, assigned addresses, serving bands, RSRP/RSRQ/SINR, modem temperature where available, and firmware version.
7. Test direct wired internet before adding a VPN, custom firewall, or tower lock.
8. Compare device and carrier data counters.
9. If investigating tethering clues, test the documented TTL/HL controls individually and record whether anything actually changes.
10. Only then experiment with SA/NSA selection, band masking, or tower locking. Keep a way to restore automatic selection.

GL.iNet firmware 4.10 exposes APN, IP type, TTL, IPv6 HL, MTU, band masking, operator locking, tower locking, modem information, AT commands, and traffic statistics on supported models. Not every model/firmware has an identical page. Operator/tower lock is not a speed guarantee; a lock can also prevent recovery during tower maintenance or after moving the router.

Source: GL.iNet cellular guide.

Why direct SIM is still a test with US Mobile

A usable APN and good signal can allow attachment without proving the accounting classification of the forwarded traffic. Conversely, a SIM may fail because of provisioning/IP-type/firmware issues without TTL being the cause. Diagnose the actual failed stage rather than immediately rewriting identities.

For clarity only, US Mobile currently publishes device-use restrictions for unlimited plans. You asked not to use permissions as the deciding factor, so this guide does not repeatedly apply them as a veto; they still mean there is no carrier assurance of long-term router service. US Mobile terms.

Calyx Sprout as a less fragile SIM alternative

Sprout is different from removing a SIM from Calyx's supplied hotspot memberships. Its own documentation says the Sprout SIM is not device-locked, supports compatible third-party equipment, and provides the same T-Mobile-network connection as its other internet memberships.

Calyx's compatibility page, explicitly dated April 1, 2025 within the text, lists:

• Peplink MAX BR1 Mini 5G
• GL.iNet GL-X3000 Spitz AX
• GL.iNet GL-XE300 Puli — the older LTE Puli, not a verification of Puli AX GL-XE3000
• MikroTik Chateau — not an exact SKU guarantee for every Chateau variant

It says the tests are compatibility findings, not device endorsements or environmental performance promises. For unlisted new equipment, get confirmation for the actual model/IMEI.

Calyx provides activation support; device support is directed to the hardware manufacturer. Its cancellation/transfer page says donations are not refundable, although memberships can be transferred. Consider the quarterly Sprout option for a lower-commitment trial, and verify current enrollment availability before paying.

Sources: Sprout, compatibility, technical support, refund/transfer policy.

Physical layout

SIM + 5G M.2 WWAN modem
           |
powered USB 3 enclosure/development board
           |
Linux mini-PC — cellular WAN + routing/firewall
           |
Ethernet LAN
           |
switch + proper access points

Suggested starting hardware, as engineering estimates rather than minimum specifications:

• Modern low-power x86 mini-PC; approximately 8 GB RAM and a modest SSD are comfortable for a simple router.
• One reliable Ethernet LAN port if WAN is USB; two Ethernet ports if WAN is Ethernet.
• USB 3 data connection for a high-speed modem.
• Powered enclosure appropriate for the exact module, its power spikes, antenna count, and cooling.
• A separate Wi-Fi access point rather than assuming the PC's Wi-Fi card is a good whole-house AP.

Three modem data-interface modes

Do not run multiple managers that fight to own the same modem. A vendor connection manager, raw QMI script, and ModemManager concurrently controlling one data session are a recipe for intermittent failures.

Sources: ModemManager device types, OpenWrt QMI/MBIM guide, GL.iNet standard versus host-less modem description.

An illustrative NetworkManager configuration

Do not run this on your current production gateway blindly. It is a starting example for a dedicated Linux box where NetworkManager owns the interfaces, ModemManager supports the modem, and the required distribution packages are already installed. Replace enp2s0 with the real LAN interface. The example intentionally starts with an IPv4-only LAN; IPv6 requires a separate, tested design.

First inspect devices:

nmcli device status
mmcli -L

Create a cellular profile for an upgraded Light Speed line:

sudo nmcli connection add type gsm ifname '*' \
  con-name cellular apn wholesale
sudo nmcli connection up cellular

For a legacy GSM line, use its documented APN instead. The gsm profile name is NetworkManager's mobile-broadband configuration category, not a request to force the radio to old 2G GSM.

Create the downstream shared Ethernet LAN:

sudo nmcli connection add type ethernet ifname enp2s0 \
  con-name home-lan \
  ipv4.method shared \
  ipv4.addresses 192.168.50.1/24 \
  ipv6.method disabled
sudo nmcli connection up home-lan

NetworkManager documents that ipv4.method shared supplies NAT, DHCP, and DNS forwarding for downstream clients. That is useful for a proof of concept. It is not a complete production security/VLAN/multi-WAN policy. Verify active profiles, firewall rules, WAN default route, DHCP behavior, and that the LAN subnet does not overlap the modem's own network.

If the modem presents Ethernet/host-less mode, do not assume the GSM-profile commands are the right way to control it; use the modem's own cellular UI and a suitable Ethernet WAN profile.

Sources: nmcli examples, GSM/APN properties, IPv4 shared-mode behavior.

OpenWrt x86 alternative

OpenWrt gives you LuCI, firewall zones, DHCP, WireGuard, traffic shaping, and routing packages on PC hardware.

The official modem guide documents QMI/MBIM packages, including:

• QMI: kmod-usb-net-qmi-wwan, uqmi, luci-proto-qmi
• MBIM: kmod-usb-net-cdc-mbim, umbim, luci-proto-mbim
• Additional USB serial/driver packages where the specific modem requires them

Package-manager commands differ by OpenWrt release and vendor fork. Do not blindly paste an old opkg recipe into an apk-based release, or mix feeds/kernel modules from a different build. Match the image, package ABI, modem mode, and documentation.

A ModemManager-backed OpenWrt setup is another possibility; use one chosen management path consistently. The best path depends on the exact modem and firmware, not on “5G” in the product title.

Sources: OpenWrt USB cellular modem guide, OpenWrt phone USB tethering.

The internal M.2 trap

An ordinary NVMe M.2 slot is not automatically suitable for a cellular modem. The host needs the correct keying, electrical interface, USB/PCIe wiring, SIM integration, power, antennas, and software support. Some laptop WWAN modules also have host/OEM enablement restrictions. Buying an M.2 adapter with a SIM holder does not prove all of those requirements are met.

A known-compatible powered USB development board/enclosure is usually the easier first build.

SIM
 |
5G Ethernet modem/router at best RF location
 |
Ethernet WAN
 |
OPNsense or pfSense mini-PC
 |
managed switch / VLANs / access points

This is my preferred architecture when the user wants a sophisticated PC firewall without spending time on direct USB-modem support in FreeBSD.

Both projects document cellular modem configuration, but their public guides emphasize supported devices and PPP/serial-style examples. That does not establish native high-speed MBIM/QMI support for every modern 5G M.2 module. A card working in Linux is not automatically a supported direct USB WAN in these systems.

Use a real Ethernet cellular handoff and the firewall can handle its strengths: VLANs, DHCP/DNS, policy routing, VPNs, logging, and multi-WAN.

Passthrough and NAT

• Router mode: the cellular appliance NATs; the PC firewall may NAT again.
• IP passthrough: depending on implementation, one downstream device receives or approximates the cellular-facing address. Read the exact manual.
• True bridge: not interchangeable with the words “DMZ” or “passthrough.”
• Carrier CGNAT: can still exist beyond any local bridge/passthrough mode.

On a private upstream WAN, adjust the firewall's WAN policy appropriately. For example, blocking all private source networks on a WAN that deliberately receives a private modem address can break your intended arrangement. Keep management access restricted; do not solve it by disabling the firewall wholesale.

Sources: OPNsense cellular guide, pfSense cellular guide.

Budget classes below are planning estimates, not live purchase quotes. Availability, promotions, modem variant, licenses, tax, shipping, and regional SKU can change the total. “Carrier certified” is not a guarantee that every SIM/rate plan is provisioned for that device.

Primary hardware references: Spitz AX, Puli AX, Mudi 7, GL-M2, RUTM50 wiki, RUTM50 T-Mobile certification, BR1 Mini 5G, Inseego FX4200, Chateau 5G ax, Chateau 5G R17 ax, Quectel RM520N series.

Additional primary hardware references: GL-M2 supported modem, power and host requirements, Spitz WAN-to-LAN reassignment, Cudy P5 1.0 US, Cudy P7 planning status, Peplink BR1 Pro, FX3100 external-antenna frequency limitation, FX4100, MoFi6500, Chester Pocket Rocket, SUNCOMM Ultra datasheet, Waveshare Ethernet converter, Fibocom FM160 variants, RUTX50 approvals.

eSIM and module-revision traps

• Spitz AX and Puli AX ordinarily require a physical eSIM adapter card plus appropriate firmware for the documented eSIM route; do not assume every retail unit has an integrated eUICC chip.
• Mudi 7 has documented onboard eSIM, but the carrier must still accept the relevant EID/device and profile transfer. Physical SIM can be simpler for an experiment; neither SIM form changes the underlying subscription policy.
• Peplink's current specifications include BYO eSIM on relevant models/firmware. Check installed firmware and exact hardware variant.
• RM520N-GL module subvariants and board compatibility matter. Chester's DIY board listing, for example, distinguishes supported AA variants from unsupported AP variants. M.2 fit is not proof of compatibility.
• The RM521F-GL manufacturer datasheet found is explicitly Preliminary with some certifications still marked TBD/in development. It is not evidence of current blanket certification.
• Quectel's January 2026 brochure makes important planning/certification distinctions for newer modules including RM551E. Some marketing includes mmWave peak figures; a normal four-antenna Sub-6 enclosure does not acquire mmWave capability simply by advertising an X75 chipset.

Sources: the GL/Peplink product pages above, Chester DIY module compatibility, preliminary RM521F datasheet, Quectel January 2026 brochure.

Small-vendor routers: MoFi, Chester, SUNCOMM and similar

These can be technically interesting, especially when sold with accessible modem controls. They are not all interchangeable products: the internal module and firmware revision can matter more than the brand name.

Before choosing one, obtain:

1. Exact module and suffix, not merely “X62/X65 5G.”
2. North American bands including n71 and appropriate LTE anchors.
3. Documented firmware-update/recovery process and support history.
4. FCC identification and relevant carrier certification, if applicable.
5. Actual routed, VPN, and shaping throughput—not theoretical radio peak.
6. External antenna-port mapping and supported frequency range.
7. Evidence that any claimed identity/TTL features exist on the shipping firmware.
8. Return policy and warranty handling for the exact use case.

A seller demonstration on another carrier or another firmware is a lead, not proof your US Mobile setup will behave identically. Do not pay a premium solely for “unlimited SIM compatible” marketing.

Low-cost 5G RedCap dongles

TCL's LINKPORT/LINKKEY IK511 is a useful research lead for a simple USB-connected 5G device. “5G RedCap” is a reduced-capability radio class, not equivalent to a full-performance X62/X72/X75 router. Check the exact US product, bands, host OS support, firmware, and sustained speed. Do not make it the default choice for maximum household peak performance merely because it has “5G” in the title.

Source: TCL IK511 product family. Regional naming/specification differences still need verification.

Bands to check

For a broadly useful modern T-Mobile US build, prioritize:

• 5G n41: important mid-band capacity/speed.
• 5G n71: low-band reach and indoor/rural coverage.
• 5G n25/n66: useful additional support where deployed/configured.
• LTE B2/B4/B66: important capacity/anchor/fallback support.
• LTE B12/B71: useful coverage/fallback support.

The exact tower, frequency deployment, device aggregation combinations, bandwidth and firmware determine what is actually available. A “global 5G” listing that lacks US low bands may appear fine next to one urban tower and disappoint badly elsewhere.

Verify both the router specification and actual installed module. Modem suffixes and North America/Europe variants matter. “Unlocked” means it is not SIM-locked; it does not mean every band, firmware, carrier profile, rate plan, and host is supported.

Sources: T-Mobile network description, manufacturer band tables linked in the hardware section. Calyx's frequency page contains clearly older deployment wording, so do not rely on its “starting to incorporate n41” statement as the current T-Mobile deployment picture.

SA versus NSA

• NSA: 5G can depend on an LTE anchor. Good n41 support alone is insufficient if the necessary LTE combinations are missing.
• SA: attaches on standalone 5G, with different supported combinations and network behavior.

Do not assume “SA is always faster” or “NSA is always more reliable.” The winning mode depends on local deployment, backhaul, spectrum, upload configuration, firmware, and subscription access.

Test automatic, SA, and NSA only where the device/network supports them; compare upload, loaded latency, stability and busy-hour throughput, not just a single download number.

Modem-generation shopping

A mature, well-supported module can outperform an unsupported newer module in a real household because it stays connected and exposes useful diagnostics.

For multi-terabyte use, prioritize:

• Stable firmware and automatic reconnection.
• Correct US band/aggregation support.
• USB 3 or sufficient Ethernet handoff.
• Adequate power and cooling.
• Working SA/NSA support where useful.
• External antenna access and port mapping.
• Driver support in the actual host OS.

A radio specification claiming 3–6 Gbps does not guarantee a 3–6 Gbps WAN, or even a router CPU capable of routing 1 Gbps with VPN/shaping enabled.

Placement first

Try several windows, sides of the house, heights, and router orientations before buying an antenna. Low-E glass, building materials and nearby interference can change performance dramatically. The location with the most bars is not automatically the location with the best n41 throughput or SINR.

A good design often separates:

cellular radio at good RF location
               |
         Ethernet backhaul
               |
Wi-Fi access points where the house needs Wi-Fi

Do not place the cellular modem in a hot attic solely to gain height.

Metrics worth recording

Approximate engineering orientation, not universal thresholds:

Compare like-for-like radio metrics. LTE and NR values, modem implementations, and simultaneous bands can make simplistic thresholds misleading.

External MIMO antennas

Potential options include directional 4x4 panels, suitable omnidirectional multi-element antennas, and outdoor modem/CPE designs.

Check:

• Frequency coverage including 617–698 MHz if n71 matters, and the relevant 2.5 GHz range for n41.
• Actual 2x2/4x4 modem antenna mapping.
• Connector type: SMA, TS9, MHF4 and adapters are not interchangeable.
• Which external ports cover which bands. FX3100's external ports are a specific low-band trap.
• Cable length and attenuation at the actual frequency.
• Correct antenna orientation/polarization and mounting.

Long coax can consume the benefit of a better antenna. Moving a suitable modem outdoors/near the antenna and running Ethernet back can be better than a very long indoor coax run. Antennas improve RF; they do not fix a congested tower or poor backhaul.

A cellular signal booster is not automatically a better answer than a properly designed MIMO antenna. Verify exact bands and whether the booster design preserves the radio capabilities you need.

Always-on phone and modem care

• Keep airflow around devices and avoid enclosed cabinets.
• Use power supplies/enclosures that tolerate cellular transmit-current spikes.
• Watch for temperature-related speed drops during long transfers.
• Use manufacturer-supported charging limits/bypass modes where available.
• Never keep using a swollen phone/hotspot battery.
• Do not assume a phone works with its battery removed; this is model-specific.
• Use a small UPS for modem, router and essential AP/switch if uptime matters.

For a desktop gateway, avoid sleep/hibernate and provide a planned update/reboot schedule. A low-power dedicated PC is normally more sensible than leaving a gaming desktop running solely for routing.

Sources: Windows hotspot support, OpenWrt SQM, cake-autorate, Tailscale subnet routers, OpenMPTCProuter, SpeedFusion.

Shaping recommendations

Start with measured, repeatable busy-hour throughput. Fixed shaping around 85–95% of a sustainable rate is an initial experiment, not an optimum for every cellular link. Because the link varies, a rate based on your fastest speed test may be too high during congestion and do nothing to control the true bottleneck.

cake-autorate adjusts CAKE using traffic load and latency observations; its project explains that variable capacity is why a fixed shaping rate is a compromise. It still cannot create missing tower capacity or repair poor RF. CPU and offload settings can affect whether traffic actually passes through the shaper.

For calls/games, controlling upload saturation can be particularly valuable. Schedule large cloud backups and uploads where feasible.

CGNAT is not fixed by replacing the local router

A cellular provider may assign a private/CGNAT IPv4 address. Opening a port on your own router cannot create a public incoming mapping through carrier NAT.

Local double NAT and carrier NAT are separate:

Home device → home router NAT → modem NAT → carrier NAT → Internet

Local passthrough may remove one of those layers. It does not remove the provider's NAT.

Practical remote-access choices

• Tailscale: install on the target computer or use a subnet router for devices that cannot run it. Approve advertised routes and restrict access appropriately.
• ZeroTier: another overlay-network option; validate direct versus relayed paths and current platform support.
• WireGuard to a VPS: can provide an externally reachable endpoint under your control; port forwarding/public services require deliberate server-side routing, firewall and security design.
• Public/static IP service: only where the actual provider/product offers it. A generic private business APN is not necessarily public inbound reachability.
• IPv6: may permit a different access design, but native IPv6 on the modem does not automatically mean your LAN receives a delegated prefix or inbound traffic is allowed.

Tailscale documents direct, peer-relayed and DERP-relayed connections. A private subnet router does not make your service reachable to arbitrary non-Tailscale internet clients. Relay performance is not guaranteed to match your 5G speed.

Sources: Tailscale connection types, subnet routers.

Streaming, consoles, and work VPNs

Test actual applications, not just a browser:

• Console multiplayer/NAT type and game updates.
• UDP voice/video, WebRTC and conferencing.
• Work VPN establishment and large file transfer.
• Streaming services and location-dependent TV packages.
• DNS and both IPv4/IPv6.

An HTTP proxy that makes a web page work may not carry every protocol used by those applications. VPN exit addresses can trigger streaming location/datacenter restrictions, and changing cellular public addresses can disrupt existing sessions.

MTU / MSS

If some sites load while others stall, or large downloads fail while small requests work, investigate path MTU and tunnel overhead. Do not choose a random MTU such as 1420 as a universal 5G fix. Different modem modes and VPNs require different values. Test a controlled change and retain a rollback path.

A VPN encrypts traffic; it does not prevent the cellular network from observing its own subscriber, equipment, radio session, or total data volume. It is not by itself a proof of hotspot classification changes.

These concepts are different:

OpenMPTCProuter documents aggregation through a VPS using MPTCP and other supported mechanisms. Peplink describes SpeedFusion bonding/smoothing/hot failover, with device and licensing differences.

Two subscriptions on the same T-Mobile tower may share the same bottleneck and outage. T-Mobile + a genuinely independent Verizon/AT&T/fixed/satellite WAN is generally a more meaningful resilience design than two T-Mobile SIMs alone, depending on local infrastructure.

A single dual-SIM modem cannot transmit on both subscriptions simultaneously merely because it has two slots. Verify actual modem count and supported WAN inputs.

For multi-terabyte bonding, check VPS/cloud egress allowances, tunnel throughput, latency, packet overhead, licenses and endpoint reliability. A cheap VPS with a tiny monthly transfer allowance is not a cheap several-terabyte gateway.

OpenWrt multi-WAN recipes are release-dependent: its documentation distinguishes an iptables mwan3 path from an explicitly unofficial nftables version. Do not assume every old mwan3 recipe matches a new firewall/image. Prefer the supported failover mechanism for the installed distribution/firmware.

Sources: OpenMPTCProuter project, SpeedFusion, OpenWrt mwan3, nftables variant.

You do not need gigabit speed merely to transfer terabytes

Calculated using decimal TB, 30 days, continuous traffic, and payload only:

Formula: TB × 10^12 × 8 ÷ (30 × 24 × 3600) ÷ 10^6.

Those averages are not a sufficient performance specification for a household: people want downloads quickly, several devices may run simultaneously, and uploads/latency matter. But they explain why a stable few-hundred-megabit gateway can handle multi-terabyte monthly traffic without needing a theoretical multi-gigabit radio.

Local transfers between your PC and NAS do not use cellular data if they stay on the LAN. Cloud backups, remote streaming and internet downloads do.

Streaming illustration

Calculated from a constant bitrate; real codecs/services vary and transport overhead adds usage:

At 25 Mbps, 50 GB lasts only about 4.44 hours. This is why the hotspot allowance is the important thing to test in a phone-based workaround, rather than relying on the word “unlimited” alone.

Current plan facts relevant to testing

• US Mobile Unlimited Premium, Light Speed: official August 17, 2026 comparison advertises unlimited high-speed handset data and 50 GB high-speed hotspot. That article lists $44/month or $390/year. Current checkout/promotions may differ. The annual price equals $32.50/month mathematically.
• US Mobile Starter, Light Speed: current documentation describes a 70 GB high-speed handset allowance; it is not the same baseline for an unthrottled multi-terabyte experiment. Do not assume every US Mobile plan/network has the same allowance.
• US Mobile Shareable: explicitly supports modems/other devices, but purchased metered data is not the solution for several terabytes.
• Calyx Sprout: $500/year or $150/quarter, no published hard volume cap on the retrieved service pages; congestion-based deprioritization after 100 GB, no off-network roaming.
• T-Mobile Home Internet: uncapped volume, but official network-management documentation says customers over 1.2 TB per billing cycle are prioritized last during congestion. This is not a 1.2 TB disconnection or a fixed-rate throttle. Supplied/select-gateway and approved-address product restrictions exist; a universal immutable one-specific-IMEI lock was not established here.
• T-Mobile business SIM-only/BYOD: a real approved-router category exists in official government/business materials, but residential/small-business eligibility, current uncapped plans and price require a specific quote. Do not assume a generic business-phone BYOD page proves unlimited router service.
• T-Mobile ordinary hotspot plans: finite high-speed allowances with slower continuation are not a full-speed multi-terabyte answer.

Sources: US Mobile August 2026 comparison, US Mobile plans, unlimited-plan help, Shareable plans, T-Mobile network management, business internet, government BYOD whitepaper, hotspot plans.

Illustrative first-year ownership costs

These are arithmetic scenarios, not bundled offers. Equipment figures are hypothetical totals; exclude tax, shipping, antenna work, licenses, power and backup service unless included in your own equipment budget.

At the sourced $390 annual US Mobile Premium price versus $500 annual Sprout, the service-price difference is $110/year, or about $9.17/month. That can be smaller than the extra costs of a PC, paid sharing software, replacement handset, or troubleshooting. If you already own the phone/PC, the initial experiment can still be inexpensive.

Power costs

Illustration: 30 days, continuous average power, $0.20/kWh:

Formula: watts ÷ 1000 × 24 × 30 × electricity price. These are not measured device consumptions.

Stage 1 — characterize the radio

Use your normal intended traffic, not a synthetic multi-terabyte stress flood.

• Confirm the phone really uses T-Mobile/Light Speed rather than another network or Wi-Fi.
• Measure morning, afternoon and busy evening behavior across several days.
• Record download, upload, idle and loaded latency, packet loss and serving bands where accessible.
• Try several locations in the house.
• Do not assume a phone with a better modem/antenna system and a different subscription priority predicts every router's result.

Stage 2 — compare native tethering and software paths

1. Record carrier total-data and hotspot counters, date/time, software versions, and settings.
2. Test native USB tethering as a baseline.
3. Test PdaNet separately with the same phone/SIM/location.
4. Test PairVPN separately if desired, verifying local tunnel mode.
5. Use a normal known-size download and record upload/background traffic too.
6. Allow carrier reporting to catch up; local Android “hotspot usage” is not necessarily the carrier's accounting view.
7. Repeat rather than treating one small transfer as proof.

Decisive question: does the provider's hotspot meter increase, stay flat, or later catch up? A page loading quickly says nothing about this.

Stage 3 — whole-house compatibility

Test a client that is not the gateway PC:

• Website/DNS over IPv4 and IPv6 where enabled.
• TV/streaming application.
• Console/PC multiplayer and large game update.
• Video call with concurrent upload/download.
• Work VPN and large file transfer.
• IoT devices that cannot install a proxy/VPN app.
• Remote access if you need it.

This stage exposes proxy-only paths and tunnels that only carry PC-originated traffic.

Stage 4 — unattended recovery

• Phone/modem reboot.
• PC/router reboot.
• USB disconnect/reconnect.
• Short upstream outage.
• Full power restoration after a UPS shutdown.
• Screen lock/background-app behavior.
• Software update and automatic reconnection.

A primary household network needs recovery without someone clicking Connect on the phone every day.

Stage 5 — sustained and higher-volume behavior

Observe a week or more of ordinary heavy usage, then the relevant billing-cycle thresholds as your intended use reaches them. Track temperature, reconnections, peak-hour throughput and carrier usage classification. A full billing cycle gives better evidence of quota/priority behavior than a 10 GB trial.

Do not retire the old connection until the alternative handles the real household and can recover unattended. Keep the option to fall back to a different subscription or uncapped BYOD SIM if the software path becomes unreliable.

Suggested log columns

timestamp | topology | phone/modem model | firmware | APN | network mode | bands | signal | temperature | download | upload | idle latency | loaded latency | loss | local RX/TX | carrier total data | carrier hotspot data | reconnect events | notes

Keep screenshots/logs with IMEI, ICCID, phone number, account identifiers and VPN secrets out of public posts.

Diagnose the stage that is failing

Security baseline

• Use a dedicated gateway rather than mixing routing with an everyday desktop containing sensitive applications.
• Keep router/OS/modem firmware supported and updated, but schedule gateway reboots deliberately.
• Restrict management interfaces to the LAN or an authenticated private overlay.
• Use strong admin credentials; avoid exposing the router UI or phone-debugging services publicly.
• Treat Android root and broad app VPN permissions as real trust decisions.
• Keep a configuration backup and a documented default/rollback route.
• Do not solve application issues by disabling all firewalls indefinitely.
• Protect outdoor Ethernet/PoE installations appropriately and get qualified help for mounting/grounding where necessary.

My first experiment for your US Mobile preference

Existing Android + existing Windows PC + PdaNet USB + Connectify Wired Router + your existing home router.

This is the lowest-commitment way to test the actual thing you care about: can phone-originated sharing supply the whole home without eating the ordinary hotspot allocation, and can it remain stable? Its advantage is that no stand-alone modem first needs to pretend to be a phone.

My preferred integrated hardware shortlist

1. Spitz AX GL-X3000, correct NA-compatible variant: best first balance of cellular controls, external antennas and practical home use.
2. Mudi 7 GL-E5800NA: interesting newer USB/Ethernet/eSIM option when portability and PC handoff matter; verify actual interface/driver behavior.
3. Teltonika RUTM50: industrial North American alternative.
4. Inseego FX4200: higher-end fixed-router option with stronger wired/external-antenna I/O.
5. Peplink BR1 Mini/Pro 5G: enterprise/resilience options when you understand throughput and licensing limits.

My preferred DIY PC build

RM520N-GL-class modem + powered/cooled USB 3 enclosure + dedicated Linux mini-PC + separate access points.

For an OPNsense/pfSense preference, use Ethernet cellular handoff rather than assuming the same USB module is natively supported.

My preferred lower-friction multi-terabyte fallback

Calyx Sprout + Spitz AX, after a local coverage/congestion trial and device/availability confirmation. The sourced service is uncapped and the router is among Calyx's tested devices. Its 100 GB congestion-priority threshold is still relevant; no source guarantees your local tower can supply several terabytes at a particular speed.

What I would avoid buying first

• An imported router with unknown n71/LTE anchor support.
• A random bare M.2 adapter assuming an NVMe slot will power/control a modem.
• A very cheap modem package with no thermal/power documentation.
• An expensive small-vendor router solely for vague “magic” claims.
• A router chosen by radio peak speed while routed/VPN throughput is low.
• A finite high-speed hotspot plan assuming its unlimited slow continuation will meet a heavy household's requirements.
• Annual service before a signal/congestion test when refunds are unavailable.

Information needed for an exact parts list and configuration

1. ZIP code or approximate region, and current T-Mobile/Light Speed download/upload at busy hours.
2. Exact US Mobile plan and whether the line is upgraded Light Speed or legacy GSM.
3. Phone model, PC operating system, and existing router/mesh hardware.
4. One-time hardware budget and monthly service budget.
5. Expected internet usage: roughly 2, 5, or 10+ TB/month; upload-heavy backups versus downloads/streaming.
6. Whether consoles, work VPNs, public servers, cameras or remote access are important.
7. Whether you prefer an experiment or an unattended appliance, and whether you are comfortable maintaining Linux/rooted Android.

Bottom line: a PC absolutely can be your house's router. The difficult part is the cellular data path, identity/provisioning, real carrier accounting and continuous reliability—not teaching the PC what a router is. For your preferred US Mobile experiment, test the real-phone/software route first. For a clean modular or all-in-one setup, use a proper North American modem and measure the exact SIM's behavior. Keep an uncapped BYOD alternative ready if the workaround does not survive ordinary heavy use.

Follow-up research checked: October 6, 2026. These are documented capabilities and recommendations, not a test of your US Mobile SIM, modem identity, carrier counters, or household equipment. Product pricing, firmware and availability can change.

The recommended hybrid: configurable cellular, polished home network

Keep the two jobs separate:

• Cellular side: the SIM, radio, APN, phone-sharing software and modem-specific controls.
• Home-network side: Wi-Fi, Ethernet, VLANs, firewall rules, client monitoring and the management dashboard.

US Mobile / T-Mobile-network SIM
                 |
   configurable 5G modem/router
       or phone + sharing PC
                 |
              Ethernet
                 |
       UniFi Cloud Gateway
                 |
          PoE switch / injector
                 |
      UniFi access points + LAN

My preferred middle-ground build: configurable modem such as the Spitz AX → Cloud Gateway Max → suitable PoE switch or injectors → appropriately placed UniFi access points.

UniFi treats a working Ethernet feed as an upstream internet connection. It does not need to know whether that feed originated from a phone, USB modem or separate 5G router. This lets you change the cellular experiment without rebuilding the household Wi-Fi, VLANs and device configuration.

With a UniFi gateway, switches and APs, the UniFi interface can manage connected clients, Wi-Fi, guest/IoT networks, VLANs, firewall rules, supported traffic identification, VPN settings and WAN health. Encrypted applications and upstream tunnels limit traffic identification. A third-party modem's radio controls stay in its own interface: do not expect UniFi to expose its band locking, arbitrary AT commands or complete cellular signal diagnostics.

Feeding UniFi from the Android/PdaNet experiment

US Mobile SIM in actual Android phone
                   |
                USB / PdaNet
                   |
             dedicated Windows PC
                   |
      Connectify Wired Router — Routed
                   |
                Ethernet
                   |
            UniFi gateway WAN
                   |
         UniFi switches / access points

1. Get PdaNet internet working on the PC first.
2. Configure Connectify Wired Router sharing in Routed, not Bridged, mode.
3. Connect the sharing PC's Ethernet output to the UniFi gateway's WAN port.
4. Start with DHCP on that WAN interface.
5. Keep the sharing network and UniFi LAN on different subnets.
6. Put household clients behind UniFi, then repeat the non-PC-client, carrier-counter and recovery tests from Chapter 16.

This can introduce another local NAT layer. Do not assume console NAT type, work VPNs or incoming connections will work just because a browser does. UniFi does not remove carrier CGNAT or prove that hotspot accounting has been avoided.

Source: Connectify: share Android internet to a home router.

Native UniFi cellular option: U5G Max

The U5G-Max-US is a separate cellular device for a UniFi network. Its current specifications list:

• 5G SA and NSA, including T-Mobile-relevant n41/n71 and US LTE bands.
• One 2.5GbE Ethernet connection and PoE power.
• Physical SIM/eSIM options.
• Four embedded cellular antennas.
• T-Mobile certification.
• UniFi Network 10.0.162 or later.

Ubiquiti documents primary-WAN mode for its current 5G Max lineup and U5G Backup. In standard WAN mode, connect the 5G device to the gateway's WAN1/WAN2 and supply power through a suitable PoE adapter. LAN-connected backup uses a different topology: it is not the same as primary WAN and does not consume a dedicated WAN port.

The US store showed $399 base / $439 including its displayed surcharge when checked, before tax and shipping. This is a historical research snapshot, not a guaranteed checkout price.

Reason to choose it: integrated UniFi management, with cellular placement separate from the gateway/APs.

Unresolved for your experiment: equivalent TTL/hop-limit or modem-identity customization was not verified. T-Mobile certification is not proof that an arbitrary US Mobile handset line has the desired traffic classification or sustained behavior.

Sources: U5G Max specifications, U5G Max store, 5G primary WAN versus LAN-connected backup.

Native all-in-one: Dream Router 5G Max

The Dream Router 5G Max combines cellular, gateway/controller and Wi-Fi in one appliance. Its specifications list:

• Integrated sub-6GHz 5G.
• Wi-Fi 7 with 2.4/5/6GHz radios.
• Four 2.5GbE Ethernet ports, one with PoE.
• 10G SFP+.
• Published 2.3Gbps IDS/IPS throughput.
• A 15.4W PoE output budget.

The US store showed $499 base / $549 including its displayed surcharge, before tax and shipping. Its support note explicitly says T-Mobile Home Internet SIMs are not supported and a data-only plan is required. This describes vendor-supported configurations; it is not a hands-on verdict about every possible experimental phone SIM configuration.

Reason to choose it: compact, integrated UniFi management with fewer separate devices.

Tradeoff: the best place for cellular reception may not be the best place for whole-house Wi-Fi. A separate modem and wired APs give more placement freedom. Phone-identity/traffic-accounting workaround features were not verified here.

Sources: Dream Router 5G Max specifications, store and support notes.

Choosing a UniFi gateway for third-party cellular

These Cloud Gateways include UniFi management software. A separate CloudKey is not required merely to manage their network. The Ultra runs Network; do not assume every gateway runs every other UniFi application. A headline IDS/IPS specification is not a guarantee of identical performance under every combination of QoS, VPN, firewall and application workloads.

Several TB monthly does not by itself require the largest gateway. Compare actual internet throughput, NAS/LAN transfers, VPN requirements and expansion plans.

Sources: Ultra, Max, Fiber, UniFi control-plane choices.

Wi-Fi access points, PoE and placement

• U7 Lite: Wi-Fi 7, 2.5GbE uplink, 2.4/5GHz, PoE, published maximum 13W. It does not have 6GHz.
• U7 Pro: adds 6GHz and uses a 2.5GbE uplink; requires PoE+.
• Cloud Gateway Ultra/Max do not replace the PoE switch/injectors needed by APs.
• Do not assume the Dream Router 5G Max's 15.4W PoE output can power arbitrary PoE+ equipment.
• Prefer appropriately placed wired APs over one powerful AP in a poor location.
• An AP's theoretical Wi-Fi link rate is not the same as measured household internet throughput.

Sources: U7 Lite, U7 Pro.

Keeping the PC as the main router instead

A valid alternative is modem → Linux/OPNsense PC → UniFi switch → UniFi APs. The PC handles routing, DHCP and firewall policy; UniFi handles APs and switches. Run UniFi management separately on supported hardware or a suitable console.

Tradeoff: routing/security and Wi-Fi settings live in separate interfaces. You do not get all the same gateway-side UniFi visibility merely by adding UniFi APs. For VLANs, create the routing/subnets/DHCP on the third-party gateway and configure matching VLAN IDs in UniFi.

Source: UniFi VLANs with third-party gateways.

Failover and remote management

UniFi supports multi-WAN failover, connection-based load balancing and policy-based routing. Ordinary load balancing is not single-connection bonding. Two T-Mobile links may share a tower outage or congestion.

Normal UniFi remote management establishes outbound connections; it does not require publicly forwarding a management port. Direct Remote Connection is a separate feature with public-IP requirements. Managing your console remotely is also not the same as exposing an arbitrary household service through carrier NAT.

Sources: UniFi multi-WAN, remote management requirements, Site Manager connection types.

Other polished-interface choices

Firewalla + UniFi APs: use the cellular Ethernet feed → Firewalla in router mode → switches/UniFi APs. Firewalla documents this topology. It is a strong option if you prefer its app-oriented device/security controls, but its dashboard and UniFi management remain separate.

TP-Link Omada: a separate modem can feed an Omada gateway, switch and APs, with a compatible controller. ER707-M2 is one multi-gigabit gateway lead. This is an alternative ecosystem, not an automatic integration into UniFi. Exact firmware/controller compatibility and the cellular feed need their own validation.

Sources: Firewalla router-mode configurations, Omada ER707-M2.

Bottom line for this build

For the preferred US Mobile experiment, feed Ethernet from a configurable modem or phone/sharing PC into a Cloud Gateway Max, then use UniFi for the house. Pick the Ultra if budget and sub-gigabit internet are the priority. Pick native UniFi 5G for integration only after verifying the exact SIM and configuration—not because a tidy dashboard makes the cellular accounting problem disappear.