Introduction

NAT started as a practical response to IPv4 address exhaustion and became so common that many engineers now think of it as part of the internet itself.

It isn't.

NAT changes addressing information as traffic crosses a device. Sometimes it changes ports too. That simple statement explains most of the technology.

Types of NAT

Static NAT maps one private address to one public address.

Dynamic NAT maps addresses from one pool to another.

PAT, often called NAT overload, lets many internal hosts share one public address by translating source ports.

PAT is why hundreds of devices in your office can appear to the internet as one public IPv4 address.

NAT is not a firewall

This needs to be repeated because the misconception refuses to die.

NAT is not a security control.

A firewall can use stateful inspection and explicit policy to decide what traffic is allowed. NAT simply changes addresses and sometimes ports.

The two are often implemented on the same device, which is probably why the confusion survives.

Port forwarding

Port forwarding is destination NAT.

A public connection arrives at an external address and port. The device translates that destination to an internal server.

It sounds simple until you add asymmetric routing, firewall policy, hairpin NAT, multiple public addresses and overlapping services.

Then somebody asks why the application works from the internet but not from the internal LAN.

Hairpin NAT

Hairpin or NAT loopback allows an internal client to reach an internal service using its public address.

Without it, internal DNS may resolve a public address that sends the client toward the firewall, while the firewall does not know how to send the connection back to the internal server correctly.

Split DNS is often cleaner than relying on hairpin NAT.

Troubleshooting NAT

Follow the packet.

Determine the original source and destination. Then determine what the NAT device translates them into. Verify the firewall policy and routing. Finally verify the return path.

Useful commands depend on the platform, but you generally want:

  • • NAT translation table
  • • Connection/session table
  • • Routing table
  • • Firewall policy hit counts
  • • Packet capture

If the translation exists but the session never establishes, NAT may not be the actual problem.

What actually matters

NAT is often blamed because it sits in the middle of everything.

Do not guess.

Compare the packet before and after translation. If you can see exactly what changed, NAT becomes boring. Boring is good.