Configuring NAT
The first step in configuring NAT is to designate the inside and outside interfaces. Beyond that, the configuration depends on whether you are configuring static NAT or dynamic NAT. For static NAT, you just create the appropriate mapping entries in the NAT table. For dynamic NAT, you create a pool of addresses to be used in the translation and create access lists to identify the addresses to be translated. A single command then ties the pool and the access leist together.
This section demonstrates the most common configuration techniques for NAT in its most common uses.
Case Study: Static NAT
In Figure 4-15, the inside network is addressed out of the 10.0.0.0 address space. Two of the devices, hosts A and C, must be able to communicate with the outside world. Those two devices are translated to the public addresses 204.15.87.1/24 and 204.15.87.2/24.
){kind=link}
Example 4-4 shows the configuration to implement NAT at Mazatlan.
Figure 4-15 The Inside Local Addresses of Devices A and C Are Statically Translated to Inside Global Addresses by the NAT Process in Router Mazatlan
Example 4-4 Implementing Static NAT at Router Mazatlan in Figure 4-15
interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip nat inside ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.705 point-to-point ip address 199.100.35.254 255.255.255.252 ip nat outside frame-relay interface-dlci 705 ! router ospf 100 network 10.1.1.1 0.0.0.0 area 0 default-information originate ! ip nat inside source static 10.1.2.2 204.15.87.2 ip nat inside source static 10.1.1.3 204.15.87.1 ! ip route 0.0.0.0 0.0.0.0 199.100.35.253 !
The router's E0 interface is designated as being on the inside with the ip nat inside command, and the Frame Relay subinterface S1.705 is designated as being on the outside with the ip nat outside command.
Next, the inside local addresses are mapped to inside global addresses with the ip nat inside source static commands. There are two of these commands, one for host C and one for host A. Example 4-5 shows the resulting NAT table.
Example 4-5 The IL Addresses of Hosts C and A Are Statically Translated into IG Addresses
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.87.2 10.1.2.2 --- --- --- 204.15.87.1 10.1.1.3 --- --- Mazatlan#
When host A or C sends a packet to the outside, Mazatlan sees the source address in its NAT table and makes the appropriate translation. The router Acapulco has a route (in this case, a static route) to network 204.15.87.0 and has no knowledge of the 10.0.0.0 network. Therefore, Acapulco and host D can respond to packets from hosts A and C. If host B or router Veracruz sends a packet to host D, the packet is forwarded, but without any translation; when D responds to the untranslated IL address, Acapulco has no route and drops the packet, as demonstrated in Example 4-6.
Example 4-6 When Host D in Figure 4-15 Responds to the Untranslated IL Address of Host B, Acapulco Has No Route to 10.0.0.0 and Drops the Packet
Acapulco#debug ip icmp ICMP packet debugging is on Acapulco# 1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5 1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5 1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5 1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5 1d00h: ICMP: dst (10.1.1.4) host unreachable sent to 201.114.37.5
Outside global addresses can also be statically translated into outside local addresses. Suppose, for example, that the administrator of the inside network in Figure 4-15 wants host D to "appear" to be a part of the inside network—say, with an address of 10.1.3.1. Example 4-7 shows the NAT configuration for Mazatlan.
Example 4-7 Configuring Mazatlan to Statically Translate Outside Global Addresses to Outside Local Addresses
ip nat inside source static 10.1.1.3 204.15.87.1 ip nat inside source static 10.1.2.2 204.15.87.2 ip nat outside source static 201.114.37.5 10.1.3.1
The router's NAT configuration remains the same, except for the addition of the ip nat outside source static command, which in this case maps the OG address 201.114.37.5 to the OL address 10.1.3.1. Example 4-8 shows the resulting NAT table.
Example 4-8 An OG-to-OL Mapping Is Added to the NAT Table by the Additional Command at Mazatlan
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.87.2 10.1.2.2 --- --- --- 204.15.87.1 10.1.1.3 --- --- --- --- --- 10.1.3.1 201.114.37.5 Mazatlan#
Although this case study has involved only static mappings, some dynamic mapping occurs after traffic has passed between host A and host D, and between host C and host D, as illustrated by Example 4-9. In each case, the inside mappings are automatically mapped to the outside mappings.
Example 4-9 The Inside Addresses of Hosts A and C Have Been Automatically Mapped to the Outside Addresses of Host D
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.87.2 10.1.2.2 --- --- --- 204.15.87.1 10.1.1.3 --- --- --- --- --- 10.1.3.1 201.114.37.5 --- 204.15.87.1 10.1.1.3 10.1.3.1 201.114.37.5 --- 204.15.87.2 10.1.2.2 10.1.3.1 201.114.37.5 Mazatlan#
It is important to understand that this configuration does nothing to prevent a host on the inside from sending packets to host D's OG address rather than the OL address. In Figure 4-16, host A can successfully ping host D at either its OL address (10.1.3.1) or its OG address (201.114.37.5).
){kind=link}
In fact, debugging output from host C in Example 4-10 reveals a bit more detail about the behavior of this network. Host C pings host D on its OG address, but the source address of the reply packets is host D's OL address. The ICMP Echo Request packet to destination 201.114.37.5 has passed through the NAT unchanged, but the ICMP Echo Reply packet, with a source address of 201.114.37.5, is translated by the NAT to the OL address.
Figure 4-16 Host A Can Send Packets to Either the OL or OG Address of Host D
Example 4-10 Although Host C Sends Pings to 201.114.37.5, NAT Causes the Replies to Have a Source Address of 10.1.3.1
HostC#debug ip icmp ICMP packet debugging is on HostC#ping 201.114.37.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 201.114.37.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms HostC# ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2 ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2 ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2 ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2 ICMP: echo reply rcvd, src 10.1.3.1, dst 10.1.2.2 HostC#
TIP
If you're recreating these examples in a lab, Example 4-10 reveals a useful trick. Host C is actually a Cisco router with IP routing disabled (no ip routing) and an ip default-gateway command pointing to Veracruz's locally attached interface. As Example 4-10 demonstrates, this setup enables you to use the IOS's extensive debugging tools to observe network behavior from a host's perspective.
If the administrator of the inside network wants to prevent traffic from being sent to OG addresses, he must implement a filter, as shown in Example 4-11.
Example 4-11 Implementing a Filter to Prevent Traffic of the Inside Network from Being Sent to OG Addresses
interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip access-group 101 in ip nat inside ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.705 point-to-point ip address 199.100.35.254 255.255.255.252 ip nat outside frame-relay interface-dlci 705 ! router ospf 100 network 10.1.1.1 0.0.0.0 area 0 default-information originate ! ip nat inside source static 10.1.1.3 204.15.87.1 ip nat inside source static 10.1.2.2 204.15.87.2 ip nat outside source static 201.114.37.5 10.1.3.1 ! ip route 0.0.0.0 0.0.0.0 199.100.35.253 ! access-list 101 permit ip any host 10.1.3.1 !
Notice that an incoming filter is used on interface E0. The filtering must take place before the address translation; an outgoing filter on S1.705 would have no way to differentiate the already translated destination address. Figure 4-17 shows the results of the filter; host A can still reach host D on its OL address, but packets to the OG address are blocked.
){kind=link}
Figure 4-17 After the Filter Is Implemented on Mazatlan, Inside Hosts Can Only Reach Host D via Its OL Address
The debug output in Example 4-10 and Example 4-6 emphasizes the fact that NAT does not, by itself, guarantee that private or illegal IP addresses do not leak into the public Internet. Wise administrators filter for the private Class A, B, and C addresses on interfaces connected to ISPs. Wise ISPs do the same on interfaces connected to their subscribers.
A difficulty with the various configurations shown in this case study so far is that very few "real-life" devices will use IP addresses to reach other devices. Names are almost always used. Therefore, DNS servers must have the correct IP addresses relevant to their side of the NAT. In Figure 4-18, DNS servers are placed on the inside and outside networks. DNS1 might have the following name-to-address mappings:
){kind=link}
HostA.insidenet.com IN A 10.1.1.3 HostB.insidenet.com IN A 10.1.1.4 HostC.insidenet.com IN A 10.1.2.2
Here, all hosts have local addresses (local to the inside network). DNS2 might have the following name-to-address mapping:
HostD.outsidenet.com IN A 201.114.37.5
These entries all map to global addresses. DNS1 is authoritative for inside.net, and DNS2 is authoritative for outside.net. Example 4-12 shows the NAT configuration for Mazatlan.
Figure 4-18 DNS1 Is Authoritative for the Inside Network, and DNS2 Is Authoritative for the Outside Network
Example 4-12 Mazatlan's NAT Configuration, Supporting DNS1 and DNS2 in Figure 4-18
ip nat inside source static 10.1.1.3 204.15.87.1 ip nat inside source static 10.1.2.2 204.15.87.2 ip nat inside source static 10.1.1.4 204.15.87.3 ip nat inside source static 10.1.1.254 204.15.87.254 ip nat outside source static 201.114.37.5 10.1.3.1 ip nat outside source static 201.50.34.1 10.1.3.2
In addition to the three inside hosts and one outside host, the configuration in Example 4-12 has entries for the two DNS servers. If host A wants to send a packet to host D, it sends a DNS query to DNS1 for the address of HostD.outsidenet.com. DNS1 then queries DNS2, which returns an address of 201.114.37.5. When this DNS message passes through the NAT, the address is translated to 10.1.3.1, and DNS1 passes this address on to host A. Host A then sends packets to this address, and the NAT translates the source and destination addresses of the packets.
If host D wants to speak to a host on the inside network, the opposite happens. Host D might query DNS2 for the address of HostC.insidenet.com, prompting DNS2 to query DNS1. DNS1 responds with an address of 10.1.2.2, which is translated to 204.15.87.2 by the NAT and passed to host D by DNS2. Again, when packets are exchanged between host D and host C, the NAT translates the source and destination addresses.
Case Study: Dynamic NAT
The problem with the configurations of the preceding case study is one of scalability. What if, instead of the four inside devices shown in Figure 4-18, there are 60 or 6000? Maintaining static NAT mappings, like maintaining static route entries, quickly becomes an administrative burden as the network grows.
The inside network in Figure 4-19 uses 10.1.1.0–10.1.2.255 for its IL address space and has been assigned the public address space 204.15.86.0/23 by its ISP. This public address space is used as a pool from which IG addresses are dynamically selected for mapping to the IL addresses. To make things more manageable and predictable, the space 10.1.1.0/24 is mapped to 204.15.86.0/24, and 10.1.2.0/24 is mapped to 204.15.87.0/24.
){kind=link}
Figure 4-19 The Inside Network Has a Large Range of IL and IG Addresses
The ip nat pool command creates a pool of addresses and gives it a name. The pool is then designated as an IG pool and is linked to an IL address range with the command ip nat inside source list. Example 4-13 shows the configuration for Mazatlan.
Example 4-13 Mazatlan Is Configured to Dynamically Assign IG Addresses from an Address Pool
interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip nat inside ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.705 point-to-point ip address 199.100.35.254 255.255.255.252 ip nat outside frame-relay interface-dlci 705 ! router ospf 100 network 10.1.1.1 0.0.0.0 area 0 default-information originate ! ip nat pool PoolOne 204.15.86.1 204.15.86.254 netmask 255.255.255.0 ip nat pool PoolTwo 204.15.87.1 204.15.87.253 netmask 255.255.255.0 ip nat inside source list 1 pool PoolOne ip nat inside source list 2 pool PoolTwo ip nat inside source static 10.1.1.254 204.15.87.254 ! ip route 0.0.0.0 0.0.0.0 199.100.35.253 ! access-list 1 permit 10.1.1.0 0.0.0.255 access-list 2 permit 10.1.2.0 0.0.0.255 !
Two pools are created, named PoolOne and PoolTwo. PoolOne is assigned an address range of 204.15.86.1–204.15.86.254. PoolTwo is assigned an address range of 204.15.87.1–204.15.87.253. Notice that the address ranges exclude the network addresses and the broadcast addresses; the netmask portion of the commands acts as a sanity check, ensuring that such addresses as 204.15.87.255 are not mapped. An alternative to using the netmask keyword is the prefix-length. For example:
ip nat pool PoolTwo 204.15.87.1 204.15.87.253 prefix-length 24
has the same effect as the command with the netmask 255.255.255.0 keyword. Because of these commands, you can assign a range such as 204.15.86.0–204.15.86.255, and the "0" and "255" host addresses will not be mapped. However, it is good practice to configure only the actual pool addresses to avoid confusion.
Notice also that PoolTwo does not include the address 204.15.87.254. This address is statically assigned to DNS1 and so is left out of the pool. Any time an outside device must be able to initiate a session to an inside device, as in the case of DNS1, there must be a statically assigned address. If its IG address were dynamic, outside devices would have no way of knowing to which address to send packets.
Next, access lists are used to identify the addresses to be translated. In Mazatlan's configuration, access list 1 identifies the IL range 10.1.1.0–10.1.1.255, and access list 2 identifies the IL range 10.1.2.0–10.1.2.255.
Last, the IL addresses are linked to the correct pool. For example, the statement ip nat inside source list 1 pool PoolOne says that an IP address sourced from the inside (that is, IL addresses) and matching the range specified in access list 1 is to be translated to an IG address taken from PoolOne.
Example 4-14 shows Mazatlan's NAT table just after the dynamic NAT configuration is added. You can see that the only mapping in the table is the static entry for DNS1.
Example 4-14 When Mazatlan's Dynamic NAT Is First Configured, No Entries Reside in the NAT Table Except for the Single Static Entry
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.87.254 10.1.1.254 --- --- Mazatlan#
Example 4-15 shows the NAT table after several inside devices have originated traffic to the outside. The IG addresses are allocated from each pool numerically, beginning with the lowest available number.
Example 4-15 Dynamic IL-to-IG Mappings Are Entered into the NAT Table as Inside Devices Send Packets to the Outside
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.86.4 10.1.1.3 --- --- --- 204.15.86.3 10.1.1.83 --- --- --- 204.15.86.2 10.1.1.239 --- --- --- 204.15.86.1 10.1.1.4 --- --- --- 204.15.87.3 10.1.2.164 --- --- --- 204.15.87.2 10.1.2.57 --- --- --- 204.15.87.1 10.1.2.2 --- --- --- 204.15.87.254 10.1.1.254 --- --- Mazatlan#
Occasionally, a network administrator might want the host portion of the IG address to match the host portion of the IL address to which it is mapped. To accomplish this, the keywords type match-host are added to the end of the statement defining the pool, as demonstrated in Example 4-16.
Example 4-16 Configuring the Host Portion of the IG Address to Match the Host Portion of the IL Address to Which It Is Mapped
ip nat pool PoolOne 204.15.86.1 204.15.86.254 netmask 255.255.255.0 type match-host ip nat pool PoolTwo 204.15.87.1 204.15.87.253 netmask 255.255.255.0 type match-host ip nat inside source list 1 pool PoolOne ip nat inside source list 2 pool PoolTwo ip nat inside source static 10.1.1.254 204.15.87.254 ! ip route 0.0.0.0 0.0.0.0 199.100.35.253 ! access-list 1 permit 10.1.1.0 0.0.0.255 access-list 2 permit 10.1.2.0 0.0.0.255
Example 4-17 shows the resulting NAT table. Comparing it with the table in Example 4-15, you can see that all the same IL addresses have been translated. Instead of selecting IG addresses from their respective pools sequentially, however, IG addresses are selected with matching host portions.
Example 4-17 The Host Portions of the IG Addresses Match the Host Portions of the IL Addresses to Which They Are Mapped
Mazatlan#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 204.15.86.4 10.1.1.4 --- --- --- 204.15.86.3 10.1.1.3 --- --- --- 204.15.86.83 10.1.1.83 --- --- --- 204.15.86.239 10.1.1.239 --- --- --- 204.15.87.2 10.1.2.2 --- --- --- 204.15.87.57 10.1.2.57 --- --- --- 204.15.87.164 10.1.2.164 --- --- --- 204.15.87.254 10.1.1.254 --- --- Mazatlan#
By default, the dynamic entries are held in the NAT table for 86,400 seconds (24 hours). You can change this time with the command ip nat translation timeout to any time between 0 and 2,147,483,647 seconds (approximately 68 years). The timeout period begins when a translation is first made and is reset each time a packet is translated by the mapping. While a pool address is mapped to an address in the NAT table, it cannot be mapped to any other address. If the timeout period elapses with no new "hits" to the mapping, the entry is removed from the table, and the pool address is returned to the pool and becomes available. If you use 0 seconds or the keyword never with the ip nat translation timeout command, the mapping is never removed from the NAT table.
The translation timeout for each entry appears with the show ip nat translations verbose command, as demonstrated in Example 4-18. The ip nat translations verbose command shows how long ago the mapping was entered into the NAT table, how long ago the mapping was last used to translate an address, and the time remaining before the end of the timeout period. You can use the Flags field to indicate translation types other than dynamic. In Example 4-18, for instance, the last entry is shown to be a static translation.
Example 4-18 The show ip nat translations verbose Command Reveals Details About the Translation Timeout Periods for Each Mapping
Mazatlan#show ip nat translations verbose Pro Inside global Inside local Outside local Outside global --- 204.15.86.4 10.1.1.3 --- --- create 00:31:55, use 00:31:55, left 23:28:04, flags: none --- 204.15.86.3 10.1.1.83 --- --- create 00:32:19, use 00:32:19, left 23:27:40, flags: none --- 204.15.86.2 10.1.1.239 --- --- create 00:33:38, use 00:33:38, left 23:26:21, flags: none --- 204.15.86.1 10.1.1.4 --- --- create 00:34:25, use 00:00:05, left 23:59:54, flags: none --- 204.15.87.3 10.1.2.164 --- --- create 00:31:02, use 00:31:02, left 23:28:57, flags: none --- 204.15.87.2 10.1.2.57 --- --- create 00:34:10, use 00:34:10, left 23:25:49, flags: none --- 204.15.87.1 10.1.2.2 --- --- create 00:35:04, use 00:35:04, left 23:24:55, flags: none --- 204.15.87.254 10.1.1.254 --- --- create 03:59:32, use 03:59:32, flags: static Mazatlan#
The translation timeout period is important when the range of IL addresses is larger than the pool of IG addresses. Consider the configuration in Example 4-19.
Example 4-19 1022 IL Addresses Share a Pool of 254 IG Addresses
ip nat pool GlobalPool 204.15.86.1 204.15.86.254 prefix-length 24 ip nat inside source list 1 pool GlobalPool ! access-list 1 permit 10.1.0.0 0.0.3.255
Here, 1022 possible IL addresses—10.1.0.1 through 10.1.3.254—are translated using a pool of 254 available IG addresses. That means that when the NAT table contains 254 mapping entries, no more available IG addresses exist. Any packets with IL addresses that have not already been mapped are dropped. The designer of such an addressing scheme is gambling that only a fraction of the total users in the network will need outside access. With each mapping remaining in the NAT table for 24 hours, however, the chances of using up all available IG addresses increase substantially. By reducing the translation timeout, the designer can reduce this likelihood.
Case Study: A Network Merger
NAT is useful for preventing possible address conflicts between internetworks. The previous two case studies demonstrate the connection of internetworks using private address space to an internetwork using public addresses. The publicly addressed internetwork might be some other enterprise, or it might be the Internet. The bottom line is that the private RFC 1918 addresses must be translated because they are not unique. Across the Internet, many enterprises use the same addresses in their internetworks, and these addresses are "hidden" by NAT.
You also can use the configurations of the previous case studies in situations where the inside network is addressed out of the public address space but the addresses were not assigned by an addressing authority. For example, the inside network's address space might be 171.68.0.0/16. When connected to the Internet, NAT is required, because this address space is assigned to another company. Allowing these untranslated packets onto the Internet will cause routing conflicts.
Another situation in which address conflicts might arise is the merger of two previously separate internetworks. In Figure 4-20, Surf Corporation and Sand, Inc. have formed a corporate merger to form Surf n' Sand Enterprises. Part of the merger is the connection of their two internetworks. Unfortunately, when the two internetworks were first constructed, the designers both chose to use the 10.0.0.0 address space. As a result, many devices in Surf Corp.'s internetwork have the same addresses as devices in Sand, Inc.'s internetwork.
){kind=link}
Figure 4-20 Two Internetworks with Many Duplicate Addresses Must Be Connected
The best solution is to re-address the new internetwork. Address schemes are frequently designed poorly, however, making re-addressing a major project. In the Surf n' Sand internetwork, for instance, all the devices have manually configured IP addresses rather than addresses assigned by DHCP. NAT can serve as an interim solution to connect the internetworks until the re-addressing project can be completed.
NOTE
Note that in this application, NAT should always be considered an interim solution. It is bad practice to allow address conflicts to exist within an internetwork indefinitely.
The Surf n' Sand administrator first applies to his ISP or an addressing authority to acquire a public address space and is assigned the CIDR block 206.100.160.0/19. This block is then split in half. 206.100.160.0/20 is assigned to the former Sand internetwork, and 206.100.176.0/20 is assigned to the former Surf internetwork. An assumption is made here that although the 10.0.0.0 network is capable of supporting more than 16 million host addresses, in reality there are not more hosts in either network than can be serviced out of the /20 address space.
The routers Cozumel and Guaymas in Figure 4-21 connect the two internetworks with the configurations in Example 4-20.
){kind=link}
Figure 4-21 NAT Is Used at the Boundaries of the Two Internetworks to Correct the Address Conflicts
Example 4-20 NAT Configurations for Routers Cozumel and Guaymas in Figure 4-21
Cozumel interface Ethernet0 ip address 10.100.85.1 255.255.255.0 ip nat inside ! interface Ethernet1 ip address 10.255.13.254 255.255.255.248 ip nat outside ! router ospf 1 redistribute static network 10.100.85.1 0.0.0.0 area 18 ! ip nat pool Surf 206.100.176.2 206.100.191.254 prefix-length 20 ip nat inside source list 1 pool Surf ip nat inside source static 10.100.50.1 206.100.176.1 ! ip route 206.100.160.0 255.255.240.0 10.255.13.253 ! access-list 1 deny 10.255.13.254 access-list 1 permit any Guaymas interface Ethernet0 ip address 10.16.95.1 255.255.255.0 ip nat inside ! interface Ethernet1 ip address 10.255.13.253 255.255.255.248 ip nat outside ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.508 point-to-point ip address 10.18.3.253 255.255.255.0 ip nat inside frame-relay interface-dlci 508 ! router eigrp 100 redistribute static metric 1000 100 255 1 1500 passive-interface Ethernet1 network 10.0.0.0 no auto-summary ! ip nat pool Sand 206.100.160.2 206.100.175.254 prefix-length 20 ip nat inside source list 1 pool Sand ip nat inside source static 10.16.95.200 206.100.160.1 ! ip route 206.100.176.0 255.255.240.0 10.255.13.254 ! access-list 1 deny 10.255.13.253 access-list 1 permit 10.0.0.0 !
The DNS servers are crucial to this design. In the NAT configurations, each server has a static IL-to-IG mapping. Suppose a device in the Sand internetwork, Beachball.sand.com, wants to send a packet to Snorkel.surf.com in the Surf internetwork. Suppose further that both devices have an IP address of 10.1.2.2. The following sequence of events occurs:
Host Beachball queries DNS2 for the address of Snorkel.surf.com.
DNS2 queries DNS1, which is authoritative for the surf.com domain. The query has a source address of 10.16.95.200 and a destination address of 206.100.176.1. The query is forwarded to Guaymas, which is advertising a route into EIGRP for 206.100.176.0/20.
Guaymas translates the source address from 10.16.95.200 to 206.100.160.1, based on the static NAT entry, and forwards the packet to Cozumel.
Cozumel translates the destination address from 206.100.176.1 to 10.100.50.1, based on the static NAT entry, and forwards the query to DNS1.
DNS1 responds to the query, indicating that Snorkel.surf.com has an IP address of 10.1.2.2. The response message has a source address of 10.100.50.1 and a destination address of 206.100.160.1. The response is forwarded to Cozumel, which is advertising a route into OSPF for 206.100.160.0/20.
Cozumel translates the source address of the DNS response to 206.100.176.1. NAT also finds the address 10.1.2.2 in the Answer field of the message; the address matches access list 1 and is translated to an address from the pool named Surf. For this example, the address is 206.100.176.3. The mapping is entered into the NAT table, and the response is forwarded to Guaymas.
Guaymas translates the destination of the DNS response to 10.16.95.200 and forwards the message to DNS1.
DNS1 informs Beachball that the IP address of Snorkel.surf.com is 206.100.176.3.
Beachball sends a packet to Snorkel with a source address of 10.1.2.2 and a destination address of 206.100.176.3. Again, the packet is forwarded to Guaymas.
At Guaymas, the source address matches access list 1, and an address is selected from the pool named Sand. For this example, the address is 206.100.160.2. The source address is translated, the mapping is entered into the NAT table, and the packet is forwarded to Cozumel.
Cozumel finds that the destination address of 206.100.176.3 is mapped in its NAT table to 10.1.2.2 and makes the translation to that IL address. The packet is forwarded to Snorkel.
Snorkel sends a packet in response. The source address is 10.1.2.2, and the destination address is 206.100.160.2. The packet is forwarded to Cozumel.
Cozumel translates the packet's source address to 206.100.176.3 and forwards the packet to Guaymas.
Guaymas translates the packet's destination address to 10.1.2.2 and forwards the packet to Beachball.
By following this example, you can see that although two devices have the same IP address, neither is aware of the other's true address. The key to making all this work is the routing configurations of Cozumel and Guaymas. Neither router leaks information about the 10.0.0.0 network to the other. Nothing in either configuration allows a packet with a destination address within the 10.0.0.0 network to be forwarded to the other router, with the exception of packets destined for the directly connected 10.255.13.248/29 subnet. Access list 1 is configured so that packets sourced from either router's E1 interface are not translated.
NOTE
Troubleshooting Exercise 3 asks you to consider this access list configuration further.
Another detail of interest in Example 4-20 is that there is more than one inside interface at Guaymas. Multiple inside interfaces are quite acceptable.
One topic of importance that is not readily evident in the configuration concerns the coordination of the NAT translation timeout period and the DNS cache Time-To-Live (TTL) period. When a DNS server receives a resource record from another DNS server, it caches the record so that it can respond directly to subsequent queries for the same record. In the example in this case study, DNS2 will cache the A RR that maps Snorkel.surf.com to IP address 206.100.176.3. DNS2 can then respond to subsequent requests for Snorkel's IP address without again querying DNS1. This cached RR has a TTL period associated with it and is flushed when the TTL expires. The DNS TTL period must be shorter than the NAT translation timeout period.
Suppose, for example, that the NAT translation timeout expires on the 10.1.2.2-to-206.100.176.3 mapping, and the IG address is returned to the pool. 206.100.176.3 is then mapped to a different IL address within the Surf internetwork, but DNS2 still has an RR mapping Snorkel.surf.com to 206.100.176.3. If a device in the Sand internetwork queries DNS2 for Snorkel's address, DNS2 responds with obsolete information, and packets are sent to the wrong host.
A final note on this design concerns Internet access. You can easily accomplish Internet access by adding an access router to the subnet between Cozumel and Guaymas (see Figure 4-22). The source addresses of packets from both the Surf and Sand internetworks already are translated to valid public addresses; all that is needed is for default routes to be added to Cozumel and Guaymas, pointing to the Internet access router.
){kind=link}
Figure 4-22 The Internet Access Router Does Not Have to Support NAT; All Translations for Internet Traffic Are Performed by Cozumel and Guaymas
Case Study: ISP Multihoming with NAT
The section "NAT and Multihomed Autonomous Systems" earlier in this chapter demonstrated ways you can employ NAT to overcome the problem of multihoming to different ISPs with different CIDR blocks. The subscriber in Figure 4-7 is multihomed, and each ISP sees packets with source addresses belonging to its own address space. Neither ISP receives packets from the subscriber with source addresses belonging to the other ISP's block of addresses.
){kind=link}
Based on the NAT case studies you have already seen, you can easily write configurations for the two NAT routers shown in Figure 4-7. But what about a situation in which a single router is multihomed to both ISPs, as shown in Figure 4-23? Montego is receiving full BGP routes from both ISPs, so it can choose the best provider to any destination. When a packet is forwarded to ISP1, the packet must have a source address from the 205.113.50.0/23 block assigned by ISP1; when a packet is forwarded to ISP2, it must have a source address from the 207.36.76.0/23 block assigned by ISP2.
){kind=link}
Figure 4-23 ISP1 and ISP2 Have Each Assigned a CIDR Block to JamaicaNet; When Packets Are Forwarded to an ISP, They Must Have the Correct Source Address for That ISP
Example 4-21 shows Montego's configuration for using different address pools on different interfaces.
Example 4-21 Montego's Configuration in Figure 4-23
interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip nat inside ! interface Ethernet1 ip address 10.5.1.1 255.255.255.0 ip nat inside ! interface Serial1 no ip address encapsulation frame-relay interface Serial1.708 point-to-point description PVC to ISP1 ip address 205.113.49.253 255.255.255.252 ip nat outside frame-relay interface-dlci 708 ! interface Serial1.709 point-to-point description PVC to ISP2 ip address 207.36.65.253 255.255.255.252 ip nat outside frame-relay interface-dlci 709 ! router ospf 10 network 10.0.0.0 0.255.255.255 area 10 default-information originate always ! router bgp 451 neighbor 205.113.49.254 remote-as 1135 neighbor 207.36.65.254 remote-as 216 ! ip nat pool ISP1 205.113.50.1 205.113.51.254 prefix-length 23 ip nat pool ISP2 207.36.76.1 207.36.77.254 prefix-length 23 ip nat inside source route-map ISP1_MAP pool ISP1 ip nat inside source route-map ISP2_MAP pool ISP2 ! access-list 1 permit 10.0.0.0 0.255.255.255 access-list 2 permit 207.36.65.254 ! route-map ISP1_MAP permit 10 match ip address 1 match interface Serial1.708 ! route-map ISP2_MAP permit 10 match ip address 1 match ip next-hop 2 !
The address blocks assigned by the ISPs are specified in the pools ISP1 and ISP2. The significant feature of this NAT configuration is that the ip nat inside source statements make calls to route maps rather than access lists. By using route maps, you can specify not only the IL address, but also the interface or the next-hop address to which the packet is to be forwarded. ISP1_MAP specifies packets that have a source address belonging to the 10.0.0.0 network (as identified by access list 1) and which are to be forwarded out interface s1.708 to ISP1. ISP2_MAP also specifies packets from 10.0.0.0 that are to be forwarded to the next-hop address 207.36.65.254 to ISP2.
NOTE
Normally, either the match interface or the match ip next-hop command is used in both route maps for consistency. Both commands are used here for demonstration purposes.
For example, an inside device with an address of 10.1.2.2 sends a packet with a destination address of 137.19.1.1. The packet is forwarded to Montego, because that router is advertising a default route into JamaicaNet via OSPF. Montego does a route lookup and determines that the best route to the destination is via ISP2, out S1.709 and with a next-hop address of 207.36.65.254. The first ip nat inside source statement checks this information against route map ISP1_MAP. Although the source address matches, the egress interface does not. The second ip nat inside source statement checks the information against route map ISP2_MAP. Here both the source address and the next-hop address match, so the source address is translated to an address out of the ISP2 pool.
Example 4-22 shows Montego's NAT table after some traffic has passed to the ISPs. Because an IL address can be mapped to an address from more than one pool, the address mappings are extended mappings, showing the protocol type and the port number. Extended mapping is discussed in more detail in the case study "Port Address Translation."
Example 4-22 Montego's NAT Table Shows That the IG Address Chosen for Translation Depends on the ISP to Which the Packet Is to Be Forwarded
Montego#show ip nat translations Pro Inside global Inside local Outside local Outside global udp 207.36.76.2:4953 10.1.2.2:4953 137.19.1.1:69 137.19.1.1:69 udp 205.113.50.2:2716 10.1.1.2:2716 171.35.100.4:514 171.35.100.4:514 tcp 205.113.50.1:11009 10.5.1.2:11009 205.113.48.1:23 205.113.48.1:23 tcp 207.36.76.1:11002 10.1.1.2:11002 198.15.61.1:23 198.15.61.1:23 tcp 205.113.50.3:11007 10.1.2.2:11007 171.35.18.1:23 171.35.18.1:23 tcp 207.36.76.2:11008 10.1.2.2:11008 207.36.64.1:23 207.36.64.1:23 Montego#
Of interest in the NAT table in Example 4-22 are the three entries for the IL address 10.1.2.2. The UDP traffic and one of the TCP sessions went to a destination via ISP2. The IG address to which the IL address is mapped is 207.36.76.2. The other TCP session was sent via ISP1 and so was mapped to 205.113.50.3. These entries demonstrate that the pool from which the IG address is chosen changes, even for the same source address, depending on where the packet is forwarded.
Figure 4-24 shows DNS servers for the three autonomous systems. The servers in ISP1 and ISP2 must access Ochee, the DNS server authoritative for JamaicaNet. This means that Ochee must have static NAT entries to addresses in both CIDR blocks. Statically mapping an IL address to more than one IG address is normally not allowed, because the mappings are ambiguous. In this case, ambiguity is not a problem because the same NAT is doing both mappings. When Montego routes Ochee's DNS queries and responses to DNS1 or DNS2, the appropriate translations are made.
){kind=link}
Figure 4-24 The DNS Server Ochee Must Have a Static IL-to-IG Mapping So That It Can Be Queried by DNS1 and DNS2
To allow static NAT mappings of one IL address to multiple IG addresses, the keyword extendable is added to the end of the mapping statements. Example 4-23 shows the NAT configuration for Montego.
Example 4-23 NAT Configuration for Montego to Allow Static NAT Mappings of One IL Address to Multiple IG Addresses
ip nat pool ISP1 205.113.50.2 205.113.51.254 prefix-length 23 ip nat pool ISP2 prefix-length 23 address 207.36.76.1 207.36.76.99 address 207.36.76.101 207.36.77.254 ip nat inside source route-map ISP1_MAP pool ISP1 ip nat inside source route-map ISP2_MAP pool ISP2 ip nat inside source static 10.5.1.2 207.36.76.100 extendable ip nat inside source static 10.5.1.2 205.113.50.1 extendable ! access-list 1 permit 10.0.0.0 0.255.255.255 access-list 2 permit 207.36.65.254 ! route-map ISP1_MAP permit 10 match ip address 1 match interface Serial1.708 ! route-map ISP2_MAP permit 10 match ip address 1 match ip next-hop 2
From the perspective of DNS1, Ochee's address is 205.113.50.1. Notice that NAT pool ISP1 is modified to exclude this address from the pool. From the perspective of DNS2, Ochee's address is 207.36.76.100. This address is taken from the middle of the 207.36.76.0/23 block rather than from one end or the other, making pool ISP2 discontiguous. The pool is modified in the configuration to specify two ranges of addresses: those before Ochee's address, and those after Ochee's address.
You configure a discontiguous range of addresses by first naming the pool and specifying the prefix length or netmask. The configuration prompt then enables you to enter a list of ranges. Example 4-24 shows the configuration steps for pool ISP2, including the prompts.
Example 4-24 Configuring a NAT Pool for a Discontiguous Range of Addresses
Montego(config)#ip nat pool ISP2 prefix-length 23 Montego(config-ipnat-pool)#address 207.36.76.1 207.36.76.99 Montego(config-ipnat-pool)#address 207.36.76.101 207.36.77.254
Port Address Translation
At the opposite extreme from the multihomed NAT router in the preceding case study is the SOHO (small office, home office) router connecting a few devices to the Internet. Instead of acquiring separate public addresses for each device, port address translation (PAT) allows all the SOHO devices to share a single IG address.
PAT allows overloading, or the mapping of more than one IL address to the same IG address. To accomplish this, the NAT entries in the routing table are extended entries—the entries track not only the relevant IP addresses, but also the protocol types and ports. By translating both the IP address and the port number of a packet, up to 65535 IL addresses could theoretically be mapped to a single IG address (based on the 16-bit port number).
NOTE
Each NAT entry uses approximately 160 bytes of memory, so 65535 entries would consume more than 10 MB of memory and large amounts of CPU power. Nowhere near this number of addresses are mapped in practical PAT configurations.
Cisco's NAT attempts to preserve BSD semantics, mapping an IL port number to the same IG port number whenever possible. A different IG port number is used only when the port number associated with the IL address is already being used in another mapping.
Figure 4-25 shows three devices connected to an ISP.
){kind=link}
Figure 4-25 Barbados Uses PAT to Map the Addresses of the Three Inside Hosts to the Single Serial Interface Address
The access router has a single public IP address assigned by the ISP on its serial interface, as demonstrated in the configuration in Example 4-25.
Example 4-25 Enabling PAT on Router Barbados in Figure 4-25
interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Serial0 ip address 207.35.14.82 255.255.255.252 ip nat outside ! ip nat inside source list 1 interface Serial0 overload ! ip route 0.0.0.0 0.0.0.0 Serial0 ! access-list 1 permit 192.168.1.0 0.0.0.255 !
PAT is enabled with the overload keyword. Although the ip nat inside source command could reference an address pool, in this case it just references the interface on which the IG address is configured. As usual, the access list identifies the IL addresses.
Example 4-26 shows the NAT table in the access router after a few packets have passed through it. Most of the IG ports match the IL ports, but notice that there are two instances in which an IL socket has a port number that has already been used (192.168.1.2:11000 and 192.168.1.2:11001). As a result, the NAT has chosen an unused port for these sockets that does not match the IL port.
Example 4-26 Different IL Addresses Have Been Mapped to Different Ports of the Same IG Address
Barbados#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 207.35.14.82:11011 192.168.1.3:11011 191.115.37.2:23 191.115.37.2:23 tcp 207.35.14.82:5000 192.168.1.2:11000 191.115.37.2:23 191.115.37.2:23 udp 207.35.14.82:3749 192.168.1.2:3749 135.88.131.55:514 135.88.131.55:514 tcp 207.35.14.82:11000 192.168.1.4:11000 191.115.37.2:23 191.115.37.2:23 tcp 207.35.14.82:11002 192.168.1.2:11002 118.50.47.210:23 118.50.47.210:23 udp 207.35.14.82:9371 192.168.1.2:9371 135.88.131.55:514 135.88.131.55:514 icmp 207.35.14.82:7428 192.168.1.3:7428 135.88.131.55:7428 135.88.131.55:7428 tcp 207.35.14.82:5001 192.168.1.2:11001 135.88.131.55:23 135.88.131.55:23 tcp 207.35.14.82:11001 192.168.1.4:11001 135.88.131.55:23 135.88.131.55:23 Barbados#
Case Study: TCP Load Balancing
Figure 4-26 shows a topology similar to the one in the PAT case study. Here the three inside devices are not hosts, however, but are identical servers with mirrored content. The intent is to create a "virtual server" with an address of 199.198.5.1; that is, from the outside there appears to be a single server at that IG address. In reality, the router Barbados is configured to perform round-robin translations to the three IL addresses.
){kind=link}
Figure 4-26 The Three Inside Devices Are Identical Servers with Mirrored Content, Which from the Outside Appear to Be a Single Server
Example 4-27 shows the configuration for Barbados.
Example 4-27 Barbados' NAT Configuration Evenly Distributes the TCP Load to the Three Identical Servers; Outside Devices See Only a Single Inside Global Address
interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Serial0 ip address 207.35.14.82 255.255.255.252 ip nat outside ! ip nat pool V-Server 192.168.1.2 192.168.1.4 prefix-length 24 type rotary ip nat inside destination list 1 pool V-Server ! ip route 0.0.0.0 0.0.0.0 Serial0 ! access-list 1 permit 199.198.5.1 !
Instead of translating an IL address as most of the previous case studies have demonstrated, this configuration translates the IG address. The address pool V-Server contains a list of the available IL addresses, and the keywords type rotary cause a round-robin assignment of the pool addresses. The access list, as usual, identifies the address to be translated—in this case, the single destination address 199.198.5.1.
Example 4-28 shows the resulting NAT table after four outside devices have sent TCP traffic to the virtual server. You can observe that the first three connections (reading from the bottom up) were allocated sequentially from the lowest IL address in the pool to the highest. Only three addresses are available in the pool, so the fourth connection is again mapped to the lowest IL address.
Example 4-28 The TCP Connections to the Virtual Server Address 199.198.5.1 Are Balanced Across the Three Real Server Addresses
Barbados#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 199.198.5.1:23 192.168.1.2:23 203.1.2.3:11003 203.1.2.3:11003 tcp 199.198.5.1:23 192.168.1.4:23 135.88.131.55:11002 135.88.131.55:11002 tcp 199.198.5.1:23 192.168.1.3:23 118.50.47.210:11001 118.50.47.210:11001 tcp 199.198.5.1:23 192.168.1.2:23 191.115.37.2:11000 191.115.37.2:11000 Barbados#
Case Study: Service Distribution
You also can use NAT to create a virtual server in which connections are distributed by TCP or UDP services rather than by TCP connection. The internetwork in Figure 4-27 is very similar to that in Figure 4-26, except that the servers are not identical. Rather, different servers offer different services. From the outside, all three servers appear to be a single server with the address 199.198.5.1.
){kind=link}
Figure 4-27 Three Inside Devices That Offer Different Services Appear to Be a Single Server from the Outside
Example 4-29 shows the NAT configuration in Barbados.
Example 4-29 The NAT Configuration in Barbados Translates the Virtual IG Address According to the TCP or UDP Port Associated with the Address
interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface Serial0 ip address 207.35.14.82 255.255.255.252 ip nat outside ! ip nat inside source static tcp 192.168.1.4 25 199.198.5.1 25 extendable ip nat inside source static udp 192.168.1.3 514 199.198.5.1 514 extendable ip nat inside source static udp 192.168.1.3 69 199.198.5.1 69 extendable ip nat inside source static tcp 192.168.1.3 21 199.198.5.1 21 extendable ip nat inside source static tcp 192.168.1.3 20 199.198.5.1 20 extendable ip nat inside source static tcp 192.168.1.2 80 199.198.5.1 80 extendable ! ip route 0.0.0.0 0.0.0.0 Serial0 !
No address pools or access lists are here; instead, the configuration is a series of simple IL-to-IG mappings. The difference between these statements and the static statements you saw earlier is that TCP or UDP is specified, as are the source and destination ports. The extendable keyword is used, because the same address—this time, the IG address—appears in more than one statement. You do not have to type the keyword: Cisco IOS Software adds it automatically. In order, the statements map SMTP (TCP port 25), syslog (UDP port 514), TFTP (UDP port 69), FTP (TCP ports 20 and 21), and HTTP (TCP port 80).
Example 4-30 shows the NAT table just after Barbados is configured; the only entries are the static entries.
Example 4-30 Before Any Dynamic Translations Occur, Barbados' NAT Table Contains Only the Static Mappings of IL Sockets to IG Sockets
Barbados#show ip nat translations Pro Inside global Inside local Outside local Outside global udp 199.198.5.1:514 192.168.1.3:514 --- --- udp 199.198.5.1:69 192.168.1.3:69 --- --- tcp 199.198.5.1:80 192.168.1.2:80 --- --- tcp 199.198.5.1:21 192.168.1.3:21 --- --- tcp 199.198.5.1:20 192.168.1.3:20 --- --- tcp 199.198.5.1:25 192.168.1.4:25 --- --- Barbados#
Example 4-31 shows the NAT table after some traffic has passed through Barbados. Notice that among all the dynamic mappings, only two OG addresses appear. Yet the sessions have been mapped to different IL addresses, depending on the port associated with the IG address.
Example 4-31 UDP and TCP Packets Are Mapped to Different IL Addresses, Depending on Their Associated Port Numbers
Barbados#show ip nat translations Pro Inside global Inside local Outside local Outside global udp 199.198.5.1:514 192.168.1.3:514 --- --- tcp 199.198.5.1:25 192.168.1.4:25 207.35.14.81:11003 207.35.14.81:11003 udp 199.198.5.1:69 192.168.1.3:69 --- --- tcp 199.198.5.1:80 192.168.1.2:80 --- --- tcp 199.198.5.1:21 192.168.1.3:21 --- --- tcp 199.198.5.1:20 192.168.1.3:20 --- --- tcp 199.198.5.1:25 192.168.1.4:25 --- --- tcp 199.198.5.1:20 192.168.1.3:20 191.115.37.2:1027 191.115.37.2:1027 tcp 199.198.5.1:21 192.168.1.3:21 191.115.37.2:1026 191.115.37.2:1026 tcp 199.198.5.1:80 192.168.1.2:80 191.115.37.2:1030 191.115.37.2:1030 udp 199.198.5.1:69 192.168.1.3:69 191.115.37.2:1028 191.115.37.2:1028 udp 199.198.5.1:514 192.168.1.3:514 207.35.14.81:1029 207.35.14.81:1029 Barbados#