Chapter 21. NAT
21.0. Introduction
Network Address Translation (NAT) was first described in RFC 1631 in 1994. The authors of that document were trying to solve the imminent problem of running out of IPv4 addresses. They proposed a simple but brilliant solution: allow devices on the inside of a network to use the standard pool of unregistered IP addresses currently defined in RFC 1918. The router or firewall at the boundary between the internal private network and the external public network could then use software to rewrite the internal IP addresses of every packet, replacing them with valid registered addresses.
There are four kinds of addresses: inside local, inside global, outside local, and outside global. Inside and outside are relative terms if you’re just connecting two private networks. But if you are connecting a private network to the public Internet, the Internet is considered the outside. A local address is generally the private address, while the global address is the globally unique public address.
To help make these terms more clear, suppose you are connecting a network that uses RFC 1918 private addresses to the public Internet. Inside your network you have private addresses, such as 192.168.1.0/24. These are the inside local addresses. NAT will translate these addresses to globally unique registered addresses, which are also the inside global addresses. The addresses on the public Internet are outside global addresses. These external network addresses are all registered in this case, so there is no need to translate them. If translation was needed, an outside global address would be changed to an outside local address.
To put this another way, the address that internal devices use to communicate with other internal devices is the inside local address. The address that internal devices uses to communicate with external devices is the outside local address. The address that external devices uses to communicate with internal devices is the inside global address. Finally, external devices communicate with one another using outside global addresses.
NAT makes it possible to have a huge internal network with thousands of local addresses represented by a handful (or perhaps even just one) global address. This is why NAT is often credited with alleviating the address shortage problem. But it solves this problem only if most people who use it have more local than global addresses.
In practice, NAT offers a huge range of possibilities. You can map local addresses uniquely to individual global addresses. You can share one global address among several local addresses. You can allocate global addresses from a pool as they are requested, or have a single global address and map all local addresses to this one address. You can even define a combination of these different alternatives.
When a device sends a packet out from the private to the public network, the translator replaces the local source address with a registered address, then routes the packet. For an inbound packet, the translator replaces the global address with the local address and routes the packet into the internal network. The translator has a much more difficult job with inbound packets than outbound, because it has to figure out which internal device to send the packet to. Since many internal devices may be using the same global address, the translator has to keep a state table of all of the devices that send or receive packets to or from the external network.
Suppose, for example, that two internal users are both using HTTP to view information on the public network. The translator must be able to determine which packets are intended for which internal device. It’s not sufficient to simply look at the external device’s IP address—both of these users could be looking at the same web page. They would both wind up with severely scrambled screens if the translator couldn’t tell which packets to send to which internal user.
This particular example is made somewhat easier by the fact that HTTP uses TCP. Because TCP is a connection-based protocol, well-defined TCP session initiation and termination helps the translator to sort out the inbound flows. In this case, Cisco’s NAT implementation uses Port Address Translation (PAT), which means that the router rewrites the source port numbers, and uses the new values as tags to distinguish between the two flows. Because UDP also uses port numbers, the same PAT technique also works here, although the router doesn’t keep the translation table entries active for the same length of time.
ICMP, on the other hand, is considerably more difficult for NAT to keep straight. For example, if two internal users both ping the same external site at the same time, the translator has to assume that it will receive the responses in the same order that they were sent. Fortunately, this rarely causes real problems in production networks. But it is worth remembering that, whether it can use PAT or not, NAT requires the router to keep track of a lot of state information that routers don’t usually care about.
Further, because IP addresses and port numbers are included in both IP and TCP checksums, the translator must recalculate these checksum values for every packet. So NAT always consumes more CPU and memory on the router or firewall that it runs on. This resource usage increases rapidly with both the number of packets and the number of different flows.
The other important thing to remember about NAT is that some protocols include IP address information in the payload of the packet, as well as in the IP header. For example, the ubiquitous FTP protocol has a PORT command that contains an IP address encoded in ASCII. In this case, the FTP protocol is well understood and NAT implementations can look out for the PORT command. But in other, less popular protocols, strange problems can occur. And, if a server happens to run FTP on a nonstandard TCP port, you must tell NAT about the change so that it can rewrite the payload addresses.
SNMP also includes IP addresses in packet payloads. For example, IP address information is part of the standard interface MIB because the address is an important piece of information about the interface. However, rewriting addresses in the pay-loads of SNMP packets is a much more difficult problem than finding the IP address for FTP, because the address could be anywhere in the payload. It is also possible for the addresses in the payload to refer to different interfaces than the address in the header. And, to make the problem even more difficult, there is no common standard format for IP addresses in SNMP packets. They are sometimes transmitted as dotted decimal ASCII strings, as packed hex bytes, or in a variety of other formats depending on the specific MIB. Consequently, Cisco routers do not attempt to rewrite IP addresses in the payloads of SNMP packets.
We have also seen custom-built applications that make life very hard for NAT by encoding IP addresses and port numbers in the data segment of a packet, then using this information to attempt new connections. It can be very hard to get NAT to work in cases like this. Often the only workaround is to encapsulate the ill-behaved application in a tunnel.
21.1. Configuring Basic NAT Functionality
Solution
In the simplest NAT configuration, all of your internal devices use the same external global address as the router’s external interface:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#15permit192.168.0.0 0.0.255.255ip nat inside source listRouter(config)#15interfaceEthernet0/0overloadinterfaceRouter(config-if)#FastEthernet0/0ip addressRouter(config-if)#192.168.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#FastEthernet0/1ip addressRouter(config-if)#192.168.2.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet0/0ip addressRouter(config-if)#172.16.1.5 255.255.255.252ip nat outsideRouter(config-if)#endRouter#
Discussion
In this example, the router will rewrite the addresses of all of the internal devices whose IP addresses are in the range 192.168.0.0/16. When these internal devices connect to devices on the outside of the network, they will all appear to have the same source address as the external interface of the router, 172.16.1.5.
This example actually includes two internal interfaces and one external interface. You designate the internal interfaces with the ip nat inside command. You can have as many inside interfaces as you like:
Router(config)#interfaceRouter(config-if)#FastEthernet0/1ip nat inside
You also need to designate at least one outside interface using the ip nat outside command:
Router(config-if)#interfaceRouter(config-if)#Ethernet0/0ip nat outside
You can also use several outside interfaces, but this configuration can be very difficult to control, so we don’t recommend it. Next, configure the actual translation action with the line:
Router(config)#ip nat inside source list 15 interface Ethernet0/0 overloadThis tells the router to translate the source addresses of any internal devices that match access list number 15. The router will translate the source addresses of all of these devices to the address that is configured on the interface Ethernet0/0, which is the outside interface.
The overload keyword is actually assumed here—if you leave it off, the router will put it in automatically. This option tells the router that many internal devices can use the same global address simultaneously. We explain this option in more detail in Recipe 21.2.
To help explain what the access list in this command does, we change it to include every address in the range except one:
Router(config)#access-listRouter(config)#15deny192.168.1.101access-list15permit192.168.0.0 0.0.255.255
If you make a connection from the excluded address (192.168.1.101) after issuing this command, the router will not rewrite its internal address. Instead, this address will appear unchanged on the outside.
NAT can be quite confusing because people usually think that there are firewall functions associated with it. There are none. If you exclude one device from your NAT access list as we just discussed, anybody on the outside of the network will be able to connect to this internal device by using its real address. Further, there is nothing to prevent an inbound packet from reaching a particular internal device if the person on the outside knows the real internal address and can route to it.
21.2. Allocating External Addresses Dynamically
Solution
You can configure the router to automatically select global addresses from a pool as they are required:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#15permit192.168.0.0 0.0.255.255ip nat poolRouter(config)#NATPOOL 172.16.1.100 172.16.1.150netmask255.255.255.0ip nat inside source listRouter(config)#15poolNATPOOLinterfaceRouter(config-if)#FastEthernet 0/0ip addressRouter(config-if)#192.168.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#FastEthernet 0/1ip addressRouter(config-if)#192.168.2.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet1/0ip addressRouter(config-if)#172.16.1.2 255.255.255.0ip nat outsideRouter(config-if)#endRouter#
Discussion
This example is similar to Recipe 21.1. The important functional difference is that the internal devices will appear on the outside with different global addresses. The first internal device that makes an outbound connection will get the first address in the range (172.16.1.100), the next one will get the next address (172.16.1.101), and so forth.
Configure the range with the ip nat pool command:
Router(config)#ip nat poolRouter(config)#NATPOOL 172.16.1.100 172.16.1.150netmask255.255.255.0ip nat inside source list15poolNATPOOL
In this case, the ip nat inside command does not have the overload keyword. Without this keyword, when the pool of addresses is used up, the router will respond to any additional requests with an “ICMP host unreachable” message. Any additional devices that try to make connections through this router will simply fail. But if you include the overload keyword, the router will simply start over at the beginning of the range and allocate multiple interior addresses for each external one:
Router(config)#ip nat inside source list 15 pool NATPOOL overloadOnce again, as in Recipe 21.1, any devices that are excluded by the access list will simply not use this NAT rule. The excluded devices will appear on the outside with their real (inside local) IP addresses.
In this example, the IP address of the external interface is 172.16.1.2/24, and the pool of translation external addresses for use in translation is 172.16.1.100 through 172.16.1.150. So the pool of NAT addresses is part of the same IP subnet as the external IP address of the NAT router. This is a common practice for Internet connections in which the ISP assigns a range of global addresses, but it is not necessary.
Your NAT pool can be anything, as long as the external network knows that this router can route to the NAT addresses. This is particularly useful in cases where you need a larger pool than what is available in that one subnet. We could easily have made our NAT pool span a Class A range such as 10.0.0.0/8, giving us access to a huge number of external addresses. Of course, this range is not globally unique, so it can’t be used on the public Internet:
Router(config)#ip nat pool NATPOOL 10.0.0.1 10.255.255.254 netmask 255.0.0.0See Also
21.3. Allocating External Addresses Statically
Solution
For some applications, you need each internal (inside local) address to always translate to the same external (inside global) address. This is particularly true if you need inbound connections from the outside network to always reach a particular internal device, such as a web or email server:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#ip nat inside source staticRouter(config)#192.168.1.15 172.16.1.10ip nat inside source staticRouter(config)#192.168.1.16 172.16.1.11interfaceRouter(config-if)#FastEthernet 0/0ip addressRouter(config-if)#192.168.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#FastEthernet 0/1ip addressRouter(config-if)#192.168.2.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet1/0ip addressRouter(config-if)#172.16.1.2 255.255.255.0ip nat outsideRouter(config-if)#endRouter#
Discussion
This recipe includes static translations for two internal devices. The internal address 192.168.1.15 will always appear on the outside as 172.16.1.10, and 192.168.1.16 will always appear as 172.16.1.11. Note that because these translations are static, they will work in either direction. Any packets sent to the NAT address from the external network will reach the internal device, and external devices can even initiate TCP sessions.
This example performs NAT translation only for these two specific addresses. The router will route all other addresses normally without any address translation.
See Also
21.4. Translating Some Addresses Statically and Others Dynamically
Problem
You want certain hosts to have static address translation properties and all others to use dynamic translation.
Solution
In some cases, you might need to use a combination of the two approaches. Some internal devices will always translate to specific external addresses, but others will use a dynamic pool. This is often the case when you have a few internal servers that need to be accessed from outside of the network, but the other devices will make only outbound connections:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#15deny192.168.1.15 0.0.0.0access-listRouter(config)#15deny192.168.1.16 0.0.0.0access-listRouter(config)#15permit192.168.0.0 0.0.255.255ip nat inside source staticRouter(config)#192.168.1.15 172.16.1.10ip nat inside source staticRouter(config)#192.168.1.16 172.16.1.11ip nat poolRouter(config)#NATPOOL 172.16.1.100 172.16.1.150netmask255.255.255.0ip nat inside source listRouter(config)#15poolNATPOOLoverloadinterfaceRouter(config-if)#FastEthernet0/0ip addressRouter(config-if)#192.168.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#FastEthernet0/1ip addressRouter(config-if)#192.168.2.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet0/0ip addressRouter(config-if)#172.16.1.2 255.255.255.0ip nat outsideRouter(config-if)#endRouter#
Discussion
In this recipe, we have used the same pool of dynamic addresses as in Recipe 21.2, combined with the same two static translations from Recipe 21.3. It is often useful to combine NAT techniques like this, particularly when you use the connection between these networks for several different applications. Some applications might need to work with well-known IP addresses, while others could work well from a dynamic pool.
The access list in this example specifically excludes the two addresses that will use static (rather than dynamic) NAT. This is not strictly necessary because the static NAT commands appear to have precedence over dynamic NAT in the router. However, this is still a good practice because your intentions are absolutely clear to anybody looking at the router configuration.
The other important thing to note in this example is that we have explicitly removed the static NAT addresses from the dynamic NAT pool. The dynamic pool is from 172.16.1.100 to 172.16.1.150, while the static addresses are 172.16.1.10 and 172.16.1.11. This is critically important because the dynamic NAT allocation does not check each address in the pool to make sure that is not configured for static NAT translation. You could have serious address conflicts if you do not explicitly separate the static from the dynamic NAT addresses.
See Also
21.5. Translating in Both Directions Simultaneously
Solution
In some cases, you might need to translate IP addresses on both sides of your router:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#15deny192.168.1.15access-listRouter(config)#15permit192.168.0.0 0.0.255.255access-listRouter(config)#16deny172.16.5.25access-listRouter(config)#16permit172.16.0.0 0.0.255.255ip nat poolRouter(config)#NATPOOL 172.16.1.100 172.16.1.150netmask255.255.255.0ip nat poolINBOUNDNAT 192.168.15.100 192.168.15.200netmask255.255.255.0Router(config)#ip nat inside source listRouter(config)#15poolNATPOOLoverloadip nat inside source listRouter(config)#16poolINBOUNDNAToverloadip nat inside source staticRouter(config)#192.168.1.15 172.16.1.10ip nat outside source staticRouter(config)#172.16.5.25 192.168.15.5ip routeRouter(config)#192.168.15.0 255.255.255.0Ethernet0/0interfaceRouter(config-if)#FastEthernet 0/0ip addressRouter(config-if)#192.168.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#FastEthernet 0/1ip addressRouter(config-if)#192.168.2.1 255.255.255.0ip nat insideRouter(config-if)#interfaceRouter(config-if)#Ethernet0/0ip addressRouter(config-if)#172.16.1.2 255.255.255.0ip nat outsideRouter(config-if)#endRouter#
Discussion
Sometimes you need to translate IP addresses on both the inside and the outside interfaces. This might happen, for example, when you need to connect to another network that uses an overlapping range of unregistered addresses. Cisco routers can do NAT translations of addresses on both the external and internal interfaces at the same time.
In this case, the router will rewrite external addresses in the range 172.16.0.0/16 so that they appear to be on the 192.168.15.0/24 subnet in the range specified by the INBOUNDNAT pool. And, at the same time, it will rewrite internal addresses that are part of the 192.168.0.0/16 subnet so that they will appear on the outside to be part of 172.16.1.0/24 in the range specified by the NATPOOL pool.
Note that the access lists defining which addresses should use the dynamic address pool both refer to the real addresses (inside local and outside global). So, for internal devices, the access list should refer to the real internal addresses, while the list for external devices should refer to the real external addresses.
The most significant reason for using this feature is to remove a conflict due to overlapping address ranges. The following example shows how to remove an address conflict at the router between two networks that both use the ubiquitous 10.0.0.0/8 address range. We will map the outside network to 11.0.0.0/8 and the inside network to 12.0.0.0/8. Note that these two address ranges are both registered network numbers, so doing this will cause some problems for Internet access. We recommend doing this only as a temporary measure to resolve an IP address conflict caused by merging two networks with overlapping IP address ranges:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#17permit10.0.0.0 0.255.255.255access-listRouter(config)#18permit10.0.0.0 0.255.255.255ip nat poolOUTPOOL 11.0.0.1 11.255.255.254netmask255.0.0.0typematch-hostRouter(config)#ip nat poolINPOOL 12.0.0.1 12.255.255.254netmask255.0.0.0typematch-hostRouter(config)#ip nat inside source listRouter(config)#17poolINPOOLip nat outside source listRouter(config)#18poolOUTPOOLip routeRouter(config)#11.0.0.0 255.0.0.0Ethernet0/0ip routeRouter(config)#12.0.0.0 255.0.0.0FastEthernet1/0interfaceRouter(config-if)#FastEthernet1/0ip addressRouter(config-if)#10.1.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet0/0ip addressRouter(config-if)#10.2.1.2 255.255.255.0ip nat outsideRouter(config-if)#endRouter#
Note that we have used the match-host keyword in the NAT pool definitions:
Router(config)#ip nat poolOUTPOOL 11.0.0.1 11.255.255.254netmask255.0.0.0 typematch-host
When you use this option, the router will translate the network prefixes and leave the host portions of the address intact. So, in this example, the arbitrary IP address 10.1.2.3 would become 11.1.2.3. Only the first byte would be changed. The key advantage of this method is that the translations are always the same, so you can reliably make connections between any internal and external devices in either direction. You cannot do this with the ordinary dynamic address pools that we have discussed so far. Note that the overload option makes no sense in this configuration.
There are a few important things to watch out for when using NAT in both directions. First, the router must have routing table entries for the fictitious IP addresses. It is quite likely that the translated addresses used for external devices will not be part of a physical IP network that the router knows how to reach. This is why we have configured a static route directing traffic for this range out through the external interface:
Router(config)#ip route 11.0.0.0 255.255.255.0 Ethernet0/0The second important thing to remember is that with dynamic NAT, the router does not create a translation for each device until it needs to. If you want to connect through the router to a particular translated address, you must make sure that the router retains the translation table information. This means that if you want any-to-any connections in either direction, you must use either static mappings or the match-host keyword. Dynamic NAT will not allow access in both directions.
The third important thing to remember is that all of the other routers must know how to reach the translated addresses. So, if the external network is translated from 10.0.0.0/8 to 11.0.0.0/8, then you need to make sure that the internal routers all know that they can reach this fictitious 11.0.0.0/8 network through the NAT router. The best way to do this is by simply redistributing the static routes for the fictitious networks through your dynamic routing protocol.
Recipe 21.6 shows a somewhat better way to solve this overlapping address problem. Instead of doing simultaneous translation in both directions on the same router, it is better to do it on two routers with a different, nonconflicting address range in the middle. One router will simply translate the prefix for one of these networks from 10.0.0.0/8 to 11.0.0.0/8. The other router will translate the addresses on the other network from 10.0.0.0/8 to 12.0.0.0/8. This is a much more stable solution, and it does not suffer from the problems of dynamic NAT mentioned earlier.
See Also
Recipe 21.1; Recipe 21.2; Recipe 21.3; Recipe 21.4; Recipe 21.6
21.6. Rewriting the Network Prefix
Problem
You want to rewrite all of the addresses in a particular range by simply replacing the prefix with one of equal length.
Solution
Sometimes you need to connect your network to another network that uses an unregistered range, such as 172.16.0.0/16. However, if you already use this range in your network, the easiest thing to do is to simply replace this prefix with another one that doesn’t have a conflict, such as 172.17.0.0/16:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#ip nat outside source static network172.16.0.0 172.17.0.0 /16no-aliasRouter(config)#ip routeRouter(config)#172.16.0.0 255.255.0.0Ethernet1/0ip routeRouter(config)#172.17.0.0 255.255.0.0Ethernet1/0interfaceRouter(config-if)#FastEthernet 0/0ip addressRouter(config-if)#10.1.1.1 255.255.255.0ip nat insideRouter(config-if)#exitRouter(config)#interfaceRouter(config-if)#Ethernet1/0ip addressRouter(config-if)#172.16.1.6 255.255.255.252ip nat outsideRouter(config-if)#endRouter#
Discussion
Unlike the previous examples, this recipe shows a very simple static form of NAT that translates addresses by simply replacing one prefix with another. So, for example, the remote host, 172.16.55.19, gets its address rewritten as 172.17.55.19.
The router can accomplish this with the following command:
Router(config)#ip nat outside source static network172.16.0.0 172.17.0.0 /16no-alias
This defines a static mapping of one network prefix to another, as required.
Note that we have included the no-alias keyword in this command. If we didn’t include this keyword, the router would try to generate aliases for the translated addresses to allow it to answer ARP requests for them. This keyword is necessary because one of the router’s own interfaces belongs to the translated range.
21.7. Adjusting NAT Timers
Solution
The router will keep NAT entries in the translation table for a configurable length of time. For TCP connections, the default timeout period is 86,400 seconds, or 24 hours. Because UDP is not connection-based, the default timeout period is much shorter: only 300 seconds (5 minutes). The router will remove translation table entries for DNS queries after only 60 seconds.
You can adjust these parameters using the ip nat translation command, which accepts arguments in seconds:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#ip nat translation tcp-timeoutRouter(config)#500ip nat translation udp-timeoutRouter(config)#30ip nat translation dns-timeoutRouter(config)#30ip nat translation icmp-timeoutRouter(config)#30ip nat translation finrst-timeoutRouter(config)#30ip nat translation syn-timeoutRouter(config)#30endRouter#
To save router memory, you can also define a maximum number of NAT translation table entries:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#ip nat translation max-entriesRouter(config)#1000endRouter#
Discussion
There are many reasons for adjusting these various timeout parameters; most are related to router performance. If sessions are generally short-lived, it is a waste of memory to maintain the NAT entries for a long time. The finrst-timeout and syn-timeout parameters are also useful when the router is connected to the public Internet because they can help to prevent DoS attacks that are based on sending TCP control packet such as SYN, ACK, and FIN. If the router keeps only the NAT entries associated with these packets for a brief period of time, you can help to limit the impact of such attacks.
We recommend using extreme caution with the max-entries command:
Router(config)#ip nat translation max-entries 1000When you set a limit like this, the router will reject any additional attempts to use NAT. So, in this example, if you already had 1000 NAT table entries, the router would simply drop any new connection attempts. This can be a useful way to prevent excessive NAT processing from overloading the router, but it can also block legitimate access.
It is difficult to select a useful upper limit to the size of the NAT table in general. In most cases it is best to use the default, which does not enforce any upper limit. You should use this command only if you start to run into serious memory or CPU utilization problems. Because restricting the table size tells the router to refuse any further requests, this method should be a last resort. In most cases it is more effective to decrease the various timeout values as shown in this recipe.
Start by looking at your NAT translation table (as shown in Recipe 21.9), and see what most of the entries look like. If you are using the overload option, you may find that there are several different entries for each internal host, each for different port numbers or protocols. The relatively long 24-hour timeout period for TCP sessions is probably the best place to start. Decreasing the size of the NAT table by reducing this timeout period will not cause any application problems.
See Also
21.8. Changing TCP Ports for FTP
Solution
The FTP protocol includes IP address information in the packet payload. Normally, Cisco’s NAT implementation rewrites IP address information in the payloads of FTP packets by looking in every packet sent on TCP port 21, which is the port that FTP uses to pass session control information by default. So when an FTP server uses a nonstandard TCP port number for session control, you must configure the NAT router to expect FTP packets on the new port number:
Router#configure terminalEnter configuration commands, one per line. End with CNTL/Z. Router(config)#access-listRouter(config)#19permit192.168.55.5ip nat service listRouter(config)#19ftp tcp port8021ip nat service listRouter(config)#19ftp tcp port21endRouter#
Discussion
As we mentioned in the introduction to this chapter, the common FTP protocol includes IP address information in the packet payload. Cisco routers expect this, and rewrite the information appropriately. But some FTP servers use a nonstandard TCP port number, which means that NAT will break the protocol. So, in IOS Version 11.3, Cisco introduced the ability to look for FTP payload information on alternate TCP port numbers.
The example configures the router to expect FTP packets for the server 192.168.55.5 on both the default port number 21 and the nonstandard port number 8021. You can easily configure similar commands for other servers as well, or expand the access list to include several servers that all use the same nonstandard FTP port number.
21.9. Checking NAT Status
Solution
There are several useful EXEC commands for checking the status of NAT on a router. You can view the NAT translation table using the following command:
Router#show ip nat translationYou can clear all or part of the NAT translation table by specifying either an asterisk (*) or a particular address. To clear a specific entry, you must specify either the global address for a device that is inside, or a local address for a device that is outside:
Router#clear ip nat translation *Router#clear ip nat translation insideRouter#172.18.3.2clear ip nat translation outside192.168.1.10
You will often want to look at NAT statistics, including information on which interfaces use NAT, how many entries are in the NAT table, how often they have been used, and, most importantly, how often packets have bypassed NAT. The command to see this is show ip nat statistics:
Router#show ip nat statisticsYou can clear these statistics as follows:
Router#clear ip nat statisticsDiscussion
The NAT translation table contains information about every translation that the router is currently tracking. In this example, there have been two connections between the interior (192.168.1.10) and exterior (172.18.3.2) device. The first of these connections is shown as ICMP:
Router#show ip nat translation
Pro Inside global Inside local Outside local Outside global
icmp 172.16.1.100:21776 192.168.1.10:21776 172.18.3.2:21776 172.18.3.2:21776
tcp 172.16.1.100:1029 192.168.1.10:1029 172.18.3.2:23 172.18.3.2:23
--- 172.16.1.10 192.168.1.15 --- ---
--- 172.16.1.11 192.168.1.16 --- ---
Router#This command shows only the currently active NAT table entries. You can see, for example, that it translates the inside local address 192.168.1.10 to the inside global address 172.16.1.100. But this router isn’t configured to translate outside addresses, so the outside local addresses are the same as the outside global addresses. As discussed in Recipe 21.7, the router removes dynamic NAT entries after a defined period of time. By default, the router will delete NAT entries for TCP connections after 24 hours.
The output has five columns. The first is the protocol. This column is blank unless you use the overload option in your NAT configuration. The “Inside global” address column is the translated address of an internal device. The “Inside local” column, on the other hand, shows the real internal address for the same device. The “Outside local” column shows the translated addresses of external devices, while “Outside global” shows their real addresses.
This can be a little bit confusing at first sight. The real address on the inside is “local,” and the translated address is “global,” while the real address on the outside is “global,” and it is translated to a “local” address. You can resolve this confusion by remembering that global addresses are always on the outside, and local addresses are always on the inside.
The last two rows represent simple static NAT entries. It shows, for example, that the internal device whose real address is 192.168.1.15 is translated to 172.16.1.10 when its packets pass through this router. There are no external addresses listed for this entry. Because it is a static entry, this translation is the same for any external device. However, the row immediately above this one shows all four entries:
tcp 172.16.1.100:1029 192.168.1.10:1029 172.18.3.2:23 172.18.3.2:23
This line includes a lot of useful information. The first column indicates that this row represents a TCP connection, and that the translation is a dynamic entry. On the inside, the source address is 192.168.1.10 and the source TCP port is 1029, while the destination is 172.18.3.2 and the destination port is 23. On the outside, the destination address and port are the same, but the source address is rewritten as 172.16.1.100 and the source port is 1029.
The verbose keyword makes this command show age information about each table entry:
Router#show ip nat translation verbose
Pro Inside global Inside local Outside local Outside global
icmp 172.16.1.100:21776 192.168.1.10:21776 172.18.3.2:21776 172.18.3.2:21776
192.168.3.2:4235
create 00:00:36, use 00:00:36, left 00:00:23,flags: extended
tcp 172.16.1.100:1029 192.168.1.10:1029 172.18.3.2:23 172.18.3.2:23
create 00:00:15, use 00:00:13, left 00:00:46, flags: extended, timing-out
--- 172.16.1.10 192.168.1.15 --- ---
create 1d00h, use 00:23:08, flags: static
--- 172.16.1.11 192.168.1.16 --- ---
create 1d00h, use 00:15:28, flags: static
Router#This level of detail is most useful when you are trying to diagnose NAT table timeout issues.
The show ip nat statistics command includes useful information about the translation configuration. The following example shows one external and two internal interfaces, with a dynamic NAT pool that runs from 172.16.1.100 to 172.16.1.150:
Router#show ip nat statistics
Total active translations: 3 (2 static, 1 dynamic; 1 extended)
Outside interfaces:
Ethernet0/0
Inside interfaces:
FastEthernet0/0, FastEthernet0/1
Hits: 2628 Misses: 44
Expired translations: 37
Dynamic mappings:
-- Inside Source
access-list 15 pool NATPOOL refcount 1
pool NATPOOL: netmask 255.255.255.0
start 172.16.1.100 end 172.16.1.150
type generic, total addresses 2, allocated 1 (50%), misses 9
Router#The “Hits” field shows the total number of times that the router has had to create new translation table entries. The “Misses” field counts the exceptions. In this case, there is an access list that excludes certain internal IP addresses.
21.10. Debugging NAT
Solution
Cisco routers include a simple but useful debug facility for NAT. The basic form of the command is debug ip nat:
Router#debug ip natYou can also add the detailed keyword to this command to get more information on each NAT event:
Router#debug ip nat detailedIt is often useful to use an access list with the debug command. You can do this by simply specifying the number of the access list. This will allow you to look only at NAT events for particular IP addresses that are permitted by the access list:
Router#debug ip nat 15You can also combine an access list with the detailed keyword for more focused debugging:
Router#debug ip nat 15 detailedDiscussion
The following shows some typical log entries:
Router#terminal monitorRouter#debug ip natSep 8 19:51:08.396 EDT: NAT: s=192.168.3.1->192.168.19.1, d=192.168.3.2 [0] Sep 8 19:51:11.560 EDT: NAT*: s=192.168.1.10->192.168.19.55, d=192.168.3.2 [4909] Sep 8 19:51:11.568 EDT: NAT*: s=192.168.3.2, d=192.168.19.55->192.168.1.10 [4909] Sep 8 19:51:11.572 EDT: NAT: s=192.168.3.2, d=192.168.19.55->192.168.1.10 [4909] Sep 8 19:51:12.552 EDT: NAT*: s=192.168.1.10->192.168.19.55, d=192.168.3.2 [4911] Sep 8 19:51:12.564 EDT: NAT*: s=192.168.3.2, d=192.168.19.55->192.168.1.10 [4911]
This particular trace follows a simple series of ping packets. The interior device 192.168.1.10 sends ICMP ping packets to the external destination 192.168.3.2. The router rewrites the internal address as 192.168.19.55 and forwards the packet to the external destination.
You can also see the ping responses coming back from the destination device. The router rewrites the internal address back to its true value and forwards the packet appropriately.