What Is CGNAT (Carrier-Grade NAT)? Why It Breaks Hosting, Gaming, and Inbound Services

CGNAT (Carrier-Grade NAT) is a technique that lets an Internet service provider share a single public IPv4 address among many customers at once, instead of giving each customer their own. It adds a second layer of network address translation inside the provider’s network, so hundreds or thousands of subscribers sit behind one public address that the outside Internet sees.

For ordinary browsing, streaming, and app use, CGNAT usually works invisibly. The problem appears the moment something needs to reach you from the outside: hosting a server, forwarding a port, running a game server, accepting VoIP or VPN connections, or enabling remote access. Because you no longer have a public address of your own — you share one with strangers — inbound connections have nowhere unambiguous to land, and these services break or become unreliable.

CGNAT is not a bug or a misconfiguration. It is a deliberate response to a structural fact: the world ran short of IPv4 addresses, and providers needed a way to keep connecting new customers without enough public addresses to go around. That makes CGNAT the clearest everyday sign that public IPv4 addresses are a finite, contested resource — and the clearest reason businesses running inbound-facing services need dedicated public address space of their own. This article explains what CGNAT is, how it works, exactly what it breaks, how to tell if you are behind it, and the paths out of it for businesses that cannot live inside it.

What Is CGNAT?

CGNAT, also written CGN and sometimes called Large-Scale NAT (LSN), is network address translation performed at the carrier level, allowing an ISP to place many customers behind one shared public IPv4 address. It extends the same basic idea as the NAT in a home router — many private devices sharing one address — but adds it a second time, at the provider’s scale, across many customers at once.

The result is that a customer behind CGNAT does not hold a unique public address. The address the outside Internet associates with their traffic is shared with other subscribers, and it is controlled by the ISP, not the customer. For outbound-initiated activity this is usually fine. For anything that depends on being individually reachable from the outside, the shared, provider-controlled address is the root of the problem.

It helps to keep one distinction clear from the start, because it explains everything CGNAT breaks: outbound connections you start work normally; inbound connections others try to start toward you are the ones that fail. CGNAT is fundamentally friendly to clients and hostile to servers.

How Does CGNAT Work?

CGNAT works by adding a second translation layer between the customer’s network and the public Internet, so traffic is translated twice: once at the home router, and again at the ISP’s carrier-grade NAT device.

In a traditional setup, a home router performs NAT between the private addresses of your devices and the single public address your ISP assigns you. You still hold one public address, and inbound connections can be directed to a device behind your router through port forwarding — the mechanism that makes self-hosting and many services possible. This relationship between private and public addressing is covered in our guide to public IP vs private IP.

CGNAT inserts a second stage. Instead of giving your router a public address, the ISP assigns it an address from a shared intermediate range, then translates the traffic of many such customers onto a smaller pool of actual public addresses at a carrier NAT device. So the path becomes: your private device address → your router’s assigned (non-public) address → the ISP’s shared public address. Your traffic reaches the Internet appearing to come from an address you share with many others and do not control.

The consequence for inbound traffic is the core issue. When an outside system tries to reach “your” public address, it arrives at the ISP’s carrier NAT device shared by many customers — which has no way to know the connection was meant for you specifically, because you never established the outbound session that would have created a translation entry. The connection has no unambiguous destination and is dropped. Port forwarding, which would normally solve this, is not available to you because you do not control the shared public address where it would need to be configured.

Why Do ISPs Use CGNAT?

ISPs use CGNAT because there are not enough IPv4 addresses to give every customer a unique one, and CGNAT lets them keep adding subscribers without acquiring more public addresses.

The world’s supply of IPv4 addresses — roughly 4.3 billion, fixed by the protocol’s 32-bit design — was effectively exhausted at the free-allocation level years ago. As we cover in our guide to IPv4 exhaustion, the regional registries that allocate addresses have run down their available pools, and new address space is now obtained mainly through a transfer market rather than fresh allocation. For a growing ISP — especially a mobile carrier or residential broadband provider adding millions of low-usage subscribers — buying or leasing enough public addresses for one-per-customer is expensive and, at sufficient scale, simply not available. CGNAT lets them stretch a limited pool of public addresses across a much larger customer base.

It is worth recognizing that this scarcity is not purely a technical accident — it is shaped by policy. How IPv4 addresses are allocated, registered, transferred, and managed is governed by the regional registries and the broader multistakeholder process that shapes the Internet, a domain known as internet governance. The rules determining who can obtain address space, and on what terms, are governance decisions as much as engineering ones, and CGNAT is one of the most visible downstream consequences of how those decisions and the underlying scarcity have played out. For further reading on how registry policy and address allocation fit into the wider governance picture, the linked resource gives a useful overview.

The honest framing is that CGNAT is a reasonable tool for its intended purpose. For the large population of users whose traffic is overwhelmingly outbound — browsing, streaming, social apps, mobile use — sharing a public address is a sensible way to conserve a scarce resource, and most of those users never notice. The trouble is that “most users, most of the time” is not “all users, all use cases,” and the exceptions are exactly the things businesses care about.

What CGNAT Breaks

CGNAT breaks anything that depends on being reachable from the outside Internet, because it removes your ability to accept unsolicited inbound connections. The specific casualties:

• Port forwarding. The foundational one, because everything else follows from it. Without control of a public address, you cannot forward a port to a device on your network — so any service that relies on port forwarding stops being possible.
• Hosting servers. Web servers, mail servers, application servers, or any service meant to accept connections from outside cannot be reached at a stable public address. For a business, this alone rules CGNAT out of any self-hosting or on-premises service scenario.
• Online gaming and hosting game servers. Hosting a game server for others requires inbound reachability. Even as a player, CGNAT can cause strict-NAT problems, matchmaking failures, and party-connection issues in games that expect direct peer connectivity.
• VoIP and video calling. Voice and video protocols often need to accept inbound media streams. CGNAT’s shared translation can cause call setup failures, one-way audio, and dropped connections, particularly for business phone systems.
• VPN servers and remote access. Running a VPN endpoint, or using remote-access tools like RDP or SSH to reach a machine at a CGNAT location, generally fails because the inbound connection cannot find its target. This is a frequent surprise for small businesses trying to enable remote work.
• Peer-to-peer and direct connections. Applications that establish direct connections between users — some file transfer, collaboration, and IoT tools — degrade or fail when both ends cannot accept inbound sessions.
• Clean geolocation and reputation. Because you share the public address with strangers, you inherit their behavior. The address’s IP reputation reflects everyone behind it, and its geolocation reflects the carrier’s NAT location, not yours — problems that surface as unexpected CAPTCHAs, blocks, or wrong-location results, and that matter a great deal for any business activity tied to a trustworthy address.

How to Tell If You're Behind CGNAT

The quickest test is to compare the public IP address your router shows on its WAN interface with the public address the Internet actually sees for you — if they differ, you are almost certainly behind CGNAT.

Two practical checks:

1. Compare the two addresses. Find the WAN or Internet address in your router’s status page, then check the public address the outside sees by searching “what is my IP” from a device on that network. If your router’s WAN address is different from the public address shown online, your traffic is being translated again upstream — the signature of CGNAT. (When you hold a normal public address, these two match.)
2. Look for the shared address range. CGNAT deployments commonly assign customer-facing addresses from the range reserved specifically for this purpose: 100.64.0.0/10 (addresses from 100.64.0.0 to 100.127.255.255). If your router’s WAN address falls in that range, it is a shared carrier-grade NAT address, not a public one. Seeing a private-style range (such as 10.x) on the WAN side can also indicate carrier translation.

If either check indicates CGNAT and you need inbound reachability, the situation will not resolve itself — CGNAT is how the network is built for you, and getting out of it requires a deliberate change, covered below.=

CGNAT vs a Dedicated Public IP

Capability	Behind CGNAT (shared address)	Dedicated public IP
Outbound browsing, streaming, apps	Works	Works
Port forwarding	Not available	Available
Hosting servers (web, mail, app)	Not possible	Possible
Hosting game servers / avoiding strict NAT	Fails or degraded	Works
VoIP / VPN endpoints / remote access	Unreliable or fails	Works
Control over address reputation	Shared with strangers	Yours alone
Predictable geolocation	Carrier NAT location	Tied to your allocation
Stable, addressable identity	No	Yes

The pattern is consistent: CGNAT is adequate for consuming Internet services and inadequate for providing them. The dividing line is whether anything needs to reach you.

CGNAT for Businesses: When It's a Dealbreaker

For any business whose operations depend on inbound reachability, CGNAT is not a minor inconvenience — it is a hard blocker. If your business hosts services, accepts connections, or relies on a clean, controllable public identity, a shared carrier address cannot support it.

This is why the conversation about CGNAT so often turns into a conversation about acquiring proper public address space. At the ISP and operator level, a common pattern is a hybrid model: carriers keep most low-usage consumer subscribers behind CGNAT to conserve addresses, while providing dedicated public addresses — often from leased IPv4 blocks — to the business customers and services that genuinely need inbound reachability. This lets an operator conserve scarce addresses where sharing is harmless and deploy real public space precisely where CGNAT would break the service. The scarce resource is directed to where it does actual work.

For the business on the receiving end, the requirement is simpler to state: services that must be reached from the outside need public addresses that are yours to control — for port forwarding, for stable hosting, for a reputation you own rather than inherit. Whether those addresses come through your provider, through bringing your own space, or through leasing, the defining need is the same: an address that is not shared with strangers and not controlled by someone whose priorities are conserving it rather than serving you.

Escaping CGNAT: The Options

Escaping CGNAT means obtaining a public IP address you control, through one of three main paths.

1. Request a public IP from your ISP. The simplest first step. Some providers will move a customer off CGNAT and assign a dedicated public address on request, sometimes for a fee, sometimes only on business plans. Where available, this solves the problem for a single location with minimal effort. The limitations: it is not offered by every provider, the address remains provider-assigned (so it does not move with you if you change providers), and at scale it depends entirely on the ISP’s own address availability.
2. Bring or obtain your own address space. Businesses with ongoing needs across services or locations increasingly obtain their own public IPv4 space rather than depending on a provider’s willingness to assign one. Address space you control can be announced through your own or your provider’s routing, moves with you across providers and locations, and carries a reputation you manage rather than inherit — the portability and control advantages that matter once inbound services become part of how the business operates.
3. Lease dedicated public IPv4. For most businesses, leasing is the fastest route to controllable public address space without a large upfront purchase. A leased block gives you dedicated, routable addresses — not shared with strangers, available for the inbound services CGNAT blocks — with the routing, reverse DNS, and reputation control that production services require. This is why CGNAT limitations are one of the most common practical reasons businesses turn to IPv4 leasing: it converts “we can’t host this because our ISP put us behind CGNAT” into “we have our own public space to deploy on.” Businesses with long-term, stable needs may instead compare the economics of a permanent purchase and choose to buy IPv4 addresses outright; the right choice depends on scale, time horizon, and how much control the business wants over the space.

One thing that does not reliably escape CGNAT is worth noting: a consumer VPN. Routing your outbound traffic through a VPN changes the address the outside sees for your outbound sessions, but it does not give you inbound reachability at your own location — you still cannot host a server or forward a port to your CGNAT-bound network. Solving inbound reachability requires an address you control at your endpoint, not merely a different outbound path.

Practical Checklist

1. Confirm whether you are behind CGNAT: compare your router’s WAN address to your public address, and check for the 100.64.0.0/10 range.
2. Inventory which of your needs are inbound: hosting, port forwarding, VoIP, VPN endpoints, remote access, game servers.
3. If your needs are outbound-only, CGNAT may be fine — no action required.
4. If you need inbound reachability, ask your ISP whether a dedicated public IP is available and on what terms.
5. For multi-service, multi-location, or reputation-sensitive needs, evaluate obtaining or leasing your own public IPv4 space rather than depending on provider assignment.
6. Don’t assume a consumer VPN solves it — it changes outbound appearance, not inbound reachability.
7. Factor in reputation and geolocation: a controlled, dedicated address avoids the shared-address problems CGNAT creates.

Practical Note from i.lease

CGNAT is where IPv4 scarcity stops being an abstract industry topic and becomes a concrete wall a business hits. The symptom is almost always the same story: a company tries to do something ordinary — stand up a server, enable remote access, host a service, run a phone system — and discovers it simply doesn’t work, because their provider quietly placed them behind a shared address to conserve a resource that ran short years ago. The problem was never their configuration. It was that they never had a public address of their own to begin with.

That is the underlying reason public IPv4 addresses continue to hold real operational value rather than being a solved problem. An address you control is what makes inbound services possible, what carries a reputation you manage instead of inherit, and what stays with you as your infrastructure changes. CGNAT conserves addresses by taking that control away; getting it back through a provider assignment, your own space, or a lease — is what turns a network that can only consume services into one that can also provide them. For businesses whose plans depend on being reachable, that distinction is the whole game, and it is worth resolving deliberately rather than discovering at the moment a deployment fails.

Final Thoughts

CGNAT is the Internet’s pragmatic workaround for IPv4 exhaustion: by sharing one public address among many customers, providers keep connecting users despite a fixed and depleted address supply. For outbound-heavy consumer use it works well enough to go unnoticed. For anything that must be reached from the outside — hosting, port forwarding, gaming servers, VoIP, VPN endpoints, remote access, it is a wall, because a shared address you do not control cannot accept the inbound connections those services depend on.

The deeper point is what CGNAT reveals about public IPv4 addresses themselves. Their scarcity is real, shaped by both the protocol’s limits and the governance decisions around allocation, and that scarcity has direct operational consequences — CGNAT being the most tangible. A business that needs to provide services rather than merely consume them needs an address of its own: to accept inbound traffic, to control its reputation and geolocation, and to keep a stable identity as infrastructure evolves. Whether that address is assigned by a provider, brought as your own space, or leased, the requirement traces back to the same distinction this article opened with — outbound works when you share, but the moment you need to be reachable, you need public

Also Read

• IPv4 Exhaustion: What It Means and Why It Matters
• IP Address Reputation: What It Is and Why It Matters
• BYOIP: Bring Your Own IP Explained

Frequent Asked Questions