NAT

Service outages, client connection failures, and UDP instability often get blocked earlier by an address-rewriting boundary. The host thinks it is talking directly to the public Internet, but the remote side sees a different address and port. The application thinks it is only sending packets, while the NAT device has created, maintained, timed out, and reclaimed a mapping relationship.

NAT is not just “changing the address”. It is a major redistribution of roles in real IPv4 networks: internal addresses are no longer directly reachable by default, outbound traffic becomes the default entry point for creating mappings, and return traffic depends on whether that state table is still alive.

NAT is not merely “saving a few public IPs”. It rewrites addresses and also collects reachability, return-path conditions, and state into a mapping table controlled by the boundary device

Why It Appears

The background is practical: IPv4 addresses were not enough, and most internal hosts did not need their own long-lived public address.

If you follow the literal public-address model:

• Every host needs a public IP
• Internal address planning becomes tightly coupled to public address resources
• Large home networks, enterprise networks, and ISP access networks run out of addresses quickly

NAT offers another route:

• Internal networks use private addresses
• The boundary device rewrites source address and port on the way out
• Many internal hosts share a small set of public addresses

It started as an address-resource and deployment-cost fix, but it quickly changed a deeper assumption about who can initiate communication with whom.

The Background It Came From

NAT was not part of the original core layering in the way IP or TCP were. It is closer to an engineering patch that grew under IPv4 pressure and later became the de facto standard.

That gives NAT a particular character:

• It serves deployment reality rather than layering purity
• It prioritizes address shortage and access problems rather than end-to-end transparency
• It naturally depends on the boundary device maintaining state
• It has strong spillover effects on upper-layer protocols

So many NAT problems are not “bad implementation”. They are because NAT was already rewriting end-to-end assumptions by design.

Grasp the Main Model First

To understand NAT, keep three things in mind:

• Rewrite: addresses and sometimes ports are changed when packets cross the boundary
• State: the boundary device keeps an internal-to-external mapping table
• Return flow: whether external traffic can come back depends on whether it matches an existing mapping or an explicit rule

You can compress the logic like this:

Internal host starts a connection
  -> NAT creates a device-side mapping
  -> The outbound address / port is rewritten
  -> External replies flow back according to the mapping

The easiest thing to underestimate here is the state. NAT does not just rewrite packets statically. It also has to remember who maps to whom, how long that relation is alive, and which reply should be returned to which internal endpoint next time.

The Most Common Main Path

Start with the most common outbound path:

The remote server no longer sees the internal host’s original address. It sees the NAT gateway’s public address and the rewritten port. The reason the reply can come back is not that the public Internet understands the private topology. It is that the NAT device still remembers the mapping.

Why NAT Usually Favors Outbound-First Traffic

The safest default logic is not “everyone can come in”. It is:

• Let an internal host initiate outbound traffic first
• Let NAT create state from that outbound flow
• Allow return traffic if it matches the state

The benefits are direct:

• Internal addresses do not need to be exposed to the public network
• The boundary device can control return traffic more centrally
• It is easier to distinguish multiple hosts sharing the same address

The cost is equally clear:

• External hosts cannot directly reach internal hosts by default
• Applications that want peer-to-peer, inbound services, or long idle connections immediately hit the NAT state boundary

So NAT does not only change the address format. It changes who owns the default right to establish communication.

Why Port Rewriting Becomes So Important

If one public address only belongs to one host, address rewriting alone is enough. In reality, NAT often has to let many internal hosts share one public address, and then address-only rewriting is not enough. Ports have to be rewritten too.

So NAT devices are really doing two things:

• Rewriting the source address
• Reassigning or reusing external ports

That is why engineering discussions often distinguish:

• Address translation
• Address plus port translation

From the application’s point of view, though, the most important change is the same: the connection identity seen from outside no longer equals the internal host’s original identity.

Why NAT Introduces State and Timeouts

NAT cannot keep mappings forever, or the state table would grow out of control. It has to reclaim state, and the most common basis for reclamation is:

• Whether TCP ended explicitly
• Whether UDP has been idle for too long
• Whether a mapping exceeded its idle timeout

That creates the classic real-world problems:

• UDP mappings often time out more easily than TCP
• After a long quiet period, the application thinks the connection still exists while NAT has already forgotten it
• Keepalive traffic is not a weird business habit. It is often what keeps NAT state alive

Many “intermittent disconnects” and “works until idle for a while” incidents are rooted here.

Why NAT Breaks End-to-End Assumptions

In the ideal end-to-end model, once both sides know each other’s address and port, they should be able to communicate directly. NAT changes that premise:

• Internal addresses usually mean nothing to the public network
• External hosts do not know how to find an internal device by default
• Even if they know a public address and port, that does not mean the mapping is still alive

That affects many upper-layer protocols and system designs:

• P2P needs hole punching
• Inbound server access needs port forwarding or reverse proxying
• If a protocol embeds IP information in its payload, extra rewriting or helper mechanisms may be required

So what NAT really breaks is not “can the packet move”. It is “does an address still mean a stable reachable identity on both sides”.

Why UDP Traversal Becomes Its Own Problem

UDP itself is connectionless. It does not maintain long-lived state for you. NAT, meanwhile, uses “have I seen traffic for this flow recently” to decide whether the mapping should remain. Put those together and UDP traversal becomes a separate engineering problem.

The usual approach is not to make NAT understand the application better. It is:

• Have both sides send packets outward first to establish mappings
• Exchange the external address and port through a coordination server
• Try to punch through while the mapping window is still alive

That is why hole punching exists. It is not a fancy UDP trick. It is the recovery step applications have to add after NAT changes the default reachability model.

Why Port Forwarding and DNAT Keep Existing

Since NAT by default does not welcome inbound traffic, two kinds of compensating mechanisms naturally persist:

• Static port forwarding
• Destination address / port translation that forwards inbound traffic to a specific internal host

Their value is simple: they reopen a controlled inbound path. A lot of “port forwarding” on home broadband and a lot of DNAT on boundary devices are just doing that.

So NAT is not completely closed. It is:

• Closed to direct inbound traffic by default
• Re-opened only through explicit rules

What to Look At in Packet Capture

The easiest way to lose time on NAT problems is to only capture one side. A more useful order is below.

First check what was actually rewritten

Confirm:

• What the internal source address and port were
• What the external address and port looked like on the way out
• Whether the return packet still matches the same mapping on the way back

Many problems are not “the server never replied”. The server replied, but it did not reach the correct mapping.

Then check whether the state is still alive

Common symptoms:

• The first exchange works, then it fails after being idle for a while
• UDP intermittently drops until a new first packet recreates the mapping
• TCP looks alive, but the NAT state has already been reclaimed

At that point the important thing is not the application payload. It is the NAT table entry lifetime.

Finally check which kind of boundary problem this really is

Many NAT problems look similar at first glance but have different root causes:

• No outbound traffic ever happened, so no mapping was created
• The mapping existed, but port rewriting made the peer fail to recognize it
• The mapping expired and the boundary device reclaimed it
• The service actually needed static mapping or a relay, but the business assumed direct inbound access would still work

If you do not separate those boundaries, troubleshooting tends to bounce around the application layer forever.

What Engineering Should Actually Think About NAT Today

• Do not think of NAT as “change the address a little”. It rewrites the default rule for connection reachability
• Do not confuse the public address seen from outside with the internal host’s real identity. NAT sits in the middle with a state table
• Do not underestimate port rewriting and timeout reclamation. A lot of disconnects and traversal problems start there
• Do not treat UDP traversal as a corner case. It is the direct result of NAT changing the default reachability model
• Do not forget that NAT is an engineering patch for real IPv4 networks. It solved address shortage, but it also added protocol semantics and troubleshooting complexity

Further Reading

• IP - why NAT directly rewrites IP-based reachability assumptions
• IPv6 - why IPv6 tries to push NAT out of the default survival model
• UDP - why UDP more easily exposes NAT state timeout and hole-punching issues
• TCP - why TCP connections still depend on state maintenance at the NAT boundary
• How TCP States Show Where a Connection Is Stuck - how half-alive long connections, TIME-WAIT, and close states help troubleshooting
• QUIC - why modern web transport reworks connection and migration boundaries on top of UDP

References

• RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations
• RFC 3022 - Traditional IP Network Address Translator (Traditional NAT)
• RFC 4787 - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
• RFC 5382 - NAT Behavioral Requirements for TCP