remote access cgnat: why port forwarding broke

Port forwarding used to be the simple answer: punch a hole in the home router, map TCP 3389 or a custom port, and you could reach the machine from anywhere. Today many of those machines are unreachable because the carrier puts customers behind CGNAT. If you search for "remote access cgnat" you want to know: why did port forwarding stop working, how do you detect it, and what are the practical, operational replacements that actually work at scale?

What is CGNAT and why ISPs use it

CGNAT (Carrier-Grade NAT) is a scale measure ISPs adopted to stretch scarce IPv4 addresses. Instead of assigning each customer a unique public IPv4, the ISP gives a private RFC 6598 address (100.64.0.0/10) or another private range and shares a single public IP among many subscribers. The ISP performs NAT at their aggregation point — hence "carrier-grade."

Two facts follow immediately: first, devices behind CGNAT no longer have a routable public IPv4 address you can point to. Second, the ISP controls the NAT mappings and policies: they decide which ports are mapped, whether inbound connections are permitted at all, and how stable ephemeral mappings are. On mobile networks, most subscribers are behind CGNAT; some fixed‑line ISPs use it as well to avoid allocating more IPv4 space.

Why port forwarding stopped being an option

• No public IPv4 = no inbound route. If your router’s WAN IP is in 100.64.0.0/10 or in a private block like 10.x.x.x, the Internet cannot open a connection directly to your local port mapping.
• Double NAT and ephemeral mappings. Even if the CPE (customer router) supports port forwarding, the carrier NAT sits upstream and usually has transient port mappings you cannot control.
• Symmetric NAT and policy blocks. Many carrier NATs are symmetric: the mapping depends on destination, which breaks hole-punching strategies and makes peer‑to‑peer unreliable.
• Carrier security and legal policies. ISPs often intentionally block unsolicited inbound connections to reduce abuse and meet regulatory requirements.
• Mobile and transient links. Cellular clients change IPs frequently; even if you had a mapping, it won’t survive an LTE handover or a modem reboot.

How to detect CGNAT (practical checks)

Before you change your architecture, confirm CGNAT. These are quick, deterministic checks you can run on the target machine or by asking the user.

Windows: ipconfig /all
Linux/macOS: ip addr show
Check public IP: curl -s https://ifconfig.co
Check router WAN: look at the router's "WAN" or "Internet" address in its admin UI
If the router shows 100.64.x.x or a private 10.x/192.168.x.x while curl shows a different public IP, you're behind CGNAT.

Another useful hint is traceroute: if the first public hop is an ISP NAT device with private addressing or if traceroute shows a private range before the public IP, that's a sign. Also, if port forwarding rules you created on the CPE have no effect from the public Internet, CGNAT is the likely cause.

What replaced port forwarding: real-world alternatives

Port forwarding is a local-router solution. When the public address disappears, you have to move to one of a few general models. Each has tradeoffs in reliability, latency, security visibility, and operational cost.

1. Peer-to-peer with hole punching (STUN/ICE/WebRTC): Works well when both endpoints are on NATs that permit UDP or predictable mappings. Many modern tools use ICE to attempt direct paths. Pros: low latency when it connects; cons: fails with symmetric carrier NATs and requires fallback.
2. Relays / TURN / managed relay: When hole punching fails, traffic is proxied through a relay. TURN-like relays guarantee connectivity at the cost of extra hops and bandwidth. This is the pragmatic replacement for port forwarding in the real world because it works regardless of the customer's NAT.
3. VPNs (site or device): A VPN can give the remote admin a routable address inside a mesh (Tailscale, ZeroTier, classic site-to-site IPsec). Pros: stable routing and strong access controls; cons: needs client install or gateway hardware and can complicate routing for large fleets.
4. IPv6: Native IPv6 restores the old model because every device can have a globally routable address. But ISPs often don’t provide IPv6 consistently, and operating IPv6 securely at scale requires a different firewall and monitoring posture.
5. Reverse tunnels (SSH, autossh): Simple and effective for a few machines: the target opens an outbound connection to a known server you control, creating an inbound path you can use. Operationally intensive for fleets because of key management and reliability at scale.

In practice, most commercial remote‑access products use a combination: try direct (STUN/UDP) first, then fall back to a relay. The relay path is the single option that reliably replaces port forwarding across the variety of carrier NATs, captive portals, and mobile links you’ll encounter.

What to expect from a relay and the security tradeoffs

Many readers assume relays are magically end‑to‑end encrypted in a way that prevents the relay operator from seeing session contents. That's not the implicit truth for most remote‑desktop systems. The real technical model is usually TLS with per‑device certificates: when a session falls back to a relay, TLS terminates at the relay, so the infrastructure operator is in a position to access or inspect session traffic if they choose. A direct P2P connection that never touches a relay is end‑to‑end between the two endpoints, but you can't count on that in a CGNAT world.

Operational consequence: choose a relay operator you trust, run relays in multiple regions for low latency and failover, and ensure the relay offers audit logs and access controls you can verify. If a regulation forbids third‑party access to session traffic, you'll need a self‑hosted relay under your control (more on that below).

Tenvo's recommended path: managed relay by default

At scale, the cheapest and least risky choice is a managed relay with a modern client that supports direct and relay paths. Tenvo ships native clients for Windows, macOS and Linux, a browser client in public beta, and a multi‑region managed relay that you can use out of the box. Pricing tiers are Free $0 / Lite $2.99/mo / Pro $7.99/mo. The managed relay removes the operational burden of patching, certificate renewal, multi‑region failover and key custody — tasks many teams under‑estimate when they consider "self‑hosting" as a free option.

Important detail: Tenvo uses TLS with a per‑device certificate for sessions. That means direct peer connections are end‑to‑end for the two devices, but sessions that use the managed relay will have TLS terminated at the relay. For teams that cannot accept the relay operator being in a position to decrypt, self‑hosting is the only correct path — but it has real costs.

For a deeper technical view of connecting without port forwarding, see Remote Desktop Without Port Forwarding Explained.

When self‑hosting a relay is the right call

Self‑hosting a relay makes sense only when a written requirement forces it: a compliance obligation that bans third‑party infrastructure, an isolated network with no Internet egress, or a mandated data‑residency rule. If you pick self‑hosting for convenience or perceived "free" cost, you will pay in hours and risk:

• On‑call patches and CVE response for the relay software and OS
• Certificate issuance and renewal (letsencrypt or enterprise PKI), and secure key storage
• High availability and multi‑region failover engineering to match managed offerings
• Operational telemetry, logging, and retention for audits

If your requirement does force self‑hosting, the canonical guide is Self-Hosted Remote Desktop: Why, How, and What Breaks, which walks through the checklist and the gotchas.

Practical migration checklist: moving from port forwarding to reliable access

• Inventory devices: identify which endpoints rely on port forwarding and whether they are behind CGNAT. Track OS, client version, and whether unattended agents are available.
• Detect CGNAT: run the checks above on representative devices. Log examples so you can talk to the ISP if needed.
• Decide connectivity model: managed relay for most fleets; VPN for networks that need a routed mesh; IPv6 where ISPs and security posture permit.
• Implement persistent agents: swap ephemeral RDP/SSH sessions for a small persistent agent that initiates outbound connections to the relay or mesh. This reduces break/fix toil.
• Plan monitoring: add session availability SLOs, relay health checks, and bandwidth cost alerts (relays consume egress bandwidth you must budget for).
• Harden access: require MFA, device attestation where possible, and centralized audit logs for session recording and post‑incident forensics.
• Test failover and recovery: simulate relay outages and ensure a secondary region or VPN path is available.

For a quick step‑by‑step on getting a remote access agent running, see How to Set Up Remote Access in 60 Seconds. For the underlying mechanics of how connections are established, read How Remote Desktop Access Works: A Simple Explanation.

Operational numbers and some expectations

Expect relay traffic to add latency and bandwidth cost. A well‑placed regional relay should add 20–80 ms of round‑trip compared with a LAN hop when endpoints are in the same continent; cross‑continent sessions will be dominated by geography regardless. Bandwidth is billable: if you run video/graphics-heavy sessions, count 1–5 Mbps as a baseline for typical admin tasks; high‑frame-rate editing or gaming can easily be 20–50 Mbps. These numbers inform whether a local VPN or an IPv6 route is preferable.

TL;DR recommendation

If you’re dealing with "remote access cgnat" in the wild, stop planning on port forwarding as a reliable solution. Detect CGNAT, then pick a model: managed relay for most teams, VPN/mesh for routed access and isolation, IPv6 when the ISP and security posture allow, and self‑hosting only when a written compliance requirement forbids third‑party relays. The managed relay option reduces operational load — Tenvo’s offering is multi‑region, supports native clients and a browser client in public beta, and comes in Free/Lite/Pro tiers (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

Lastly, remember the security tradeoff: relays terminate TLS. If your policy allows a trusted operator to run relays with audit controls, use the managed option. If not, plan the budget and staff time to run your own relays correctly.

Ready to stop chasing port forwarding and get reliable remote access that handles CGNAT? Download the Tenvo client and test a managed relay path on your fleet: Get Tenvo.