The scenario
External Client (203.0.113.50) is on the public side and knows only its own network, 203.0.113.0/24. Internal Web (10.0.0.10) has a private address behind the NAT Gateway, whose public address is 203.0.113.1. The gateway has three port forwards (DNAT rules): port 80 to 10.0.0.10:80, port 443 to 10.0.0.10:443 and port 22 to 10.0.0.10:22. When External Client connects to 203.0.113.1:80, the gateway rewrites the destination to 10.0.0.10:80 and delivers it inside. Internal Web runs HTTP (TCP 80) and HTTPS (TCP 443) but no SSH service, so the port 22 forward is refused by Internal Web. The gateway also has a source NAT rule for 10.0.0.0/24, which is used when Internal Web starts a connection of its own toward the outside.
What you will work out
Understand how destination NAT rewrites incoming connections to reach an internal service, how their replies are translated back, and why a forward is useless without a listening service behind it.
Why this matters
Hosting anything at home or behind an office firewall, from a web server to a game server, comes down to a port forward to a service that is really running. Docker's 'docker run -p 8080:80' does the same thing on a single machine: it installs a DNAT rule so connections to the host's port 8080 reach port 80 inside the container. When a forward 'doesn't work', check both halves: does the rule point at the right address and port, and does something listen there? A forward you no longer use is also worth removing, because it lets the outside reach an inside host.
Running it
NAT: Port Forwarding 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 NAT: Port Forwarding
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →