NAT: Private to Public

The scenario

Office PC (192.168.1.10) has a private address. Private ranges such as 192.168.0.0/16 are not routed on the public internet, and in this lab the Internet Server (203.0.113.50) has no route to 192.168.1.0/24 either: it knows only its own network, 203.0.113.0/24. The NAT Gateway has one foot on each side, 192.168.1.1 on the LAN (ge0) and the public address 203.0.113.1 on the WAN (ge1). Its source NAT rule rewrites 192.168.1.10 to 203.0.113.1 as packets leave through ge1, so the Internet Server sees the gateway's address and can answer it directly. The gateway also has a port forward: a connection to its own address on port 8080 is sent on to 192.168.1.10 port 80. Nothing listens on Office PC's port 80 yet, so that forward is refused until you start a web server there.

What you will work out

Learn how source NAT lets private hosts start connections to the internet, how connection tracking translates the replies back, and what a port forward needs before it works.

Why this matters

Almost every home and office connects to the internet through source NAT: many private devices share one public address. The same idea appears in the cloud: an AWS NAT Gateway lets instances in a private subnet start connections to the internet, and it does not accept connections started from the internet. When someone says 'I can browse, but nobody can reach my server', the questions are the ones this lab asks: is there a port forward, does it point at the right host and port, and is anything listening there?

Running it

NAT: Private to Public 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.