In the previous chapter, I assumed that you would use a standard ACL to specify the inside local addresses to be translated when leaving the network. The problem with this process is that, in some situations, you want to control when address translation takes place. For example, you might want a particular set of inside local addresses to be translated when they are sent to a particular network number, or to not be translated at all.
Figure 12-2 shows a simple example of a situation in which you might not want to translate addresses. Controlling the use of address translation is common in VPN connections, in which you are using a public network as a transparent transport to tunnel information between your sites. In this example, an IPSec VPN is used to connect the two remote sites. In this instance, when traffic is flowing between the two sites, the addresses should not be translated; however, when traffic from either site goes to other locations in the Internet, it should be translated.
One of the easiest ways to control address translation is to use ACLs. ACLs are not used to filter traffic in this instance; they are used to specify when addresses should be translated. Chapter 11, "Address Translation," discussed how to use a standard ACL to do this. However, the problem with a standard ACL is that it specifies when traffic should be translated based on where the traffic is coming from: not where it is both coming from and going to.
No restriction states that you must use a standard ACL. Instead, you can use an extended ACL. As an example, you could use the code listing in Example 12-2 to implement address translation control for the network shown in Figure 12-2 for RouterA.
Router(config)# ip nat inside source list dynamic-nat-addresses (1) pool dynamic-nat-pool Router(config)# ip access-list extended dynamic-nat-addresses (2) Router(config-ext-nacl)# deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 Router(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any Router(config-std-nacl)# exit Router(config)# ip nat pool dynamic-nat-pool 192.1.1.20 (3) 192.1.1.254 netmask 255.255.255.0 Router(config)# interface ethernet0 Router(config-if)# ip nat inside Router(config-if)# exit Router(config)# interface ethernet1 Router(config-if)# ip nat outside
Refer to the numbers on the right side of Example 12-2 for the explanation. As you can see from Statement 1, dynamic NAT is used. Statement 2 sets up an extended ACL:
Any traffic from 192.168.1.0/24 to 192.168.2.0/24 is not translated.
Any other traffic from 192.168.1.0/24 is translated.
In Statement 3, the NAT pool is defined: Addresses from 192.1.1.20 to 192.1.1.254 are placed in this pool. You will see more examples like this when I discuss VPNs in Part VIII, "Virtual Private Networks."
NOTE
Even though this example used NAT, you also could have used PAT in this configuration.
ACLs are only one method that you can use to specify when address translation should occur. The Cisco IOS also supports the use of route maps. Route maps create a fully extended translation entry, which contains the inside and outside local and global addresses, as well as the local and global TCP or UDP port numbers in the translation table. Table 12-2 explains the difference between the entries in the address translation table with ACLs and route maps.
Translation Method | What Is Translated |
---|---|
ACL (no overload) | Only the local and global IP inside addresses. This is referred to as a simple entry in the address translation table. |
ACL (with overload) | The local and global addresses, as well as the local and global port numbers. |
Route map | The local and global addresses, as well as the local and global port numbers (the same as an ACL with PAT, or overload). |
Using ACLs without PAT, or address overloading, can create problems in certain situations. In Figure 12-3, the internal network on the left is using a private address space (10.0.0.0/8) and has a connection to two different ISPs. For ISP1, this network must use the public address space of 192.1.1.0/24 when connecting to its internal network (192.1.2.0/24). For ISP2, the network must use 193.1.1.0/24 when connecting to IPS2's internal network (193.1.2.0/24). RouterA is performing the address translation.
Assume that dynamic NAT is used for outbound traffic and that the configuration uses ACLs. Example 12-3 shows a simplified configuration that RouterA is using.
Router(config)# ip nat pool isp1-pool 192.1.1.1 192.1.1.254 (1) prefix-length 24 Router(config)# ip nat pool isp2-pool 193.1.1.1 193.1.1.254 (2) prefix-length 24 Router(config)# ip nat inside source list isp1-acl pool isp1-pool (1) Router(config)# ip nat inside source list isp2-acl pool isp2-pool (2) Router(config)# ip access-list extended isp1-acl (1) Router(config-ext-nacl)# permit ip 10.0.0.0 0.255.255.255 192.1.2.0 0.0.0.255 Router(config-ext-nacl)# exit Router(config)# ip access-list extended isp2-acl (2) Router(config-ext-nacl)# permit ip 10.0.0.0 0.255.255.255 193.1.2.0 0.0.0.255 Router(config-ext-nacl)# exit Router(config)# interface ethernet0 Router(config-if)# ip nat inside Router(config-if)# exit Router(config)# interface ethernet1 Router(config-if)# ip nat outside
In this example, the statements marked 1 on the right refer to the address translation that occurs between 10.0.0.0/8 and 192.1.2.0/24; statements marked 2 refer to the address translation between 10.0.0.0/8 and 193.1.2.0/24. Notice that this example uses dynamic NAT, not PAT, translation.
Now take a look at a problem that this configuration produces when an internal device, Host1, wants to connect to Host2 in ISP1 and Host3 in ISP2. Assume that Host1 makes an initial connection to Host2, perhaps a Telnet connection. When this occurs, RouterA examines the connection, realizes that an address translation does not exist in the translation table, and creates one:
Pro Inside global Inside local Outside local Outside global --- 192.1.1.1 10.1.1.1 --- ---
Notice that in the translation table, only the local and global addresses are listed for the translation. This is because this configuration used dynamic NAT without overload, so a simple translation is created.
Assume that after the Telnet connection has been established, Host1 sets up a Telnet to Host3 in ISP2. Can you see what the problem is? When RouterA receives the packets from Host1, it examines the address translation table and sees that there is already an entry for Host1. So, RouterA translates Host1's source address to 192.1.1.1. The problem with this scenario is that Host1 should be translated to 193.1.1.x when sending traffic to 193.1.2.x. In this situation, the router ignores the address translation information in the two ACL statements because an entry already exists in the translation table.
You can use two methods to solve the previous problem: Use address overloading or use route maps. With address overloading, PAT is used, creating an extended entry in the address translation table that includes the local and global inside and outside IP addresses, as well as the local and global inside and outside port numbers. The main problem with address overloading is that it requires the use of PAT, which might cause issues if you really need to use NAT.
Fortunately, route maps also support extended entries but do not require the use of PAT. Normally, route maps are used to implement routing policies on your router, but Cisco has adapted them to be used in other situations, such as address translation. I assume that you are familiar with the general use of route maps on a Cisco IOS router. To reference a route map to use with dynamic NAT, use the following dynamic NAT command:
Router(config)# ip nat inside source route-map route_map_name pool NAT_pool_name
As you can see, this command is similar to the one in which you use an ACL to specify which addresses are translated; the only difference is that you use the route-map parameter, along with the name of the route map, instead of the list parameter.
Example 12-4 shows a configuration on RouterA that uses route maps to perform address translation for the network shown in Figure 12-3.
Router(config)# ip nat pool isp1-pool 192.1.1.1 192.1.1.254 prefix-length 24 Router(config)# ip nat pool isp2-pool 193.1.1.1 193.1.1.254 prefix-length 24 Router(config)# ip nat inside source route-map isp1-map (1A) pool isp1-pool Router(config)# ip nat inside source route-map isp2-map (1B) pool isp2-pool Router(config)# route-map isp1-map permit 10 (2A) Router(config-route-map)# match ip address isp1-acl Router(config-route-map)# exit Router(config)# route-map isp2-map permit 10 (2B) Router(config-route-map)# match ip address isp2-acl Router(config-route-map)# exit Router(config)# ip access-list extended isp1-acl (3A) Router(config-ext-nacl)# permit ip 10.0.0.0 0.255.255.255 192.1.2.0 0.0.0.255 Router(config-ext-nacl)# exit Router(config)# ip access-list extended isp2-acl (3B) Router(config-ext-nacl)# permit ip 10.0.0.0 0.255.255.255 193.1.2.0 0.0.0.255 Router(config-ext-nacl)# exit Router(config)# interface ethernet0 Router(config-if)# ip nat inside Router(config-if)# exit Router(config)# interface ethernet1 Router(config-if)# ip nat outside
I want to point out a few things concerning this example. Statements 1A and 1B (referring to the numbers on the right side of Example 12-4) associate the internal addresses that should be translated (through a route map) with the global address pool that should be used in the translation. Notice that this example uses dynamic NAT, not PAT, which is just like the previous ACL example. Statements 2A and 2B create the route maps. In this example, for isp1-map, any packets that match isp1-acl should be translated using the associated ip nat inside source route-map command. Statements 3A and 3B specify the ACLs used by the two route map commands, which control which packets will be translated.
Now re-examine the connections that Host1 makes and the address translation process that occurs when route maps are used, using the same scenario described in the ACL example.
First, Host1 Telnets to Host2. Assume that this is the first connection from Host1. When this occurs, RouterA notices that no address translation exists, so it creates one:
Pro Inside global Inside local Outside local Outside global tcp 192.1.1.1:1024 10.0.0.1:1024 192.1.2.1:23 192.1.2.1:23
This entry obviously looks different from the one in the ACL example. Remember that ACLs with dynamic NAT create a simple entry, whereas route maps (and ACLs with dynamic PAT) create an extended entry.
Next, Host1 sets up a Telnet connection to Host3. When RouterA receives the first packet of this Telnet connection, it compares this to the entries that the router already has in its translation table. It notices that it does not have an entry for this specific connection, so it adds one:
Pro Inside global Inside local Outside local Outside global
tcp 192.1.1.1:1024 10.0.0.1:1024 192.1.2.1:23 192.1.2.1:23
tcp 193.1.1.1:1025 10.0.0.1:1025 193.1.3.1:23 193.1.3.1:23
As you can see from the previous translation table, the bottom entry is the second Telnet, thus solving the connectivity problem: Because the translation has both fully extended entries, the Cisco IOS correctly can translate traffic between the internal host (Host1) and the two external hosts (Host2 and Host3). Of course, you could have used ACLs and PAT to solve this problem, but perhaps PAT would have introduced other connection problems, and using NAT was the preferred solution.
CAUTION
By using route maps, the Cisco IOS creates extended entries in the address translation table, which enables you to set up different address-translation policies with NAT based on the destination address. The only downside of route maps, which is also true of PAT, is that because these configurations create extended entries, you need more memory on your router to store all the entries.
Address Translation and Route MapsOne of my customers needed to use NAT to connect to two other customers; PAT caused problems. However, when performing address translation, one set of translations was to be used for one remote customer, and another set was to be used for the other remote customer. When I set it up, I did not realize that route maps were supported, so I used extended ACLs to match the packets to be translated. I soon found out that when an internal employee tried to access both remote customers, only one worked. It took a day to track down the problem. When I called TAC for a helpful hint, the experts recommended the use of route maps. Since then, I have been a die-hard route-map fan when it comes to setting up address translation. You can do some interesting things with route maps that can't be done with ACLs; I show you one of these things, using the route map match interface command, in the next section. |
The previous section showed you how to use route maps with dynamic NAT. Route maps also are supported with static NAT as of Cisco IOS 12.2(4)T. Currently, static NAT with route maps is supported only for individual address translations; translation of entire network numbers is not supported yet with route maps. To configure static NAT with a route map, use one of the following two commands:
Router(config)# ip nat inside source static local_IP_address global_IP_address route-map route_map_name [extendable] Router(config)# ip nat inside source static tcp | udp local_IP_address local_port_# global_IP_address global_port_# route-map route_map_name [extendable]
Typically, the ip nat inside source static command is used to translate a small number of entries between your network and two other networks. However, this command provides one interesting parameter: extendable. This parameter causes the Cisco IOS to create an extended translation entry in the translation table instead of a simple entry.
Take a look at the use of this parameter by examining the network shown in Figure 12-4. In this example, the network on the left has two Internet connections for redundancy. ISP1 has assigned an IP address space of 192.1.1.0/24. ISP2, which does not support ISP1's address space, has assigned 193.1.1.0/24 to this network. This poses a problem because you need to set up a static translation for the internal web server. Normally, a static statement allows only one translation. In this example, you must choose between 192.1.1.1 translated to 10.0.0.1, or 193.1.1.1 translated to 10.0.0.1 for the web server translation.
Using the extendable parameter, however, you can associate more than one global address with a local address. To solve the address translation problem shown in Figure 12-4 for the internal web server, RouterA's configuration would look like Example 12-5.
Router(config)# ip nat inside source static (1A) 10.0.0.1 192.1.1.1 route-map isp1-map extendable Router(config)# ip nat inside source static (1B) 10.0.0.1 193.1.1.1 route-map isp2-map extendable Router(config)# route-map isp1-map permit 10 (2A) Router(config-route-map)# match interface ethernet1 Router(config-route-map)# exit Router(config)# route-map isp2-map permit 10 (2B) Router(config-route-map)# match interface ethernet2 Router(config-route-map)# exit Router(config-ext-nacl)# exit Router(config)# interface ethernet0 Router(config-if)# ip nat inside Router(config-if)# exit Router(config)# interface ethernet1 Router(config-if)# ip nat outside Router(config-if)# exit Router(config)# interface ethernet2 Router(config-if)# ip nat outside
In this example, Statements 1A and 1B (referring to the numbers on the right side of Example 12-5) specify the static translations of the web server for the two ISPs. Notice that I included the extendable parameter: This causes the Cisco IOS to create an extended entry when a user sends traffic to the internal web server. When the web server responds with the HTML information, the Cisco IOS can determine how to undo the translation and send the traffic out the right interface (ISP1 or ISP2) to return the traffic to the user who originated the request.
TIP
One of the interesting things about the route maps in Example 12-5 (Statements 2A and 2B) is that they specify the interface of the inbound traffic, helping the router perform the address translation correctly. In most instances, you have two interfaces on your router connecting to the two ISPs. In this instance, you set up the appropriate address translation (static or dynamic), but you reference the translation with the match interface command in your route map configuration. I use this quite often when I have a single router with dual ISPs that require me to use different address spaces.