Controlling Address Translation

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.

Figure 12-2. Controlling Address Translation

[View full size image]
graphics/12fig02.gif


Using ACLs

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.

Example 12-2. Using an Extended ACL in Address Translation

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.


Using Route Maps: Dynamic Translations

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.

Table 12-2. ACLs Versus 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).


Problems with ACLs and Address Translation

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.

Figure 12-3. ACLs Versus Route Maps

[View full size image]
graphics/12fig03.gif


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.

Example 12-3. Problems with ACLs and Address Translation

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.

Route Map Configuration

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.

Example 12-4. Using Route Maps to Create Extended Address Translation Entries

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 Maps

One 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.


Using Route Maps: Static Translations

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.

Figure 12-4. Extendable Statics and Route Maps

[View full size image]
graphics/12fig04.gif


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.

Example 12-5. Using Extendable Static Translations in Route Maps

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.