CGNAT, why your gaming session disconnects when your phone bills change

You've probably had this experience. You're on mobile data, playing or browsing. Suddenly the connection drops. You reconnect. It drops again. Or you can't host a server from your home, even though you've port-forwarded everything correctly. Or your IP address from a "what is my IP" site changes between requests.

The culprit, increasingly often, is CGNAT: Carrier-Grade Network Address Translation. It's how ISPs cope with IPv4 scarcity. It's also why specific things break specifically.

CGNAT in the path

Inbound connections die at NAT 2. Your home router can forward all it wants, but the ISP's CGNAT layer has no per-customer mapping for incoming packets. Hosting from home is essentially impossible behind CGNAT.

What CGNAT is

In a typical home network with a real public IP:

• Your router has one public IPv4 from your ISP.
• Multiple devices share that public IP via NAT.
• One household, one public IP.

In a CGNAT setup:

• Your ISP has one public IP.
• Many households share that single public IP via a giant NAT operated by the ISP.
• Many households, one public IP.

The ISP is running NAT at scale, with multiple customer households behind each public IP. From the outside internet, all those households look like one address.

Without CGNAT, every household needs at least one IPv4 address. The world doesn't have enough. CGNAT lets one IPv4 serve dozens or hundreds of households. It's how IPv4 scarcity is managed in practice.

How it works

Inside CGNAT:

1. Your home router gets a "private-looking" IP from your ISP. Usually in the 100.64.0.0/10 range (a special range reserved for CGNAT).
2. Your home router does its own NAT for your devices (private addresses inside your home).
3. When your home traffic leaves, it hits your ISP's CGNAT.
4. The ISP's CGNAT translates your home's IP to one of its public IPs (shared with others) and picks an external port.
5. Return traffic arrives, the CGNAT looks up the port, and forwards to your home.

So there are two layers of NAT between your device and the public internet: your home NAT, and the ISP's CGNAT.

This double-NAT is the source of most CGNAT problems.

How to tell if you're behind CGNAT

A few signs:

Your router's WAN IP is in 100.64.0.0/10. This range is specifically reserved for CGNAT. If you see it, you're behind a CGNAT.

Your WAN IP and the IP from "what is my IP" don't match. Your router shows one address; the public-facing one is different (the ISP's outer NAT).

Port forwarding doesn't work. You've configured everything correctly inside your home, but nothing can reach you from outside.

Common on:

• Mobile data on most carriers.
• Many budget cable broadband plans.
• Many fiber providers' basic tiers.
• Most residential connections in countries with very tight IPv4 supply.

Less common on:

• Premium / business broadband.
• Some fiber providers in IPv4-rich countries.
• Connections with dedicated static IPv4 (usually paid extra).

What breaks under CGNAT

Specifically problematic things:

Inbound connections. You can't run a server reachable from the public internet. Nobody can connect to you because they can't address you uniquely. Port forwarding only works one level (your home router); the ISP's NAT layer rejects unmatched inbound traffic.

P2P protocols. Many P2P protocols (older BitTorrent, classic VoIP, some game multiplayer) try to set up direct connections between users. CGNAT breaks this. Multiple users behind the same public IP can't reliably establish unique connections.

IP-based reputation. Services that ban "by IP" sometimes ban you because someone else on your CGNAT'd block did something bad. Innocent collateral damage.

Long-lived idle connections. CGNAT translation tables have idle timeouts. If a connection sits idle longer than the timeout (often 5 to 30 minutes for UDP, longer for TCP), the entry is dropped. The next packet has no translation, so it's dropped. Your "always-connected" SSH session or game session quietly dies.

Source-port exhaustion. When you're sharing a public IP with hundreds of users, all the external ports might be in use. New outbound connections can't get assigned a port. This is rare but real on overloaded CGNAT.

WebRTC and video calls. Some platforms work; some don't. STUN can usually get around CGNAT; TURN is needed when STUN doesn't.

Why ISPs do it

Reasons:

• IPv4 scarcity is real. ISPs have a limited pool. CGNAT lets them serve more customers.
• Cost. Each IPv4 address has real cost ($40 to $50 each as of 2026). Many ISPs would have to spend significant money to give each customer their own.
• Mobile networks especially. Tens of millions of phones can't each have a unique IPv4. CGNAT is essentially mandatory.

ISPs don't love CGNAT either. It causes support tickets. It limits features they could otherwise sell. But the alternative (buying enough IPv4 for each customer) is prohibitively expensive.

What ISPs offer to escape it

Many ISPs offer:

A static or dedicated public IPv4 for an extra fee. $5 to $20/month. You opt out of CGNAT.

IPv6 by default. If both endpoints support IPv6, you connect directly, no CGNAT in the path.

Business plans that include public IPs.

For users who care about inbound connections (gamers, hobbyist server runners), this matters. Mobile carriers usually offer fewer options than fixed-line ISPs.

CGNAT and gaming

Specific issues for gaming:

Hosting a server from a CGNAT'd connection: impossible. Players can't reach you because there's no way to address your home through the ISP's NAT.

Strict NAT type in console games. Console games often label connections as "Strict NAT," meaning the game's P2P features have limited functionality. CGNAT users almost always show as Strict.

Voice chat connections. Some implementations use direct peer-to-peer voice; CGNAT can break this. Modern systems (Discord, Xbox Live) use TURN servers as fallbacks.

Latency. CGNAT adds a small but real latency penalty: every packet goes through the ISP's NAT box. Negligible for most traffic; noticeable for very fast-paced games on poorly-provisioned CGNATs.

The practical recommendation for gaming: if you're a heavy gamer behind CGNAT, paying the small monthly fee for a real public IP is often worth it.

CGNAT and "what's my IP" services

Sites that show your IP show your outermost public IP, which is the ISP's CGNAT outer address. This means:

• Your visible IP changes when the CGNAT rebalances (often during peak hours).
• Your IP is shared with many others. Geolocation databases are often wrong about you.
• Services that fingerprint by IP are unreliable: your "fingerprint" varies.

This is sometimes a feature (privacy through shared IP) and sometimes a bug (false IP-based bans).

Workarounds

If you're stuck behind CGNAT and need inbound connections:

Pay for a public IP. Cleanest solution if your ISP offers it.

Use a VPN with a dedicated IP. Some VPN services sell dedicated IPs. You connect to the VPN; the dedicated IP is yours; inbound works.

Use a cloud VPS as a frontend. Rent a $5/month VPS. Tunnel from your home server to the VPS via WireGuard or similar. Public traffic hits the VPS's IP and is forwarded to your home. The CGNAT is bypassed because the VPS is making outbound connections to your home (which works through CGNAT).

Cloudflare Tunnel and similar services. Free for some use cases. Reverse-tunnel from your home server to a public-facing endpoint. Cloudflare (or similar) handles the public-facing IP.

IPv6. If you and the destination both have IPv6, the CGNAT layer is bypassed entirely. Many gaming networks now support IPv6.

IPv6 as the fix

Strictly speaking, IPv6 solves CGNAT. Each device gets its own globally-routable IPv6 address. No NAT needed for address conservation.

In practice, IPv6 adoption is still partial. Even where ISPs deploy IPv6, many destinations are IPv4-only. The fallback to IPv4 (and CGNAT) remains.

Over the long term, as IPv6 reaches 80+ percent of traffic, CGNAT will recede. For now, it's getting more common, not less.

What this means for hosting

If you run a hosting business, CGNAT is mostly a "what your customers face" issue:

Customers can't connect to your servers if their network is broken (rare). Most CGNAT setups still allow outbound connections, so customers can reach your servers. The problem is inbound to their home.

Servers themselves shouldn't be behind CGNAT. No professional hosting uses CGNAT for server-side connections.

Player-to-player connections (in P2P games) face CGNAT issues. This is a game-design problem, not a host-design one, but it affects your customers' experience.

If you host customers behind CGNAT'd ISPs, you'll occasionally hear complaints about features that depend on inbound connectivity. The fix is on their side (a different connection or a workaround), not yours.

Conclusion

CGNAT is the price the residential internet has paid to keep IPv4 alive. For most casual use, it's invisible. For specific use cases (hosting, P2P, certain gaming features), it breaks things.

The medium-term fix is IPv6 adoption. The short-term fix is paying your ISP for a real public IP or using a workaround.

If you're a user with a specific need, check whether you're behind CGNAT. The answer determines what solutions will and won't work. Many "why doesn't this work" mysteries on residential connections trace back to a CGNAT layer the user didn't know was there.

Coming up

CGNAT was a network problem caused by limited addresses. The next article covers a network problem caused by limited packet size: MTU and Path MTU Discovery, the obscure detail that explains many "weird disconnect" issues.