NAT Traversal

Note: work in progress

Overview

NAT (Network Address Translation) is widely used to connect private networks to the internet. The main idea is to map several private IP addresses to only one public IP address. Having in mind that P2P network clients should be able to communicate with each other, one basic question comes into mind: how can internet hosts communicate with a host in a private network? We will first have a look at NAT itself and problems it brings. Then, we show how to traverse NATs by either changing router's configuration or by using other tricks.

Network Address Translation

A network address is simply the IP address ( + Port number for UDP/TCP). A NAT router receives an incoming IP packet, saves the address in its NAT table, rewrites sender address to one of its public addresses and sends the packet to the destination address. Now, the NAT router accepts incoming packets on this public address (NAT endpoint). These packets are forwarded to the private host. The most important facts are:

• The mapping depends on the sender's port number. If the private host uses two different outgoing port numbers, the NAT endpoints will differ.
• The private host has to send first. Otherwise no incoming packets will be forwarded to the private host.
• The client does not know all that...

The behavior of the NAT router is not standardized. The only thing that works with every NAT router is simple request and answer. That means the remote host answers a request using the port number the client used for its request. Some NATs allow replies from other ports or even hosts, some use different endpoint mappings for every session.

According to their behavior, NATs can be classified into four types:

• Full Cone
• Restricted Cone
• Port Restricted Cone
• Symmetric

Full Cone NAT A private host (PH) sends an initial request to A. As a result, the NAT router opens a public endpoint. Every connection to any remote host from PH's port A will be mapped to the same port A' at the NAT router. If PH uses port B, the mapping will be B' and not A'. Now NAT's endpoint is availiable to all remote hosts. Every host may send a message from any source port to NAT's endpoint.

Figure 1: Full Cone NAT

Restricted Cone NAT The behavior of Restricted Cone NATs is nearly the same as Full Cone NATs, except that not every other host may send a message to the public endpoint. Depending on the implementation, NAT router rejects the packet or simply drops it. In case the PH sends a message to another remote host, this host will be able to give an answer. Whether the same NAT endpoint is used or not depends on the port PH uses for sending the message (see above).

Figure 2: Restricted Cone NAT

Port Restricted Cone NAT This type of NAT implements a stronger restriction then Restricted NAT. The restriction now focusses on the target port (and the target host since it is a higher restriction).

Figure 3: Port Restricted Cone NAT

Symmetric NAT Here are the highest restrictions. In opposition to cone NATs, every target host and port will be mapped to another endpoint. While Cone NATs use the same endpoint for every PH's source port, Symmetric NAT uses different endpoints. One endpoint mapps to exactly one (IP,Port_R,Port_PH)-Tuple. Port_R means remote port, Port_PH means private host's source port.

Figure 4: Symmetric NAT

Hole punching

Hole punching deals with the problem that two clients have behind NAT routers, when they want to establish direct connections. Here, a client A cannot establish a connection with client B, because B is behind a NAT and vice versa. However, using a slightly modified STUN server enables both clients to obtain the public NAT endpoint addresses and the clients' private addresses. Now hole punching can be tried: both clients send messages to one another. Now, the following happens: client A's message is the first one. It will be rejected or dropped at B's NAT. Hence, A's NAT opened a public endpoint for A's connection. Now, B sends his message. This message will be forwarded by A's NAT. As a result, both NATs have open endpoints; direct communication is established. One special case is when A and B send their messages synchronously. Here, both messages will reach their targets. What about Symmetric NAT? That's the problem case hole punching cannot handle. We require public endpoint addresses obtained by STUN; so here is the failure. Symmetric NAT assigns different endpoints to different communication partners, so connection attempts from other servers than the STUN server automatically fail.

Figure 5: Hole punching

Since hole punching works for two clients behind different NATs, we now focus on a special case when two clients are behind the same NAT. Remember the restrictions to the STUN protocol: the clients may find out they are behind the same NAT, but they actually do not know whether they are in the same private network (--> cascaded NATs). Now the clients can try normal hole punching. If this works or not depends on the NAT's ability of doing so-called hairpin translation. Since clients from private network try to connect to NAT's public addresses, the NAT may deny this communication. In the best case, the NAT will translate the request internally by opening a direct route to the NATed client. Also possible were to send the request to the internet and receive it like a normal request, but this is inefficient. To achieve the best performance, clients may try to connect to the private address obtained from STUN server. If the clients are located in the same subnet, this will work. By the way, this is a possible method for traversing symmetric NATs.

Figure 6: Hairpin translation

Conclusion: hole punching is not a cure-all for traversing NATs, but works fine for Cone-type NATs. Symmetric NATs cannot be traversed by using these simple methods. Hairpin translation is a special case for hole punching and may allow direct communication for clients behind the same symmetric NAT. If all that does not work, the fallback strategy is to use relayed connections using the TURN protocol.

Refereces

• Ford, Srisuresh, Kegel: Peer-to-Peer Communication Across Network Address Translators (link)
• Rosenberg, Huitema, Mahy: Traversal using relay NAT (TURN), Internet Draft (link)
• Rosenberg, Weinberger, Huitema, Mahy: STUN – simple traversal of user datagram protocol (UDP) through network address translators (NATs), March 2003, RFC3489 (link)
• Rosenberg: Interactive Connection Establishment (ICE), Internet Draft (link)
• Schulzrinne: diverse documents concerning NAT and SIP, e.g. NAT Types.pdf (NAT and SIP)