Networking: Network Address Translation

Networking: Network Address Translation

Home

Network Address Translation (NAT) is an increasingly popular technique for sharing a single network connection among several client computers. It does this by monitoring network traffic, then mapping between the internal (private) network address and port and an external (apparent) address and port -- then modifying the packet headers accordingly as they pass through.

This works rather well for the most common types of network operations, where a NAT-based client initiates a network connection to a remote server and the NAT automatically creates the necessary mapping, but it is not as flexible when a NAT host wants to act as a network server or for peer-to-peer network protocols. In such cases, the application software may need to detect the limitations of the intervening NAT and select an appropriate strategy for coping with them (if possible).

How Address Translation Works

A NAT mapping consists of 3 elements:

Internal address of an endpoint "inside" the private network
Remote address of an endpoint somewhere "outside" the network
Apparent address of the internal endpoint when talking to the outside

Throughout these documents, we will use the following notation to represent a NAT mapping between the internal and apparent addresses when talking to a given remote host:

(internal host:port, apparent host:port, remote host:port)

For example, the following sample configuration is represented using the indicated mapping summary.

The internal host behind that NAT creates a UDP endpoint and binds it to 10.0.1.2:1000 on the local network. It then sends a request packet to the remote server running at 128.1.2.3:80. When the NAT forwards the packet, it modifies the header so that it appears to have originated from an endpoint at 24.10.11.12:5201. Once the mapping is created, each outgoing packet is modified accordingly -- the internal and remote remote addresses determine which apparent address to use).

Outgoing Mapping:

( 10.0.1.2:1000 , 24.10.11.12:5201 , 128.1.2.3:80 )

Conversely, when the remote host sends his response back to the apparent address of the sender, the NAT does a reverse lookup on the mapping so that it can forward the packet to the appropriate internal endpoint -- the combination of remote and apparent addresses indicate which internal address the packet is destined for.

Incoming Mapping:

( 10.0.1.2:1000 , 24.10.11.12:5201 , 128.1.2.3:80 )

Overall, this process is relatively transparent for the local clients that initiate connections to a non-NAT servers, but there are many other ways for hosts to interact that NAT is ill-equipped to handle. Most of these stem from limitations in the way that the NAT has been configured (intentionally or otherwise), and also from invalid assumptions on the part of the designer or programmer of a network protocol.

How Address Translation Sucks

One of the "features" of NAT is that it can selectively forward or refuse packets, which provides a certain level of security from spurious connection requests. Specifically, if an incoming packet does not exactly match any mapping between a remote host:port and the apparent host:port, the NAT may:

Forward the packet if another mapping exists between the apparent host:port and any port on any remote host. (Permissive)
Forward the packet only if a mapping exists between the apparent host:port and any port on the remote host. (Protective)
Refuse packets from unknown hosts or ports outright. (Consistent or Restrictive)

Another way NAT provides nominal security is to select a different port for each mapping it creates -- even for the same local endpoint.

Remote Host 1:		`(10.0.1.2:1000, 24.10.11.12:5201, 128.1.2.3:80)`
Remote Host 2:		`(10.0.1.2:1000, 24.10.11.12:5202, 130.6.5.4:80)`

In this way, the same endpoint may appear as different endpoints to different remote hosts. The NAT may choose the port for a new mapping in several ways:

Always use the same apparent host:port for a given internal host:port. (Consistent)
Always use the next available host:port for each new mapping. (Incremental)
Select an available host:port at random to prevent lucky guesses. (Inconsistent)

Finally, some network protocols (typically peer-based) operate by referring one host to another endpoint by passing an IP address and port in the data section of a packet. While this works when all the hosts involved have absolute (non-NAT) addresses, but clearly may not work when NAT starts remapping addresses and ports in packet headers.

Most NAT implementations do not modify host addresses when passed as data over a network connection, while others may tweak a specific few NAT-challenged protocols (such as FTP), while still others will try to sniff the data section and replace ASCII or binary representations of internal addresses. The latter may cause problems even for well-written software, where the NAT may recognize and modify incidental data within the packet.