Scaling the Network with NAT and PAT
Two Internet scalability challenges are the depletion of registered IP version 4 (IPv4) address space and scaling in routing. Cisco IOS Network Address Translation (NAT) and Port Address Translation (PAT) are mechanisms for conserving registered IPv4 addresses in large networks and simplifying IPv4 address management tasks. NAT and PAT translate IPv4 addresses within private internal networks to legal IPv4 addresses for transport over public external networks, such as the Internet, without requiring a registered subnet address. Incoming traffic is translated back for delivery within the inside network.
This translation of IPv4 addresses eliminates the need for host renumbering and allows the same IPv4 address range to be used in multiple intranets. This section describes the features that are offered by NAT and PAT and shows you how to configure NAT and PAT on Cisco routers.
Introducing NAT and PAT
NAT operates on a Cisco router and is designed for IPv4 address simplification and conservation. NAT enables private IPv4 internetworks that use nonregistered IPv4 addresses to connect to the Internet. Usually, NAT connects two networks and translates the private (inside local) addresses in the internal network into public addresses (inside global) before packets are forwarded to another network. As part of this functionality, you can configure NAT to advertise only one address for the entire network to the outside world. Advertising only one address effectively hides the internal network from the world, thus providing additional security. Figure 7-1 shows an example of address translation between a private and public network.
Figure 7-1 Network Address Translation
Any device that is between an internal network and the public network—such as a firewall, a router, or a computer—uses NAT, which is defined in RFC 1631. In NAT terminology, the inside network is the set of networks that are subject to translation. The outside network refers to all other addresses. Usually these are valid addresses located on the Internet.
Cisco defines the following list of NAT terms:
- Inside local address: The IPv4 address that is assigned to a host on the inside network. The inside local address is likely not an IPv4 address assigned by the Network Information Center or service provider.
- Inside global address: A legitimate IPv4 address assigned by the NIC or service provider that represents one or more inside local IPv4 addresses to the outside world.
- Outside local address: The IPv4 address of an outside host as it appears to the inside network. Not necessarily legitimate, the outside local address is allocated from a routable address space on the inside.
- Outside global address: The IPv4 address that is assigned to a host on the outside network by the host owner. The outside global address is allocated from a globally routable address or network space.
NAT has many forms and can work in the following ways: - Static NAT: Maps an unregistered IPv4 address to a registered IPv4 address (one to one). Static NAT is particularly useful when a device must be accessible from outside the network.
- Dynamic NAT: Maps an unregistered IPv4 address to a registered IPv4 address from a group of registered IPv4 addresses.
- NAT overloading: Maps multiple unregistered IPv4 addresses to a single registered IPv4 address (many to one) by using different ports. Overloading is also known as PAT and is a form of dynamic NAT.
NAT offers these benefits over using public addressing:
- Eliminates the need to readdress all hosts that require external access, saving time and money.
- Conserves addresses through application port-level multiplexing. With NAT, internal hosts can share a single registered IPv4 address for all external communications. In this type of configuration, relatively few external addresses are required to support many internal hosts, thus conserving IPv4 addresses.
- Protects network security. Because private networks do not advertise their addresses or internal topology, they remain reasonably secure when they gain controlled external access in conjunction with NAT.
One of the main features of NAT is PAT, which is also referred to as “overload” in Cisco IOS configuration. PAT allows you to translate multiple internal addresses into a single external address, essentially allowing the internal addresses to share one external address. Figure 7-2 shows an example of Port Address Translation. The following list highlights the operations of PAT:
Figure 7-2 Port Address Translation
- PAT uses unique source port numbers on the inside global IPv4 address to distinguish between translations. Because the port number is encoded in 16 bits, the total number of internal sessions that NAT can translate into one external address is, theoretically, as many as 65,536.
- PAT attempts to preserve the original source port. If the source port is already allocated, PAT attempts to find the first available port number. It starts from the beginning of the appropriate port group, 0 to 511, 512 to 1023, or 1024 to 65535. If PAT does not find an available port from the appropriate port group and if more than one external IPv4 address is configured, PAT moves to the next IPv4 address and tries to allocate the original source port again. PAT continues trying to allocate the original source port until it runs out of available ports and external IPv4 addresses.
Translating Inside Source Addresses
You can translate your own IPv4 addresses into globally unique IPv4 addresses when you are communicating outside your network. You can configure static or dynamic inside source translation.
Figure 7-3 illustrates a router that is translating a source address inside a network into a source address outside the network.
Figure 7-3 Translating an Address
The steps for translating an inside source address are as follows:
Step 1 The user at host 1.1.1.1 opens a connection to host B.
Step 2 The first packet that the router receives from host 1.1.1.1 causes the router to check its NAT table.
- If a static translation entry was configured, the router goes to Step 3.
- If no static translation entry exists, the router determines that the source address 1.1.1.1 (SA 1.1.1.1) must be translated dynamically. The router then selects a legal, global address from the dynamic address pool and creates a translation entry (in the example, 2.2.2.2). This type of entry is called a simple entry.
Step 3 The router replaces the inside local source address of host 1.1.1.1 with the translation entry global address and forwards the packet.
Step 4 Host B receives the packet and responds to host 1.1.1.1 by using the inside global IPv4 destination address 2.2.2.2 (DA 2.2.2.2).
Step 5 When the router receives the packet with the inside global IPv4 address, the router performs a NAT table lookup by using the inside global address as a key. The router then translates the address back to the inside local address of host 1.1.1.1 and forwards the packet to host 1.1.1.1. Host 1.1.1.1 receives the packet and continues the conversation. The router performs Steps 2 through 5 for each packet.
The order in which the router processes traffic depends on whether the NAT translation is a global-to-local translation or a local-to-global translation. Table 7-1 illustrates the order in which a router processes traffic, depending on the direction of the translation.
Table 7-1 Router Processing Order
To configure static inside source address translation on a router, follow these steps:
Step 1 Establish static translation between an inside local address and an inside global address.
RouterX(config)# ip nat inside source static local-ip global-ip
Enter the no ip nat inside source static global command to remove the static source translation.
Step 2 Specify the inside interface.
RouterX(config)# interface type number After you enter the interface command, the CLI prompt changes from (config)# to (config-if)#.
Step 3 Mark the interface as connected to the inside.
RouterX(config-if)# ip nat inside
Step 4 Specify the outside interface.
RouterX(config-if)# interface type number
Step 5 Mark the interface as connected to the outside.
RouterX(config-if)# ip nat outside
Use the command show ip nat translations in EXEC mode to display active translation information, as demonstrated here:
RouterX# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 192.168.1.2 10.1.1.2
Static NAT Address Mapping
The example shows the use of discrete address mapping with static NAT translations for the network in Figure 7-4. The router translates packets from host 10.1.1.2 to a source address of 192.168.1.2.
Figure 7-4 Static NAT Address Mapping
To configure dynamic inside source address translation, follow these steps:
Step 1 Define a pool of global addresses to be allocated as needed.
RouterX(config)# ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length}
Enter the no ip nat pool global command to remove the pool of global addresses.
Step 2 Define a standard access control list (ACL) that permits the addresses that are to be translated.
RouterX(config)# access-list access-list-number permit source [ sourcewildcard]
Enter the no access-list access-list-number global command to remove the ACL.
Step 3 Establish dynamic source translation, specifying the ACL that was defined in the prior step.
RouterX(config)# ip nat inside source list access-list-number pool name
Enter the no ip nat inside source global command to remove the dynamic source translation.
Step 4 Specify the inside interface.
RouterX(config)# interface type number After you enter the interface command, the CLI prompt changes from (config)# to (config-if)#.
Step 5 Mark the interface as connected to the inside.
RouterX(config-if)# ip nat inside
Step 6 Specify the outside interface.
RouterX(config-if)# interface type number
Step 7 Mark the interface as connected to the outside.
RouterX(config-if)# ip nat outside
CAUTION The ACL must permit only those addresses that are to be translated. Remember that there is an implicit deny any statement at the end of each ACL. An ACL that is too permissive can lead to unpredictable results. Using permit any can result in NAT consuming too many router resources, which can cause network problems
Use the command show ip nat translations in EXEC mode to display active translation information.
Dynamic Address Translation
The example in Figure 7-5 shows how the device translates all source addresses that pass ACL 1, which means a source address from the 192.168.1.0/24 network, into an address from the pool named net-208. The pool contains addresses from 171.69.233.209/28 to 171.69.233.222/28.
Figure 7-5 Dynamic Address Translation
ip nat pool net-208 171.69.233.209 171.69.233.222 netmask 255.255.255.240 ip nat inside source list 1 pool net-208 ! interface serial 0 ip address 171.69.232.182 255.255.255.240 ip nat outside ! interface ethernet 0 ip address 192.168.1.94 255.255.255.0 ip nat inside ! access-list 1 permit 192.168.1.0 0.0.0.255
Overloading an Inside Global Address
You can conserve addresses in the inside global address pool by allowing the router to use one inside global address for many inside local addresses. When this overloading is configured, the router maintains enough information from higher-level protocols—for example, TCP or User Datagram Protocol (UDP) port numbers—to translate the inside global address back into the correct inside local address. When multiple inside local addresses map to one inside global address, the TCP or UDP port numbers of each inside host distinguish between the local addresses.
Figure 7-6 illustrates NAT operation when one inside global address represents multiple inside local addresses. The TCP port numbers act as differentiators.
Figure 7-6 Overloading an Inside Global Address
Both host B and host C think they are talking to a single host at address 2.2.2.2. They are actually talking to different hosts; the port number is the differentiator. In fact, many inside hosts could share the inside global IPv4 address by using many port numbers. The router performs the following process when it overloads inside global addresses:
Step 1 The user at host 1.1.1.1 opens a connection to host B.
Step 2 The first packet that the router receives from host 1.1.1.1 causes the router to check its NAT table. If no translation entry exists, the router determines that address 1.1.1.1 must be translated and sets up a translation of inside local address 1.1.1.1 into a legal inside global address. If overloading is enabled and another translation is active, the router reuses the inside global address from that translation and saves enough information to be able to translate back. This type of entry is called an extended entry.
Step 3 The router replaces the inside local source address 1.1.1.1 with the selected inside global address and forwards the packet.
Step 4 Host B receives the packet and responds to host 1.1.1.1 by using the inside global IPv4 address 2.2.2.2.
Step 5 When the router receives the packet with the inside global IPv4 address, the router performs a NAT table lookup. Using the inside global address and port and outside global address and port as a key, the router translates the address back into the inside local address 1.1.1.1 and forwards the packet to host 1.1.1.1. Host 1.1.1.1 receives the packet and continues the conversation. The router performs Steps 2 through 5 for each packet. To configure overloading of inside global addresses, follow these steps:
Step 1 Define a standard ACL that permits the addresses that are to be translated.
RouterX(config)# access-list access-list-number permit source [ sourcewildcard]
Enter the no access-list access-list-number global command to remove the ACL.
Step 2 Establish dynamic source translation, specifying the ACL that was defined in the prior step.
RouterX(config)# ip nat inside source list access-list-number interface interface overload
Enter the no ip nat inside source global command to remove the dynamic source translation. The keyword overload enables PAT.
Step 3 Specify the inside interface.
RouterX(config)# interface type number RouterX(config-if)# ip nat inside After you enter the interface command, the CLI prompt changes from (config)# to (config-if)#. Step 4 Specify the outside interface. RouterX(config-if)# interface type number RouterX(config-if)# ip nat outside
Use the command show ip nat translations in EXEC mode to display active translation information. The NAT inside-to-outside process comprises this sequence of steps:
Step 1 The incoming packet goes to the route table and the next hop is identified.
Step 2 NAT statements are parsed so that the interface serial 0 IPv4 address can be used in overload mode. PAT creates a source address to use.
Step 3 The router encapsulates the packet and sends it out on interface serial 0.
For the return traffic, the NAT outside-to-inside address translation process works in the following sequence of steps:
Step 1 NAT statements are parsed. The router looks for an existing translation and identifies the appropriate destination address.
Step 2 The packet goes to the route table, and the next-hop interface is determined.
Step 3 The packet is encapsulated and sent out to the local interface.
No internal addresses are visible during this process. As a result, hosts do not have an external public address, which leads to improved security.
By default, dynamic address translations time out from the NAT and PAT translation tables after some period of nonuse. The default timeout periods differ among various protocols. You can reconfigure the default timeouts with the ip nat translation command. The syntax for this command is as follows:
ip nat translation {timeout | udp-timeout | dns-timeout | tcp-timeout | finrst-timeout |
icmp-timeout | pptp-timeout | syn-timeout | port-timeout} {seconds | never}
Table 7-2 describes the parameters for this command.
Table 7-2 ip nat translation Parameters
Table 7-3 lists commands you can use to clear the entries before they time out.
Table 7-3 clear ip nat translation Commands
Resolving Translation Table Issues
When you have IPv4 connectivity problems in a NAT environment, it is often difficult to determine the cause of the problem. Many times NAT is blamed, when in reality there is an underlying problem. When you are trying to determine the cause of an IPv4 connectivity problem, it helps to eliminate NAT as the potential problem. Follow these steps to verify
that NAT is operating as expected:
Step 1 Based on the configuration, clearly define what NAT is supposed to achieve. You may determine that the NAT configuration has a problem.
Step 2 Use the show ip nat translations command to determine if the correct translations exist in the translation table.
Step 3 Verify whether the translation is occurring by using show and debug commands.
Step 4 Review in detail what is happening to the translated packet, and verify that routers have the correct routing information for the translated address to move the packet. If the appropriate translations are not in the translation table, verify the following items:
- There are no inbound ACLs that are denying the packet entry into the NAT router.
- The ACL that is referenced by the NAT command is permitting all necessary networks.
- The NAT pool has enough addresses.
- The router interfaces are appropriately defined as NAT inside or NAT outside.
In a simple network environment, it is useful to monitor NAT statistics with the show ip nat statistics command. However, in a more complex NAT environment with several translations taking place, this show command is no longer useful. In this case, it may be necessary to run debug commands on the router.
The debug ip nat command displays information about every packet that is translated by the router, which helps you verify the operation of the NAT feature. The debug ip nat detailed command generates a description of each packet that is considered for translation. This command also outputs information about certain errors or exception conditions, such as the failure to allocate a global address. The debug ip nat detailed command will generate more overhead than the debug ip nat command, but it can provide the detail that you need to troubleshoot the NAT problem.
Example 7-1 demonstrates sample debug ip nat output.
Example 7-1 Displaying Information About Packets Translated by the Router
RouterX# debug ip nat NAT: s=192.168.1.95->172.31.233.209, d=172.31.2.132 [6825] NAT: s=172.31.2.132, d=172.31.233.209->192.168.1.95 [21852] NAT: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6826] NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23311] NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6827] NAT*: s=192.168.1.95->172.31.233.209, d=172.31.1.161 [6828] NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23312] NAT*: s=172.31.1.161, d=172.31.233.209->192.168.1.95 [23313]
In Example 7-1, the first two lines show the debugging output that a DNS request and reply produce where the DNS server address is 172.31.2.132. The remaining lines show the debugging output from a Telnet connection from a host on the inside of the network to a host on the outside of the network.
The asterisk (*) next to NAT indicates that the translation is occurring in the fast-switched path. The first packet in a conversation is always process-switched. The remaining packets go through the fast-switched path if a cache entry exists.
The final entry in each line, within brackets ([ ]), provides the identification number of the packet. You can use this information to correlate with other packet traces from protocol analyzers. Another useful command when verifying the operation of NAT is the show ip nat statistics command. This command is shown in Example 7-2.
Example 7-2 show ip nat statistics
RouterX# show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0, Serial2 Inside interfaces: Ethernet1 Hits: 0 Misses: 0 Expired translations: 0 Dynamic mappings: -- Inside Source access-list 7 pool test refcount 0 pool test: netmask 255.255.255.0 start 172.16.11.70 end 172.16.11.71 type generic, total addresses 2, allocated 0 (0%), misses 0
Table 7-4 describes the show ip nat statistics fields.
Table 7-4 show ip nat statistics Field Descriptions
Resolving Issues with Using the Correct Translation Entry
You know from the configuration that the source address (10.10.10.4) should be statically translated to 172.16.6.14. You can use the show ip nat translation command to verify that the translation does exist in the translation table, as demonstrated here:
RouterX# show ip nat translation Pro Inside global Inside local Outside local Outside global --- 172.16.6.14 10.10.10.4 --- ---
Next, ensure that the translation is occurring. You can confirm this in two ways: by running a NAT debug command or by monitoring NAT statistics with the show ip nat statistics command. Because debug commands should always be used as a last resort, start with the show ip nat statistics command.
To determine whether the translation is taking place, monitor the hits counter to see if it increases as traffic is sent through the router. The hits counter increments every time a translation in the translation table is used to translate an address. First, clear the statistics and then display them. Next, try to execute a ping through the router and then display the statistics again, as demonstrated in Example 7-3.
Example 7-3 Verifying That Address Translation Is Occurring
RouterX# clear ip nat statistics RouterX# RouterX# show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0, Serial2 Inside interfaces: Ethernet1 Hits: 0 Misses: 0 Expired translations: 0 Dynamic mappings: -- Inside Source access-list 7 pool test refcount 0 pool test: netmask 255.255.255.0 start 172.16.11.70 end 172.16.11.71 type generic, total addresses 2, allocated 0 (0%), misses 0
After you ping through the router, the NAT statistics show, as demonstrated in Example 7-4.
Example 7-4 show ip statistics to Verify Translation
RouterX# show ip nat statistics Total active translations: 1 (1 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0, Serial2 Inside interfaces: Ethernet1 Hits: 5 Misses: 0 Expired translations: 0 Dynamic mappings: -- Inside Source access-list 7 pool test refcount 0 pool test: netmask 255.255.255.0 start 172.16.11.70 end 172.16.11.71 type generic, total addresses 2, allocated 0 (0%), misses 0
You can see from the output of the show command that the number of hits incremented by five after the NAT statistics were cleared. In a successful ping, the number of hits should increase by 10. The five ICMP echoes that were sent by the source should be translated, and the five echo reply packets from the destination should be translated, for a total of 10 hits.
The five missing hits are most likely due to the echo replies not being translated or not being sent from the destination router.
To determine why the echo reply is not being returned when you issue a ping, check the default gateway of the destination default gateway router for a route back to the translated address, as demonstrated in Example 7-5.
Example 7-5 Verifying the Default Gateway
RouterY# show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter are * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 4 subnets C 172.16.12.0 is directly connected, Serial0.8 C 172.16.9.0 is directly connected, Serial0.5 C 172.16.11.0 is directly connected, Serial0.6 C 172.16.5.0 is directly connected, Ethernet0
The routing table of Router B does not have a route for 172.16.6.14, which is the translated address. Therefore, the echo replies in response to the ping fail. Once you add this return route, the ping works. In Figure 7-7, the network administrator is
experiencing the following symptom: Host A (192.168.1.2) cannot ping host B (192.168.2.2). The next several examples show how to troubleshoot this issue. To troubleshoot the problem, use the show ip nat translation command to see if any translations are currently in the table: RouterA# show ip nat translations Pro Inside global Inside local Outside local Outside global --- --- --- --- ---
Figure 7-7 NAT Problem Cannot Ping Remote Host
You find that no translations are in the table. This could indicate a problem, or it could mean that no traffic is currently being translated. Next, you must verify if any translations have ever taken place and identify the interfaces between which translation should be occurring. Use the show ip nat statistics command to determine this information, as demonstrated in Example 7-6.
Example 7-6 Identifying Translations and Interfaces
RouterA# show ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Outside interfaces: Ethernet0 Inside interfaces: Serial0 Hits: 0 Misses: 0 …
From the results in Example 7-6, you determine that the NAT counters are at 0, verifying that no translation has occurred. You also find that the router interfaces are incorrectly defined as NAT inside or NAT outside.
After you correctly define the NAT inside and outside interfaces, generate another ping from host A to host B. In the example, the ping still fails. Issue the show ip nat translations and show ip nat statistics commands again to troubleshoot the problem. In the example, you find that translations are still not occurring.
Next, you should use the show access-list command to verify whether the ACL that is referenced by the NAT command is permitting all the necessary networks:
RouterA# show access- list Standard IP access list 1 10 permit 192.168.1.1, wildcard bits 255.255.255.0 From this output, you determine that an incorrect wildcard bit mask has been used in the ACL that defines the addresses to be translated. After correcting the ACL wildcard bit mask, you generate another ping from host A to host B. The ping still fails. However, when you reissue the show ip nat translations and show ip nat statistics commands, you find that translations are now occurring: RouterA# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 172.16.17.20 192.168.1.2 --- --- Next, you use the show ip route command on Router B to verify the existence of a return route to the translated address. From the results in Example 7-7, you discover that Router B has no route to the translated network address of 172.16.0.0.
Example 7-7 Verifying a Return Route to the Translated Address
RouterB# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0/24 is directly connected, Serial0 192.168.2.0/24 is subnetted, 1 subnets R 192.168.2.0/24 is directly connected, Ethernet0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks R 192.168.1.0/24 [120/1] via 10.1.1.1, 2d19h, Serial0
You return to Router A and enter the show ip protocol command to determine if Router A is advertising the translated address of 172.16.0.0, as demonstrated in Example 7-8.
Example 7-8 Verifying Advertisement of a Translated Address
RouterA# show ip protocol Routing Protocol is “rip” Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 0 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 1, receive any version Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 192.168.0.0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120)
You find that Router A is advertising 192.168.1.0, which is the network that is being translated, instead of advertising network 172.16.0.0, which is the network to which the addresses are being translated.
So, to fix the original problem where host A (192.168.1.2) could not ping host B (192.168.2.2), you changed the following configurations on Router A:
- Interface S0 is now the outside interface, rather than the inside interface.
- Interface E0 is now the inside interface, rather than the outside interface.
- The wildcard mask now matches any host on the 192.168.1.0 network. Previously, the access-list 1 command did not match inside local IPv4 address.
- Router A is now configured to advertise network 172.16.0.0. Previously, Router B did not know how to reach the 172.16.17.0/24 subnet. The configuration is done by creating a loopback interface and modifying the Routing Information Protocol (RIP) network statements.
More Resources