SMIP
All articles
networkingadvancedipv4

How does NAT actually work? Network Address Translation in detail

NAT is the trick that lets dozens of devices in your home share a single public IP address. Here's exactly what NAT does to packets, the different NAT types, and why it caused decades of headaches for peer-to-peer apps.

May 6, 20266 min read

NAT — Network Address Translation — is one of the most quietly important pieces of internet infrastructure ever invented. It's the reason your laptop, phone, smart TV, printer, and twelve other devices all share one public IP address. It's the reason the IPv4 internet didn't run out of space in 2005. It's also the reason peer-to-peer applications spent two decades figuring out workarounds.

If you've read our public vs private IP post or our CGNAT post, this is the deep dive on what's actually happening inside the box.

The two-line summary

NAT rewrites the source IP and port on outgoing packets, then reverses the rewrite on incoming reply packets. This lets many devices share one public IP for outbound traffic.

Inbound unsolicited traffic doesn't work — there's no mapping yet — which is both NAT's main feature (free firewall) and its main problem (peer-to-peer is hard).

What NAT does, packet by packet

Imagine your laptop (192.168.1.50) wants to load 203.0.113.10:443 (HTTPS).

Your laptop opens a TCP connection. It picks a random ephemeral source port (say, 52341) and sends:

SRC: 192.168.1.50:52341
DST: 203.0.113.10:443

This packet goes to your router. The router's NAT engine notices it's destined for the internet, not the LAN. It does three things:

  1. Picks a NAT public port (say, 41234) for this connection.
  2. Records the mapping in its NAT table: 
    external 41234 ↔ internal 192.168.1.50:52341 to 203.0.113.10:443
  3. Rewrites the packet before forwarding: 
    SRC: 198.51.100.25:41234   ← your router's public IP and chosen port
DST: 203.0.113.10:443

The packet leaves your router and reaches the destination. The destination sees a request from 198.51.100.25:41234, doesn't know about your laptop, and replies:

SRC: 203.0.113.10:443
DST: 198.51.100.25:41234

Reply comes back to your router. The NAT engine looks up port 41234 in its table, finds the mapping, and rewrites:

SRC: 203.0.113.10:443
DST: 192.168.1.50:52341

Your laptop receives the reply with addresses that match the connection it opened. From the laptop's perspective, nothing weird happened.

When the connection closes (TCP FIN, or after a UDP idle timeout), the NAT entry is deleted and port 41234 becomes available again.

NAT table: the heart of the box

The NAT engine maintains a table of every active connection. For typical home routers it holds 5,000–50,000 entries. Modern carriers operating CGNAT track millions.

Each entry has:

  • Internal IP and port
  • External IP and port (the router's public side)
  • Protocol (TCP, UDP, ICMP)
  • Destination IP and port
  • Idle timeout

When the table fills up, new connections fail. This is why some routers misbehave on networks with many devices — the table fills, connections drop, restart fixes it.

What NAT can't easily do

The trick of "rewrite source on outbound, reverse on inbound" works for client-initiated connections. For other patterns, NAT has limitations:

Inbound unsolicited connections

If someone tries to connect to 198.51.100.25:80 from outside, your router's NAT table has no entry. The router doesn't know which internal device should receive the packet. It drops it.

This is actually a security feature (free firewall — random internet traffic can't reach your internal devices) but a problem for hosting services or peer-to-peer apps that need inbound connections.

Solution: port forwarding. Manually configure the router to send "anything arriving on port 80 → internal IP 192.168.1.100 port 80." Now there's a static NAT mapping that doesn't depend on outbound state.

Peer-to-peer

If two NAT-ed devices want to talk directly, neither can initiate a connection to the other (both would arrive at the other's NAT with no entry). For decades, P2P apps relied on:

  • STUN servers — public servers that tell each peer what its public IP/port looks like to the world.
  • TURN servers — relays that both peers can reach outbound, used as fallback when direct connection fails.
  • Hole punching — both peers send outbound packets to each other simultaneously, hoping NAT entries land such that the inbound traffic matches.

This is the technology behind WebRTC, video calls, online gaming, and BitTorrent. It mostly works. Modern protocols have made it almost transparent.

Protocols that embed IPs in payloads

Some old protocols (FTP, SIP, some VoIP) include the client's IP inside the application data. NAT rewrites the headers but doesn't know to rewrite the payload. Connections break.

Solution: "ALG" (Application Layer Gateway) — special NAT logic for these specific protocols. Most home routers include ALGs for FTP and SIP. They sometimes cause more problems than they solve.

Types of NAT

The IETF defined NAT behaviors that determine how easily peer-to-peer connections work through them. From most permissive to most restrictive:

Full Cone NAT

Once an internal address 192.168.1.50:52341 has an external mapping 41234, anyone can send packets to external:41234 and they'll reach 192.168.1.50:52341. Easy for P2P.

Restricted Cone NAT

Same as full cone, but only the destination that the internal address contacted can send back. So if 192.168.1.50 talked to 8.8.8.8, only 8.8.8.8 can send back through the mapping.

Port-Restricted Cone NAT

Even more restrictive: only the same destination IP and port that was contacted can reply.

Symmetric NAT

The strictest: each new destination gets a different external port. So 192.168.1.50 talking to 8.8.8.8:53 and 1.1.1.1:53 shows up as two different external ports. P2P hole-punching is much harder because the external port isn't predictable.

Modern home routers are mostly Port-Restricted or Symmetric. Modern P2P protocols handle most NAT types via fallback to STUN/TURN.

NAT and IPv6

IPv6 was designed to eliminate NAT for end users. Every device gets a globally unique address. No address translation needed.

Reality is slightly more complex. IPv6 networks generally don't use NAT, but they do use firewalls. A typical home IPv6 router still drops unsolicited inbound by default — same security as IPv4 NAT — but without the address translation. Cleaner, simpler, but the practical effect for users is similar: outbound works, inbound requires configuration.

This means migrating to IPv6 doesn't automatically make peer-to-peer easy. The firewall still drops unsolicited traffic. Hole-punching is still required for true peer-to-peer.

CGNAT — the bigger NAT

When ISPs ran out of IPv4, they extended NAT to the carrier level. Customer routers connect not to a public IP but to a CGNAT pool address (typically 100.64.0.0/10). Multiple subscribers' traffic is then NATed to a smaller pool of public IPs at the carrier's edge.

This is double NAT — your devices behind your router's NAT, your router behind the carrier's NAT. It works for most things; breaks port forwarding entirely; complicates peer-to-peer further.

See our CGNAT post for the full picture and workarounds (Cloudflare Tunnel, IPv6, ISP-provided public IP).

Quick FAQ

Does NAT slow down my connection? For typical home use, no — modern routers do NAT in hardware or optimized software, with negligible latency. Could be a bottleneck on very high-bandwidth links with weak routers.

Is NAT a firewall? Effectively, yes — for inbound. NAT drops unsolicited inbound traffic because there's no mapping. This is sometimes called the "implicit firewall" of NAT and is the reason home networks are reasonably safe by default.

Why does my game say "moderate NAT" or "strict NAT"? That's roughly the cone vs symmetric distinction above. Strict NAT (symmetric) makes P2P harder; some online games downgrade to relayed connections, increasing latency. Solution: set your router to "open" / UPnP, or manually port-forward the game.

What's UPnP? A protocol that lets applications request port-forwarding rules from the router automatically. Useful for P2P apps; sometimes a security risk because malicious software can also use it.

Will IPv6 eliminate NAT entirely? For end users, mostly. Some networks use NAT for other reasons (privacy, simplification) so it's not gone forever — just much rarer.

TL;DR

  • NAT rewrites source IP and port on outgoing packets, reverses on incoming. Lets many devices share one IP.
  • Inbound unsolicited traffic is dropped — implicit firewall, also a problem for P2P.
  • Different NAT types affect P2P difficulty: cone (easy) → symmetric (hard).
  • IPv6 eliminates NAT but firewalls remain.
  • CGNAT extends NAT to the carrier level when ISPs run out of IPs.

NAT is a giant pile of cleverness that's kept the IPv4 internet alive 30 years past its theoretical capacity. It's also why "just open a connection" is harder than it sounds.