Network Address Translation (NAT)

The Internet has grown larger than anyone ever imagined. Although its exact size is unknown, the current estimate is that there are approximately 100 million hosts and more than 350 million users actively on the Internet. This is more than the entire population of the United States. The Internet is effectively doubling in size each year.

When IPv4 addressing first appeared, everyone thought there were plenty of addresses to cover any need. Theoretically, you could have 4,294,967,296 unique public addresses (232). The actual number of available public addresses is smaller (somewhere between 3.2 and 3.3 billion) because of the way the addresses have been separated by the Internet Engineering Task Force (IETF) into classes (A, B, C) and the need to set aside some of the addresses for multicasting, testing, or other specific uses (Class D).

With the explosion of the Internet and the ever-increasing need for IP addresses in home networks and business networks, the number of available IPv4 addresses is simply insufficient. The obvious solution is to redesign the IP addressing scheme to allow for more possible addresses. This is being developed in a solution known as IPv6, but it will take many years to implement because it requires the modification of the Internet’s entire infrastructure. As a result, the process of converting from IPv4 to IPv6 has been slow and will likely continue slowly as NAT further extends the life of IPv4. Because of the massive number of addresses that IPv6 provides, NAT was not built into IPv6 initially. RFC 6052 is the most recent update for IPv6.

NAT enables organizations to resolve the problem of IP address depletion when they have existing networks and need to access the Internet. Sites that do not yet possess NIC-registered IP addresses must acquire them from the Internet Assigned Numbers Authority (IANA) and American Registry for Internet Numbers (ARIN), who delight in causing bureaucratic delay. Many sites do not pass ARIN’s bureaucratic detailed examination or justification process and are denied public IP addresses; therefore, NAT is the solution for most organizations.

NAT enables companies to use public IP addresses on the outside of the network (that is, on those devices that connect directly to the public Internet). However, as discussed, there probably will not be enough public IP addresses for every network printer, PC, server, switch, router, wireless device, and so forth to be assigned a public IP address.

These devices need an IP address to connect with TCP/IP, so we use private IP addresses on the internal network. The use of private IP addresses inside our network provides for all devices to now communicate using TCP/IP, which was the goal. However, you must activate NAT because the private IP addresses are not allowed out onto the Internet.

NAT is deployed and implemented on a device (firewall, router, or computer) that sits between an internal network using private IP addresses and the Internet, which uses public IP addresses. The device performing the address translation from private to public is usually a firewall and, to a lesser extent, a router. The device performing NAT usually sits with one part connected to the internal network and another part connected to the Internet (or some external network). Figure 5-7 shows the placement of NAT as part of a layered defense-in-depth architecture.

Figure 5-7 Placement of NAT in a Network

Discussion of how NAT also provides an additional level of security to your network is discussed later in the section “Increasing Network Security.” NAT has many forms and can work in several ways:

• Static NAT: Provides for mapping a private IP address to a public IP address on a one-to-one basis. This is particularly useful when a device needs to be accessible from outside the network; for example, if your web server has an internal IP address of (10.0.0.1) and it needs to be accessible from the Internet—it is your web server, after all! NAT must be statically configured to enable users who have only a single public IP address for it always to be translated to 10.0.0.1. The use of static NAT is quite common for devices such as web servers, which must always be accessible from the Internet.

• Dynamic NAT: Provides for mapping a private IP address to a public IP address from a group of registered IP addresses. In this type of NAT, there is a one-to-one relationship in the mapping from private to public. For example, if your PC is assigned an internal IP address of 10.0.0.2 and your co-worker is assigned 10.0.0.3, each of you would be assigned a public IP address at the firewall via NAT as your traffic went to the Internet. Dynamic NAT is helpful, but it might not be the right solution in many cases. For example, what if your other co-worker wanted to access the Internet and the firewall was out of available public IP addresses? He would be denied. This could introduce a serious problem; therefore, NAT overloading was developed.

• NAT Overloading (aka PAT): A form of dynamic NAT that provides for the dynamic translation of multiple private IP addresses to a single public IP address by using different TCP ports. This is also known as Port Address Translation (PAT) or single address NAT. Its many names are not important, but how it functions is crucial. Because, with 65,535 TCP ports possible per single IP address, NAT enables an effective means of providing Internet access to many users who have been assigned private IP addresses. This type of NAT is the most commonly used because it serves large numbers of users at once.

Increasing Network Security

Solving the IPv4 address depletion and waste problems was the leading reason for the development of NAT, which also provides for yet another layer of security to protect your network. In general, using NAT makes it slightly more difficult for an attacker to do the following:

• Discover and map the target’s network topology and determine connectivity

• Identify the number of systems running on a network

• Identify the type of machines and the operating systems they run

• Implement denial-of-service (DoS) attacks such as SYN (synchronize/start) flooding, port and service scans, packet injection, enumeration, and escalation of privilege on your network

NAT’s Limitations

It is clear that the introduction of NAT to the realm of networking and the Internet has solved or at least extended the IP address depletion problem. Many people have asked whether networks will ever evolve to IPv6 now that NAT works so well. The question is not actually if, but when will this conversion take place. For example, the Asia/Pacific region of the world is leading the implementation of IPv6 with many networks already using it.

As connectivity and convergence increase, the need for additional IP addresses will grow and expand. We will therefore make the change to IPv6 eventually; NAT has simply delayed the inevitable. NAT is useful and has brought advantages; however, it does have some limitations:

• Issues with UDP: NAT tracks and controls connections based on state and, as discussed earlier in this chapter, UDP has no inherent mechanism to determine state because it is connectionless as a protocol. Thus, NAT has no way of knowing whether a packet is part of an ongoing conversation or an isolated transmission. NAT devices then need to guess at how long a conversation involving UDP should remain open after the last packet; this is known as the idle time. Cisco firewalls provide the functionality to set idle time on UDP sessions to limit such cases.

• Sensitive protocols: Some protocols hide, alter, or otherwise obscure aspects of the packets that NAT requires to properly perform the translation. For example, IPsec VPN, Kerberos, X-Window, remote shell, and Session Initiation Protocol (SIP) can have trouble operating through a NAT device. This trouble is caused by applications that have embedded IP addresses in the packets where this issue occurs. Cisco firewalls have special “inspect” for different protocols, such as Skinny for telephony, that enable these applications to work when the inspect command is activated.

• Interferes with encryption and authentication systems: Many data encryption systems attempt to ensure the integrity of packets by ensuring that packets were not tampered with in transit. By its design, NAT tampers with packets, thus causing encryption and authentication technologies to not work well with NAT (by default). This is commonly seen with IPsec VPNs when a VPN device expects unaltered packets but the user is behind a firewall performing NAT. This means my VPN packets leave my computer and get NAT’d to be sent off onto the Internet, and <boom> the VPN breaks.

• Complicated logging: When devices log through a device, the correlation of the logs requires users to understand the translations being performed by NAT. Correlation of system logs with the NAT system can thus become highly complicated and tedious to understand which internal systems were actually involved.

• One size fits all: If your organization is using PAT, and one person in the company authenticates to a protected resource outside your company, it’s possible that the rest of your organization now has access to that resource as well. Remember that if you use PAT, you’re using only one IP address that has been multiplexed using port numbers. The protected resource that requires authentication sees all conversations from your company as coming from the same IP address.

As NAT has matured, there have been ways of addressing many of these limitations allowing them to work seamlessly; the VPNs requirement for special exemption from the packet-checking process of IPsec is one example. The final point to reinforce is that NAT is useful in many regards, from enabling an entire company to access the Internet to providing an additional layer of security. If you go back to the network referenced in figures throughout this chapter, you can see that including NAT adds another layer of protection (refer to Figure 5-7).

The following section looks at how security can be further deepened through tools and technologies that look deeper into a TCP packet.