What Is CGNAT? Why You Can Have a Public IP Yet Still Fail at Port Forwarding, and What 100.64.0.0/10 Means

Most people do not first encounter CGNAT because they saw the phrase “Carrier-Grade NAT.” They encounter it because something concrete broke: the router shows a WAN address, but inbound access still fails; port forwarding is configured, yet the NAS, camera, game server, or self-hosted app is still unreachable from the public internet. Others notice it during IP analysis: multiple accounts appear under the same public IP, geolocation feels unstable, or logs keep surfacing addresses like 100.64.x.x.

Those symptoms often point to the same cause: your ISP is using CGNAT. This is not the ordinary NAT running inside your home router. It is a second NAT layer deployed in the provider network. In practical terms, the key consequence is simple: you may think you have a direct public IPv4 identity, but in reality that public address is being shared among many subscribers.

This article explains what CGNAT is, why 100.64.0.0/10 appears so often, how it differs from ordinary private address space, why it breaks typical port-forwarding expectations, and what it changes for geolocation, logging, fraud review, and SEO interpretation. You can verify those signals with ipinfo.im's IP lookup, WHOIS, ASN, and Traceroute tools.

What CGNAT actually is

CGNAT stands for Carrier-Grade NAT, also commonly called large-scale NAT. The translation logic is familiar: many addresses are multiplexed behind fewer public IPv4 addresses. The difference is where it happens. Home NAT translates your internal devices into one upstream address. CGNAT translates many customers again inside the ISP network into an even smaller public IPv4 pool.

That means your connection may effectively have two NAT layers:

1. Your home router translates 192.168.x.x, 10.x.x.x, or 172.16.x.x - 172.31.x.x into its upstream address.
2. Your ISP CGN then translates many subscriber-side addresses into a smaller number of truly internet-visible public IPv4 addresses.

So when a user says “my router got a WAN IP, therefore I must have public inbound access,” that assumption is often wrong. The router may have received an address from the ISP's shared space, not a globally reachable address exclusively assigned to that customer.

What 100.64.0.0/10 means, and why it is not a normal public range

100.64.0.0/10 is a special shared address block reserved specifically for provider-side CGN deployments. It frequently appears in home broadband, mobile, wireless broadband, and some business access links. The common misunderstanding is that it does not look like the familiar RFC 1918 ranges, so people assume it must be public. It is not.

It is also not identical in purpose to ordinary private ranges like 192.168.0.0/16 or 10.0.0.0/8. Those are mainly used inside customer or enterprise networks. 100.64.0.0/10 is intended for the path between customer equipment and provider-side CGN functions. For most end users, seeing this range is one of the strongest hints that the ISP still has another NAT layer in front of them.

Why port forwarding fails so often behind CGNAT

Port forwarding assumes that when the internet sends traffic to a public IP and port, that connection can be deterministically delivered to your own router and then forwarded into your LAN. Under CGNAT, the truly public IPv4 address is not directly yours. It is shared with many other subscribers. The provider NAT layer usually tracks outbound sessions but does not simply hand arbitrary inbound requests to one customer by default.

That is why you can map 443, 3389, 25565, or your NAS service port perfectly on the home router and still remain unreachable from outside. The problem may not be your router at all. The inbound flow never reliably crosses the ISP NAT layer in the first place.

How to tell whether you are behind CGNAT

The most practical test is not reading marketing pages from the ISP. It is a three-step comparison:

1. Check the WAN / Internet IPv4 shown on your router.
2. Open ipinfo.im and check the public IPv4 the site sees.
3. Compare the two, and verify whether the router WAN address falls into 100.64.0.0/10, RFC 1918 space, or another obviously non-public range.

# Check local addressing on Windows
ipconfig

# Check local addressing on Linux / macOS
ip addr

# The key questions are not your host IP.
# They are:
# 1. What WAN address did the router receive?
# 2. What public IP does ipinfo.im see?
# 3. Are they the same?

If your router WAN address is something like 100.72.15.8 while ipinfo.im reports a totally different public IPv4 such as 203.0.113.45, there is another NAT stage between your home and the internet. In most consumer scenarios that means you do not have exclusive inbound IPv4 reachability.

Why CGNAT changes how logs, fraud systems, and account linkage should be read

Many websites and SaaS systems still treat a public IP as part of a user identity hint. Under CGNAT, that signal weakens materially because one public IPv4 can be shared by many devices, many homes, and many unrelated people at the same time. As a result, these effects become common:

• Multiple accounts appear under the same public IP without implying the same person or household.
• Blocking one public IP can create collateral damage for unrelated users.
• “Many accounts from one IP” becomes a weaker fraud indicator.
• Abuse tracing becomes less precise if you do not have exact timestamps and port context.

That is why serious operational logging should not stop at “source public IP.” In shared-address environments, you often need precise timestamps, source ports, proxy-chain headers, ASN data, UA context, and session-level evidence to make the signal meaningful.

Why CGNAT can make IP geolocation look inaccurate

CGNAT does not automatically mean a geolocation database is wrong. It means the visible public exit point may represent a larger shared network edge rather than one subscriber's actual location. An ISP may aggregate traffic from many users to a more centralized egress city or backbone node before exposing it to the internet.

So a person in city A appearing in city B is not unusual. On residential broadband that often reflects the ISP exit architecture. On mobile networks the mismatch can be even stronger because centralized egress and address sharing are more common. For a deeper explanation of those location mismatches, see this related article on the site: Why Your IP Location Does Not Match Your Real Location.

What CGNAT means for remote access, self-hosting, and P2P applications

For ordinary outbound web browsing, CGNAT is often invisible because most traffic is initiated by the user. It becomes much more visible in these scenarios:

• Home NAS, cameras, router admin pages, self-hosted sites, or APIs that need public inbound reachability.
• Remote desktop, gaming, or P2P workloads that depend on successful direct connectivity.
• Services expecting internet-initiated callbacks into a home or small-office network.
• Systems relying on a stable, unique public IPv4 for allowlists, device pairing, or origin control.

In those cases, the visible side effects are consistent: inbound connections do not arrive, NAT traversal success rates drop, port forwarding becomes ineffective, and some applications fall back to relay paths with extra latency and more complex troubleshooting.

How websites and analytics systems should interpret shared public IPs

For operations, SEO, localization, and analytics, the safer interpretation is not “this IP equals this exact user.” It is: this request is currently exiting through a particular operator or network edge. That leads to better decisions:

• Do not treat the city label of an IP as the user's precise location.
• Do not treat “same public IP” as strong standalone evidence of account linkage.
• Keep region redirects and content localization tolerant; do not hard-code them around one IP result.
• Combine ASN, network type, behavior, and other signals instead of relying on a single IP label.

This also matters for SEO and regional UX. Many sites attempt aggressive country or city redirects based on IP. CGNAT, mobile egress, and office gateways make that logic fragile. When those redirects become too rigid, both user experience and crawler handling can degrade. In most cases, explicit region/language controls plus IP as a weak hint are safer than IP as a hard rule.

If you truly need inbound public reachability, what are the realistic options?

If your goal is to make a home or small-office network reachable from the public internet, CGNAT usually will not be solved by “tuning the router a bit more.” The realistic paths are usually one of these:

1. Ask the ISP for a real public IPv4 or move to a plan that includes one.
2. Use IPv6 for inbound access, assuming the service path and clients support it.
3. Use a remote-access design with relay or reverse-tunnel capability.
4. Move the service to a cloud or edge host with a stable public IP.

If your immediate task is simply “why can nobody reach my service from outside,” the first productive step is to confirm whether CGNAT exists. Otherwise you may waste hours reconfiguring a router that is not the actual bottleneck.

What people most often confuse: home NAT versus carrier NAT

The most common confusion is this: people know home routers do NAT, so they assume that normal port forwarding should always solve inbound access. That only works if the world can first reach a truly public IPv4 that is actually yours. Home NAT is under your control. CGNAT usually is not.

Put differently, home NAT is mainly about translation between your LAN and your upstream. CGNAT changes something more fundamental: whether you have an exclusive public IPv4 entry point at all.

Conclusion

If your router has a WAN address but port forwarding never works, if shared public IPs keep creating ambiguity in logs or fraud review, or if your upstream address sits inside 100.64.0.0/10, CGNAT deserves to be checked early.

CGNAT is not “the network is broken.” It is an ISP-side IPv4 sharing mechanism created under address scarcity. It may leave ordinary browsing mostly unaffected, but it changes the meaning of port forwarding, remote access, account linkage, traceability, and location interpretation in very practical ways. Once you recognize that, it becomes much easier to understand what an IP result on ipinfo.im is really telling you, and which layer of the network stack you should troubleshoot next.

References

• RFC 6598 - IANA-Reserved IPv4 Prefix for Shared Address Space
• RFC 6888 - Common Requirements for Carrier-Grade NATs (CGNs)
• RFC 6269 - Issues with IP Address Sharing
• APNIC - Network Address Translation (NAT)