How to Work Around CGNAT
CGNAT is an ISP-level constraint, so solutions either involve getting the ISP to give you a real public IP, or building around the limitation at the application layer.
Option 1: Request a Static Public IP from Your ISP
The most direct solution. Many ISPs offer a dedicated public IP for a monthly fee ($5–$15 is typical for residential, more for business plans). This removes you from the CGNAT pool entirely. Your router gets a real, globally routable IP, and port forwarding works normally.
When to use this: Home lab servers, security cameras, self-hosted services, small business hosting. The cost is low and the solution is clean.
Limitation: Not all ISPs offer this, particularly mobile carriers. LTE/5G home internet providers almost universally use CGNAT with no static IP option.
Option 2: IPv6
IPv6 has 340 undecillion addresses — enough to give every atom on Earth its own IP. ISPs typically assign each customer a /64 or /56 prefix (billions of addresses). With IPv6, there's no need for NAT at all — every device gets a globally unique, publicly routable address. Whether a connection actually has working IPv6 is a quick check against any IPv6-only endpoint, or by inspecting the machine's own assigned addresses.
When to use this: Modern applications (Xbox Live, BitTorrent, many CDNs) already prefer IPv6. If both endpoints support IPv6, CGNAT is completely bypassed.
Limitation: IPv6 adoption is still incomplete. Many home routers, ISPs, and applications don't support it. You can't rely on IPv6 alone if you need to reach IPv4-only services or users.
Option 3: Reverse Tunnels (VPS-Based)
Rent a cheap VPS (Virtual Private Server) with a public IP. Create a persistent outbound tunnel from your home machine to the VPS. The VPS forwards incoming connections through the tunnel to your home server — an SSH reverse tunnel is the simplest version of this: the home machine, sitting behind CGNAT, initiates an outbound connection to the VPS and asks it to forward a chosen public port back down that same connection to a local port on the home machine. Because the tunnel is initiated from inside the CGNAT boundary, no inbound port forwarding is ever needed.
Tools like frp (Fast Reverse Proxy) and Cloudflare Tunnel automate this pattern with better reliability and TLS handling than raw SSH tunnels.
When to use this: Self-hosting behind CGNAT when a static IP isn't available. Cloudflare Tunnel is particularly elegant — it's free for basic use and handles TLS automatically.
Option 4: Overlay Mesh Networks (Tailscale / ZeroTier)
These tools create an encrypted virtual network that spans all your devices, regardless of what NAT they're behind. They use a combination of hole punching and relay servers to establish direct or relayed connections.
Tailscale uses WireGuard under the hood. You install the client on your home server and your laptop. Both register with Tailscale's coordination server. Tailscale attempts direct connection via hole punching; if that fails (common with CGNAT), it falls back to DERP (Designated Encrypted Relay for Packets) servers.
Once connected, your home server is reachable at its Tailscale IP — drawn from the same 100.64.0.0/10 shared address space that CGNAT itself uses, though on an entirely separate overlay network — from any device on your Tailscale network, regardless of CGNAT.
When to use this: Remote access to home lab, connecting distributed team infrastructure, accessing services across multiple NAT layers. This is the most practical solution for most engineers.
Option 5: Port Control Protocol (PCP / RFC 6887)
A standards-based approach where your router negotiates with the ISP's CGNAT device to reserve a specific external port for you. Think of it as asking the ISP's NAT table to create a permanent mapping for your use.
When to use this: When your ISP supports it (rare) and your router firmware implements it. Check your router's advanced WAN settings for "PCP" or "NAT-PMP" options.
Decision framework:
Need to host public services?
├── ISP offers static IP → Buy it. Simplest solution.
├── ISP doesn't offer static IP
│ ├── Have a VPS? → Use reverse tunnel (frp/Cloudflare Tunnel)
│ └── No VPS? → Cloudflare Tunnel (free tier) or Tailscale
│
Need remote access to your own devices only?
└── Tailscale or ZeroTier → Best option, works everywhere
Application supports IPv6 and ISP provides IPv6?
└── Use IPv6 directly → Cleanest solution, no NAT at all
Key Point: For platform engineers, the architectural lesson from CGNAT is that you cannot assume inbound connectivity to any endpoint. Design services to initiate outbound connections to a known rendezvous point (a relay, a coordination server, a message queue) rather than expecting to receive inbound connections. This pattern — sometimes called "phone home" or "reverse tunnel" architecture — is how Kubernetes operators, IoT devices, and edge agents are designed to work reliably across arbitrary network topologies.