NAT and Private/Public IPs

In Article 4, traceroute showed something odd: your machine has the private IP 192.168.71.168, but a server on the Internet sees you arriving from the public IP 203.0.113.45. The transformation between these two addresses is NAT (Network Address Translation) — and it's the reason the IPv4 Internet is still alive despite having run out of addresses.

The problem NAT solves

Remember Article 2: a private IP (192.168.x.x...) is not routable on the Internet. But every device in your home uses a private IP. So how do they reach the Internet?

And the bigger problem: IPv4 only has ~4.3 billion addresses, exhausted long ago. You can't hand a public IP to every phone, laptop, and TV in the world.

NAT solves both: it lets many devices with private IPs share one (or a few) public IPs to reach the Internet. Your whole household — laptop, phone, TV — reaches the Internet through exactly one public IP, 203.0.113.45, belonging to the router.

How NAT works

The router (sitting between the private LAN and the public Internet) does the address translation. When a packet from inside the home goes out:

   Inside the home (private)        Router/NAT              Internet (public)
   192.168.71.168:51000  ──────►  rewrite source IP  ──────►  203.0.113.45:40000
   (your laptop)                   192.168.71.168 → 203.0.113.45   (what the server sees)

The router replaces the private source IP with its public IP before pushing the packet out to the Internet. The destination server only sees 203.0.113.45 and replies to that address.

But there's a problem: if the laptop and the phone both go out to the Internet, both get rewritten to 203.0.113.45. When the responses come back, how does the router know which packet belongs to whom?

The port is the key: NAPT

The answer is to use the port to tell them apart (this mechanism is fully called NAPT/PAT — Port Address Translation, the most common form of NAT). The router keeps a translation table, recording each connection along with its port:

   The router's NAT table:
   ┌──────────────────────────────────────────────────────────┐
   │ Internal                   ↔  Public (sent to Internet)   │
   │ 192.168.71.168:51000       ↔  203.0.113.45:40000          │
   │ 192.168.71.200:48211       ↔  203.0.113.45:40001          │  (phone)
   └──────────────────────────────────────────────────────────┘

Each outbound connection is assigned its own public port. When a response comes back to 203.0.113.45:40000, the router looks up the table → knows this belongs to 192.168.71.168:51000 → rewrites the destination address back to that machine. Thanks to the port acting as a "label," hundreds of devices share one public IP without getting mixed up. (What a port is, we dig into in Article 6.)

Consequence: incoming connections don't naturally reach in

NAT works smoothly for outbound connections (you actively connect to a server). But it creates a barrier for inbound connections: if someone on the Internet wants to connect to your laptop, all they see is 203.0.113.45 — the router doesn't know which device inside the home to forward it to (the NAT table only has entries for connections you actively opened).

This is actually a layer of accidental protection: machines inside the home aren't directly reachable from the Internet. But when you do want to let something in (say, running a server at home), you have to configure port forwarding on the router: "a packet to 203.0.113.45:8080 goes to 192.168.71.168:80." Only then does the router know the way to bring the connection in.

   Internet ──► 203.0.113.45:8080 ──(port forward)──► 192.168.71.168:80

This is why "exposing a service at home to the Internet" requires opening port forwarding — and why, in the cloud, a server needs a public IP or sits behind a load balancer (Article 11) to receive incoming connections.

SNAT and DNAT

The two directions of translation have their own names (you'll meet them when configuring firewalls — Article 10):

SNAT (Source NAT) — rewrites the source IP. This is the outbound NAT above (laptop → router's public IP).
DNAT (Destination NAT) — rewrites the destination IP. This is port forwarding (a packet to the public IP → forwarded to an internal IP).

CGNAT: NAT on top of NAT

Many ISPs now don't even have enough public IPs for each customer, so they use CGNAT (Carrier-Grade NAT) — another layer of NAT on the ISP side. In that case the "public" IP your home router sees is itself another private IP, and many households share one real public IP. The practical consequence: port forwarding at home may not work (because there's still the ISP's NAT layer above it). This is when people move to IPv6 (which needs no NAT) or use a tunnel service.

NAT in the cloud and in containers

This concept recurs in other series:

Docker (Docker series, Article 7): a container has a private IP on the bridge network, reaching out through the host's NAT — exactly this mechanism. -p 8080:80 is port forwarding (DNAT) into the container.
AWS (AWS series): an instance in a private subnet reaches the Internet through a NAT Gateway; an "Elastic IP" and a load balancer are how you let connections in from outside.

Now you understand why they work the way they do.

Wrap-up

NAT lets many devices with private IPs share one public IP out to the Internet — the router rewrites the private source IP into its public IP and uses the port to tell each connection apart (NAPT). The consequence: outbound connections are seamless, but inbound ones need port forwarding (DNAT). NAT both conserves IPv4 addresses and incidentally protects the internal network. The same mechanism runs in Docker (-p) and the cloud (NAT Gateway).

NAT uses the "port" as a label to distinguish connections — but what is a port really, and how is a connection established? Article 6 digs into the transport layer: TCP, UDP, and ports.