The scenario
Your-PC (192.168.1.10) runs a game server on TCP 25565. Your Home-Router translates 192.168.1.0/24 to its WAN address, 100.64.0.10, and forwards port 25565 to Your-PC. But 100.64.0.10 is not a public address: it comes from 100.64.0.0/10, the range set aside for carrier-grade NAT (RFC 6598). Your ISP's ISP-CGNAT gateway translates its customers' 100.64.0.0/24 addresses again, to the public 203.0.113.1. Internet (203.0.113.50) sees only 203.0.113.1 and has no route to 100.64.0.0/24 or 192.168.1.0/24. Outbound connections work through both translations. An inbound connection to 203.0.113.1:25565 stops at ISP-CGNAT, which has no forward for that port and nothing listening on it.
What you will work out
Understand carrier-grade NAT, why outbound traffic survives two translations, and why a port forward only helps on the NAT that owns the public address.
Why this matters
Many ISPs, mobile carriers in particular, put customers behind CGNAT because public IPv4 addresses ran out. If a port forward 'does nothing', check your router's WAN address before anything else. The real-world options are the ones this lab hints at: ask the ISP for a public IPv4 address (sometimes a paid option), use IPv6 if both ends have it, or run a tunnel or relay service that makes an outbound connection from your side, which CGNAT lets through.
Running it
Two Layers of NAT opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.
Open Two Layers of NAT
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →