What CGNAT Means for Your IP Address

Carrier-grade NAT, usually written CGNAT, is when your internet provider puts many customers behind a single shared public IP address instead of giving each connection its own. Your router still hands out private addresses inside your home, but the address it holds on the provider side is also private — so there is a second layer of translation you do not control.

The everyday effect is that outbound browsing works normally while anything that needs to reach into your network stops working, often mysteriously.

Two layers of translation instead of one

On an ordinary connection there is one translation step: your router swaps private device addresses for its single public address. That is the arrangement described in public vs private IP addresses.

Under CGNAT there are two. Your router swaps device addresses for the address it was given, but that address is itself private — commonly in the 100.64.–100.127. range set aside for exactly this purpose, though providers also use ordinary private ranges. The provider’s own equipment then performs a second translation onto a genuinely public address shared with many other subscribers.

The consequence is that your router’s idea of “my public address” is wrong. It thinks it holds an address that the internet cannot reach.

How to tell whether you are behind it

Compare what your router reports with what the internet reports.

Open your router’s status page and note the WAN address. Then check what address a site sees for you. If the router’s WAN address is in a private or 100.64.-style range while the internet sees something entirely different, you are behind CGNAT. If the two agree, you are not.

Two other strong hints: your provider is a mobile network or a newer fixed-wireless service, or port forwarding rules you have configured on the router have no effect at all no matter how carefully you set them.

Why providers do it

There are not enough public addresses to go around. The original address space was allocated long ago, and while a replacement scheme exists, plenty of the internet still depends on the old one. Sharing addresses across subscribers is how providers keep signing up customers without acquiring more address space, which is expensive and increasingly scarce.

It is worth noting this is the same scarcity that makes address space a real cost line for VPN operators — a provider running exit servers has to lease addresses that are not already burned by abuse.

What breaks

Everything that requires an unsolicited inbound connection.

• Port forwarding. Rules on your own router are honoured, but the provider’s translation layer has no rule sending traffic to you in the first place. This is one of several reasons port forwarding stops working in setups people expect it to.
• Self-hosting. A game server, media server, or web service on your network cannot be reached from outside.
• Remote access. Cameras, network drives, and desktop-sharing tools that expect a direct connection fall back to relay services or fail.
• Some peer-to-peer connections. Applications that negotiate direct paths between users may end up relaying instead, which usually costs performance.
• Dynamic DNS becomes pointless. Tracking a changing address does not help when the address is not reachable.

What does not break: web browsing, streaming, email, messaging, app usage, and outbound VPN connections. Any traffic your device initiates works normally, because the translation layer creates a return path for it.

Shared addresses and shared reputation

Sharing a public address means sharing whatever reputation it accumulates. If another subscriber behind the same address triggers abuse detection, you can pick up CAPTCHAs, rate limiting, or blocks on sites you have never visited.

You may also see location guesses that are further off than usual. Address-to-location data is keyed to the provider’s public block, and CGNAT concentrates many subscribers spread across a wide area onto the same addresses. This is not something a customer can fix, and it is one of the reasons address-based location estimates should be treated as approximate.

What a VPN does and does not solve

A VPN routes around CGNAT for outbound traffic, and mostly does not fix inbound.

The outbound side is straightforward. Your device opens a tunnel to a VPN server — an outbound connection, which CGNAT permits — and from then on the address the internet sees is the VPN server’s. You escape the shared reputation of your provider’s block, and you get a predictable address for sites that were treating you oddly. This is the ordinary substitution described in what a VPN hides about your IP address.

The inbound side is more limited. Because your traffic now arrives from the VPN server, anything reaching you must be routed through that server too. That only works if your VPN provider supports it, and many deliberately do not. Where a provider offers a dedicated address with inbound port support, it can genuinely restore self-hosting from behind CGNAT — one of the practical arguments in shared vs dedicated VPN IP addresses.

Your realistic options

Ranked by effort:

1. Do nothing if you only browse. CGNAT is invisible for outbound use.
2. Ask your provider for a public address. Many will move a connection off CGNAT on request, sometimes free, sometimes as a paid add-on. This is the cleanest fix and worth trying first.
3. Use a relay or tunnel service for the specific thing that broke. Remote-desktop and camera products usually offer this, and it avoids re-architecting anything.
4. Use a VPN provider that supports inbound connections on a dedicated address, if self-hosting matters and your provider will not budge.
5. Change provider if inbound reachability is central to what you do and nothing else works.

The thing to avoid is spending an evening on router configuration. When CGNAT is the cause, no amount of correct configuration on your side of the second translation layer will help, and confirming CGNAT first saves that time.