CGNAT (Carrier-Grade NAT) is provider-operated network address and port translation that carries connections from multiple subscribers through a smaller pool of public IPv4 addresses. The public address, transport protocol, port, and time identify an active mapping; sharing ratios and port-allocation policies vary by provider.
Table of Contents
CGNAT usually supports outbound-initiated TCP and UDP flows, although applications can still be affected by port limits, mapping behavior, filtering, or shared-address reputation. Unsolicited inbound traffic normally needs an existing or explicit mapping, provider support, a relay or tunnel, or a globally reachable IPv6 path.
CGNAT is a deliberate provider deployment choice used to conserve public IPv4 addresses. Its operational effect depends on the provider’s mapping, filtering, port-allocation, logging, and port-control policies. A workload that needs inbound reachability should evaluate native IPv6, provider mappings, relays or tunnels, a provider-assigned public IPv4 address, or properly routed address space rather than assume that only one remedy exists.
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.
Outbound-initiated flows usually create temporary CGN mappings. Unsolicited inbound traffic usually has no mapping and is filtered, but this is a default behavior rather than an absolute rule: PCP or static mappings, provider-assigned ports, NAT traversal, relays, tunnels, and globally reachable IPv6 can provide inbound paths when the network supports them.
How Does CGNAT Work?
A common NAT444 deployment translates traffic once at the customer router and again in the provider network. Other large-scale address-sharing designs can place translation elsewhere or use different transition mechanisms, so two translation stages are common but not part of every CGNAT-related architecture.
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.
When inbound traffic reaches a shared public address without a matching mapping, the CGN cannot select the intended subscriber and normally filters the packet. Some providers support explicit inbound mappings through PCP, static configuration, or assigned port ranges; whether those options exist is a provider policy and implementation question.
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 can disrupt applications that require unsolicited inbound IPv4 reachability when the provider offers no usable mapping or traversal path. The effect depends on mapping and filtering behavior, port limits, application NAT traversal, relay services, provider controls, and whether a globally reachable IPv6 path is available.
- Port forwarding. A rule on the customer router alone cannot create a mapping in the provider’s CGN. Inbound IPv4 may still be possible if the provider offers PCP, static mappings, an assigned port range, or a separate reachable endpoint.
- Hosting servers. Direct hosting is usually unavailable without an explicit inbound mapping, relay, tunnel, provider-assigned public address, or globally reachable IPv6. A public address by itself is not sufficient; routing, DNS, firewall, and service configuration must also be correct.
- 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. NAT mapping and filtering behavior can affect call setup or media. ICE, STUN, TURN, session border controllers, keepalives, and provider-specific handling may preserve connectivity, so results depend on the application and network rather than CGNAT alone.
- VPN servers and remote access. Direct unsolicited IPv4 usually needs a provider mapping or public endpoint. Provider port control, an outbound-established overlay, a relay or reverse tunnel, and globally reachable IPv6 are possible alternatives; each has distinct security and availability requirements.
- 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.
- Geolocation, reputation, and attribution. Multiple subscribers can appear behind one public address, so address-only rate limits, reputation, geolocation, and abuse attribution become less precise. Providers may need the external address, protocol, port, and timestamp to identify a subscriber, and geolocation remains database-specific.
How to Tell If You're Behind CGNAT
Compare the WAN address shown by the router with a public-IP lookup made from the same connection. A WAN address in 100.64.0.0/10 is a strong CGN indicator. Different addresses show that another translation or intermediary exists upstream, but they do not by themselves distinguish CGNAT from a VPN, proxy, enterprise NAT, or another router; confirm the service design with the provider.
Two practical checks:
- Compare the two addresses. A difference indicates upstream translation or another intermediary, not CGNAT by itself. Repeat the check without a VPN or proxy and ask the provider whether the access service uses CGNAT, DS-Lite, NAT64, or another design.
- 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 the checks suggest upstream address sharing and the service needs inbound reachability, document the required protocols and ports, then ask the provider which mappings, public-address options, IPv6 paths, relays, or tunnels it supports. The correct remedy depends on that verified access design.
CGNAT vs a Dedicated Public IP
| Capability | Behind CGNAT | Dedicated public IPv4 |
|---|---|---|
| Outbound browsing, streaming, and apps | Usually works; port limits and NAT behavior can matter | Usually works; routing and firewall policy still apply |
| Direct inbound IPv4 | Usually needs provider mapping, assigned ports, relay, tunnel, or another path | Possible when routing, firewall, NAT, DNS, and service configuration allow it |
| Hosting servers | Possible only through a supported reachable path | Possible after the full network and service path is configured |
| Gaming, VoIP, VPN, and peer-to-peer | Application- and provider-dependent; traversal or relays may help | Still application-, firewall-, and NAT-dependent |
| Address reputation and attribution | Multiple subscribers can share one visible address | No simultaneous subscriber sharing, but prior history still matters |
| Geolocation | Database-specific and may reflect the provider network | Database-specific; assignment does not guarantee location |
| Stability and control | Mappings, ports, and addresses follow provider policy | Depends on assignment terms, routing authority, and operations |
CGNAT is generally optimized for outbound-initiated traffic. Providing a service requires a verified inbound path, which may come from provider port control, an explicit mapping, a relay or tunnel, globally reachable IPv6, or a routed public IPv4 arrangement. A dedicated public IPv4 address still requires correct routing, firewall, DNS, and service configuration.
CGNAT for Businesses: When It's a Dealbreaker
For a business that depends on inbound reachability, an unmanaged CGNAT service can be a deployment blocker. Before changing address arrangements, verify whether the provider supports PCP or static mappings, assigned ports, native IPv6, relays or tunnels, or a public IPv4 option, and test the exact application path.
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.
Services that must accept new inbound sessions need a stable, authorized path that the operator can configure and monitor. That path may use native IPv6, a provider mapping, a relay or tunnel, a provider-assigned public IPv4 address, or routed address space; address assignment alone does not establish reachability, portability, reputation, or geolocation.
Escaping CGNAT: The Options
Escaping CGNAT means obtaining a public IP address you control, through one of three main paths.
- 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.
- Bring or obtain address space when the network supports it. Provider-independent or portable addressing requires registry authority and a compatible routing arrangement, often including an ASN, LOA, IRR route object, RPKI ROA, filtering, and an upstream that accepts the announcement. An address assignment does not automatically move between providers.
- Lease public IPv4 only for a verified routed use case. A lease grants time-limited use under a contract; it does not automatically provide routing, inbound reachability, reverse DNS, clean reputation, geolocation, portability, or registry control. Confirm the exact prefix, announcing ASN, LOA, IRR and RPKI state, routing handoff, abuse process, renewal, and return before relying on it.
A VPN changes reachability only when the VPN service supplies a usable public endpoint, port mapping, relay, or reverse tunnel. A typical outbound-only consumer VPN changes the visible source address but does not expose a service at the CGNAT-bound site. Verify the VPN’s inbound-port, protocol, firewall, DNS, and retention behavior rather than relying on the VPN label.
Practical Checklist
- Diagnose the path: record the router WAN address, a same-connection public-IP lookup, whether a VPN or proxy is active, and whether the WAN address falls in 100.64.0.0/10; then confirm the provider’s access design.
- Inventory which of your needs are inbound: hosting, port forwarding, VoIP, VPN endpoints, remote access, game servers.
- If your needs are outbound-only, CGNAT may be fine — no action required.
- If you need inbound reachability, ask your ISP whether a dedicated public IP is available and on what terms.
- For multi-service, multi-location, or reputation-sensitive needs, evaluate obtaining or leasing your own public IPv4 space rather than depending on provider assignment.
- Don’t assume a consumer VPN solves it — it changes outbound appearance, not inbound reachability.
- Treat reputation and geolocation as separate checks. A dedicated address avoids simultaneous subscriber sharing, but it can still carry prior history and database-specific location data that require validation and remediation.
Practical Note from i.lease
CGNAT can become visible when an application needs inbound connectivity, stable port mappings, or address-level attribution. A failed deployment is not proof that CGNAT is the only cause: customer and provider firewalls, routing, DNS, application listeners, NAT traversal, and IPv6 policy should be tested before selecting a remedy.
Reliable inbound service depends on a complete path: authorized address use, routing, mapping where NAT exists, firewall policy, DNS, application listeners, monitoring, and failure handling. CGNAT changes the mapping and attribution boundary; restoring reachability may use provider controls, IPv6, a relay or tunnel, a provider public address, or properly routed leased or owned space.
Final Thoughts
CGNAT is one deployed response to IPv4 scarcity: a provider translates connections from multiple subscribers through a smaller public-address pool. It commonly supports outbound-initiated traffic, while unsolicited inbound IPv4 normally needs an explicit mapping or another reachable path. Application behavior depends on the provider’s NAT policy, port capacity, traversal support, relays, and IPv6 availability.
A business that provides Internet-facing services needs a stable, authorized and monitored reachability design, not merely an address label. Compare native IPv6, provider mappings, relays or tunnels, provider-assigned public IPv4, and routed leased or owned space against protocol support, routing, firewall, DNS, reputation, geolocation, abuse response, continuity, and cost.
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
What is CGNAT?
CGNAT is provider-operated network address and port translation that lets multiple subscribers use a smaller pool of public IPv4 addresses. The provider tracks mappings by address, protocol, port, and time. Unsolicited inbound IPv4 usually needs an explicit mapping or another reachable path.
How do I know if I’m behind CGNAT?
Does CGNAT block port forwarding?
Why do ISPs use CGNAT?
Because IPv4 addresses are exhausted and there aren’t enough to give every customer a unique one. CGNAT lets providers keep adding subscribers — especially large numbers of low-usage mobile and residential users — without acquiring more public addresses, by sharing each public address among many customers.
