How Address Translation Works
Now that you have a basic understanding of what address translation is, take a look at some of the terms used in address translation, as well as the different kinds of address translation. Many different kinds of devices, such as firewalls, routers, and even servers, can perform address translation (Cisco routers have supported address translation sine Cisco IOS 11.2). The following sections will help you become more familiar with these concepts.
Terms Used in Address Translation
Before you can understand how address translation is performed by a device, you first need to become familiar with some terms commonly used with address translation. Table 11-2 explains some basic terms used with address translation; Table 11-3 explains some common types of address translations.
Term | Explanation |
|---|---|
Inside | These devices are located inside your network. |
Outside | These devices are located outside your network. |
Local | These addresses physically are assigned to devices. They are typically private addresses but can be public addresses. |
Global | To the outside world, devices appear to be using these addresses. These are public addresses but are not necessarily translated addresses because these devices can be assigned public addresses. |
Inside local address | This is an address that either is statically assigned or is assigned through DHCP to your internal device. It can be a public or private address. This is the address that other internal devices in your network see in the source IP address field when viewed inside the network. |
Inside global address | This is an address that your internal device appears to be using. It can be assigned by an address-translation device. This is the address that external devices (devices outside your network) see in the source IP address field. |
Outside local address | This is an address that an external device is using in its configuration when it generates packets. |
Outside global address | This is an address that an external device appears to be using. This is what your devices see in the source IP address field of the remote device's packet. |
Term | Explanation |
|---|---|
Simple translation | One IP address is translated to another IP address; this commonly is called Network Address Translation (NAT). |
Extended translation | One IP address and port number are mapped to another IP address and possibly a different port number. This commonly is called Network Address Port Translation (NAPT) or Port Address Translation (PAT). |
Static translation | Address translation is configured manually on an address-translation device, mapping one address to another. This also can include port mappings. With port mappings, this commonly is called Port Address Redirection (PAR). |
Dynamic translation | Address translation dynamically is performed by an address-translation device by using a pool of addresses. This also can include the dynamic assignment of new port numbers. |
Address Translation TermsIn the industry, I commonly see people misuse address translation terms. For example, I see people use the term NAT to refer to NAT and PAT. In reality, NAT refers to an address translation of one IP address to another, whereas PAT refers to translating many IP addresses to a single IP address and making sure that the source port numbers are unique for each of these translations. Be aware that these terms sometimes are used loosely in the industry. |
Performing Address Translation
Many different types of address translation exist, as you saw in Table 11-3. This section covers the mechanics and the variations of the different kinds in this table, focusing on specific address translation types.
Network Address Translation
The most common form of address translation is the translation of one IP address to another. Two common forms of this translation exist:
Changing a source inside local address to a source inside global address
Changing a destination inside global address to a destination inside local address
You can see how this is done by examining Figure 11-2. In this example, the network on the left is using private addresses (10.0.0.0/8), and the router is performing address translation for these addresses. In Step 1, 10.0.0.1 creates a packet destined for 200.1.1.1. In Step 2, the router receives the packet and performs address translation on the source address. The router first looks at its static configuration for address translation. If it finds a match, it uses the inside global address as the replacement; if not, it uses a dynamic assignment method by checking to see whether this packet should be translated and, if so, what pool of addresses the router should use. In this example, the source IP address was translated from 10.0.0.1 to 192.1.1.1. When the destination device (200.1.1.1) receives the packet in Step 3, it thinks that it is talking to 192.1.1.1 and thus replies to this address. As mentioned earlier, one advantage or disadvantage of this is that the source is anonymous, depending on your view; in this example, the destination has no idea who the real source is. In Step 4, the router receives the packet and performs its address-translation process again. In this instance, though, it changes the destination IP address in the packet header: 192.1.1.1 to 10.0.0.1.
Figure 11-2. Network Address Translation Example
NOTE
One important thing to point out concerning NAT (versus PAT) is that, for each device that sends packets through the address-translation device, you need a separate inside global IP address. For example, if you have simultaneous outbound connections from 500 inside devices, you need 500 global addresses either statically configured or dynamically assigned through an address pool on the address-translation device. Each device needs a unique inside global IP address. Because you might have thousands of internal devices, but only a limited number of public addresses, NAT typically is not used to assign IP addresses for internal devices as they make outbound connections. Instead, NAT is used to assign addresses to devices that external users need access to, such as internal DNS servers, web servers, e-mail servers, FTP servers, and other types of public resources.
Overlapping Addresses
Sometime during your life as a network administrator, you probably will need to connect two networks, but they happen to be using the same address space. Obviously, this creates connectivity problems. As an example, look at Figure 11-3. Companies A and B are using 10.0.0.8/24. This would be okay if both companies used different subnet numbers, with A using 10.1.x.x and Company B using 10.2.x.x. However, as you can see in this example, both companies are using some of the same networks and addresses. This presents a connectivity problem. How can 10.0.0.1 in Company A send information to 10.0.0.1 in Company B?
Figure 11-3. Overlapping Addresses Example
To overcome this problem, you must do one of two things:
Readdress one of the two networks (or both networks)
Use address translation
Address translation can be used to solve this problem. In this example, the router connected to Company A translates the local IP addresses to an address in the 172.16.0.0/16 network. Company B's router translates its inside local addresses to 172.17.0.0/16. Therefore, from the two companies' perspectives, the networks look like 172.16.0.0/16 and 172.17.0.0/16. However, there is one issue with this type of address translation: Normally, devices use names to access other devices, and they rely on DNS to resolve names to IP addresses.
Take a closer look at this problem. Assume that the device on Company A (10.0.0.1) wants to access www.companyb.com, which is a web server. It does a DNS lookup, and the DNS server in Company B replies with 10.0.0.1. Company A's device then uses this IP address as a destination and tries to set up a connection to itself. To solve this issue, address-translation devices also need to inspect DNS replies and fix the DNS replies with the appropriate address, commonly referred to as DNS doctoring. In this example, Company B's address translation device would have to change the DNS reply address of www.companyb.com from 10.0.0.1 to 172.17.x.x, an address that does not overlap with Company A.
TIP
Use address translation as only a temporary solution when solving overlapping addresses. In other words, use address translation to solve the initial connectivity problem, but begin readdressing one or both networks so that address translation is not necessary. Remember that address translation has its deficiencies. If these networks constantly will be communicating with each other, you want to take address translation out of the picture. Plus, eventually removing address translation makes it much easier to implement, enforce, and troubleshoot your policies.
Also, many companies require vendors to use specific addresses with the VPN when using extranet VPNs. In this situation, either you or the vendor must translate the addresses. Sometimes this is done for security reasons, but in many cases, it is to ensure that overlapping addressing does not cause a problem.
Address Overloading
Address overloading, commonly called PAT, uses one or more inside global IP address to encompass all inside devices. To differentiate between the different internal connections, PAT ensures that the TCP or UDP source port numbers in the segment header are unique. With this capability, an address-translation device can handle thousands of inside local addresses with a single global address.
NOTE
Theoretically, this would enable you to map 65,536 addresses to a single address because the source port field in a TCP or UDP segment is 16 bits in length. Realistically, though, only about 4000 devices can share a single global IP address because certain port numbers are not used or are not recommended for use. Therefore, if you have 6000 devices that need outside access, you need two inside global addresses for PAT.
Take a look at an example of how address overloading works. In Figure 11-4, the network on the left is using PAT to translate inside local addresses to one inside global address: 192.1.1.1. For the first connection, 10.0.0.1 Telnets to 200.1.1.1 using a source TCP port number of 1024. As you can see from the first entry in the router's address-translation table, the router translated the source IP address to 192.1.1.1 but left the source port number as is because this is the first connection; therefore, no other device is using the same source port number. 10.0.0.1 then makes another Telnet connection to 200.1.1.1. As a source port number, 10.0.0.1 chooses a number greater than 1023 that is not in use; in this instance, it chose 1025. As you can see from the second entry in the address-translation table, the router translated only the source address because the source port number is different from the one used in the first entry. For the third connection, a different device (10.0.0.2) Telnets to the same destination. In this instance, the source port number happens to be the same as the first connection; therefore, the address-translation device changes the source address (10.0.0.2 to 192.1.1.1) as well as the source port number (1024 to 1026). From this translation table, the router easily can determine, based on returning traffic, how it should undo the address-translation process.
Figure 11-4. Address Overloading Example
TIP
Note that NAT and PAT are not mutually exclusive. Where NAT is used to perform address translation of inside addresses that external users need to access, PAT typically is used to conserve addresses as inside users access external resources. As an example, assume that your ISP assigned you six public IP addresses. If you had a DNS server, a web server, and an e-mail server, you would need three static NAT configurations for these devices, using up three addresses. This would leave you with three addresses. Assume that you had only 1000 devices that needed access to the Internet. In this example, you could use PAT with one of the remaining public addresses to allow outside access, still leaving you with two spare public IP addresses.
One issue with PAT is that it works fine for traffic that uses TCP and UDP as a transport. However, how can PAT work for applications or protocols that do not use TCP or UDP, such as ping, which uses ICMP? ICMP does not have port numbers. To solve this problem, a vendor typically uses a proprietary mechanism to place identifying information in either the packet header or the payload, to help undo translations for returning traffic. However, this assumes that the destination will include this information in the packet header or payload of returning traffic. Some vendors maintain a state table for this kind of translated traffic, keeping tabs on who generated what, thereby undoing the translation correctly for returning traffic. However, this can pose a problem if two inside devices send the same kind of information to the same destination device. For example, two internal devices simultaneously might ping the same destination device. In this example, the address-translation device could not rely on state information alone to undo the address translation; it would need some type of additional identification information in the returning packets.
CAUTION
PAT works fine with most TCP and UDP connections, but it can experience problems with other types of protocols, such as ICMP, IPSec (with either AH or ESP), PPTP, and others. There is no guarantee that a vendor will support a PAT process for non-TCP and non-UDP connections. In some instances, you might have to use NAT for devices that need to use other protocols, such as IPSec with ESP, when accessing external resources, instead of using PAT.
Traffic Distribution and Load Balancing
One of the commonly forgotten uses of address translation is the traffic distribution feature, commonly called load balancing. As an example, assume that you have a web server that contains content that is very popular on the Internet and that is getting thousands of hits every hour. Because of this traffic, load, the CPU processing on the server is very high and sometimes hits 100 percent, causing it to drop many connection requests and frustrating external users with poor download times. One solution to this problem is to buy a bigger, faster server. However, if you have ever been through this process, it is not simple to buy a new server, migrate the information to the old server, and then swap the old server for the new one.
Traffic distribution in address translation enables you to get around this upgrade process. Instead of swapping out an older server for a newer one, you can purchase a second server and simultaneously use both. At first, you might think that this would cause a problem because both servers have different IP addresses. You could have your DNS server respond in a round-robin fashion, to assign one address to one DNS request, the other address to a second request, and so on. This assumes that your DNS server supports this function; however, one downside to this approach is that the requesting client caches the DNS information and uses it repeatedly. This can lead to a disproportionate amount of traffic being sent to one of the two servers.
A better approach is to have an address-translation device perform this process. In Figure 11-5, the network on the left has two internal web servers that have exactly the same content. The internal DNS server advertises this content as being at 192.1.1.5, even though both servers have the content. When an external device accesses 192.1.1.5 on TCP 80, the address-translation device looks at the last translation that it made and then chooses the next IP address in the server pool for this request. As you can see in this example, the two external users use the two internal servers to obtain the same content.
Figure 11-5. Traffic Distribution Example
CAUTION
Many different kinds of products, including Cisco IOS routers, perform traffic distribution. However, not all of them do this process equally. For example, some solutions just round-robin between the different server addresses, not checking to see if the server is actually available or checking the current load on the server. Some solutions actually check on the server's status and use this when computing how it should perform traffic distribution. Using a Cisco IOS device is probably not the best load-balancing solution: The Cisco local director or content switches would provide a better solution.
Limitations of Address Translation
Even though address translation provides many solutions to your connectivity problems, especially when using private addresses, it does have limitations and restrictions.
For example, as mentioned with PAT, PAT does not work with all types of IP protocols. Here are some common limitations in which address translation might not or will not work:
Many applications embed IP address and port number information in the payload. Unless an address-translation device is designed to look for this kind of information, these applications will fail when address translation is used. For example, ICMP, SNMP, DNS (replies and zone transfers), BOOTP and DHCP, routing updates, NetBIOS, and multimedia applications commonly include IP addressing in the payload of packets. Chapter 12, "Address Translation Issues," discusses how a Cisco router deals with this issue.
Address translation will not work if the headers of the packet or the segment are encrypted.
Some vendors do not support address translation for multicast addresses (the Cisco IOS does, but that is beyond the scope of this book).
There are other limitations, but these three (especially the first) are the most common issues you will find when dealing with address translation.
