Networking · 30 min read
NAT and Private Networks
How private address spaces and network address translation stretch IPv4 and hide internal topology, at the cost of true end-to-end addressing.
Why this exists
IPv4 addresses ran short relative to the number of devices. Organizations also wanted internal addressing freedom and a blunt perimeter.
Private ranges (RFC 1918) plus Network Address Translation let many hosts share scarce public addresses. The tradeoff is that the internet no longer has a simple globally unique locator for every host.
Understanding NAT is mandatory for debugging home networks, cloud VPCs, carrier-grade sharing, and peer-to-peer applications that must invent reachability on top of a one-way-friendly world.
Axioms & primitives
- 01Private IPv4 ranges are reusable inside sites and are not globally routable.
- 02NAT rewrites addresses (and often ports) at a boundary so outbound traffic can share public IPs.
- 03Return traffic must match a translation entry; unsolicited inbound is blocked by default.
- 04NAT breaks the pure end-to-end model; protocols that embed addresses need helpers.
- 05IPv6 reduces the scarcity motive for NAT, but operational NAT habits persist.
- 06A mapping is soft state with a lifetime; idle flows expire.
Learning objectives
After this lesson you should be able to:
- Explain why 192.168.0.0/16 addresses do not appear as destinations on the public internet.
- Describe what a NAT mapping stores for a typical outbound TCP connection.
- Predict why inbound connections to a NATed host fail without port forwarding or hole punching.
- Name one application-level protocol that historically struggled with NAT and why.
- Contrast home NAT with carrier-grade NAT for inbound services and logging.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Your phone, laptop, and TV all want addresses, but your ISP gave the house one public IPv4 address. The router assigns private addresses inside and translates outbound packets so the internet sees the public address.
Replies come back to the public address and port. The router consults its table, rewrites the destination to the correct private host, and delivers the packet. Without a table entry, inbound packets have nowhere trusted to go.
This is why hosting a server at home feels like a special project, while browsing the web just works: you initiate outbound, and NAT remembers enough to let answers return.
Formal shape
Typical NAPT (network address and port translation) keys a mapping on protocol and ports as well as addresses. Outbound TCP SYN creates a mapping; return segments match it. UDP mappings are similar but often shorter-lived and more implementation-defined.
Hairpinning (NAT loopback), ALGs (application layer gateways), STUN/TURN/ICE for realtime media, and explicit port forwards are all adaptations to the loss of globally reachable locators.
Endpoint-independent versus endpoint-dependent mapping behaviors change how hard hole punching is. Two NATs facing each other can require a relay.
IPv6 unique local addresses and global addresses change the scarcity story, but enterprise middleboxes and legacy dual-stack designs still matter. NPTv6 and firewalls can recreate NAT-like operational patterns.
NAT outbound and return
Click a stage to follow the sticky-note mapping this page describes: outbound create, public path, return rewrite.
Loading diagram...
Select a stage to read the boundary detail.
Worked examples
Hosting a game server at home usually requires port forwarding: a static mapping from public port to private host. Without it, inbound SYN packets hit the router's public IP with no table entry and die.
Video calls often use STUN to discover the public mapping and TURN relays when direct paths fail. The app is reconstructing end-to-end connectivity that NAT removed.
Two companies both using 10.0.0.0/8 who later VPN together must renumber or carefully NAT overlapping spaces. Private reuse becomes a collision when islands merge.
Logging: your public IP in a server log may identify a household or a CGNAT pool, not a person. Abuse reports need timestamps and ports to be actionable under CGNAT.
Edge cases
Carrier-grade NAT (CGNAT) places ISP-level translation in front of customer routers, breaking assumptions in logging, geolocation, and inbound services.
DNS and email authentication can be confused by shared IPs. Some protocols embed IP literals in payloads (older FTP active mode) and need helpers or die.
Relying on NAT alone for security theater invites malware that phones home outbound, which NAT happily allows. Outbound policy and host security still matter.
Symmetric NAT behaviors can make P2P hole punching fail even when both sides 'opened' something. Relays are not failure; they are the fallback tax.
Mental models
Hotel phone system
Rooms dial out through the front desk, which rewrites the caller ID to the hotel's number and remembers which room placed which call so replies can be delivered back.
Many-to-one mailbox
Many apartments share one street address. The postal clerk (NAT) needs apartment numbers (ports) to sort return mail.
One-way mirror
Easy to initiate outward; hard for strangers to initiate inward unless you create an explicit mapping.
Sticky note on the router
Each outbound flow puts a sticky note: 'public port 40122 belongs to 192.168.1.10:52344 for a while.'
Common misconceptions
Myth
NAT is a firewall, so it makes you secure.
Reality
NAT happens to block unsolicited inbound by needing mappings, but it is not a substitute for a real security policy, patching, or authentication.
Myth
Private IPs are secret and unguessable.
Reality
They are well-known ranges. Secrecy of topology is limited; security must not rely on obscure addressing.
Myth
Carrier-grade NAT is just like your home router.
Reality
CGNAT adds another translation layer shared across customers, making inbound services and troubleshooting harder.
Myth
IPv6 means NAT disappears everywhere.
Reality
Scarcity pressure drops, but enterprises still deploy middleboxes for policy. Do not assume a clean end-to-end IPv6 world.
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
A host 192.168.1.10 opens TCP to 203.0.113.50:443. The router's public IP is 198.51.100.8. What must the NAT remember so responses return correctly?
What good looks like
Mapping of public IP/port to internal 192.168.1.10 and its ephemeral port for that flow; protocol TCP.
Exercise 02
Why does "allow inbound from anywhere to my laptop" usually fail on a home network even if the laptop firewall is off?
What good looks like
No public mapping; unsolicited inbound has no NAT entry unless forwarded. Laptop firewall is a second gate, not the first.
Exercise 03
Your ISP uses CGNAT. You set a port forward on your home router to a NAS. Why might the internet still be unable to connect?
What good looks like
Port forward only maps home WAN IP; CGNAT WAN is not uniquely yours; need ISP mapping, IPv6, tunnel, or relay.
Sources & further reading
External references. Prefer primary documents and clear explainers.
Uncertainty notes
- Exact NAT binding lifetimes and hairpin behaviors vary by vendor; treat them as implementation-defined.
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
Defines the private IPv4 ranges. Use it when you need the exact reserved blocks and rationale.
Classic NAPT behavior and mapping. Read it when debugging why inbound connections fail behind a router.
- Practical Networking: NATDeep dive
Diagram-heavy explanation of address translation in home and enterprise networks. Use it after the RFCs feel dense.