NAT
In this post I will try to explain as simple as possible how NAT works. This post is actually a prequel to my next post which will talk about Surebackup and Networking. But before I can go into detail in that post, you need to understand how NAT works on Linux (as this is the core). If you already know how SNAT, DNAT and NETMAP work please ignore the post.
So what is NAT or Network Address Translation? Well NAT is actually a technique which is used to modify the source or target IP address in a IP packet. NAT is mostly done on Routers when a packet transfers from one subnet to another subnet.
NAPT
One of the most common use cases of NAT is
NAPT . When you have a broadband connection at home, your provider will probably only assign you one public IP. So when you want to use this connection with multiple devices you put a "router" in between. Basically this home router does NAPT between your local network and the internet.
Let us start with a simple example. You have a computer connected on your local LAN. Your router is the default gateway in this LAN but is also connected to the Internet. Your computer wants to get a page at 173.194.35.19. So the setup of IP's would look something like this:
- Your computer 192.168.1.2
- Router LAN 192.168.1.1
- Router WAN 109.132.94.20
- Internet GW 109.132.94.1
- Website 173.194.35.19
Remember that 192.168.x.x is a
private range and has no meaning on the internet itself. So when your computer sends a package to request the website the following conversation will happens:
Your Computer send the following packet to the Router LAN
| IP Packet |
|---|
| Source |
192.168.1.2 |
| Source Port |
29831 |
| Destination |
173.194.35.19 |
| Destinatin Port |
80 |
| Message |
Get index.html |
Your Router will get this package. It only has one default gateway itself (the one given by your provider). It wants to forward this package to this default gateway but it knows that 192.168.1.x is a local subnet. So it translate the source to its own ip. While doing this it tracks that it send out this package for the internal server. With NAPT this tracking is done on port base. Basically it modifies the Source Port and keeps a table of the "original settings" linked to the source port and destination. It "tracks" the connection
Router WAN send a modified version of the package to Internet GW
| IP Packet |
|---|
| Source |
192.168.1.2 109.132.94.20 |
| Source Port |
29831 30001 |
| Destination |
173.194.35.19 |
| Destinatin Port |
80 |
| Message |
Get index.html |
In a "Translation table" it puts
| Translated Source Port | Destination | Original Source Port | Original IP |
| 30001 | 173.194.35.19 | 29831 | 192.168.1.2 |
So when a package returns from the website via your Internet GW the following happens on the router. It will inspect the package and match it to his translation table based on the translated source port and destination ip (which is now the destination port and source ip). There it can see that the final destination is not itself but is an internal IP. It will translate the port and the destination back and put the package back on the lan
Internet GW > Router WAN
| IP Packet |
|---|
| Source |
173.194.35.19 |
| Source Port |
80 |
| Destination |
109.132.94.20 192.168.1.2 |
| Destinatin Port |
30001 29831 |
| Message |
Random HTML |
Router LAN > My computer
| IP Packet |
|---|
| Source | 173.194.35.19 |
| Source Port | 80 |
| Destination | 192.168.1.2 |
| Destinatin Port | 29831 |
| Message | Random HTML |
This basically show how NAPT works. But of course there are multiple forms of NAT. There are a couple of interesting things to get from this example
The first interesting thing here is that the NAT rules are applied before the package leaves the ROUTER Wan port. However this is not always the case. Inside the router NAT can be done on two locations.
Lan interface or Entering interface (Pre Routing) > Routing (computer decides the package should go the internet default gateway) & Firewall > Wan Interface or Exiting interface (Post Routing)
Another interesting thing is that although the computer in the local network can talk to the outside world, the outside world can only talk back when the router has a way to translate the package back into the local LAN. In fact one of the reason why people could use one form of NAT is a form of security. Because the router intercepts all the traffic it hides away the local network specifics and can actually act as a firewall. In fact in Linux, NAT is configured via iptables, the same command that is used to configure the built-in firewall.
Linux and NAT
Now that you know what NAT does, lets look at some other forms of NAT in specific to Linux.
For the following example I will use the following networks. You can see that the Router has two interfaces: 0 and 1, one in each network.
Network A (192.168.1.x)
- Computer X with IP 192.168.1.2
- Router interface 0 192.168.1.1
Network B (109.132.94.x)
- Router interface 1 109.132.94.20
- Server Y with IP 109.132.94.60
Source NAT (SNAT)
With Source NAT you will actually define a NAT rule that will translate a Source IP to another IP. Source NAT is defined as a Post Routing process.
So lets imagine the following rule
| When? | Type | Coming from Interface | Leaving on Interface | Original Source | Translation Source |
| Post Routing | SNAT | * | Interface 1 | 192.168.1.0/24 | 109.132.94.20 |
When computer x sends a package to server y it will pass the router. Just before it leaves on interface 1, the source will be translated.
| IP Packet |
|---|
| Source | 192.168.1.2 109.132.94.20 |
| Destination | 109.132.94.60 |
| Message | Hello from Computer X |
When a package comes back, the address is translated back
| IP Packet |
|---|
| Source | 109.132.94.60 |
| Destination | 109.132.94.20 192.168.1.2 |
| Message | Hello back from Server Y |
Interesting to know is that source NAT can be done on a single IP as well, meaning that the original source address might be only be 192.168.1.2. In this case only 192.168.1.2 would be translated but no other hosts.
You can also see why SNAT should be a Post Routing process. If it would be a Pre Routing / Firewall process, the source would be the router itself. It would be hard to make firewall rules for the original host as this information is already replaced.
Masquerading
Source NAT does look a lot like NAPT. This true but there is one problem. Your network interface at the WAN side might change IP. Most providers assign public ip addresses to home users via DHCP. So it is hard to predict what the outside ip will be. Masquerading solves this. It is a special form of Source NAT where instead of defining a fixed ip it will define only an interface.
| When? | Type | Coming from Interface | Leaving on Interface | Original Source |
| Post Routing | Masquarding | * | Interface 1 | 192.168.1.0/24 |
In this case the same thing will happen as in the previous example. The router will use the dynamic IP assigned to Interface 1 (in this case 109.132.94.20) and will rewrite the source. If the connection is reset and interface 1 gets a new IP, the rule will dynamically use this new IP.
Destination NAT (DNAT)
DNAT is the inverse of source NAT. In fact it will rewrite the Destination address instead of the source address. A lot of companies use DNAT to hide their real server in a private range behind a Firewall / Router.
Consider the following example:
Network A (192.168.1.x)
- Server X with IP 192.168.1.2
- Router interface 0 192.168.1.1
Network B (109.132.94.x)
- Router interface 1 109.132.94.20
- Client Y with IP 109.132.94.60
Notice that the server is now in the private subnet. There is one problem, the server is not reachable from the outside because of the use of private IPs. The ideal scenario would be that all traffic pointed to 109.132.94.20 is translated to 192.168.1.2 when it enters the router.
In this case we will do the translation in the Pre Routing stage. Since the connection is now initiated from the outside Pre Routing is now on Interface 1 (Pre Routing Interface 1 > Routing > Post Routing Interface 0) . If the translation would be done in the Post Routing process, the routing process would think that the packet with destination 109.132.94.20 would be for a service running on the router itself.
| When? | Type | Coming from Interface | Leaving on Interface | Original Dest | Translation Dest |
| Pre Routing | DNAT | Interface 1 | * | 109.132.94.20 | 192.168.1.2 |
So how does the communication go?
Client Y sends a package to router interface 1. Router interface 1 will translate it before sending it to server X
| IP Packet |
|---|
| Source | 109.132.94.60 |
| Destination | 109.132.94.20 192.168.1.2 |
| Message | Hello from client Y |
Before the answer is send back to Client Y, the address is translated back to the original IP
| IP Packet |
|---|
| Source | 192.168.1.2 109.132.94.20 |
| Destination | 109.132.94.60 |
| Message | Hello back from Server X |
Of course if you have multiple server in DMZ and multiple public IP address you can map them on the same router. Most of the time what happens is that the router will claim multiple IP address on the same interface. In that case you will have to write multiple DNAT rules. Consider:
Network A (192.168.1.x)
- Server X with IP 192.168.1.2
- Server Z with IP 192.168.1.3
- Router interface 0 192.168.1.1
Network B (109.132.94.x)
- Router interface 1 109.132.94.20,109.132.94.21
- Client Y with IP 109.132.94.60
| When? | Type | Coming from Interface | Leaving on Interface | Original Dest | Translation Dest |
| Pre Routing | DNAT | Interface 1 | * | 109.132.94.20 | 192.168.1.2 |
| Pre Routing | DNAT | Interface 1 | * | 109.132.94.21 | 192.168.1.3 |
Redirection
This is a special form of DNAT comparable to Masquerading for SNAT. If you have a dynamic IP on the outside, you can use redirection to translate all the packages that are coming in to an internal destination without knowing the original destination (IP on Interface 1). The rule will be dynamically adapted. In this case the original destination 109.132.94.20 will be used. However if the connection is reset and the outside IP on interface 1 changes to 109.132.94.30, the rule will use 109.132.94.30 as the original destination.
Basically if you want to run a server in your home network, you will have to configure redirection on your home router.
| When? | Type | Coming from Interface | Leaving on Interface | Translation Dest |
| Pre Routing | Redirection | Interface 1 | * | 192.168.1.2 |
SNAT vs DNAT
So when should you use SNAT or when DNAT. Well this depends on the network you want to hide and the server its position. If the server is in the network you want to hide, you should use DNAT. If the client is in the network you want to hide you need a form of SNAT.
One interesting this that is not discussed is that you can create NAT rules that are only valid for a certain port. Even more you can use NAT to not only translate the IP but also the Port part. Consider the DNAT rule. If you have a webserver running on port 8080 on server x and an smtp server on server y that you want to hide behind NAT rules, you create two rules:
- Redirect source port 80 to port 8080 on server x
- Redirect source port 25 to port 25 on server y
In this case you could use one Public IP that is redirected to an internal server based on which destination port was used.
What is also interesting is that I described all scenarios with a public network and a private network. However you could also use NAT between private networks. But again one network will be hidden from the other one.
NETMAP
Before I explain NETMAP know that an IP has a network part and host part uniquely defining a host in the network. For example if you have an IP 192.168.1.1 with subnet mask 255.255.255.0, the network part would be 192.168.1 and the host part would be 1.
In the previous cases you can see that for DNAT we need to define a fix Destination IP. For SNAT you need to define a fix Source IP. What if you wanted to translate a whole network at once. Let say that for all IPs coming in you want to translate the network part but not the host specific part. In that case you can use NETMAP.
NETMAP can be used as a substitute for DNAT and SNAT. If you use NETMAP in Pre Routing it will rewrite the destination so it will do DNAT. If you define it as a Post Routing rule, it will rewrite the source address thus acting like an SNAT rule
To see the use case consider the following DNAT example
Network A (192.168.1.x)
- Server A with IP 192.168.1.2
- Server B with IP 192.168.1.3
- Server C with IP 192.168.1.4
- Router interface 0 192.168.1.1
Network B (109.132.94.x)
- Router interface 1 109.132.94.1, 109.132.94.2, 109.132.94.3, 109.132.94.4, 109.132.94.5
- Client Y with IP 109.132.94.60
We want to map the outside IP to the corresponding inside IP address.
- 109.132.94.2 > 192.168.1.2
- 109.132.94.3 > 192.168.1.3
- 109.132.94.4 > 192.168.1.4
You can do this using 3 DNAT rules. However each time a new server is deployed you will need to add another rule. A more lazy way of doing this is using NETMAP. To use NETMAP however the SUBNET mask must match -which is the case-.
| When? | Type | Coming from Interface | Leaving on Interface | Original Dest | Translation Dest |
| Pre Routing | NETMAP | Interface 1 | * | 109.132.94.x/24 | 192.168.1.x/24 |
The same things happens now as using standard DNAT rules. Only the NAT process will only translate the host part.
Client Y sends a package to router interface 1. Router interface 1 will translate it before sending it to server X
| IP Packet |
|---|
| Source | 109.132.94.60 |
| Destination | (109.132.94 192.168.1).2 |
| Message | Hello from client Y |
Before the answer is send back to Client Y, the address is translated back to the original IP
| IP Packet |
|---|
| Source | (192.168.1 109.132.94).2 |
| Destination | 109.132.94.60 |
| Message | Hello back from Server X |
If a new server is deployed with ip 192.168.1.5 and the router has the matching public IP claimed to interface 1, it will automatically do the translation.
Overlapping SUBNETS
Another use case for NETMAP could be if you have duplicate subnets in different VLANs. For example if you have a VLAN 2 with subnet 192.168.1.x/24 and a VLAN 3 with subnet 192.168.1.x/24 there is no way of connecting this VLANs via normal routing. What you could do is use Netmap to translate one of the networks
Network A (192.168.1.x) VLAN A
- Client X with IP 192.168.1.2
- Router interface 0 192.168.1.20
Network B (192.168.1.x) VLAN B
- Server A with IP 192.168.1.2
- Router interface 1 192.168.1.1
| When? | Type | Coming from Interface | Leaving on Interface | Original Dest | Translation Dest |
| Pre Routing | NETMAP | Interface 0 | * | 192.168.2.x/24 | 192.168.1.x/24 |
If Client X wants to talk to Server A it will need to know that the router will translate the address from 192.168.2.x addresses to 192.168.1.x addresses. So Client X will not try to connect to Server A on address 192.168.1.2 but on 192.168.2.2.
Another interesting problem is that this will translate the Destination IP but not the Source IP. This can be confusing for the Server A as the Source IP is in the same range. To solve this problem we could add an SNAT rule or just masquerading.
| When? | Type | Coming from Interface | Leaving on Interface | Original Source |
| Post Routing | Masquarding | * | Interface 1 | 192.168.1.0/24 |
In this case the Router will replace the original source with its own IP forcing Server A to reply back to the router. So lets see the conversation
In Pre Routing the following package enters the Router on Interface 0. The NETMAP will do a translation
of the destination IP
| IP Packet |
|---|
| Source | 192.168.1.2 |
| Destination | 192.168.2.2 192.168.1.2 |
| Message | Hello from Client X |
One if the interesting problems now is that the Routing will be confused because it has two networks that both have the Subnet 192.168.1.x. So how does the routing process know which is the correct Interface for the packages destination. This can be done using marks. Basically you mark a packet when it enters the router. The mark is only relevant during the stay in the router. For example you can mark all traffic that comes in on interface 0 with mark 2. In fact the Mangle / Mark rule is processed before the Netmap rule will apply so you can use the original target IP Address range. The router can then be set up to route correctly based on this mark
| When? | Type | Mark | Coming from Interface | Leaving on Interface | Source | Target |
| Pre Routing | Mangle / Mark | 0x2 | Interface 0 | * | 0.0.0.0/0 | 192.168.2.0/24 |
| IP Packet |
|---|
| Source | 192.168.1.2 |
| Destination | 192.168.2.2 192.168.1.2 |
| Message | Hello from Client X |
| Mark | 2 |
Now all packages entering via interface 0 going to 192.168.2.0/24 are marked with a 2 and forwarded correctly if the routing tables are setup correctly. If you don't care how this is done, just skip the following indented paragraph.
When you mark packages and you want those package to select another route then the default routing table, you will need to create an IP rule
ip rule add fwmark 0x2/0x2 lookup 2
Basically all the packets with mark 2 will be routed using another routing table as the default called "2"
Then you will need to add routes to this alternate routing table
ip route add 192.168.1.0/24 dev eth1 table 2
You can query the result using
ip route list table 2
It should show you something like
192.168.1.0/24 dev eth1 scope link
If the default routing table send all the traffic to eth0, your problem is solved.
All the traffic generated on interface 0 that has to be NAT will be marked. During routing, based on this mark the router will use an alternate routing table. This will state that the traffic should be send via eth1.
If the traffic is occurring from interface 1 it will not be marked. Hence the routing process will use the default table and forward the packet to interface 0.
Routing will be done and finally the package will enter the Post routing stage just before it is send out on Interface 1
| IP Packet |
|---|
| Source | 192.168.1.2 192.168.1.1 |
| Destination | 192.168.2.2 192.168.1.2 |
| Message | Hello from Client X |
The Server will receive the package and will reply. It will send over the reply to the router; There again, the reverse process will rewrite the package in an inverse order
| IP Packet |
|---|
| Source | 192.168.1.2 |
| Destination | 192.168.1.1 192.168.1.2 |
| Message | Server A at your service |
| IP Packet |
|---|
| Source | 192.168.1.2 192.168.2.2 |
| Destination | 192.168.1.1 192.168.1.2 |
| Message | Server A at your service |
Interesting in this scenario is that although Client X can start the conversation to Server A, Server A can only talk back. Server A is thus in the isolated environment.
