Network Address Translation (NAT) is the process of remapping one IP Address space into another by modifying the network addressing information in IP header packets. This process occurs while the packets are in transit across a traffic routing device and was originally used as a shortcut instead of having every individual host readdressed whenever a network was moved. Since then, however, especially thanks to the exhaustion of IPv4 addresses, NAT has become a popular and essential tool for conserving global address space. This is because even just one Internet-routable IP Address of a NAT gateway can be used for an entire private network.
It should be noted that while NAT has become popular and commonplace because of how great it is for conserving address space, it does carry with it serious consequences to the quality of an Internet connection. As such, careful and great attention to detail is needed when implementing it to ensure that it does not become a detriment. This is because the implementation of NAT can vary in addressing behavior and their effect on network traffic.
There are two main types of NAT and the simplest version of it is fittingly called Basic NAT which performs one-to-one IP Address space translation. In this version, only the IP Addresses, IP header checksum, and any higher-level checksums that include the IP Address are translated. It is typically used to connect two networks which have incompatible addressing.
The other type of NAT is called One-to-Many NAT which is the more common version used. This version allows multiple private hosts to be mapped to one publicly exposed IP Address. As a matter of fact, it is through this method that allows the typical local network configuration to be the use of a designated private IP Address subnets. In this setup, a router on the network will have a private address in that address space while also being connected to the Internet by having a public address assigned by an Internet Service Provider (ISP). This allows the router to apply the source address for each packet as the private address of a host on the local network on the fly before passing it onto the Internet. It then tracks this basic data and when a reply returns to it, it uses this data which it tracked to identify for which private host on the network needs it. It should also be noted that it is through this method which helps conserve IPv4 Addresses.
As some application protocols that use IP Address information they would need to determine the external address of the NAT; that is, the address which the NAT’s private hosts use for communication. These protocols may also need to identify and categorize the type of mapping implemented; especially in the case of communication between two hosts who are behind two separate NATs. This led to the creation of the Simple Traversal of UDP over NATs (STUN) protocol which classified NAT into four categories: full-cone NAT, address-restricted cone NAT, port-restricted cone NAT, and symmetric NAT. With this protocol was also a methodology on how to identify these types of implementations, however; they have been deprecated as they failed to correctly assess many devices. New methods have been since standardized and the STUN acronym has since been changed to mean Session Traversal Utilities for NAT.
A Full-Cone NAT has two core features. Firstly, any internal address mapped to an external address, all packets sent to that external address is sent to the internal address. Secondly, any external host can send packets to an internal address by using its external address.
An Address-Restricted Cone NAT is similar to a Full-Cone NAT in that any internal address mapped to an external address receive packets sent to the external address. It differs, however, when considering that its other feature is that an external host can only send packets to an internal address via its external address only if the internal address has previously sent a packet to the host. It should be noted that for the external host, it doesn’t matter which port number is used. Post-Restricted Cone NATs are identical to Address-Restricted Cone NATs with the only difference being that the restriction also extends to the port number.
And finally, a Symmetric NAT’s core features revolves around having each request from an internal address (and port) to a specific destination address (and port) is mapped to a unique external source address (and port). However, if the same internal host sends a packet to a different destination; even if its internal address (and port) are the same, a different mapping is used. The other core feature of the NAT implementation is that an external host can send a packet to an internal host only if it received a packet from that internal host.
It should be noted, however, that despite these translation methods have been standardized, there is still a lot of confusion surrounding them and their terminology as many believe they do not accurately identify modern-day NAT implementation.
When it came to the issue of having two peers behind separate NATs trying to communicate, port-forwarding was another solution used along with NAT traversal techniques. The most common of these techniques for the Transmission Control Protocol (TCP) is TCP hole punching which required the NAT to follow the port preservation design of TCP. On the other hand, communication over the User Datagram Protocol (UDP) did not need to use this as multiple UDP communications can occur on the same source port and applications reuse the same UDP sockets to send packets to distinct hosts. In other words, port prediction over UDP is straightforward as it is the same source port for each packet; something that is impossible for TCP.
NAT can be a very common and powerful tool for use, however; it is not without its limitations. Private hosts behind a NAT-enabled router cannot use end-to-end communication and thus; cannot use some IP protocols. For instance, services which require TCP connections from outside the network and stateless connections like UDP can all be disrupted. This means that the router itself must make an effort to support these protocols less incoming packets which use them will never reach their intended recipient. Some protocols can support an instance of NAT between hosts, such as the File Transfer Protocol (FTP) when in passive mode, but they will sometimes need help from an application-level gateway and they will fail when the systems are separated from the Internet by NAT. Another limitation is that tunneling protocols are also complicated as NAT changes values in the headers of packets which will affect the integrity checks of these protocols.
Another limitation is that in certain NAT implementations, particularly those which are designed only to track ports can face exhaustion and depletion by internal applications which use simultaneous connections like an HTTP request for a web page with many embedded objects. This is a problem which can be mitigated by tracking the destination address and port on packets but it comes at the cost of implementation complexity and CPU/memory resources of the translation device.
Another issue is that because the internal addresses are hidden behind a single publicly accessible one, it is impossible for an external host to initiate communication to an internal host without some special configuration on the firewall to allow this. As such, applications which utilize Voice over IP (VoIP), video-conferencing, and other peer-to-peer features must NAT traversal techniques to function.
Throughout time, the NAT technique evolved and formed various derivatives and innovations from it. One of the more confusing ones is called SNAT, an acronym which can mean quite a few different things depending on which company utilizes it. Source NAT is a common expansion of NAT and is the counterpart to DNAT, Stateful NAT is used by Cisco Systems, Static NAT is used by WatchGuard, and Secure NAT is used by F5 Networks and Microsoft. Microsoft’s SNAT, in particular, is part of their Internet Security and Acceleration (ISA) Server and an extension for their NAT driver in Microsoft Windows Server.
Destination Network Address Translation (DNAT) is a derivative of NAT which revolves around transparently changing the destination IP Address of an end route packet and performing inverse for replies (Source NAT). It is commonly used for deploying a service which might be located on in a private network onto a publicly accessible address. This type of DNAT can also be referred to as port-forwarding when used on an entire server. Typically, any router which is set up between two endpoints can perform this technique.
Dynamic NAT (also DNAT), like Static NAT (used by WatchGuard), is not common in small networks but in large networks used in corporations with complex networks. While Static NAT provides a one-to-one internal to public static IP Address mapping, Dynamic NAT differs by not making the mapping static and uses a pool of available public IP Addresses.
NAT loopback (also called NAT hairpinning or NAT reflection) is a common feature in consumer routers which allows access to a service on a private network via the public address. This feature eliminates the need to use separate domain name resolution for hosts on the network rather than for the public network of a website.
Although not a direct derivative, IP masquerading is another technique which makes it possible to hide an entire IP Address space behind a single IP Address in another IP Address space. Typically, the hidden IP Address space consists of private IP Addresses while the address space of the non-hidden IP Address is public. Through this method, a hidden address is changed into a public one as a “new” source address of an outgoing IP packet to make it appear as if it is coming from the routing device and not a hidden host. This technique has made the terms IP masquerading and NAT are synonymous in the modern world as it can also help with conserving IPv4 IP Addresses.
Finally, it should be noted that NAT is not commonly used in IPv6 since one of the goals of IPv6 is to restore end-to-end network connectivity. This means that NAT loopback is not needed and although its possible, the large addressing space of IPv6 makes diminishes the need to conserve addresses.