NAT

Why it exists

IPv4 addresses ran short. Private address space lets many networks reuse the same blocks, but those addresses are not unique on the public internet and cannot be routed there without a boundary that rewrites them. RFC 1918Address Allocation for Private InternetsRFC 1918 · BEST CURRENT PRACTICE · February 1996

Traditional NAT — Basic NAT and NAPT — is that boundary. NAPT is what almost everyone deploys: many internal addresses share one external address, distinguished by transport port. RFC 3022 §2.2Overview of NAPTRFC 3022 · INFORMATIONAL · January 2001

NAT64 exists for a different shortage story: IPv6-only clients reaching IPv4-only servers. It is a translator between families, not a rename of IPv4 NAPT. RFC 6146 §1IntroductionRFC 6146 · PROPOSED STANDARD · April 2011

One public address, many private sources

NAPT rewrites the source address and transport port on the way out, records the mapping, and reverses it on the way back.

How it works

On outbound traffic the NAT replaces the internal source address — and for NAPT the source transport port — with an external pair, then stores the binding. Return traffic matches the external destination and is rewritten back. RFC 3022 §2.2Overview of NAPTRFC 3022 · INFORMATIONAL · January 2001

Every rewrite touches checksums. The IPv4 header checksum covers the addresses; TCP and UDP checksums cover a pseudo-header that includes them. Skipping either produces a packet the far end silently drops. RFC 3022 §4.1IP, TCP, UDP and ICMP Header ManipulationsRFC 3022 · INFORMATIONAL · January 2001

Endpoint-independent mapping keeps one external port for an internal source regardless of destination. RFC 4787 requires it because peer-to-peer and UNSAF techniques depend on learning one public binding and reusing it. RFC 4787 §4.1Address and Port MappingRFC 4787 · BEST CURRENT PRACTICE · January 2007

Filtering is separate from mapping. Endpoint-independent filtering accepts inbound packets to a mapped port from any external address; address-dependent filtering only accepts peers the internal host has already contacted. RFC 4787 §5Filtering BehaviorRFC 4787 · BEST CURRENT PRACTICE · January 2007

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Configure it

When it breaks

Symptom first, because that is what you have when it happens.

1. Two internal hosts cannot reach each other by the public name of a service that lives inside the same network.

   Narrow it down

   1. Resolve the name from inside and confirm it returns the public address.
   2. Check whether the NAT device translates a packet whose source and destination are both inside.
   3. Compare with resolving the internal address directly, which will work.

   Cause

   The packet leaves the client toward the public address, reaches the NAT device, and would have to be translated and sent straight back out the interface it arrived on. Many devices will not do that.

   Fix

   Enable hairpin NAT, or run split-horizon DNS so the internal name resolves to the internal address and no translation is involved.

   RFC 4787 §6Hairpinning BehaviorRFC 4787 · BEST CURRENT PRACTICE · January 2007

2. An application works from one network and not another, with no error beyond a timeout.

   Narrow it down

   1. Determine whether the application expects an inbound connection or embeds an address in its payload.
   2. Check the NAT mapping behaviour — whether the external port depends on the destination.
   3. Test from a network with a different NAT type.

   Cause

   Address-dependent mapping. A NAT that allocates a different external port per destination breaks any protocol that learns its own external address from one peer and gives it to another.

   Fix

   Use endpoint-independent mapping, which RFC 4787 requires, or a protocol that does not assume its own address is knowable.

   RFC 4787 §4.1Address and Port MappingRFC 4787 · BEST CURRENT PRACTICE · January 2007

3. Under load, new connections fail intermittently while existing ones are fine.

   Narrow it down

   1. Count active translations against the configured pool size.
   2. Check the port range available per external address.
   3. Look at how long translations are held after the last packet.

   Cause

   Port exhaustion. Every translation consumes an external port, and idle timers hold them long after a connection is finished — a browser opening dozens of connections per page multiplies quickly.

   Fix

   Add addresses to the pool, shorten idle timers for the protocols that tolerate it, or move to carrier-grade NAT with per-subscriber port blocks.

   RFC 6888 §3Requirements for CGNsRFC 6888 · BEST CURRENT PRACTICE · April 2013

4. A protocol that embeds IP addresses in its payload works without NAT and fails through it, while ordinary HTTPS through the same NAT is fine.

   Narrow it down

   1. Identify whether the application carries address or port literals in the payload.
   2. Check whether an ALG is enabled for that protocol on the NAT.
   3. Compare behaviour with the ALG disabled and with a tunnel that avoids translation.

   Cause

   An application-level gateway rewrote payload contents incorrectly, or the application assumed its own address was visible end-to-end. Classic NAT only rewrites headers; payloads are opaque unless an ALG intervenes.

   Fix

   Disable the ALG if the application has its own traversal, or use a protocol that does not embed addresses. Prefer fixing the application over depending on ALG behaviour.

   RFC 4787 §7Application Level GatewaysRFC 4787 · BEST CURRENT PRACTICE · January 2007

5. An internal service is reachable from some external test points and not others, or never receives unsolicited inbound traffic despite a public address on the NAT.

   Narrow it down

   1. Confirm a static or port-forward mapping exists for that external port.
   2. Check filtering behaviour: address-dependent filtering drops peers the host has not contacted.
   3. Verify the packet arrives on the outside interface with the mapped destination port.

   Cause

   No mapping means no inside destination. Dynamic mappings are created by outbound traffic; inbound services need an explicit static map, and restrictive filtering can still drop peers outside the ones already contacted.

   Fix

   Create an explicit inbound mapping for the service, and prefer endpoint-independent filtering when unsolicited peers must connect.

   RFC 4787 §5Filtering BehaviorRFC 4787 · BEST CURRENT PRACTICE · January 2007

Design notes

Prefer endpoint-independent mapping and test hairpinning before declaring a service “published.” A static inbound map that works from the internet can still fail from inside the same network. RFC 4787 §6Hairpinning BehaviorRFC 4787 · BEST CURRENT PRACTICE · January 2007

Treat ALGs as a last resort. An application-level gateway that rewrites IP literals inside SIP or FTP couples the NAT to application syntax; RFC 4787 recommends avoiding ALGs that interfere with UNSAF traversal. RFC 4787 §7Application Level GatewaysRFC 4787 · BEST CURRENT PRACTICE · January 2007

NAT is not a security policy. Unsolicited inbound traffic fails only because there is no mapping. Anything that creates an outbound mapping — malware included — gets a return path, and the NAT applies no content rule to what comes back.

Under carrier-grade load, port allocation and idle timers dominate failures. RFC 6888 requires per-subscriber port limits and logging that can attribute an external address and port to a subscriber at a time. RFC 6888 §3Requirements for CGNsRFC 6888 · BEST CURRENT PRACTICE · April 2013

Misconceptions

“NAT is a firewall.”

It blocks unsolicited inbound traffic as a side effect of having nowhere to send it, not as a policy. Anything that establishes an outbound mapping — including malware — gets a return path, and the NAT applies no rule to what comes back through it.

“NAT and PAT are different features.”

What almost everyone calls NAT is port address translation: many internal addresses behind one external address, distinguished by port. One-to-one NAT without ports exists but is rarely what is deployed. RFC 3022 §2.2Overview of NAPTRFC 3022 · INFORMATIONAL · January 2001

“IPv6 removes the need for NAT, so IPv6 has no NAT.”

IPv6 removes the address-shortage reason for it. NAT66 and NPTv6 exist and get deployed for multihoming and address independence, and NAT64 is essential to reaching IPv4-only services from an IPv6-only network. RFC 6146 §1IntroductionRFC 6146 · PROPOSED STANDARD · April 2011

More walkthroughs

Terms

NAPT

Network Address Port Translation: many internal addresses share one external address, distinguished by transport port. What most deployments call “NAT” or “PAT”.

Hairpinning

When two hosts behind the same NAT communicate using each other’s external mapped addresses, the NAT must translate and send the packet back out the inside interface. RFC 4787 requires it.

Endpoint-independent mapping

A NAT mapping behaviour where the external address and port for an internal source do not depend on the destination. Required by RFC 4787 so a host can learn one public binding and reuse it with other peers.

Check yourself

• An internal client cannot reach an internal server by its public hostname. What is the cleanest fix?

  • Open the firewall port
  • Split-horizon DNS, so the internal name resolves internally and no translation happens
  • Give the server a second public address
  • Disable NAT
• What does endpoint-independent mapping mean?

  • The same internal source always gets the same external port, whatever the destination
  • The NAT chooses ports at random
  • Inbound connections are allowed from any endpoint
  • The mapping never expires
• Why is NAT not a security control?

  • It is, when combined with PAT
  • It blocks unsolicited inbound traffic incidentally, applies no policy, and gives a return path to anything that connects outbound
  • Because it operates at layer 3
  • Because addresses are still visible in the payload
• Under heavy load, why do new connections fail while existing ones continue?

  • The routing table is full
  • External ports are exhausted, so no new translation can be allocated
  • The MTU has changed
  • TCP sequence numbers wrapped
• On outbound NAPT, which IPv4 header field is rewritten for every packet?

  • Only the destination address
  • The source address (and typically the source transport port)
  • Only the TTL
  • Only the DSCP
• Why must a NAT adjust the TCP checksum when it rewrites the IPv4 source address?

  • TCP checksums cover only the TCP header, so they must change whenever any header changes
  • The TCP checksum covers a pseudo-header that includes the IP addresses
  • Routers refuse packets whose transport checksum equals the IP checksum
  • Only UDP needs checksum adjustment; TCP is exempt
• How does stateful NAT64 differ from traditional IPv4 NAPT?

  • It is the same function under a new name
  • It translates between IPv6 and IPv4 so an IPv6-only client can reach an IPv4-only server
  • It only rewrites ports, never addresses
  • It replaces DNS instead of translating packets
• A static port forward exists, but unsolicited peers still cannot connect. What else might be wrong?

  • Endpoint-independent mapping is disabled
  • Address-dependent filtering is dropping peers the internal host has not already contacted
  • The IPv4 header checksum cannot be recomputed on inbound packets
  • Hairpinning is required for all inbound traffic

Related

• Subnetting

  Divides an address space by moving a boundary through the bits, and decides which route wins by how many of those bits a prefix pins down.

• NDP

  IPv6’s on-link discovery: NS/NA replace ARP, RS/RA find routers and prefixes, and DAD proves an address is unique — a rogue RA is an incident.

• DNS

  A delegated, cached database that answers questions about names — and whose two most useful signals are the record type asked for and how long the answer may be remembered.