NAT (Network Address Translation)

NAT is the quiet mechanism that lets every home network, office, and container cluster share a single public IP among many private-IP devices. It's essential context for understanding why services in a Kubernetes cluster or a Docker Compose network can talk to each other by private IP but need explicit port mapping to be reachable from outside.

What Is NAT?

NAT (Network Address Translation) is what lets many devices on a private network share one public internet address. Every phone, laptop, and smart TV in your house has its own private address, but your internet provider only gave your router one public address — so the router swaps each device's private address for its own public one whenever traffic leaves the house, and swaps it back on the way in.

Where This Is Used

• Your home Wi-Fi router does this for every device connected to it, all sharing one public IP from your ISP.
• Offices and coffee shops run dozens or hundreds of laptops through NAT on a single internet connection.
• Cloud providers like AWS use NAT gateways so private servers can reach the internet to download updates without being directly exposed to it.
• Mobile carriers NAT huge numbers of phones behind a small pool of public IPs to conserve address space.

A Day-to-Day Example

Think of a hotel's front desk and its single published phone number. Guests in every room can call out, and the front desk keeps a log of which room made which call so it can route the return call back to the right extension — but the outside world only ever sees one phone number for the whole building, never the individual room extensions.

Deep Dive: The Translation Table — How Return Traffic Finds Its Way Back

Phone:  192.168.1.10:52000  ──┐
                                │   Router rewrites source to its
                                ▼   own public IP + a new port
                          [ NAT Router ]  49.x.x.x:61000  ──► internet server

NAT translation table (kept in router memory):
Internal (private)         External (public)         Protocol
192.168.1.10:52000    ↔    49.x.x.x:61000             TCP
192.168.1.12:52001    ↔    49.x.x.x:61001             TCP
192.168.1.10:52002    ↔    49.x.x.x:61002             UDP

Response arrives at 49.x.x.x:61000 -> router looks up table ->
rewrites destination back to 192.168.1.10:52000 -> forwards inward.

This is Port Address Translation (PAT), sometimes called "NAT overload" — the mechanism virtually every home router and cloud NAT gateway actually uses, because a single public IP has 65,536 ports, which is enough to multiplex thousands of simultaneous private connections behind it by giving each one a distinct external port.

Deep Dive: NAT Types and Why They Matter for P2P/Real-Time Traffic

Full Cone           any external host can send back to the mapped port
Restricted Cone      only hosts the internal client already contacted can reply
Port-Restricted Cone same as above, but must match the exact source port too
Symmetric NAT        a NEW external port is assigned for EVERY distinct destination
                      -> hardest to traverse, breaks naive peer-to-peer connect attempts

This matters concretely for anything doing peer-to-peer connectivity — WebRTC video calls, gaming, VoIP. Behind Symmetric NAT, the external port a peer sees depends on who they are, so a third party (like a STUN server) can't hand out one address that works for everyone; you often need a TURN relay to actually get traffic through. This is why WebRTC architecture always includes a STUN/TURN fallback story, not just a direct connection attempt.

Key Pointers

• NAT rewrites the source (or destination) IP address — and usually the port — in packet headers as traffic crosses a router or gateway boundary.
• The most common form, PAT (Port Address Translation, aka NAT overload), maps many private IP:port pairs to one public IP by using different public ports for each internal connection.
• The NAT device maintains a translation table mapping each outbound connection's private IP:port to a public IP:port, so return traffic can be routed back correctly.
• NAT types matter for peer-to-peer and real-time traffic: Full Cone, Restricted Cone, Port-Restricted Cone, and Symmetric NAT differ in how permissive they are about which external hosts can send traffic back in — Symmetric NAT is the hardest to traverse and often requires TURN relays.
• In cloud/container networking, a NAT gateway lets private-subnet instances reach the internet for outbound calls (e.g. pulling packages) without being directly reachable from it.
• NAT is not a firewall — it's an address-translation mechanism that happens to make unsolicited inbound connections harder because there's no matching table entry, not because it enforces any access policy.

How It Works

1. A device on a private network (e.g. 10.0.1.5) initiates an outbound connection to a public server.
2. The NAT router rewrites the packet's source IP to its own public IP and assigns a unique source port, recording the mapping in its translation table.
3. The public server responds to the NAT router's public IP and port, having no visibility into the original private address.
4. The NAT router looks up the translation table, rewrites the destination back to the original private IP:port, and forwards the packet inward.
5. Entries expire after a period of inactivity, freeing up the port for reuse.

Try It Yourself

# Confirm your machine's private IP differs from its public IP (proof NAT is active):
ifconfig | grep "inet "        # your private LAN IP, e.g. 192.168.1.20
curl ifconfig.me               # the public IP the internet sees, e.g. 49.x.x.x

# Inspect your router's active NAT/port-forwarding table (varies by router):
# open http://192.168.1.1 (or your router's gateway IP) in a browser
# -> look for "NAT", "Port Forwarding", or "Connection Table" in admin UI

# See your default gateway (the NAT device your traffic goes through):
ip route                       # Linux — look for "default via ..."
netstat -rn | grep default     # macOS

# Watch NAT in action live (source port changes as connections are made):
sudo tcpdump -i any -nn tcp and host example.com

Interview Q&A

Q: Why can two services in the same private subnet reach each other directly, but a request from the internet needs a load balancer or NAT gateway with explicit port mapping?

A: Within the same private subnet, both hosts have routable private IPs relative to each other — no translation is needed, traffic flows directly. But the internet has no route to a private IP at all (RFC 1918 ranges are non-routable globally), so inbound traffic must land on something with a public IP — a load balancer or a NAT gateway/instance — which then explicitly forwards to the right private IP:port. It's entirely about routability and translation state, not permission.

Q: Is NAT a security boundary?

A: Not by design, even though it has a side effect that looks like one. Because NAT only creates translation table entries for connections initiated from inside, unsolicited inbound traffic typically has no matching entry and gets dropped — but that's an artifact of how the table works, not an access-control policy. Real security still requires firewalls, security groups, network ACLs, and application-level authentication; treating NAT as your security boundary is a common and dangerous shortcut.

Q: Can two private machines on different networks use the same private IP address?

A: Yes. Private IPs only need to be unique within their own private network/routing context. Your home router's 192.168.1.10 and your office's 192.168.1.10 can coexist with zero conflict because NAT means neither address is ever directly exposed to or routed by the other network.

System Design Tie-in

In a "design a scalable web service on cloud infrastructure" interview, NAT gateways are the concrete answer to "how do private-subnet app servers pull dependencies or call third-party APIs without being directly internet-reachable?" You'd place a NAT gateway in the public subnet, route the private subnet's outbound traffic through it, and note the operational trade-off: NAT gateways have connection and bandwidth limits, so a fleet of instances all funneling third-party API calls through one NAT gateway can hit port exhaustion — motivating multiple NAT gateways (one per AZ) rather than a single shared one.

Trade-offs

NAT conserves public IPv4 address space and adds a layer of implicit protection since unsolicited inbound connections have no matching table entry — but it's not a substitute for a firewall and complicates protocols that embed IP addresses in their payload (like older FTP or SIP), which need application-layer gateways to work through NAT. It also breaks true end-to-end connectivity, which is part of why IPv6 (with its abundant address space) was designed to make NAT unnecessary. A frequent interview question: "why can two services in the same private subnet reach each other directly, but a request from the internet needs a load balancer or NAT gateway with explicit port mapping?" — the answer is entirely about NAT and routing table asymmetry.