In this post I explain the different types of NAT and why you need to use them. With the shortages of IPv4 addresses and the yet-to-arrive nirvana of IPv6 we’re still using NAT to maintain network connectivity, and network engineers everywhere need to know how and when to use NAT.
Introduction: Let’s Talk NAT Like We’re Two People Chatting Over Coffee
Imagine you’re hanging out in a café, and you’re the router, sipping your flat white. Then along come a bunch of devices—computers, phones, tablets—each trying to talk to the outside world. But you’ve only got one public IP address. You need some magic to let them all chat without stepping on each other’s toes. That’s where NAT comes in. NAT stands for Network Address Translation. It’s a middleman that’s configured on routers or firewalls which changes IP addresses as traffic passes through.
Now, there’s not just one flavour of NAT. There are multiple kinds—source NAT, destination NAT, static NAT… and shadily‐named versions like NAT44 and NAT66. There’s even this trickster called NAT-PT (Protocol Translation) that bridges the chasm between IPv4 and IPv6, like NAT46, NAT64, and NAT464. It’s a lot, but stick with me. I’ll break it down in plain English, share why each exists, and hopefully make you go, “Oh, that’s quite cool”
Source NAT (SNAT): Outbound Transformations
The idea:
Source NAT is what happens when you’re inside a private network (usually behind a private IP pool like 192.168.x.x or 10.0.x.x), and you want to talk to the internet. But your IP is like “Oops, you’re not publicly reachable.” Source NAT swoops in and says, “Let me swap that internal IP—replace it with a public-facing one that’s valid—and forward the packet along.” On the return journey, the NAT device reverses the swap so it lands at the correct internal host.
Casual analogy: you’re going to a party wearing a costume. Everyone at the door only recognizes the costume, not who’s underneath. When you get in, you’re labelled “Guest A.” When you leave, the bouncer sees “Guest A,” flips back to “Carol Under the Costume,” and lets you out again.
Uses:
- Letting multiple internal devices share a single public IP.
- Simplifying outbound traffic policy.
- Sometimes used to rewrite source ports (called port-address translation, or PAT) when you need many sessions.
Destination NAT (DNAT): The Incoming Traffic Wrangler
The idea:
Now reverse that. Suppose people on the internet need to hit a server inside your private network—like a web server at 192.168.1.10. But that address is private and unreachable from the outside. Enter destination NAT: it takes packets destined for your public IP (and maybe a certain port, like port 80), and says, “Let me change that destination to the internal server.” Boom—your traffic flows to the right place.
Then the server replies, and NAT makes sure the returning traffic finds its way back out—and sometimes flips symbols (source/destination) accordingly. Novel analogy: traffic reaching your moat’s gate addresses it to “Castle Public Gate,” then the guard sees “Ah, this is for the wizard in tower room 10,” and redirects inside quietly.
Uses:
- Hosting internal servers behind NAT.
- Load-balancing: sending incoming traffic to multiple internal servers.
- Concealing internal IP scheme from the outside world.
Static NAT: One-to-One Mappings
The idea:
Static NAT is the more rigid form of NAT. Instead of dynamic changes, it sets a fixed, unchanging mapping between internal and external IPs. For example: internal host 10.0.0.2 always gets mapped to external IP 198.51.100.2 whether the connection is going in or out — no surprises.
Think of it like having a pen-pal alias: you send letters from “Sir Lance-A-Lot” and always get replies to that same alias. Inside, you’re still the same person, but publicly you always look like “Sir Lance.” And people can reach you consistently at that name.
Uses:
- Ensuring specific internal hosts are reachable at fixed public addresses (e.g. internal mail server, FTP server).
- Easier firewall configuration because the mapping doesn’t change.
- Useful when IPv4 public addresses are assigned in a block and you want predictable addressing.
NAT44 vs NAT66: IPv4-to-IPv4 vs IPv6-to-IPv6
Here’s where naming gets pretty technical — but let’s clarify:
- NAT44: Traditional NAT, mapping IPv4 addresses to IPv4 addresses. This includes static NAT, source NAT, destination NAT, PAT, etc. It’s basically the NAT we’ve been doing for ages.
- NAT66: Same idea, but operating in the IPv6 world—IPv6 in, IPv6 out. Why would you even do NAT in IPv6? After all, IPv6 was designed with tons of addresses and end-to-end reachability in mind. True, but there are still use cases:
- Privacy: hiding internal IPv6 scheme.
- Renumbering: keeping internal addresses stable when external prefix changes.
- Specific policies or address reuse.
Use cases and contrast:
IPv6 with NAT66 is controversial. Purists hate it because it’s violating the design philosophy of IPv6 (thou shalt avoid NAT). But in the real world, duplicates exist. So NAT66 might translate a host’s private IPv6 address (like fd00::5) to a global-routable prefix (like 2001:db8::5) when it goes out. If you need IPv6 privacy, flexibility, or legacy policy compatibility, NAT66 may still land in your toolbelt.
NAT-PT and the IPv4/IPv6 Translation Family: NAT46, NAT64, NAT464
As IPv6 started to roll out, people cried, “But the IPv4 Internet is still here!” So we needed ways for IPv6-only clients to talk to IPv4 servers, and vice versa. That spawned NAT-PT (Protocol Translation)—somewhat of a misnomer, because these days we talk about NAT46, NAT64, NAT464:
NAT46
- “IPv4-in → IPv6-out.” (NAT between IPv4 client and IPv6 server.)
- But… not used much in the wild. Why? Hard to stomach because IPv4 client expects IPv4 replies; massively ugly.
NAT64 (the biggie)
- The most widely used pattern: IPv6 client → IPv4 server.
- IPv6 client wants to reach an IPv4-only server—e.g. website, API. The NAT64 translates the IPv6 request into something IPv4‐native, replaces addresses, and talks on IPv4. When the IPv4 server responds, translation happens again, and the IPv6 client gets what it wants.
Its cousin, DNS64, works in sync: when the IPv6 client tries to resolve an IPv4-only domain, DNS64 synthesizes an AAAA record that points to a special prefix handled by NAT64, so the connection flows through.
NAT464
- Sets up a path for IPv4 client → NAT64 → IPv6 server. It’s like two steps: IPv4 to IPv6, then back to IPv4? Actually, NAT464 provides a mechanism where a customer site has IPv4 internal clients, but the Internet path is IPv6. So the IPv4 client goes out through a NAT464 device, which encapsulates or translates traffic through IPv6 networks to reach IPv4 servers or to reach a NAT64 that further translates. It’s used in some large ISPs who’ve gone mostly IPv6 in infrastructure but still have IPv4 clients.
Why NAT-PT? Isn’t “translation” a dirty word?
It was, but practical realities forced adaptation. NAT64 is particularly common in mobile networks and IPv6 transition strategies. Without it, you’d have IPv6 clients banging on IPv4 walls with no way through. Translation stuffed addresses and OSI layers into the seam—it’s not pretty, but it works.
Legacy Cone-NAT Techniques: The Old-School NAT
Now let’s cruise into legacy territory. Cone-NAT is a technique mostly seen on home routers, and it comes in different varieties: Full Cone, Restricted Cone, Port-Restricted Cone, Symmetric NAT. These aren’t often spoken of nowadays in enterprise circles, but they matter—especially when you’re gaming, doing peer-to-peer stuff on your home Wi-Fi router, or trying to get old versions of FTP working.
Full Cone NAT
- “Full open door.” Once an internal host sends outbound, the NAT picks a public port and publishes it. Any external host can then send back to that public IP and port, and the NAT blindly passes it in. No questions asked.
Restricted Cone NAT
- Slightly more selective. The NAT still does the public port mapping. External hosts are restricted a bit: only IPs that the internal host has previously contacted can reach in—that’s the IP-based restriction.
Port-Restricted Cone NAT
- Even tighter: only IPs and ports that the internal host has asked out to can reply. So if internal 192.168.1.5:1234 contacted 203.0.113.5:80, only traffic from 203.0.113.5:80 can reply—even if someone else grabs 203.0.113.5:80 later.
Symmetric NAT
- The strictest of the bunch—and a pain for peer-to-peer. Each outbound flow—defined by internal IP:port plus external IP:port—gets its own public IP:port mapping. If the same internal host later talks to a different external host, even on the same port, the NAT assigns a completely different external port. Replies only work if they come back on the exact external host/port combo. It blocks inbound flows purely from outside without that exact footprint.
Cone NATs (especially full and restricted ones) were easier on P2P like file-sharing or VoIP. Symmetric NAT can break things—requiring STUN/TURN/ICE dance routines. Most consumer devices now include NAT traversal helpers for this.
Deep Dive and Colourful Asides
Let’s zoom in for some casual talk—because a blog post without a few interesting asides.
Source NAT, but make it PAT
When you configure NAT at home, often your router uses PAT—Port Address Translation. That’s where multiple internal devices all share not just the public IP, but specific ports, too. For example:
- 192.168.1.2:80 → 198.51.100.1:32768
- 192.168.1.3:80 → 198.51.100.1:32769
One IP, different source ports, each magically mapped to the right internal host. If you look at your cable modem’s “connected devices,” you see “16.0.28.x” or whatever assigned port, but behind the scenes, NAT is juggling these to send data to the correct internal host.
Destination NAT for Load Balancing
A nifty trick: make a public IP or FQDN like www.example.com point to a virtual IP. Behind that, you’ve got three web servers: web1, web2, web3. DNAT lets the router or load-balancer rewrite the incoming address and send it to different servers based on round-robin or least-connections. The outside world sees only one IP, but you’re distributing traffic. It’s like a restaurant waiter telling each guest to sit at one of three tables without the guest realising there are three tables.
F5 load balancers, as well as other manufacturers, are the grand masters at using Destination NAT for load balancing.
Static NAT: Fixing That Server Address
Suppose you’re running an internal file server at 10.0.0.25, and you want your remote users or partners to connect to it using a stable address. You configure static NAT so that 198.51.100.25 always maps to 10.0.0.25. That way, your partner can bookmark that public IP or DNS name, and it reliably points to your internal server—even if you later shift your internal address scheme. The firewall sees the same consistent external IP; easier for rules and logs.
NAT44 vs NAT66, Let’s Talk Context
- NAT44 is everywhere—your home router, hotel Wi-Fi, corporate firewalls. It’s the original NAT.
- NAT66 is rare, but sometimes useful:
- Renumbering scenarios: Instead of rewriting all your internal devices’ IPv6 addresses when your ISP changes your /64 or /48, you can keep internal addresses stable and just NAT66 to the new prefix.
- Simplified firewalling: You create ACLs against NAT66 external addresses instead of chasing dynamic ULAs inside.
- Privacy: Prevent internal global-range IPv6 addresses from being visible outside.
That said, IPv6 fans often hate NAT66. They’d rather you use privacy extensions or Unique Local Addresses (ULAs) with routing instead. But life isn’t purely theoretical—sometimes NAT66 is convenience over purity.
NAT64: The Bridge Between Eras
Think about your smartphone on an IPv6-only mobile network. You tap a link to an IPv4-only website. NAT64 tells the phone, “Relax—I’ve translated that IPv6 request into IPv4. DNS64 even tricks you into thinking the IPv4 site has an IPv6 address!” It suppresses the complexity of dealing with an IPv4-only web. The phone connects to a “synthesized” IPv6 AAAA record, but the NAT64 handles the translation seamlessly.
- IPv6 client asks DNS for “example-v4-only.com” → DNS64 gives AAAA record like
64:ff9b::192.0.2.33→ the client sends to that IPv6 address → NAT64 sees the prefix64:ff9b::and knows, “oh hey, that ends in 192.0.2.33, that’s IPv4 192.0.2.33.” NAT64 sends an IPv4 request to 192.0.2.33, gets response, translates back, hands it to client. Magic!
NAT464: IPv4 inside IPv6 Infrastructure
Let’s think of a big ISP that’s gone mostly IPv6 in its core. But its customers still have IPv4-only devices. They create NAT464 gateways. The IPv4 client sends to NAT464, which either encapsulates or translates into IPv6 to traverse the provider’s backbone, then maybe hits another NAT that translates to IPv4 destination—or maybe the destination is IPv6, too. It’s a bit heavyweight, but operationally useful until full IPv6 maturity arrives.
Cone NATs: The Old-School NAT That Built the Internet’s Gaming Soul
During the OTT (over-the-top) explosion—games, P2P video, VoIP—cone NATs were kind to us because they didn’t object to inbound replies.
- Full cone NAT let any stranger from the internet hit your forwarded port once you’d initiated traffic. Super easy.
- Restricted/Port-Restricted tightened it by allowing only hosts you’d contacted in the first place.
- Symmetric NAT? That’s the bully. Every outbound flow gets its own ephemeral port, and only that same endpoint can talk back. It’s designed to prevent inbound unsolicited traffic. Useful for security, but a P2P nightmare.
These days, when you hop into a Zoom call or fire up a multiplayer game, your device runs STUN/TURN/ICE to figure out NAT behavior and traverse it—especially if you’re behind symmetric NAT. Nowadays, Eero, Google Wi-Fi, etc., handle this NAT traversal stealthily via UPnP or NAT-PMP for local forwarding. Legacy cone NAT feels like the analog dial-up era compared to modern zero-touch auto-traversal, but it paved the way.
Cone NAT in the enterprise may still be seen when there’s protocols like FTP around – classic active FTP requires extra helpers to make the reverse data connection for file transfers. Fortunately, passive FTP was invented to avoid this. You should never see active FTP in the wild much anymore, everyone has moved on.
Summary
| NAT Type/Technique | What it Does (In a Nutshell) | When You See It |
|---|---|---|
| Source NAT (SNAT) | Rewrites internal IP/port to public IP/port for outgoing packets | Home router, outbound internet access |
| Destination NAT (DNAT) | Forwards public IP/port inbound to specific internal host/port | Hosting internal servers, port forwarding |
| Static NAT | Fixed 1-to-1 IP mappings from external to internal | Stable remote access or published services |
| NAT44 | Classic IPv4 ↔ IPv4 NAT | Ubiquitous today |
| NAT66 | IPv6 ↔ IPv6 NAT | Rare, renumbering/privacy scenarios |
| NAT46 / NAT64 / NAT464 | Protocol translation between IPv4 and IPv6 (various directions) | Transition, IPv6-only clients accessing IPv4 servers |
| Cone NAT (Full, Restricted, Port-Restricted) | Permissive inbound mapping once flow initiated | Legacy home routers, P2P-friendly NAT, legacy FTP |
| Symmetric NAT | Different mapping per destination, strict inbound rules | P2P/Kicking-off-connection nightmares |
Security? – Yes, No, Maybe
There is always some debate in CyberSecurity fields about whether or not NAT is a security feature. In particular, source-NAT which hides the real source IP of a device behind the public IP address on the router. It’s not specifically a security feature, but sure – it helps to obfuscate the real IP of a device.
In addition, source-NAT makes it difficult for an outside entity to connect to an inside device – which improves security for sure. And any improvement is a benefit, so lets’s just leave the argument there.
Final Thoughts: Why You Should Care About NAT
NAT might sound dry—real network nerd stuff—but it’s everywhere. It connects networks together, saves scarce IPv4 addresses, enables internal networks to talk externally, and still silently often gets in people’s way (hello, gaming lag and awkward Zoom calls).
Understanding NAT types helps troubleshoot:
- Why can’t my friend connect to my game server? (Private IP + no DNAT.)
- Why can’t my P2P app connect to that peer? (Symmetric NAT + no relay.)
- Why does only one device get past the firewall? (Static NAT hogging mapped IP.)
- Why can my IPv6 phone access IPv4-only sites? (NAT64 doing the heavy lifting.)
The IPv4→IPv6 handshake zone—where NAT-PT, NAT64, NAT464 live—is particularly interesting, because it feels like networking triage. IPv6 advocates might roll their eyes, but NAT64 literally keeps a vast IPv6-only mobile ecosystem compatible with an IPv4-filled world. Until IPv4 fades away (if it ever does), these translation technologies—and yes, even NAT66 or cone NAT—will keep silently powering much of our internet glue.
So next time you hear “NAT”, you can smile knowingly and say, “Ah yes—the many faces of my network’s secret identity manager.”
