Double NAT and CGNAT: how to tell which you have, and what actually breaks

Open your router's status page and read the WAN IP. If it sits in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, your router is plugged into another NAT device: that is double NAT, and you can probably fix it yourself. If it sits in 100.64.0.0/10, the second translation happens inside your ISP's network, that is carrier-grade NAT, and no setting on your hardware will remove it.

Two address ranges do all the diagnostic work

RFC 1918, published February 1996, reserved three private blocks: 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255. It says "packets with private source or destination addresses should not be forwarded across such links," meaning inter-enterprise links, and that ISP routers "are expected to be configured to reject (filter out) routing information about private networks." So an address from those ranges cannot have reached you from the public internet. Something upstream handed it to you, and that something is doing NAT.

RFC 6598, published April 2012, added a fourth block for a narrower job: 100.64.0.0/10, or 100.64.0.0 through 100.127.255.255, which is 4,194,304 addresses. Its stated purpose is "to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE)." The RFC is blunt about the constraints. Packets from this space "MUST NOT be forwarded across Service Provider boundaries," and reverse DNS queries for it "MUST NOT be forwarded to the global DNS infrastructure." IANA's special-purpose registry files it with the same flags as the RFC 1918 blocks: usable as source and destination, forwardable, not globally reachable. It got its own block because carriers were already using 10.0.0.0/8 internally and colliding with subscribers doing the same.

Read the second octet carefully. 100.64.x.x through 100.127.x.x is shared address space and a near-definitive CGNAT signal, since nothing else residential should use it. 100.128.x.x is ordinary public space and means nothing of the sort.

Checking it in two minutes

The first method is a comparison. Read the WAN IP off the router's status page, then load any external "what is my IP" page from the same network. If the two numbers disagree, at least one more NAT device sits between you and the internet.

The second method is traceroute 8.8.8.8 on macOS or Linux, tracert 8.8.8.8 on Windows, reading only the first two or three hops. Two RFC 1918 hops in a row, say 192.168.1.1 then 192.168.0.1, means a second router you own is translating ahead of the gateway. A hop in 100.64.0.0/10 is the carrier's CGN device.

One caution. ICMP time-exceeded replies get rate-limited or dropped by consumer gateways and carrier routers alike, so a row of * * * proves nothing. Only an address actually printed in the output counts.

"Double NAT" is support-desk vocabulary, not an IETF term. CGNAT runs the same mechanism inside the carrier's network instead of your hallway. The difference that matters is control: you can log into your own second router and turn its NAT off, and you cannot log into a CGN device to add a port forward, a DMZ host, or a UPnP mapping.

What genuinely breaks

Anything inbound. A port forward, a DMZ host, or a UPnP mapping only works if the device holding the real public IP is the one that accepts the rule. Under double NAT, the inner router's rule is invisible from outside unless the outer router carries a matching rule pointing at it. Under CGNAT there is no customer-reachable device on which to write that outer rule. That takes out self-hosted game servers, remote access to Plex or Jellyfin, remote camera NVR viewing, self-hosted sites and NAS shares, and inbound remote desktop.

PPTP breaks for a mechanical reason worth knowing. It carries its payload inside GRE, IP protocol 47, which has no port numbers, so port-based translation has nothing to multiplex on. A NAT without a PPTP helper can pass about one tunnel per public address, since the source IP is all that is left to tell sessions apart. Helpers that rewrite GRE Call IDs lift that limit, and Linux ships one as nf_conntrack_pptp, which is what a router's "PPTP passthrough" toggle usually enables. Behind CGNAT you cannot check whether the carrier runs an equivalent. IPsec also breaks without NAT traversal, and AH breaks under any NAT, because AH signs the IP header that NAT rewrites.

The last real problem is shared fate. Many subscribers sit behind one CGNAT address, so if one of them trips a streaming service's proxy heuristics or lands on a reputation blocklist, everyone mapped to that address inherits the flag. Carriers do not publish subscribers-per-address ratios, so treat any specific figure you see quoted as guesswork.

What gets blamed on it wrongly

Modern IPsec is not one of the casualties. NAT traversal was standardized for IKEv1 in RFC 3947 (January 2005) with RFC 3948 for UDP encapsulation of ESP: the peers "detect one or more network address translation devices (NATs) between IPsec hosts" and wrap ESP inside UDP so port translation can rewrite it. IKEv2 folded the same idea into the core protocol in RFC 7296, so current remote-access VPNs cross multiple NAT hops unconfigured. "VPNs break behind NAT" was true of specific legacy protocols and modes, never of the category.

Speed complaints are the bigger misdiagnosis. The expensive part of NAT is creating the mapping for a new flow; after that, each packet costs a table lookup and a header rewrite, which hardware-accelerated forwarding paths handle at line rate. Where a double-NAT setup really is slow, the culprit is an underpowered box, or one running heavy QoS, deep packet inspection, and logging on the CPU that also forwards traffic. Fix the device, not the topology.

Most of what a household does is untouched either way. Browsing, video-on-demand streaming, and games hosted on matchmaking servers all initiate outbound, so the inbound limitation never applies. A console reporting Strict NAT is not proof of a second NAT hop either: UPnP switched off on a single ordinary router produces the same symptom.

Console NAT labels versus the actual standard

RFC 4787 (January 2007) stopped using the STUN-era Full Cone, Restricted Cone, Port-Restricted Cone, and Symmetric labels, because "this terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior." It substitutes two independent axes: mapping behavior and filtering behavior, each endpoint-independent, address-dependent, or address-and-port-dependent. Xbox's Open, Moderate, and Strict and PlayStation's NAT Type 1, 2, and 3 are vendor simplifications on top of that, not IETF terminology. Nintendo publishes the same three tiers and one very specific rule: a Strict player "can connect to games hosted by a user with an Open NAT type, however, if a game supports multiple users, they will get disconnected if a user with Moderate NAT type joins the same game." Both double NAT and CGNAT push a console down that ladder.

The fixes, in the order worth trying

Bridge mode first, if the problem is home-side. Bridging turns a gateway into a passthrough, so the next device downstream gets the public IP and becomes the only NAT hop. Netgear's knowledge base tells you to "put your ISP gateway in bridge mode" for best performance and, failing that, to turn its Wi-Fi off and run your own router in access point mode, noting that "some router features are disabled in AP mode." If the upstream box is a second router of your own, removing it beats bridging it. None of this reaches ISP-side CGNAT.

Next, ask the ISP for a public IPv4 address, and say "public" rather than "static," because reps conflate the two and they are different requests. Satellite and fixed wireless are the clearest cases. Starlink's residential service is reported to hand out CGNAT addresses from 100.64.0.0/10 by default and to sell a public IPv4 option on its higher tiers; T-Mobile's home internet reportedly charges monthly for one. Ask for the current price rather than trusting a blog post. Several large cable ISPs publish no self-service path at all, and customers report raising it with support case by case.

IPv6 is the structural answer rather than a workaround, because a globally routable address per device removes the scarcity that produced CGNAT. ARIN issued the final addresses in its IPv4 free pool on September 24, 2015; the RIPE NCC ran out on November 25, 2019. RFC 6177 (March 2011) recommends that end sites get "a block larger than a single /64," while declining to fix a number: "the exact choice of how much address space to assign end sites is an issue for the operational community." /56 is the operator convention most often cited as consistent with that reasoning. IPv4 CGNAT and native IPv6 routinely coexist on one dual-stack line, so whether you are behind CGNAT and whether your IPv6 works are separate questions.

Adoption is no longer marginal, though no single figure is honest. Google's measurement of its own users crossed 50 percent in spring 2026: The Register logged 50.1 percent for March 28, 2026 and called it "notable, and nice, but not solid proof that IPv6 has finally become dominant," while APNIC's blog dates the crossing to April 23. Other trackers run lower, near 40 percent of HTTP requests at Cloudflare Radar and 42 to 43 percent of networks at APNIC Labs, because they count different things.

If the ISP will not sell a public address and IPv6 does not cover what you need, an outbound tunnel bypasses CGNAT by construction. Cloudflare's documentation describes cloudflared initiating "an outbound connection through your firewall from the origin to the Cloudflare global network," giving "a secure way to connect your resources to Cloudflare without a publicly routable IP address." Tailscale tries direct connections first using the STUN and ICE standards, then falls back to its DERP relays, which "just blindly forward already-encrypted traffic." Neither asks you to open a port. That is why they work where port forwarding cannot.