Networks (and applications) are getting more and more global and the usage of NAT is inevitable. To run application efficiently such global networks (that are built over internet) should be NAT-friendly, which means aware of NAT operation!
In this post, we’ll review the general idea behind NAT operation and how it could affect positively (friendly) or negatively (unfriendly) the performance of our network services on the cloud.
First of all, what NAT Stands for
NAT stands for network address translation which means that to join a destination, a source will use at least two addresses (IP): one to the NATter (the device that will do this translation, firewall, router, application gateway, etc.) and another one from the NATter to the destination. This helps resolve many routing issues, IP address space starvation, management, add more security by hidden the original IP information…
NAT and P-NAT
Ideally, the NATter (application) would map each “inside” address (that is towards the NATted source) to an “outside” or “global” address (that is towards the destination) in a one to one fashion. But, it is possible to overload the outside interface of the NATter by mapping inside addresses to application ports (TCP or UPD); many inside address could be mapped to one global address and many ports. In this case the NATter is called P-NATter (P for port).
Hierarchical NATting
Things could get more complicated in case at least two NATters exist in the transit path from the source to the destination. Let’s see what happens in those scenarios: 1) two NATters, 2) one NATter and one P-NATter, 3) two P-NATters.
Session ports usage
In the case where the traffic goes through two P-NATters, the first P-NATter creates an entry in its translation table mapping the inside IP address to the overlapping outside IP address and adds a distinguisher that is a port number. This port information should be sent in the packet (from the source) so that the destination returns it to the correct source port (the outside interface is acting as an application server).
When the second P-NATter receives the firstly P-NATted packet (with the first outside global address and source port TCP or UDP), would it keep the same in its translation table? or use another one? the answer to this question may depend also on where was firstly stored this packet source port information and how… but as for now, only source and destination ports in the in the TCP/UDP headers are altered.
Application ports information
From an upper-layer point of view, the application have specific service ports that it passes to TCP and UDP (FTP application for example may use multiple TCP sessions) and that shouldn’t be altered (the service may break). How to store this information? in the payload? and reserve the header port fields for NAT (to ensure network continuity)? or at NATer level in its translation table?
Translation table size
Let’s note also that the translation tables (of all NAT nodes in the path) are of limited size. What happens if no port is available for the next translation? is there any mechanisms to hint on the end of a session? Yes, in TCP thanks to FIN and SYN packets, we may know when to drop a session. But it is another story using UDP…
As a summary
How NAT friendly is your network depends on two things : how your network is configured but also on you application behavior.
