NAT and CGNAT Explained: Why Your Public IP Changes and Who Shares It

How NAT and CGNAT actually work, why your public IP isn't really yours, and what these systems mean for self-hosting, gaming, fraud detection, and IP geolocation.

NAT and CGNAT Explained: Why Your Public IP Changes and Who Shares It

Every device on the internet supposedly has a unique address. Anyone who has ever set up a home router knows this isn’t really true — there are dozens of devices in a house sharing one public IP. Network Address Translation (NAT) is what makes that work. And as IPv4 addresses have run out, ISPs have started layering NAT on top of NAT — Carrier-Grade NAT (CGNAT) — sharing one public IP between hundreds or thousands of customers.

This post explains how NAT and CGNAT actually work, why your “public IP” usually isn’t really yours, and what these systems mean for self-hosting, gaming, fraud detection, and IP geolocation.

The Original Problem: Not Enough IPv4 Addresses

IPv4 addresses are 32 bits long. That gives 4.3 billion possible addresses. Sounds like a lot — except the internet has 5+ billion users, most of whom have multiple devices, and many of whom run servers and IoT gear that also need addresses.

IPv6 was designed to fix this (128-bit addresses, effectively unlimited). But IPv6 adoption has been gradual, and meanwhile the IPv4 internet keeps growing. The bridge is NAT.

How NAT Works (Home Router Edition)

Your home router has a public IP from your ISP — something like 203.0.113.45. Behind the router, all your devices have private IPs from a reserved range like 192.168.1.0/24. When your laptop wants to load a webpage:

  1. Laptop (192.168.1.10) sends a packet to the server (104.18.27.89).
  2. Router intercepts. It changes the source address from 192.168.1.10 to its own public IP (203.0.113.45) and remembers the mapping in a NAT table.
  3. Packet goes to the server.
  4. Server replies to 203.0.113.45.
  5. Router looks up the NAT table, sees the connection belonged to 192.168.1.10, rewrites the destination back, and forwards it.

To the server, all your devices look like one client at 203.0.113.45. Inside your house, each device thinks it has a unique IP and is talking directly. The router is doing the bookkeeping.

This is port translation specifically — the router uses different source ports for different internal connections to keep them straight. The technical name is PAT (Port Address Translation) or NAPT (Network Address Port Translation), but everyone calls it NAT.

The Consequences (Even at the Home Level)

Several familiar pain points come from NAT:

You can’t be a server without help

External clients can’t initiate a connection to your laptop. The router doesn’t know which internal device to forward it to. This is why hosting a game server or running a web server from home requires port forwarding — manually telling the router “incoming connections on port 25565 should go to 192.168.1.10.”

Some protocols struggle

SIP, FTP (active mode), peer-to-peer games — anything that embeds IP addresses inside its data — gets confused by NAT. The protocol expects its endpoint to be globally reachable; the router has lied about the address. Workarounds (STUN, TURN, ALGs) exist but add complexity.

Port limits are real

Each NAT mapping uses a unique source port. With 65,535 ports total, one IP can in theory handle ~65,000 concurrent connections. For a home router serving a household this is plenty. For a corporate gateway or a CGNAT box, it isn’t — which we’ll get to.

Enter CGNAT

CGNAT is NAT, but at the ISP level instead of the home level. The ISP gives you a “public” IP that isn’t actually public — it’s still inside a private range, owned by the ISP. The ISP then NATs that through a small pool of real public IPs shared across thousands of customers.

So now your packet’s journey is:

  1. Your laptop sends to the server.
  2. Your home router NATs it to your “public IP” (100.64.0.45, in a CGNAT range).
  3. The ISP’s CGNAT box NATs it again to a real public IP (203.0.113.7), one of many shared by thousands of customers.
  4. Packet goes to the server.
  5. Reply comes back, gets un-NATed at the CGNAT box, gets un-NATed at your router, lands on your laptop.

Two layers of NAT. The “you” that the server sees is 203.0.113.7, which is also the “you” that hundreds of other customers see.

CGNAT is most common in:

  • Mobile networks (almost universal — 4G/5G traffic is almost always CGNAT-ed).
  • Cable ISPs in countries where IPv4 is expensive (most of South America, much of Asia, large parts of Africa).
  • WISPs and rural fiber providers in markets where IPv4 allocations are no longer easy to obtain.

Why CGNAT Matters

For self-hosting, it’s mostly bad

Behind CGNAT, you don’t even own a “public” IP. There’s no router port-forwarding you can do — the ISP’s NAT box is between you and the world. Your only paths to inbound connectivity:

  • A VPS or cloud proxy that holds a real public IP and tunnels traffic back to you.
  • Cloud-hosted services like Cloudflare Tunnel, Tailscale Funnel, or Ngrok that maintain a persistent outbound connection from your network to a public endpoint.
  • IPv6 if your ISP supports it — IPv6 traffic typically isn’t CGNAT-ed, and you get globally reachable addresses for your devices. See IPv6 vs IPv4.

For peer-to-peer applications, it’s harder

Direct peer-to-peer connections between two users behind CGNAT often require a third party to introduce them (TURN servers, hole-punching coordination). Many gaming platforms quietly run massive TURN infrastructure to make this work.

For IP geolocation, it’s a known problem

The IP your traffic appears from is the CGNAT box’s IP, not yours. The geolocation of that IP is the carrier’s gateway, which can be hundreds of miles from any individual customer. This is why mobile data and CGNAT-heavy markets are inherently less accurate for IP geolocation. See IP geolocation accuracy for the full discussion.

For fraud detection, it’s noisy

Many unrelated users share one IP behind CGNAT. “Many accounts from one IP” — usually a fraud signal — generates false positives in CGNAT markets. Fraud detection systems have to weight this signal carefully or filter by ASN type (mobile/CGNAT vs residential). See IP-based fraud detection.

Why Your Public IP Changes

Beyond the CGNAT layer, even your “public IP” (the one your home router presents) probably isn’t permanently yours. Most ISPs allocate IPs dynamically — your modem leases an IP for a period (often hours to days) and may get a different one next time it reconnects.

Reasons:

  • ISPs have far fewer IPs than customers (especially mobile carriers).
  • Recycling addresses is how the system scales.
  • Static IPs cost extra at most ISPs (often $5-20/month).

When your IP changes:

  • Any port-forwarded service is briefly unreachable until DNS catches up.
  • Active connections from your home are usually preserved (the connection is in the NAT table).
  • New connections come from the new IP.
  • Geo data is mostly the same (the new IP is usually in the same region).
  • IP allowlists you’ve configured for remote access — VPN, firewalled SSH, etc. — break until you update them.

The most common solution is dynamic DNS (DDNS) — a service that updates a DNS A record automatically when your IP changes. Cloudflare, No-IP, DynDNS, and many others offer this.

How to Tell If You’re Behind CGNAT

A quick check:

  1. Find your router’s public IP. Log into the router admin panel or use traceroute to see your first external hop.
  2. Find your “internet IP.” Run what-is-my-ip or query curl ifconfig.me from a device on your network.

If those two IPs are different — specifically, if your router’s “public” IP is in a private/CGNAT range (10.x.x.x, 100.64.x.x to 100.127.x.x, 172.16.x.x to 172.31.x.x, or 192.168.x.x) but the world sees you from a public IP — you’re behind CGNAT.

The most telling range is 100.64.0.0/10 (the range 100.64.0.0 to 100.127.255.255), which IANA specifically reserved for CGNAT use in RFC 6598. If your router’s public-side IP is in that range, you’re definitely CGNAT-ed.

Workarounds and Mitigations

IPv6

The simplest answer. IPv6 doesn’t need NAT — every device gets a real, globally routable IP. If your ISP supports IPv6 (most do in 2026), enable it on your router and your devices, and IPv6 traffic skips the CGNAT layer entirely. Your server-side code and your peer-to-peer apps will Just Work for IPv6 connections.

Tunneling services

Tools like Cloudflare Tunnel, Tailscale, WireGuard with a cloud relay, and Ngrok maintain a persistent outbound connection from your network to a publicly-reachable endpoint. Inbound connections hit the public endpoint, which forwards them through the tunnel. This works behind any NAT.

For most people who want to self-host something small, Cloudflare Tunnel is now the easiest path — free for non-commercial use, no port forwarding required, no CGNAT issue.

Static IP (paid)

If you genuinely need a publicly-reachable static IPv4 address, your ISP almost certainly sells one. Often $5-20/month. Worth it for some use cases (running a mail server, SaaS hosted at home, IPv4-only legacy clients).

Just use a VPS

If you’re running anything substantial, a $5/month VPS gives you a stable public IP, full inbound connectivity, and no CGNAT. For most “I want to host something accessible” needs, this is the cleanest path.

What This Means for Your Code

A few practical notes for application developers:

Don’t assume one IP = one user

Behind CGNAT (and corporate proxies, and university networks, and large NAT setups generally), many users share one IP. Rate limits, fraud signals, and any “one IP = one customer” logic needs to account for this.

Don’t assume one user = one IP

Mobile users frequently shift between cellular and Wi-Fi, between cell towers, between IPv4 and IPv6 — all of which can change their apparent IP within a single session. Authentication that breaks on IP change is hostile to mobile users.

Geo at the ASN level when possible

City-level geolocation behind CGNAT is unreliable. But the ASN is reliable — you can always tell which carrier/ISP the user is on. For fraud detection and routing decisions, ASN-based logic is more robust than IP-based.

IPv6 dual-stack

Make sure your application works correctly over both IPv4 and IPv6. Many “weird” connectivity bugs in 2026 come from IPv6 paths failing silently while IPv4 works.

Handle “unknown” gracefully

Some IPs really don’t have a meaningful location (newly allocated, satellite, edge cases). Your code should treat “unknown” as a valid state.

Looking Up the Mess

If you want to see how this affects a specific IP, look it up in a real geo tool and look at the ASN field. Mobile carrier IPs and CGNAT IPs will usually be flagged at the ASN level — T-Mobile USA, Vodafone D2 GmbH, Reliance Jio Infocomm — even if the geo data looks similar to residential addresses. The ASN is what tells you the IP is behind CGNAT.

For the curious: try whois on the public IPv4 ranges used by mobile carriers. You’ll see “CGN” in the comments, plus often huge prefix sizes — a single ASN announcing a /12 block for tens of thousands of customers.

The Big Picture

NAT exists because IPv4 ran out. CGNAT exists because home NAT wasn’t enough. Both are workarounds for the same shortage. Both make the internet harder to reason about — for users, for developers, for fraud teams, for geo databases.

The real fix is IPv6, where every device gets a real address and NAT becomes unnecessary. Adoption has been frustratingly gradual but is finally accelerating: in 2026, IPv6 traffic is the majority on many large networks, and several markets are running IPv6-only. The CGNAT era will end eventually. Until then, expect that “the user’s IP” is increasingly a fuzzy concept.

TL;DR

  • NAT lets multiple devices share one public IP. Standard home router behavior since the 1990s.
  • CGNAT layers NAT on top of NAT at the ISP level. Common on mobile and in IPv4-scarce markets.
  • Your “public IP” usually isn’t really yours. Especially on mobile.
  • CGNAT breaks self-hosting, complicates P2P, degrades IP geolocation, and confuses fraud detection.
  • IPv6 is the long-term fix. Enable it where supported.
  • For specific use cases, tunneling services (Cloudflare Tunnel, Tailscale) are usually cleaner than fighting CGNAT.

If you’re building an application that deals with IPs — for any reason — assume NAT and CGNAT exist and design accordingly. Don’t be surprised when one IP represents many users. Don’t trust city-level geo for mobile traffic. Don’t assume the IP is “the user.” It rarely is anymore.

Get Started

Convert IPs into accurate location data in milliseconds.

Sign up today and get 1,000 free monthly stored conversions, and discover why developers trust us for fast, reliable, and affordable IP conversions.