Visual walkthrough — NAT — why, how, types (SNAT, DNAT, PAT)
This page derives the parent's central result — how "one home, one public IP, many devices" actually works — from absolute zero. See 4.3.10 NAT — why, how, types (SNAT, DNAT, PAT) (Hinglish) for the parent overview.
Step 0 — The four labels every packet carries
Let us earn each word before using it:
- An IP address is the street address of a machine, written like
192.168.0.10. It says which computer. - A port is a number from to that says which conversation inside that computer. One computer can have thousands of chats at once (a browser tab, an email app…); the port is the "apartment number" inside the machine.
- src = source = who is speaking. dst = destination = who they speak to.
Look at the figure: the envelope has four slots. NAT is a machine that is allowed to reach in and rewrite some of those slots as the envelope crosses the router. Everything below is just which slots, and how it remembers to undo the change.
Step 1 — The setup: private inside, public outside
WHAT: We place two laptops inside a house. Both have private addresses. The house owns exactly one public IP on its router.
WHY: This is the whole problem in one picture — many private machines, one public identity. If we cannot tell the two laptops apart from outside, replies will go to the wrong laptop.
PICTURE:
- Laptop A =
192.168.0.10 - Laptop B =
192.168.0.11 - Router's public IP =
203.0.113.5 - Web server they both visit =
93.184.216.34, listening on port80(the standard "web" door).
The red boundary is the router. Anything crossing left-to-right gets its labels inspected. That boundary is where all the magic happens.
Step 2 — The naive attempt (IP-only rewrite) and why it breaks
WHAT: First try the simplest idea — rewrite only the source IP, leave everything else alone. This is plain SNAT (Source NAT).
Laptop A sends. Its envelope leaves as:
SNAT rewrites only the src IP to the public one:
WHY it fails: By coincidence Laptop B also chose source port 51000 (apps pick these fairly randomly, so clashes happen). After IP-only rewrite, both envelopes read identically:
PICTURE:
When the server replies, both replies are addressed to 203.0.113.5:51000. The router looks at its notebook and finds two matching rows — it cannot decide which laptop to hand the reply to. The two flows have collided.
Step 3 — The fix: rewrite the port too (PAT is born)
WHAT: Rewrite the source port to a fresh, unused number picked by the router, on top of rewriting the IP. This is PAT (Port Address Translation) — sometimes called "NAT overload."
- Laptop A's flow gets public port
40001. - Laptop B's flow gets public port
40002.
Now the two envelopes leaving the house are:
WHY this works: the router chooses these public ports and guarantees it never hands out the same one twice at the same moment. So even if both laptops used 51000 internally, their outside identities now differ in the bold field. The flows are unique again.
PICTURE:
The orange arrows show the two rewrites happening at the red boundary: private port 51000 → public 40001 for A, and 51000 → 40002 for B. Same private port going in, different public ports coming out.
Step 4 — Writing the notebook (the translation table)
WHAT: To reverse the rewrite later, the router must remember what it did. It stores one row per flow in the translation table (the doorman's notebook).
Each row is a promise: "if a reply arrives addressed to this public identity, translate it back to this private identity."
| Public identity (outside sees) | Private identity (real owner) | Talking to |
|---|---|---|
203.0.113.5:40001 |
192.168.0.10:51000 |
93.184.216.34:80 |
203.0.113.5:40002 |
192.168.0.11:51000 |
93.184.216.34:80 |
WHY the public port is the key: it is the one field guaranteed unique across all live flows, so it can act like a lookup index — no two rows share it.
PICTURE:
The notebook has one row per laptop. Notice the private port column is identical (51000 twice) — that's fine, because we never look up by the private port. We look up by the unique public port.
Step 5 — The reply comes back (reversing the map)
WHAT: The web server answers. It only ever saw 203.0.113.5, so it addresses the reply there. For Laptop A's reply the server swaps source and destination roles:
WHY this is the crucial moment: the router reads the destination port 40001, looks it up in the notebook (Step 4), finds the row pointing to 192.168.0.10:51000, and rewrites the destination back to the real laptop:
PICTURE:
The green arrow is the reverse rewrite: incoming dst = 203.0.113.5:40001 → dst = 192.168.0.10:51000. Follow the same logic and 40002 would route back to Laptop B. Every reply lands in the right room. This is the entire NAT round trip.
Step 6 — Edge & degenerate cases (the reader must never be surprised)
Real networks are messy. Here are the corners the clean example hid.
PICTURE:
The bar chart makes the ceiling concrete: 50 flows sit far below the ~64000 limit — a single public IP is nowhere near full.
The one-picture summary
Everything on one canvas: private tuple in, port-and-IP rewrite out, a notebook row saved, and the green reverse-rewrite bringing the reply home to the correct laptop.
Recall Feynman retelling — say the whole walkthrough in plain words
Two laptops in one house both want the same website. Each envelope carries four labels: who-from, which-door-from, who-to, which-door-to. The house has only one public street address, so if we rewrite only the who-from, and both laptops happen to use the same door number, their envelopes look identical from outside — replies can't be sorted. The fix: the doorman also changes the door number to a fresh unique one (40001, 40002) and writes a note in his book: "reply on door 40001 → hand to laptop A." When the website answers to the house on door 40001, the doorman reads his note and passes it to the right laptop. That book is the translation table; the door number is the port; the whole trick is PAT — many rooms, one street address, sorted by door number. It has limits (~64000 doors, breaks if an address is hidden inside the letter), but for a normal house it just works.
Connections
- IPv4 Addressing & Subnetting — where public/private come from
- RFC 1918 Private Addresses — the reusable inside ranges
- Ports & TCP-UDP Headers — the 16-bit port field PAT depends on
- Port Forwarding & DMZ — Case C, hand-installed DNAT rows
- STUN, TURN & NAT Traversal — Case D fixes
- Firewalls vs NAT — why this hiding is not security