Network Address Translation is a popular network engineering technique. It brings a special terminology and can be implemented in different flavours.
Why network address translation?
The basic advantage of network address translation in the Internet world is to allow a set of internal hosts to communicate with hosts on the Internet, using a single public IP address. Recall that we can not conceptually make a private IP address communicate with a public IP address:
Network address translation terminology
- Public-side IP address: the public IP address to which the internal IP address is mapped during NAT Traversal
- Public-side source port: the source port number to which the original source port number is mapped, when an internal host communicates with an external host, in NAPT
- Trigger outgoing packet: the outgoing packet, sent from the internal host towards the external host, that triggers the NAT mapping. without a trigger outgoing packet -from an internal host to an external one- no packet could traverse the NAT device.
- NAT pool: the collection of public-side IP addresses available for NAT operations. When creating a NAT binding, the NAT devices allocates a public-side IP address from the NAT pool to the packet that is going out.
- NAT timer: aka NAT idle timer: characterizes a NAT binding entry. The NAT timer of a particular binding entry resets when it is matched in the NAT mapping table. Once the timer expires, the NAT binding entry ages out and the public-side IP address is restored to the NAT pool
NAT binding: a relationship between :
- an inside local IP address and a public-side IP address, or
- a pair of “inside local IP address, local source port number” and a pair of “public-side IP address, public-side source port number”
- NAT mapping table: a table that stores all NAT bindings.
- NAT mapping entry: an entry in the NAT mapping table.
- NAT Traversal: the mechanism where packets traverse one or more NAT devices and get manipulated in some sort. The basic transformation during a NAT Traversal is that the destination IP address is changed according to the NAT mapping table
- NAPT: Network Address Port Translation. It is also known as PAT for Port Address Translation. It allows to map a source port number of an outgoing packet to public-side source port number
NAT Hairpinning: to understand NAT hairpinning, let’s consider a host that desires to communicate with a server using its public IP address. This scenario can be seen for example if you have a company-hosted web server and you try to connect to it through its publicly allocated IP address.
- the client sends packets with source 10.0.0.15 to 22.214.171.124. The SRX device, which is a NAT device,
checks its NAT mapping table and finds a binding entry for 126.96.36.199. It translates it to 10.0.0.5. The server receives the packets and finds that packets were sourced with IP address 10.0.0.15 (because the source address was not translated). So it replies with packets to 10.0.0.15, with source address 10.0.0.5. Now this traffic does not traverse the NAT device. The client receives the traffic and sees that it is coming from 10.0.0.5. It simply drops it because it was waiting for an answer from 188.8.131.52, not 10.0.0.5 (although it is the same server).
- Making NAT work in a hairpin fashion solves this problem (hence the word “Hairpin”). By translating both the destination IP address (184.108.40.206 to 10.0.0.5 and vice-versa) and the source IP address (10.0.0.15 to a public IP and vice-versa), we make sure that traffic traverses the NAT device in both directions.
- the client sends packets with source 10.0.0.15 to 220.127.116.11. The SRX device, which is a NAT device,
RendezVous Server: we talked about the RendezVous server in the Bidirectional Bytestream model article. This server is used in the following situations:
- Internet host A wants to communicate with an entreprise host B that is behind NAT
- an enterprise host C, behind NAT, wants to communicate with another entreprise host D, behind NAT also.
Relay Server: we also encountered the concept of a Relay server in the Bidirectional Bytestream model article.
Simply put, the Relay server is solicited when both clients sit behind NAT devices. Since neither host can communicate with the other, they need to communicate with an “intermediate” server called the Relay server.
- In the figure :
- Host B wants to send data to host A. So it sends it to the Relay server. the Relay server transfers it to host A
- The same things goes for host A. If it wants to communicate with host B, it sends data to the Relay server, which transfers it to host B.
- In the figure :
We will discuss the use cases of both the Rendezvous server and the Relay server in the next article.
Network Address Translation (NAT) Types
In this post I’ll review the basic Network address translation types. I’ll begin with Full Cone NAT.
On rule to remember before detailing NAT types is: for an external host to be able to communicate with an internal one, the internal host must have triggered an outgoing connection with that external host first.
Full Cone NAT
- In this type of NAT, any external host can write to the “publicIP.port” connection pair at the NAT device, once the trigger outgoing packet is initiated from Host A. The “publicIP.port” connection pair maps the public-side IP address and port number of A to its internal IP address and internal port number. The NAT device then will forward the packets to the internal host, according to this NAT mapping.
- The Full Cone NAT is the most permissive form of NAT. In the figure, host A has an internal “IPaddress.port” pair (A/2001) and a public-side “IPaddress.port” pair (Z/3001). When A communicates with B, the NAT device rewrites the ip address and source port of A as follows:
- the ip address A is set to its external equivalent: Z
- the source port is set to its external equivalent: 3001
- The destination “IPaddress.port” pair is kept as it is (B/90)
- Similarly, when host B wants to communicate with A, it sends packets to the public-side”IPaddress.port” pair – which is here Z/3001- because that’s what it sees (this is one of the purposes of NAT). The NAT device rewrites the ip address and destination port as follows:
- the IP address Z is set to its internal equivalent: A
- the destination port is set to its internal equivalent: 2001
It is called “Cone” because the connection seems like a cone:
Restricted Cone NAT
It is based on the Full Cone NAT, but with a restriction on the IP address of the external server. Once the initial trigger outgoing packet is sent from Host A to a destination B, any packets from host B (from any source port) will be accepted at the NAT device. However, host C’s packets towards A will not be accepted at the NAT device because there was no trigger outgoing packets from A to C.
In the figure below, supposing that host A initiated trigger outgoing packets towards hosts B and C, then both hosts will use the same NAT mapping at the NAT device, when communicating back to A.
Port Restricted NAT
It is based on Restricted Cone NAT, but with a restriction on the source port number also. Once the initial trigger outgoing packet is sent from the internal host A to an external remote destination “IP address.port” pair, then the remote host sitting at that IP address can send traffic only from that source port towards the internal host. So only specific “IPaddress.port” pairs coming from the outside are allowed to traverse the NAT device.
In the figure below, we have Private Host PH and three external hosts B, C and Y. Traffic from “IPaddressOfB.Port1OfB” is a allowed through the NAT device because Private Host already initiated a connection to “IPaddressOfB.Port1OfB” pair. Another traffic coming from the same host B but from another source port will be blocked at the NAT device, because Private Host did not previously send any packets on that port.
In the figure, if Private Host already initiated trigger outgoing packets to B and Y, then both B and Y can send traffic to Private Host, using a same NAT mapping on the NAT device.
Remember that the NAT mapping we are talking about is between two pairs of Private Host PH:
- Private host’s local IP and port, and
- Private Host’s public-side IP and port.
In symmetric NAT, a NAT mapping links two pairs:
- a “public-side IP.port” pair (the public representation of the company’s internal host) and
- an “ExternalHostIP.port” pair.
If anything of these pairs changes, a different NAT mapping entry must exist in the NAT table for communication to occur.
In the figure below:
- Host X sends out an initial outgoing trigger packet from source port y to host M, on its port n. The “X,y” pair is mapped at the NAT device to a “C,d” pair. Now host M can send back packets from source port n to “C,d” pair.
- Host X sends out an initial outgoing trigger packet from source port y to host P, on its port q. The “X,y” pair is mapped at the NAT device to a new pair “A,b” (notice a different port number here). Now host P can send back packets from source port q.
- Host P can not send packets to X from a source port different than q because the NAT binding states the following combination: “A,b” – “P,q“. So traffic from source port r is dropped.
- Traffic from host S is dropped because host X has never initiated a trigger outgoing packet to S.
So if we could draw a table of pairs and describe how NAT matches IP addresses and ports, we would have something like this:
internal pair, public-side IP addr and port pair, external IP addr and port pair
“X y“, “C d“, “M n“
“X y“, “A b“, “P q“
Network Address Translation (NAT) Traversal Techniques
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 (18.104.22.168: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 22.214.171.124: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