What Is CGNAT?

CGNAT, short for carrier-grade network address translation, is an ISP-level way to share public IPv4 addresses across many customers. The short answer to what is CGNAT is simple: your home router may no longer sit directly behind a unique public IPv4 address. Instead, your router gets a private or shared WAN address, and the internet provider performs another translation step upstream.

That design is common on mobile networks, fixed wireless networks, some fiber and cable plans, and regions where public IPv4 addresses are scarce or expensive. It usually does not stop normal browsing, streaming, messaging, or app updates. It can matter a lot when you want inbound connections, port forwarding, game hosting, a home VPN server, cameras, NAS access, or any self-hosted service reachable from outside your network.

CGNAT is not proof that your network is hacked, and it is not a privacy guarantee. It is an address-sharing design. It can reduce what an IP-only log says about one customer, but accounts, cookies, payment records, device identifiers, timestamps, and provider records can still connect activity to a person or account in many situations.

What is CGNAT?

Carrier-grade NAT is network address translation performed by the internet provider rather than only by your home router. Traditional home NAT lets several devices on your local network share one public IPv4 address. CGNAT adds another translation layer in the provider network, so several customer routers can share a smaller pool of public IPv4 addresses.

The key range to know is 100.64.0.0/10, defined in RFC 6598 for shared address space. ISPs often use that space between customer routers and provider translation systems. Some networks also use private ranges such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, which are described by RFC 1918.

When people ask what is CGNAT, they are usually seeing one of three symptoms: port forwarding does not work, a game reports strict NAT, or the router WAN address does not match the public IP shown by a website. Those are useful signals, but they need context. Double NAT at home, a mesh router, a work gateway, or a VPN can produce similar confusion.

CGNAT vs home NAT vs public IP

The easiest way to understand CGNAT is to compare where address translation happens and who controls it.

CGNAT is therefore mainly an IPv4 scaling workaround. Traditional NAT helped households share one public IPv4 address. Carrier-grade NAT applies a similar idea at provider scale, with extra operational requirements described in RFC 6888.

How to tell if you are behind CGNAT: 7 checks

No single sign is perfect, but these checks usually make the picture clear. Keep the test limited to your own router, account, and network.

1. Check your visible public IP. Open What Is My IP and write down the public IPv4 address shown to websites.
2. Check your router WAN or internet address. In the router status page, find the WAN, internet, or external IPv4 address. Use the router only from your trusted local network.
3. Compare the two addresses. If the router WAN address is different from the public IP, an upstream NAT layer, modem-router, mesh gateway, work gateway, or CGNAT may be involved.
4. Look for shared or private ranges. A WAN address in 100.64.0.0/10 strongly suggests shared provider space. A WAN address in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 means your router is not receiving a public IPv4 address directly.
5. Check the network owner. Use ASN Lookup to see whether the public IP belongs to your ISP, mobile carrier, hosting provider, VPN, or another network.
6. Test with VPN off and on. A VPN can change the public IP and confuse the diagnosis. First test your normal connection, then test the VPN separately if relevant.
7. Ask the ISP using precise wording. Ask whether your plan receives a public IPv4 address, CGNAT, dynamic public IP, static public IP, or IPv6 prefix delegation. Support teams may understand those terms better than "strict NAT."

The practical answer to what is CGNAT becomes obvious when the router does not hold the same public IPv4 address that websites see. The ISP, not your router, controls the final public IPv4 translation.

What CGNAT breaks or changes

CGNAT usually affects inbound traffic and reputation signals more than normal outbound browsing. Most apps start connections from your device to the internet, so they continue to work. Problems appear when a remote device, player, service, or monitoring system must start a connection back to your network.

• Port forwarding: forwarding a port on your home router usually cannot punch through the ISP's upstream NAT layer.
• Game hosting and NAT type: consoles and games may show strict NAT, symmetric NAT, or connection trouble because direct peer connections are harder.
• Home VPN server: an inbound WireGuard, OpenVPN, or router VPN server may not be reachable over IPv4 through CGNAT.
• Cameras, NAS, and smart devices: direct access from outside the home often fails unless the device uses a relay service, IPv6, or another managed path.
• Self-hosted websites or APIs: public IPv4 visitors cannot reach a server behind CGNAT unless traffic is relayed or routed another way.
• IP reputation: you may share a public IPv4 address with many customers, so rate limits, CAPTCHAs, or abuse reputation can involve other users.

These effects do not mean CGNAT is malicious. They are side effects of sharing scarce IPv4 addresses. The correct fix depends on whether you need gaming stability, remote administration, hosting, business allowlisting, or just an explanation for why the router address looks unusual.

CGNAT workarounds and safer fixes

The safest workaround is the one that solves your actual need without exposing admin panels or weak services to the public internet.

A VPN with port forwarding can help in some cases, but only if the provider supports that feature and you understand what is exposed. A VPN does not automatically make a home service safe. A reverse tunnel can also help, but the endpoint, credentials, software updates, and access rules still need careful management.

CGNAT, gaming, cameras, and self-hosting

Gaming problems are often the first time home users notice CGNAT. A game console may report strict NAT even though the internet connection is fast. The reason is not raw speed. It is that inbound peer traffic and connection negotiation are harder when several translation layers sit between players.

For cameras and smart devices, avoid the instinct to expose everything directly. Vendor cloud relay features may be convenient but raise trust and account-security questions. Direct IPv4 access may fail under CGNAT. IPv6 may work technically, but it still requires sensible firewalling and device updates.

For self-hosting, separate the learning project from the exposure decision. A home lab can run locally without being reachable from the internet. When public access is needed, compare a small VPS, reverse proxy, managed tunnel, IPv6 setup, or ISP public IP. The practical question is not just "can traffic reach me?" It is "can traffic reach only the service I intended, with controls I understand?"

CGNAT, IPv6, VPNs, and port forwarding

IPv6 can change the situation because it was designed with a much larger address space. With a working IPv6 prefix, devices may have globally routable IPv6 addresses while IPv4 remains behind CGNAT. That can solve some reachability problems for IPv6-capable services, but IPv6 still needs firewall policy, device hygiene, and careful testing.

A VPN changes the route for traffic that goes through the VPN. It may show a different public IP, different DNS resolvers, and different WebRTC behavior. It does not remove CGNAT from the ISP link itself, and it does not make you anonymous. Some VPNs offer dedicated IPs or port forwarding; others do not. Read the provider documentation before relying on those features.

Port forwarding behind CGNAT is often misunderstood. Your router can forward traffic from its WAN side to a device on your LAN, but if the ISP's upstream NAT never sends unsolicited traffic to your router, the rule has nothing useful to receive. That is why a public IP, IPv6, relay, reverse tunnel, or provider-supported port-forwarding service may be needed.

What not to do

• Do not treat CGNAT as a security product. It changes reachability, but firewalls, updates, passwords, and access controls still matter.
• Do not expose router admin, RDP, SSH, NAS, or cameras directly to the internet. Use safer remote-access design and strong authentication.
• Do not assume a VPN makes CGNAT disappear. A VPN may provide another path, but the ISP access link can still be behind CGNAT.
• Do not disable IPv6 as a default fix. If IPv6 causes confusion, troubleshoot route, firewall, and VPN behavior first.
• Keep scans and probes authorization-only. Limit reachability tests to your own services, your own network, or systems you are explicitly authorized to manage.
• Do not assume dynamic DNS makes exposure safe. Dynamic DNS only solves the naming problem; it does not add authentication or firewalling.

What to do next

If you only wanted to know what is CGNAT, the practical answer is that it is ISP-level IPv4 sharing. It is common, usually harmless for normal browsing, and often frustrating for inbound connections.

If a real workflow is broken, identify the workflow before choosing a fix. For gaming, ask whether the platform supports relays or IPv6 and whether the ISP can provide a public IP. For cameras and NAS access, avoid direct public exposure when a private VPN or managed remote-access method would be safer. For business allowlists and hosting, document whether you need a static public IP, cloud endpoint, or IPv6-capable design.

Finally, retest after any network change. Compare public IP, router WAN address, ASN, IPv6, DNS, VPN, and WebRTC signals together. These checks are snapshots, not permanent proof of how every app routes traffic.