Carrier-grade NAT lets an ISP put hundreds of customers behind a single public IPv4 address by translating a second time inside its own network. Detect it by comparing your router WAN address against your public address. A WAN address in 100.64.0.0/10 is definitive.
What CGNAT is and why ISPs deploy it
Ordinary home NAT translates once: many private devices in your house share one public address assigned to your router. Carrier-grade NAT adds a second translation upstream. Your router receives an address that is not publicly routable, and the ISP's own equipment translates that into a public address shared with many other subscribers.
The driver is arithmetic. IANA allocated the last free IPv4 blocks to the Regional Internet Registries in February 2011 and ARIN's free pool ran dry in September 2015. An ISP adding subscribers today either buys addresses on the transfer market at $30 to $50 each, or shares what it already holds. Typical CGNAT oversubscription ratios run from 64 to several hundred subscribers per public address, depending on how many concurrent port mappings each customer needs.
Mobile networks have used it universally for years. It is now standard for fixed wireless, most satellite service, many fibre overbuilders, and increasingly for cable operators on new accounts. Legacy cable and DSL accounts frequently still hold a dynamic but genuinely public address, which is why two customers of the same ISP can have completely different experiences.
CGNAT is sometimes called LSN (large scale NAT), NAT444 (because there are three IPv4 hops of translation), or in its stateful IPv6 transition form, NAT64. The mechanism your ISP uses affects the workarounds available.
The 100.64.0.0/10 tell
RFC 6598 reserved a specific block for exactly this purpose: 100.64.0.0/10, spanning 100.64.0.0 to 100.127.255.255, about 4.2 million addresses. It is called Shared Address Space, and it exists because ISPs deploying CGNAT could not safely use RFC 1918 private ranges. Customers already use 192.168.0.0/16 and 10.0.0.0/8 inside their homes, and an address collision between the customer LAN and the carrier's transition network breaks routing in ways that are difficult to diagnose.
So if your router's WAN address falls in 100.64.0.0/10, you are behind CGNAT and the matter is settled. There is no other legitimate use for that range.
The absence of a 100.64 address does not clear you, however. Some operators use RFC 1918 space in their transition network anyway, so a WAN address of 10.x.x.x is equally diagnostic. Others use public address space on the customer-facing side while still translating, which is the hardest case to spot and requires the comparison test below.
- 100.64.0.0/10 (RFC 6598): definitive CGNAT indicator.
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918): private space; on a WAN interface it means upstream translation.
- 169.254.0.0/16 (RFC 3927): link-local; means DHCP failed, not CGNAT.
- A public address on the WAN that differs from your observed public address: translation is happening further upstream.
How to detect CGNAT in two minutes
The test is a comparison. Find the address on your router's WAN or internet interface, then find the address the internet sees. If they match, you have a public address. If they differ, something between you and the internet is translating.
The router address is in the administration interface under a heading like WAN, Internet, or Status, and is often labelled IP Address or WAN IP. The public address comes from any external service.
A traceroute adds confirmation. On a genuinely public connection the first hop past your router is your ISP's gateway with a public address. Behind CGNAT you will typically see one or more private or 100.64 hops before any public address appears.
- Router WAN address matches your public address: not behind CGNAT.
- Router WAN address in 100.64.0.0/10: behind CGNAT, confirmed.
- Router WAN address private (10.x, 172.16-31.x, 192.168.x) and different from public: behind CGNAT or a double-NAT you created yourself with two routers in series.
- Traceroute showing 100.64.x.x or 10.x.x.x as hop 2 or 3: carrier translation.
# what the internet sees
curl -s https://ifconfig.co; echo
dig +short myip.opendns.com @resolver1.opendns.com
# what your router's upstream looks like
traceroute -n -m 6 1.1.1.1 # macOS / Linux
tracert -h 6 1.1.1.1 # Windows
# check whether an address is in the CGNAT range
python3 -c "import ipaddress,sys; a=ipaddress.ip_address(sys.argv[1]); print('CGNAT' if a in ipaddress.ip_network('100.64.0.0/10') else 'not CGNAT')" 100.72.15.3Before blaming your ISP, check for a double NAT of your own making. An ISP-supplied gateway in router mode with your own router plugged into it produces exactly the same symptoms. Put the ISP device into bridge or passthrough mode and re-test.
What CGNAT actually breaks
Outbound browsing, streaming and general use are unaffected. CGNAT is invisible for anything you initiate. What breaks is anything that requires the outside world to reach you first.
Port forwarding stops working entirely. You can forward a port on your own router, but the carrier's translator has no rule sending that port to you, and you cannot configure it. This is the single most common practical complaint: a home NAS, a self-hosted service, a security camera recorder, or a game server becomes unreachable from outside the house.
Peer-to-peer connectivity degrades. Multiplayer games report strict or moderate NAT type, voice chat falls back to relay servers with added latency, and BitTorrent connects only to peers who can accept inbound connections. This is a performance and connection-quality issue rather than a total failure, because most protocols include relay fallbacks.
Remote access needs a workaround. Reaching your home network from elsewhere, whether by VPN into the house, SSH, or remote desktop, requires one of the techniques in the next section because there is no inbound path.
UPnP and NAT-PMP negotiate only with your own router, not the carrier's, so applications that believe they have opened a port are wrong. Some carriers deploy PCP (RFC 6887), which can request mappings from the carrier translator, but support is inconsistent and rarely documented.
The four ways around it
Ask for a public address. Most ISPs will assign one, sometimes free on request, more often as a static IP add-on at roughly $5 to $20 per month on residential plans, or bundled with a business tier. This is the cleanest solution and it removes every symptom at once. Ask specifically for a public routable IPv4 address, not a static IP, since the two are conflated in support scripts.
Use IPv6. If your ISP provides native IPv6, your devices already have globally routable addresses with no translation involved. Inbound connections work if you permit them in the router firewall. The limitation is on the far side: you can only reach your house over IPv6 from a network that also has IPv6, which excludes a surprising number of corporate and hotel networks. It is an excellent primary path with a fallback needed.
Use an overlay network. WireGuard-based mesh products such as Tailscale, along with ZeroTier and Nebula, establish connectivity between your devices without inbound ports, using coordinated NAT traversal and falling back to relays when direct connection fails. This works from behind any CGNAT, requires no ISP cooperation, and is the pragmatic default for personal remote access.
Use a reverse tunnel. A service reachable from the public internet holds a connection your home device initiated, and forwards inbound requests down it. Cloudflare Tunnel, ngrok, and a plain ssh -R reverse port forward to a cheap VPS all implement this pattern. It is the right approach for publishing a web service, because the tunnel endpoint provides a stable public hostname and TLS termination.
Some VPN providers also offer port forwarding on their exit addresses, which gives you an inbound path through the tunnel. Availability has narrowed considerably as providers dropped the feature over abuse concerns, so verify it exists before relying on it.
# reverse tunnel to a VPS you control, no inbound ports needed at home
ssh -N -R 8080:localhost:80 user@your-vps.example.com
# make it durable
autossh -M 0 -N -R 8080:localhost:80 \
-o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
user@your-vps.example.com
# verify IPv6 reachability from outside
curl -6 -sv https://[2001:db8::1]/ 2>&1 | headDo not solve CGNAT by exposing services directly once you get a public address. A publicly reachable RDP, VNC, or camera recorder is scanned within minutes of appearing. Put remote access behind a VPN or an authenticated tunnel regardless of which method you choose.
The shared-reputation problem
The privacy consequence of CGNAT cuts both ways. Your traffic is mixed with that of hundreds of strangers at the same public address, so an observer cannot attribute a given connection to you from the address alone. The ISP can, because it logs the port-range assignments, but a third party cannot.
The cost is that reputation is shared. If someone else behind your carrier translator runs a scanner, sends spam, or triggers a fraud rule, the address gets flagged and everyone behind it inherits the consequence. This is why CGNAT users see more CAPTCHAs, more account verification prompts, and occasional outright blocks from sites that have never seen them before.
If you are being blocked and suspect a shared address is the cause, check whether your public address appears on public reputation lists. You cannot get it delisted yourself, since you do not control it, but knowing that is the cause saves you from troubleshooting your own machine indefinitely. The realistic remedies are the same as the workarounds above: obtain a dedicated public address, or route the affected traffic through something else.
Frequently asked
How do I know if my ISP uses CGNAT?
Compare your router's WAN address with the address the internet sees. If they differ, translation is happening upstream. A WAN address in 100.64.0.0/10 is definitive under RFC 6598. A private RFC 1918 address on the WAN interface, with no second router of your own in the path, means the same thing.
Does CGNAT slow down my internet?
Not measurably for normal browsing and streaming. The translation adds well under a millisecond. What degrades is connection establishment for peer-to-peer applications, which may fall back to relay servers and pick up real latency, and total concurrent connections, which are capped by the port range your subscriber slot is allocated.
Can I port forward through CGNAT?
No, not through the carrier's translator, because you cannot configure it. Forwarding a port on your own router accomplishes nothing since inbound packets never reach it. Use IPv6, an overlay network like Tailscale, a reverse tunnel such as Cloudflare Tunnel or ssh -R, or pay for a public address.
Is CGNAT good for privacy?
Partially. Mixing your traffic with hundreds of other subscribers makes address-based attribution unreliable for third parties, though your ISP retains full logs of port assignments. The trade-off is inherited reputation: abuse by anyone sharing your address produces CAPTCHAs and blocks for you, with no way to appeal.
Will IPv6 fix CGNAT?
For inbound reachability, largely yes. Native IPv6 gives every device a globally routable address with no translation, so you can accept connections by permitting them in the router firewall. The limitation is that the remote network you connect from must also have IPv6, and many corporate and hotel networks still do not.