NAT: Network Address Translator
Ron McCarty
Due to the well-publicized global IP depletion, the Internet community and vendors developed NAT (Network Address Translator). NAT allows organizations to use non-unique addresses (RFC 1918) internally to be translated into unique addresses. NAT is formalized in RFC 1631 and revisited in RFC 2663. Additionally, the IETF has a Web page for its NAT working group at: http://www.ietf.org/html.charters/ \
nat-charter.html. This article covers the intricacies of NAT as well as various architectures that can be deployed within your organization and shows how NAT can help solve network architecture challenges.
The Mechanics To help explain NAT, I've provided a simple view of it in action (Figure 1). The user typed a URL into his browser, which triggered a session with www.sysadminmag.com after name resolution. Once NAT receives the initial TCP packet, it replaces the source address with its own external address and the source port with an available port.
NAT then computes a new checksum (required for the IP, ICMP, and TCP headers, but not for UDP) and places the new checksums in the packet. NAT then adds the mapping created in its active state table until it determines that the session is no longer active.
When the replies for the session are received, NAT examines the destination port address to determine which internal host is associated with the reply packets. Assuming an entry exists in the state table, NAT replaces the destination port and address with the original client port and address and computes necessary checksums. If an entry does not exist, NAT will either notify the external host via an ICMP host not reachable or silently discard the packet (which is often desired for security reasons).
To remove an entry from its session table, NAT typically waits a determined period of time after the FIN bit is seen for TCP sessions. For ICMP and UDP, a hold-down counter is used. When traffic is not seen to and from the hosts after a fixed amount of time, the entry is removed from the state table. Most firewalls support NAT (including application-level firewalls for unsupported protocol scanning), and work in much the same way with the added inspection steps.
Address Translation Simple Outbound NAT, as previously discussed,is very popular for home and small office use. All traffic is initiated from the inside with limited users so that the state tables will typically remain small and can be serviced by a small router or workstation. Ascend Pipelines, Cisco routers, and Linux (IP Masquerading) are very popular for simple outbound NAT. Since there is only one external address used, most of the processing is actually port address translation (PAT) network address port translation (NAPT).
Since all traffic is initiated from the inside, the simple outbound router is naturally hardened against outside attacks when compared to the same router that is not using NAT. However, this solution should not create a false sense of security -- if the router is compromised, the hacker has full access to the internal network. Packet filtering is provided by most NATs in this class and is recommended. Consider a firewall for environments with tougher security policies.
Basic NAT Basic NAT functions by using at least two globally unique addresses for translation. There are four popular methods for translation:
Static addresses no port address translation -- this mapping is only for an environment where there are enough translated addresses for internal addresses, such as an ExtraNet. For example, if two organizations have overlapping address spaces, such as 192.168.1.0/24, as shown in Figure 2, then static address translations with no port address translation are ideal. Notice that with this method your ExtraNet partner's machines believe they are communicating with the 10.3.1.0/24 network.
Static addresses with port address translation -- this mapping can provide a means of management for address translation in environments where there cannot be a one-to-one mapping of internal addresses to translated addresses. For example, as shown in Figure 3, the Human Resources network 192.168.1.0/24 is translated to 172.1.1.1, whereas the Sales and Marketing network 192.168.2.0/24 is translated to 172.1.1.2. Keep in mind that this type of mapping can become very cumbersome.
Dynamic addresses, no port address translation -- this mapping can be used in ExtraNets where traffic is only initiated in one direction and there are enough translated addresses to meet the need without port address translation. An example of this is a remote site with 40 users that uses RFC 1918 addresses and has received a /24 network for NAT use from its local ISP. Assuming static mapping is not needed for management or accounting purposes, dynamic addresses without port translation are ideal here.
Dynamic addresses, with port address translation -- this method can be deployed in similar environments to the dynamic assignment without port address translation, but where there are not enough translated addresses. An example is a /24 network with 254 addresses available from an ExtraNet partner, but with 2000 clients that will need translation.
Two-Way NAT As shown here, simple outbound NAT and basic NAT do not address environments where sessions are initiated in both networks, including many organizations that have Web, ftp, email, or other services. Two-way NAT is required in these networks, where sessions will be initiated in both directions. Regardless of direction, address translation can take place with one of these methods independent of the other direction. Normally, inbound sessions will be static addresses with no port translation since these will typically be email servers, Web servers, and other servers that are accessible by the Internet or, from a security perspective, your bastion host on your DMZ as shown in Figure 4. When the bastion email server wishes to relay inbound mail, it will connect to 172.3.1.1. The outbound packet receives an address of 172.1.1.1 with dynamic port address translation when an internal browser connects to a web server on the Internet.
The key to effective two-way NAT deployment is simplification. Since traffic in both directions can be treated differently, it is important that the simplest, easiest to maintain NAT is implemented. Most modern firewall software eases the management of two-way NAT and makes NAT very transparent to the administrator. Since security is a major concern in most networks of this size or complexity, firewalls will typically be the NAT for the organization.
Overlap NAT Organizational takeovers often require the use of NAT since address spaces overlap. The overlap can be managed with a well-planned NAT. The plan will typically require identification of central services, with static mappings to those services and dynamic mappings for the clients. The actual topology can consist of two NATs with one placed on each edge of the joining networks, or by a router that supports overlapping NAT. Plenty of processing power and RAM are needed in deployments with large networks.
Additional Design Consideration There are limitations to what NAT can do, as explained in the IETF Web page. Applications that carry IP addresses in the payload may not encounter a NAT unless they are documented and supported by the NAT-like ftp (supported by most NATs). Always draw out address mappings to refer to during configuration and check vendors' recommendations on processing power and RAM, based upon users and network access. NAT is a good addition to your network design tool kit. Enjoy!
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: mccarty@my-own-domain.to.
|