In this article, we will discuss popular Network Address Translation (NAT) Traversal techniques. We will begin with Relaying, then Connection Reversal and finish with UDP Hole Punching.
NAT Traversal technique #1: Relaying
A simple NAT Traversal technique is Relaying. This technique uses a public IP server that will relay requests and responses between NATed hosts (i.e. hosts behind NAT). The Relay server must not sit behind a NAT device.
Here is how it works:
- Peer A must establish a connection with the Relay server: peer A sends data on source port 2020 to its gateway (here the NAT device). The NAT device creates a NAT binding between peer’s A “localIP.port” pair and a “public-sideIP.port” pair. The data leaves the NAT device from source port 4040. Similarly, peer B establishes a connection with the Relay server. Peer B sends data from source port 2020 to its NAT device. A NAT binding is created between peer B’s “localIP.port” pair and a “public-sideIP.port” pair. Here, the NAT device transmits data from source port 6060 to the Relay server.
- Now that NAT bindings have been created (on both NAT devices), anytime one peer wants to send data to the other peer, it must do so through the Relay server.
If we want to draw the NAT mappings, we get the following table:
|Peer||Local pair||Public-side pair|
We notice here that:
- There is no direct communication between both peers. Everything goes through the Relay.
- Data is not secure because all of it transits through the Relay
- There is a single point of failure (SPOF), which is the Relay.
NAT Traversal technique #2: UDP Hole Punching
This is a technique that works for hosts that are both behind NAT. As its names implies, it uses UDP.
For the simplicity of the explanation, we assume that peer A and B communicate with the Rendezvous server at the same time.
- First, peers must communicate with the Rendezvous server:peer A sends a packet to the IP address of the Rendezvous server (with local pair of 192.168.0.100:2020). The packet reaches the NAT gateway and a NAT mapping is created: 192.168.0.100:2020 <—> 100.100.100.100:4040. The packet reaches the Rendezvous server which learns two things: peer A’s IP address and port pair is 100.100.100.100:4040, and peer A is behind NAT (because it “sees” different source IP addresses in the packet it received). If the Rendezvous server has already learned the “publicIP.port” pair of peer B, then it gives them to peer A in the form of a reply packet. So the Rendezvous server responds to the “publicIP.port” pair of A by presenting the “publicIP.port” pair of peer B. The NAT device receives the response, finds that the packet is destined to “publicIP.port” pair of A and reads the NAT mapping to know where to forward the packet internally. According to the NAT mapping, the packet must be forwarded to 192.168.0.100:2020 (remember the NAT mapping earlier). So it forwards the packet to peer A’s local IP address and port.
Peer A has established a communication with the Rendezvous server; we say that peer A has punched a UDP hole in NAT.
- Peer B does the same. Peer B sends a packet (source address 10.10.10.200, source port 2020) through its NAT gateway, towards the Rendezvous server. A NAT mapping is created: 10.10.10.200:2020 <—> 100.100.100.200:6060. The NAT device forwards the packet with its public representation (100.100.100.200:6060) to the Rendezvous server. The Rendezvous server replies with the “publicIP.port” pair of peer A. The NAT device transfers this information to peer B. We can say now that peer B has also punched a UDP hole in NAT.
- Now both peer A and B have the “publicIP.port” pair of each other; they can exchange data through their respective NAT devices, without using the Rendezvous server.
- UDP Hole Punching technique works for all types of NAT except for Symmetric NAT. That’s because UDP Hole Punching assumes that, once the NAT bindings are created, they are reused as they are (same IP, same port number).
- Also, in UDP Hole Punching, sometimes the first exchanged packets between A and B get dropped. This continues until the other party has punched a UDP hole in NAT. So the transmitter needs to make as many connection attempts as needed for the connection.
NAT Traversal technique #3: Connection Reversal
The Connection Reversal technique is also a NAT Traversal technique. But unlike the Relaying technique, it does not use a Relay server. Instead, it uses a Rendezvous server. The Rendezvous server must not sit behind a NAT.
The Connection Reversal technique is used when we need communication between one Internet host and another host sitting behind NAT. Let’s assume we are using UDP as a transport protocol.
- The first step in this technique is that both peers A and B make a connection with the Rendezvous server. A sends a packet directly to Rendezvous server because it is not behind a NAT. However, in the case of peer B, when it sends a packet to the IP address of the Rendezvous server, the packet hits the NAT gateway, which installs a NAT binding in the NAT table. The NAT binding is the following: “192.168.0.100:2020 <—> 100.100.100.100:6060”.
- At this point, Rendezvous server learned the IP address and port of peer A (184.108.40.206:2020) and learned the public side of peer B (100.100.100.100:6060). In fact, Rendezvous server now knows that peer B is sitting behind a NAT, because it saw different IP addresses in the packet (192.168.0.100 and 100.100.100.100). The Rendezvous server replies to each peer with the address and port of the other peer. It sends a packet to 220.127.116.11:2020 and another one to 100.100.100.100:6060. The latter reaches the NAT device, which reads the NAT binding and forwards the packet to peer B’s local IP address and port (192.168.0.100:2020). Now that communication has been established between peer B and the Rendezvous server, we say that a UDP hole is punched.
- Now peers can communicate without the need for the Rendezvous server. In fact, its job was successful: to make peer B learn how to reach A, and to help punching a hole in NAT. peer B sends data to peer A through the NAT device. And peer A sends data to peer B’s NAT device.
- In the connection reversal technique, the Rendezvous server is not a single point of failure, like we saw in the Relaying technique. Also, data is exchanged from peer to peer and not flowing through an intermediate server.
I’d like to draw attention to the difference between a NAT Traversal request and an IP request. Given the NAT device with “publicIP address.port” pair of 100.100.100.100:6060, what if an IP packet coming from the outside with destination IP 100.100.100.100 and destination port of 34110 arrives at the NAT device? Should it create a new mapping?
If you answered “yes a new mapping”, then it’s the wrong answer. Remember that an external host can not initiate a connection to an internal NATed device. So, the packet destined to 100.100.100.100 on destination port 34110 will be treated like any IP packet…destined to the NAT device itself! In fact, the NAT device behaves like any IP device (router, switch,…) if an inbound packet does not match any NAT binding.
- How To Traverse NAT, Davide Carboni, 2005-2006
- NAT Traversal In Peer-to-Peer Architecture, Marc-André Poulain, Lucas Rioux Maldague, Alexandre Daigle, François Gagnon – Carleton University