The two previous lessons left a paradox hanging: Marta's PC has the private address 192.168.10.21, Internet routers drop any packet carrying RFC 1918 addresses… and yet Marta browses the web without a hitch. The trick is called NAT (Network Address Translation) and it lives in the Valencia router: it rewrites packet addresses on the way out and on the way back. In this lesson you will see step by step how it does it, what that IP:port translation table making it all possible is, how an internal service gets published with port forwarding, and — very important for your career — what NAT breaks and why. NAT is one of the most pervasive and invisible technologies in today's networks: understanding it will explain dozens of "weird" behaviors you will run into in support, cloud and development.

1. The problem: IPv4 exhaustion and non-routable addresses
2. Source NAT (SNAT/masquerade): the journey of one of Marta's requests
3. PAT / NAT overload: the real-world case of almost every network
4. Types of NAT: static, dynamic and PAT
5. Port forwarding (DNAT): publishing the intranet to the outside
6. What NAT breaks: the price of the patch
7. NAT as a "pseudo-firewall"
8. Operational curiosities: hairpin NAT and double NAT

Let's recap the pieces from the previous lessons:

• IPv4 has ~4.3 billion addresses; they seemed infinite and they weren't. IANA exhausted its free blocks in 2011 and the RIRs followed.
• The 1990s response was twofold: CIDR (assign precisely, without classes) and RFC 1918 (private ranges reusable by everyone).
• But private addresses carry the limitation you already know: they are not routable on the Internet. It is not a technical limitation of the packet format — an IP datagram with source 192.168.10.21 is perfectly valid — but a filtering rule: since millions of networks use the same ranges, a private address does not uniquely identify anyone, and carrier routers drop those packets. Besides, even if your request got out, the reply would not know how to come back: to which of the planet's millions of 192.168.10.21s?

Meridiano has 20 machines in Valencia and its ISP gives it one public IP (we will use the fictional documentation address 203.0.113.50). The math doesn't add up: 20 machines, 1 address valid on the Internet. NAT is the mechanism that makes it add up: all the internal machines share the router's public IP, with the router acting as a middleman rewriting packets.

SNAT (Source NAT) means rewriting the source address of outgoing packets. When the public IP is that of the router's own interface and can change (typical with home and small-business ISPs), the variant is called masquerade: the internal machines go out "disguised" as the router.

Let's follow a complete case: Marta opens a public vendor's website in her browser, www.proveedor-cloud.example, which resolves (DNS, module 2) to 198.51.100.80. Her browser opens a TCP connection to port 443 from a local ephemeral port, say 51612 (ports and sockets: module 2).

Step 1 — The packet leaves Marta's PC:

Destination outside her network (AND with the mask, lesson 05-02) → the packet goes to the gateway 192.168.10.1.

Step 2 — The router translates and takes note. Before forwarding the packet toward the Internet, the router:

1. Replaces the private source IP with its public IP: 192.168.10.21 → 203.0.113.50.
2. Replaces (if needed, and in practice always) the source port with a free one of its own: 51612 → 40001.
3. Records the translation in its NAT table, the key piece of the whole mechanism:

The packet travels across the Internet looking like this — the server never sees the 192.168.10.21:

Step 3 — The reply comes back and the translation is undone. The server replies to the only thing it knows: 203.0.113.50:40001. The router receives the reply, looks up 40001 in its table, finds Marta's row and rewrites the destination: 203.0.113.50:40001 → 192.168.10.21:51612. It delivers the packet on the LAN and Marta's browser receives its reply as if nothing had happened.

Operational details worth knowing:

• Table entries expire: if a connection stops carrying traffic (TCP closed or idle, UDP after a few seconds/minutes), the router deletes the row and reuses the port. That is why very long idle connections "drop through NAT" and protocols use keepalives.
• NAT recalculates the IP and TCP/UDP checksums on every rewrite: the header changes, so the signature must change.
• The vendor's log server will record that "203.0.113.50 made the request": from the outside, all of Meridiano-Valencia is a single address.

What we just described — many private IPs sharing one public IP, told apart by port — has its own name: PAT (Port Address Translation), also called NAT overload or NAPT. It is what your home router does and what Meridiano's does.

The key is the port column. If Ana looks up the same website while Marta is browsing it, the table distinguishes both connections unambiguously:

With ~64,000 usable ports per public IP, a single address supports tens of thousands of simultaneous connections — plenty for Valencia's 20 machines, and the reason IPv4 is still alive two decades after "running out". When the mechanism is applied by the carrier to share one public IP among several customers it is called CGNAT (Carrier-Grade NAT); you will run into it on mobile connections and cheap fiber plans, and it makes every problem in section 6 worse.

When someone says just "NAT" in 2026, they almost always mean PAT. At Meridiano: PAT on the Valencia router (everyone goes out as 203.0.113.50) and PAT on the Bilbao one with its own public IP. Important note: inter-site traffic through the site-to-site VPN is not NATted — inside the tunnel, Marta (192.168.10.21) and Jon (192.168.20.7) see each other with their real private addresses; that is what the VPN is for.

SNAT solves outbound connections. What about inbound ones? Suppose Jon is traveling, without VPN, and wants to check the intranet (https://grupomeridiano.example, served by 192.168.10.10 on port 443, with its GET /api/proyectos API). Someone outside connecting to 203.0.113.50:443 runs into the symmetric problem: the router receives the packet, looks in its NAT table… and there is no row, because nobody inside initiated that connection. With no further information, the router drops it.

The solution is DNAT (Destination NAT), or port forwarding: a static rule the administrator writes by hand on the router:

With that rule, Jon's external request travels like this:

The external port need not match the internal one: you could publish 203.0.113.50:8443 → 192.168.10.10:443.

So why does Meridiano NOT do it? Because publishing a port means opening a door to the entire Internet, not just to Jon: scanning bots would find the service within hours and try credentials and vulnerabilities against the intranet — an internal server never designed to be exposed. Meridiano's policy is the recommended one for this case: internal services are reached through the VPN (the remote employee connects to the VPN and accesses 192.168.10.10 as if they were in the office), and only what is designed, maintained and monitored for public exposure gets published with DNAT. Port forwarding is not bad in itself — it is how any self-hosted service gets published; what is dangerous is using it as a shortcut to expose internal services.

In module 4 we saw TCP/IP's end-to-end philosophy: the network only transports; the intelligence sits at the endpoints, and any host can talk to any host. NAT breaks that symmetry: behind NAT you are no longer a full endpoint of the Internet — you can initiate connections, but not receive them. Concrete consequences:

• Servers at home / on the LAN: invisible from outside without explicit DNAT. "I'll set up a server on my PC and give my IP to a friend" does not work: your 192.168.x.x is useless to them, and your public IP lands on the router, which drops the inbound connection.
• P2P, video calls and online gaming: two users, both behind NAT, cannot connect directly — neither one can receive. The industry built an entire layer of workarounds (STUN, TURN, ICE, hole punching, relay servers) just to get through NAT. If a video call has ever gone through a "relay" with lag on you, you have paid the NAT tax.
• Loss of end-to-end visibility: the server sees 203.0.113.50 no matter what Valencia's 20 machines do. To the vendor, abuse from an infected machine and Marta's legitimate traffic are the same address: collective bans and captchas. With CGNAT, you share reputation with strangers.
• Protocols that carry IPs inside the data: NAT rewrites headers, not the payload. Module 2's active FTP is the classic example: the client sends inside the data channel the IP the server should connect to — and it sends the private one, which is useless. Routers patch this with "ALGs" (per-protocol inspectors), another piece of complexity that sometimes causes more failures than it fixes.
• Fragility of long-lived connections: if the NAT table entry expires from inactivity, the connection dies silently (typical with idle SSH sessions or websockets).

Hold on to this idea: NAT is not a design principle, it is a brilliant patch over IPv4 exhaustion. It works so well that it became permanent, but its cost in complexity is one of the central motivations for IPv6 (next lesson).

You will have heard "you're protected, you have NAT". There is a real basis to it: since inbound connections with no table entry are dropped, NAT de facto blocks direct access from the Internet to the internal machines. It is a valuable side effect… but it is not a firewall:

• It does not inspect or filter outbound traffic: an infected machine on the corporate VLAN talks to its command-and-control server without NAT saying a word.
• It protects against nothing the victim initiates: phishing, malicious downloads, compromised websites.
• It does not filter inside the LAN: between Marta's PC and Ana's there is no NAT whatsoever.
• Its "exceptions" open easily (UPnP lets applications — and malware — create DNAT rules automatically on many home routers).

The correct posture: NAT plus a firewall with explicit rules (small-business routers integrate both). At Meridiano, the Valencia router does PAT and enforces rules: guest VLAN 20 gets out to the Internet but cannot reach the corporate VLAN or the servers.

Two situations you will see in practice and should be able to name, without going deep:

• Hairpin NAT (NAT loopback): Marta, from inside, opens the public URL 203.0.113.50:443 (or a public DNS name pointing there) instead of the internal one. The packet goes to the router and must "make a hairpin turn": apply DNAT toward 192.168.10.10 and SNAT so the reply comes back through the router. Not every router supports it well — hence the classic "the website works from my phone on 4G but not from the office". The elegant fix is split DNS: have grupomeridiano.example resolve to the internal IP inside the LAN and to the public one outside.
• Double NAT (NAT 444): two chained translations — for example, the ISP's router does NAT and behind it the company's own router does another; or carrier CGNAT + customer NAT. Everything outbound works; port forwarding gets complicated (you would have to open the port at both levels, and on the CGNAT you can't) and the problems from section 6 double up. Quick diagnosis: if the WAN IP your router shows is private or in the 100.64.0.0/10 range (reserved for CGNAT), there is another NAT above you.

• Giving your private IP to someone outside. "Connect to my 192.168.10.21" only makes sense within the same network (or via VPN). To know how the Internet sees you, check a "what is my IP" service: you will see the router's public one.
• Confusing NAT with the VPN. Traffic between Valencia and Bilbao through the VPN tunnel keeps its private IPs end to end; NAT only acts on traffic toward the Internet.
• Opening port forwarding "just to test" and forgetting it. Every DNAT rule is a permanent exposure; document, restrict and review the router's rules.
• Believing NAT replaces the firewall. It blocks unsolicited inbound and nothing more; outbound and lateral traffic need explicit rules.
• Being surprised that "we all go out with the same IP". That is PAT's normal behavior; if an external service bans all of you over one machine's abuse, that is why.
• Tip: when an app "works in one direction but not the other" (a call heard only one way, a server reachable only from outside), think NAT: who initiated the connection? is there a table row for the other direction?
• Tip: in diagnostics, always distinguish three addresses: the machine's private one, the router's public one and the destination's. Writing them down prevents 90% of NAT confusion.

From Valencia, simultaneously: Marta (192.168.10.21) opens a TCP connection to port 443 of 198.51.100.80 from her port 51700, and Ana (192.168.10.22) opens another to the same server and port from her port 51700 (a perfectly possible coincidence). The router's public IP is 203.0.113.50. a) Write out the resulting NAT table (choose plausible external ports). b) A packet arrives from the server with destination 203.0.113.50:40002. Who does the router deliver it to, and with what rewritten destination? c) Why can't the router keep port 51700 for both?

Meridiano wants an external client to consume GET /api/proyectos from the intranet (192.168.10.10:443) during a 2-week project. A technician proposes the DNAT rule 203.0.113.50:8443 → 192.168.10.10:443. a) Write out the source and destination of the client's request packet (client public IP: 198.51.100.7, ephemeral port 50123) before and after the router. b) Give two risks of this solution and one safer alternative consistent with Meridiano's policy.

An employee complains: "from home I can't ping my office PC (192.168.10.30), but from the office PC I can browse the Internet just fine". Explain both behaviors using the NAT table, and state the correct way to reach the office PC from home.

Solution 1

a) The router assigns each connection a different free external port:

b) The router looks up external port 40002 in the table → Ana's row. It rewrites the destination to 192.168.10.22:51700 and delivers it on the LAN to Ana.

c) If both went out as 203.0.113.50:51700 toward the same server and port, the two connections would be indistinguishable on the way back: the tuple (external IP, external port, remote IP, remote port, protocol) must be unique. The external port is precisely the discriminator that lets a single public IP multiplex many internal connections — the essence of PAT.

Solution 2

a)

b) Risks (two of these): (1) the port is exposed to the whole Internet, not just the client: scanners will find it and try attacks against a non-hardened internal server; (2) the entire intranet (not just /api/proyectos) becomes reachable through that port; (3) the classic "temporary rule" nobody removes after the 2 weeks. Alternative consistent with Meridiano: give the client limited VPN access (or publish the API on a specific, isolated server maintained for public exposure, restricting the client's source IPs at the firewall) — never direct DNAT to the internal server.

Solution 3

• Browsing from the office works: PC 192.168.10.30 initiates the connection; the router creates the SNAT entry in its table and the replies find their row on the way back.
• The ping from home fails: the packet reaches the public IP 203.0.113.50 as unsolicited inbound traffic; no NAT table entry says which private IP it corresponds to (and no DNAT rule defines it), so the router drops it. Besides, 192.168.10.30 is private: from home it is not even a reachable address.
• Correct way: connect to Meridiano's VPN from home; inside the tunnel, the employee reaches 192.168.10.30 at its real private address, without exposing anything to the Internet.

You now have the complete picture of the real IPv4 world: RFC 1918 private addresses inside, one shared public IP outside, and in the middle the router doing PAT with its IP:port translation table — creating rows when someone inside initiates a connection, undoing them on the way back, and dropping unsolicited inbound traffic unless a port forwarding rule (DNAT) says otherwise. You know why Meridiano prefers the VPN over publishing its intranet, what NAT breaks (home servers, P2P, module 4's end-to-end visibility) and why its "pseudo-firewall" effect is no substitute for a real firewall.

But don't lose sight of the nature of all this: NAT is a patch — brilliant, ubiquitous, but a patch — over an address space that became too small. The real solution has existed since the 1990s and has been rolling out for decades: a protocol with so many addresses that every device on the planet can once again be a full endpoint of the network, with no translations. That is the next lesson, the last of the module: Introduction to IPv6.