← Back to Guides

    Access devices behind CGNAT and mobile networks

    You can access devices behind CGNAT (carrier-grade NAT) and mobile networks without special configuration. With m87 (make87's command line + device runtime), the device connects outbound to the make87 platform — no public IP, no port forwarding, no carrier cooperation required.

    The problem

    Mobile and LTE networks use carrier-grade NAT (CGNAT), where your device shares a public IP address with thousands of other subscribers. The carrier blocks unsolicited inbound traffic, and since you don't control their NAT gateway, there's no way to configure port forwarding. To make matters worse, the IP assigned to your device changes frequently as you move between cells or reconnect.

    Traditional remote access methods — SSH with a public IP, VPNs that expect inbound ports — simply don't work in this environment.

    Why CGNAT breaks traditional access

    With a home router, you control the NAT gateway. If you need to reach a device from the internet, you configure a port forward and traffic flows through:

    Internet → Your router (port forward) → Device

    CGNAT inverts this control. The carrier operates the NAT gateway, and you have no access to configure it. Inbound connections are blocked at the carrier level:

    Internet → Carrier NAT (blocked) → Your device

    The device can still initiate connections outward, but nothing from the internet can reach it directly.

    The solution: outbound-only connectivity

    Instead of waiting for inbound connections, the device initiates an outbound connection to the make87 platform and keeps it open. When you want to access the device, you connect to the platform, and your traffic flows back through that already-established channel:

    Your laptop → make87 platform ← Device (outbound connection)

    This works on any network that allows outbound internet access — no public IP, no carrier configuration, no firewall exceptions.

    Quick start

    1) Set up the device (on the mobile network)

    m87 runtime login
m87 runtime enable --now

    The device connects outbound over LTE/5G.

    2) Access from anywhere

    m87 login
m87 devices list
m87 <device> shell

    3) Forward ports as needed

    m87 <device> forward 8080
# Access localhost:8080 on your laptop

    Common CGNAT scenarios

    LTE/5G modems and routers

    Devices using cellular data (Raspberry Pi with LTE hat, industrial gateways, mobile routers):

    • The carrier assigns a private IP (e.g., 10.x.x.x, 100.64.x.x)
    • No inbound access possible through the carrier
    • m87 works because it only needs outbound connectivity

    Starlink and satellite internet

    Similar to mobile networks — you get a private IP behind carrier NAT:

    • No port forwarding available
    • Outbound-only access works normally

    Shared/public WiFi

    Hotels, cafes, airports — you're behind NAT you don't control:

    • Can't configure port forwarding
    • Often restrictive firewalls
    • Outbound UDP port 443 typically allowed (m87 uses QUIC)

    Corporate networks with strict egress

    If the network allows outbound UDP port 443, m87 works:

    • No special firewall rules needed
    • No VPN client required on the network

    Mobile and aerial use cases

    Delivery robots and autonomous vehicles

    Delivery robots and autonomous ground vehicles operate across cellular networks as they move through cities. They frequently hand off between cell towers and may pass through areas with varying signal quality. CGNAT is the norm — these devices never have public IPs.

    m87's outbound-only connectivity handles this environment: the device maintains its tunnel regardless of which cell tower it's connected to or what private IP the carrier assigns.

    Aerial drones

    Drones face similar challenges with more extreme mobility. A drone conducting an inspection or delivery may:

    • Start on WiFi at the launch site
    • Transition to LTE/5G during flight
    • Move between multiple cell towers
    • Return to WiFi on landing

    The m87 runtime maintains connectivity through these transitions, and QUIC's connection migration allows the tunnel to survive network changes without reconnecting.

    Field robotics and remote equipment

    Construction robots, agricultural equipment, and remote sensors often operate on temporary cellular connections at job sites. These environments have unpredictable network conditions and always use CGNAT. Outbound-only connectivity removes the need to coordinate with carriers or configure site networks.

    Verifying connectivity

    Check device status

    m87 devices list

    If the device shows as online, it has successfully connected outbound.

    Test from the device side

    On the device, check runtime status:

    m87 runtime status

    If the device doesn't appear

    1. Verify internet connectivity: ping 8.8.8.8
    2. Verify DNS works: ping google.com
    3. Check runtime logs: m87 runtime status or journalctl -u m87-runtime

    Bandwidth and latency considerations

    Mobile networks have variable latency and bandwidth:

    • Interactive sessions (m87 <device> shell): usable on 3G+, better on LTE/5G
    • Port forwarding: depends on what you're forwarding
    • File sync: works, but large transfers take time on slow connections

    For bandwidth-intensive work, consider syncing files during off-peak hours or compressing before transfer.

    Alternatives (and why they don't work for CGNAT)

    VPN with public relay

    Some VPNs (Tailscale, ZeroTier) use relay servers when direct connections fail:

    Pros:

    • Works behind CGNAT via relay fallback
    • Direct peer-to-peer connections when NAT traversal succeeds

    Cons:

    • NAT traversal (STUN/ICE) fails 10-30% on symmetric NAT (common in CGNAT), forcing relay fallback
    • Relay adds 50-200ms RTT depending on distance to DERP/relay server
    • Requires coordination server (self-hosted or third-party control plane) for device authentication
    • Mesh topology means O(n²) connection state as fleet grows

    Reverse SSH tunnel

    The device SSHs out to a server you control, creating a reverse tunnel:

    Pros:

    • Works behind CGNAT
    • Uses standard SSH (no additional protocols)

    Cons:

    • TCP connections timeout on mobile networks (carrier NAT table TTL often 30-120s); requires aggressive keepalives or autossh
    • autossh doesn't handle all failure modes (half-open connections, DNS failures) — needs external health monitoring
    • Point-to-point: multi-client access requires proxy setup or multiple tunnels
    • SSH key rotation at scale requires out-of-band provisioning mechanism
    • Jump host is single point of failure; production use needs HA setup

    Carrier solutions (static IP add-ons)

    Some carriers offer static public IPs for an extra fee:

    Pros:

    • True inbound access with routable public IP

    Cons:

    • Typically €5-20/month per SIM on top of data plan (varies by carrier/region)
    • Not offered by MVNOs or consumer plans — often requires business contract
    • Device becomes directly internet-exposed; requires host firewall (iptables/nftables), fail2ban, CVE patching
    • Static IP may still NAT to device's private interface depending on carrier (APN configuration required)

    FAQ

    Does m87 work on any mobile network?

    Yes, as long as the network allows outbound UDP port 443 (QUIC). This covers virtually all consumer and business mobile networks.

    What about data usage?

    The m87 runtime maintains a lightweight connection. Active sessions (shell, port forwarding) use bandwidth proportional to your activity. Idle connections use minimal data.

    Can I use this for always-on monitoring?

    Yes. The runtime maintains the connection persistently. Combine with m87 <device> forward to access dashboards, or deploy monitoring agents via Docker.

    What if the connection drops?

    The runtime automatically reconnects when connectivity is restored. Sessions in progress will need to be restarted, but the device becomes reachable again automatically.

    Is this secure over public mobile networks?

    Yes. All traffic is encrypted end-to-end. The mobile network sees encrypted QUIC traffic to the make87 platform.

    Does the connection survive network changes (WiFi → cellular)?

    Yes. QUIC supports connection migration, which allows the tunnel to move between network interfaces without dropping. When your device switches from WiFi to cellular (or vice versa), the connection migrates to the new network path transparently. This is particularly important for mobile devices like drones and robots that frequently change networks during operation.

    Unlike TCP, which identifies connections by IP address and port (requiring a full reconnect when the IP changes), QUIC uses connection IDs that persist across network changes. The m87 runtime takes advantage of this to maintain sessions even as the underlying network shifts.

    Next