Section 11-2. Configuring Network Address Translation

11-2. Configuring Network Address Translation

You can use Network Address Translation (NAT) to translate the IP address of a host on one IOS firewall interface to a different address on another interface. This is useful for conserving IP address space, as well as for isolating or hiding internal hosts behind public IP addresses so that they don't have a presence on the public network.

Address translation is triggered by packets moving across NAT boundaries. The boundaries are marked by an inside and outside NAT interface. For example, when a packet arrives on an inside NAT interface and is forwarded on an outside NAT interface, address translation is triggered. The reverse is also truea packet arriving on the outside NAT interface triggers address translation on its way to an inside NAT interface.

Naturally, the packet addresses must then match a configured NAT entry for the translation to actually take place. For example, you can configure NAT to translate a source or destination address that appears on an inside NAT interface. This is usually called inside NAT because it occurs on an inside NAT interface. You can also configure NAT to translate a source or destination address on an outside interface. This is called outside NAT.

Inside NAT is typically used when host addresses on an inside private network need to appear as global addresses on an outside public network. Outside NAT is useful when host addresses on an outside interface need to appear as something else on an inside private network.

NOTE

Don't confuse inside and outside NAT interfaces with inside and outside firewall interfaces. These are two different conceptsone involving address translation boundaries and the other involving security policy boundaries. To avoid confusion, interfaces involved with NAT are always called NAT interfaces in this section.

NAT Operation

You can configure NAT to translate addresses on an inside or outside NAT interface. NAT also can translate either source or destination addresses in IP packets passing through the IOS firewall. Because of its flexibility, NAT can be somewhat confusing to understand and configure.

To simplify matters, NAT is based on the following concepts:

• Local address A host's original or untranslated address

• Global address The translated address of a host's local address

The local and global addresses apply to inside and outside hosts as well. For example, a host's inside local address is that host's original address as it appears on an inside NAT router interface. The inside global address is the inside host's translated address as it appears on an outside NAT interface.

Figure 11-2 illustrates the NAT process. In this case, Host A is located on an inside NAT interface, and Host B is on an outside NAT interface. When Host A initiates a connection with Host B, the IOS firewall is configured to perform inside source address translation. In other words, for every packet that Host A sends through the IOS firewall toward Host B, the firewall translates the source address in the IP header. The inside source address is rewritten to become the corresponding global source address.

Figure 11-2. NAT Through an IOS Firewall

When packets return from Host B to Host A, the process is reversed. The object of the translation is now located in the destination address field of inbound packets. As the packets cross the NAT boundary, the inside global addresses are rewritten to the inside local address. This occurs automatically, without any configuration to translate the destination address. The firewall can determine the reverse translation based on the fact that the inbound packets pass in the reverse direction, from an outside NAT interface to an inside NAT interface.

When connections are initiated between hosts and NAT is triggered, the IOS firewall adds an entry to its IP translation table. This entry can be one of two types:

• Simple translation A local address is translated to a global address. No port or target address information is kept.

• Extended translation The local and global addresses of an inside and outside host are kept, along with the corresponding port numbers.

Notice that the simple translation entry describes only the translation of a host's address. It isn't specific about UDP or TCP ports that need translating or about any target host addresses or ports. The idea is to use a simple translation as a catchall so that the translation occurs any time that host crosses the NAT boundary in the firewall.

A simple translation entry can become ambiguous when several different types of NAT are configured for the same inside or outside addresses. For example, suppose an inside host with local address 192.168.1.1 is configured to be translated to global address 10.1.1.1. That NAT table entry might look like this:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global --- 10.1.1.1           192.168.1.1        ---                --- IOSFirewall# 

This works fine as long as 192.168.1.1 can always appear as 10.1.1.1. Now suppose a second type of NAT is configured so that 192.168.1.1 is translated to a different global address (10.2.1.1) when the host opens a connection to a specific target address. You might expect that the firewall would create a second NAT translation table entry for 192.168.1.1. However, if the previous translation entry to global address 10.1.1.1 is already present in the table, the firewall incorrectly uses that one before creating a new one.

When a local address needs to be translated in multiple ways, the simple translation entry doesn't have enough information to make each one unique. In other words, the translation becomes ambiguous and probably won't occur correctly.

The extended translation entry, however, has enough information to be unique and unambiguous. For example, the following entry triggers a translation from the inside local address and port to the inside global address and port when the target is the outside local address and port listed:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global tcp 10.1.1.1:4383      192.168.17.1:4383  10.71.4.4:80       10.71.4.4:80 IOSFirewall# 

The extended entry is unique right down to the protocol (TCP) and ports being used, allowing the translations to be made correctly. You might have noticed that the extended entry looks very much like it is defining a TCP connection between the hosts. In fact, extended translation entries are often created dynamically as connections initiate.

Security is one other aspect of the translation table that you need to consider. Address translation alone cannot provide a sufficient level of security. You should couple address translation with stateful packet inspection to become fully secure.

However, a simple translation entry can introduce vulnerabilities. The simple entry specifies only the translation of the local host to the global address, which also means that hosts on the outside can potentially reach the inside host by using its global address. If the firewall is configured to permit the inbound traffic, a malicious host on the outside can freely contact the inside host.

This scenario is not true with the extended translation. The translation occurs only for traffic passing between two specific hosts using a specific protocol and two specific port numbers. Hosts other than those in the extended entry would not be able to send traffic through the translation and through the firewall.

As you work through NAT configuration, be aware that certain types of NAT create simple translation entries, and other types create extended entries. For example, static NAT and NAT triggered by an access list both create simple entries. Static PAT and NAT triggered by a route map create extended entries.

Using Static Address Translations

• Static address translations are used when an internal or local host needs to have the same global address for every connection. Address translation occurs on a one-to-one basis.

• Figure 11-3 shows two internal hosts that have a static translation. To hosts on the outside of the IOS firewall, the internal hosts appear to use global addresses. For example, Host A is configured with IP address 192.168.100.100 on its internal network but appears to use 169.65.41.100 on the outside.

  Figure 11-3. Static NAT Operation Across an IOS Firewall

  

  
  

Static translations can be defined for a single host or for all addresses contained in an IP subnet.

Port static address translations allow a specific UDP or TCP port on a global address to be translated to a specific port on a local address. In other words, both address and port numbers are translated.

Several inside local addresses can be translated into a single global address, each having a distinct global port number. Outside hosts can access one global address for many different services, depending on the port number used. The port numbers are translated to individual local hosts on the inside.

Port static translation can be very handy if your service provider gives you only one IP address to use for the outside IOS firewall interface. In this case, no additional global addresses are available for static translations to inside hosts.

Figure 11-4 shows how port static translation can be used. One global address, 172.17.3.3, is configured to represent three unique inside servers and their applications. Connections to 172.17.3.3 on TCP port 80 actually go to Host A at 192.168.5.100 on TCP port 80. Connections to 172.17.3.3 on TCP port 25 go to Host B at 192.168.5.101 on TCP port 25. Finally, connections to 172.17.3.3 on UDP port 53 go to Host C at 192.168.5.102 on UDP port 53.

Figure 11-4. Port Static NAT Operation Across an IOS Firewall

To configure static NAT on an IOS firewall, follow these steps:

1.	(Optional) Conditionally translate based on a route map. Beginning with Cisco IOS software Release 12.2(4)T, you can reference a route map to define the conditions that trigger the creation of a static NAT entry. Configure the route map named map-name with the following command: IOSFirewall(config)# route-map map-name permit [statement-num] The statement numbers within a route map are automatically defined and incremented unless you specify a statement-num here. Next, specify the translation parameters to match using one or more of the following commands: IOSFirewall(config-route-map)# match ip address {acl-num | acl-name} or IOSFirewall(config-route-map)# match ip next-hop {acl-num | acl-name} or IOSFirewall(config-route-map)# match interface type mod/num These match statements are used to identify the local IP address, next-hop router address, or outbound interface, respectively. Matching conditions flag the packet for address translation.
2.	Define a static NAT method. You can define a static NAT that translates a single local address (and any protocols or ports it uses), a whole subnet of local addresses, or a single local protocol/port/address combination. In each of the static NAT configurations, you can specify any of the following options: - extendable You can use this keyword when several ambiguous simple translations exist for the same local or global IP addresses. In that case, fully extended address and port NAT entries are created to resolve the ambiguity. - no-alias By default, the router answers ARP requests for translations to nonexistent but unused global IP addresses. Use the no-alias keyword if this behavior is not desired. - no-payload Normally, an IOS firewall using the CBAC stateful inspection feature (see section 11-3) looks inside certain application protocol packets for embedded IP addresses. If these are found, any matching address translation entries are used to translate the embedded addresses. You can use the no-payload keyword to prevent translation of embedded addresses. - route-map route-map-name You can use a route map to identify specific conditions that trigger the static NAT. A route map must be defined separately, as discussed in Step 1. a. (Optional) Define a static NAT for a single address: IOSFirewall(config)# ip nat inside source static local-ip global-ip [extendable] [no-alias] [no-payload] [route-map route-map-name] A static entry is made in the translation table such that the source address of local-ip on the inside NAT interface is translated into global-ip on an outside NAT interface. b. (Optional) Translate each address in a subnet: IOSFirewall(config)# ip nat inside source static network local-ip global-ip {netmask | /prefix-length} [extendable] [no-alias] [no-payload] [route-map route-map-name] A static entry is made in the translation table such that each source address within the entire subnet local-ip is translated into corresponding addresses in the global-ip subnet. The network mask is specified as either a regular netmask in dotted notation or as a single number /prefix-length representing the length of the subnet mask prefix. c. (Optional) Define a single port translation: IOSFirewall(config)# ip nat inside source static {tcp | udp} local-ip local-port global-ip global-port [extendable] [no-alias] [no-payload] [route-map route-map-name] A single tcp or udp port number (local-port) is translated, along with the local IP address (local-ip). The resulting translation has a global IP address (global-ip) and a global port number (global-port). You can repeat this command to define other static address/port mappings.
3.	Identify an inside NAT boundary interface: IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip nat inside An inside NAT interface is the one where hosts using local addresses are located. You can repeat this command to define multiple inside NAT interfaces if needed.
4.	Identify an outside NAT boundary interface: IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip nat outside An outside NAT interface is the one where hosts using global addresses are located. You can repeat this command to define multiple outside NAT interfaces if address translation is needed toward multiple networks.

Static NAT Example

For the example shown in Figure 11-3, the IOS firewall can be configured with the following commands:

 IOSFirewall(config)# ip nat inside source static 192.168.100.100 169.65.41.100 IOSFirewall(config)# ip nat inside source static 192.168.100.170 169.65.41.170 IOSFirewall(config)# interface fastethernet 0/0 IOSFirewall(config-if)# description Inside NAT interface IOSFirewall(config-if)# ip address 192.168.100.1 255.255.255.0 IOSFirewall(config-if)# ip nat inside IOSFirewall(config-if)# exit IOSFirewall(config)# interface fastethernet 0/1 IOSFirewall(config-if)# description Outside NAT interface IOSFirewall(config-if)# ip address 169.65.41.1 255.255.255.0 IOSFirewall(config-if)# ip nat outside 

After this configuration, the NAT translation table has the following contents:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global --- 192.168.100.100    169.65.41.100      ---                --- --- 192.168.100.170    169.65.41.170      ---                --- IOSFirewall# 

Conditional or Policy Static NAT Example

You can also reference a route map to identify specific conditions or policies that trigger a static translation. Even though the static NAT entry is created and put into the NAT table, the actual translation entries that are used are generated dynamically as traffic matches the route map.

For example, inside host 192.168.17.1 should be translated to global address 10.1.108.251 when it exchanges packets with any address in the 10.1.111.0/24 subnet. Likewise, the same host should be translated to global address 10.1.108.252 when it communicates with any address in the 10.1.89.0/24 subnet.

You can configure the IOS firewall for these policy NAT operations as follows:

 IOSFirewall(config)# ip access-list extended acl-test1 IOSFirewall(config)# permit ip 192.168.17.0 0.0.0.255 10.1.111.0 0.0.0.255 IOSFirewall(config)# exit IOSFirewall(config)# ip access-list extended acl-test2 IOSFirewall(config)# permit ip 192.168.17.0 0.0.0.255 10.1.89.0 0.0.0.255 IOSFirewall(config)# exit IOSFirewall(config)# route-map test1 IOSFirewall(config-route-map)# match ip address acl-test1 IOSFirewall(config-route-map)# exit IOSFirewall(config)# route-map test2 IOSFirewall(config-route-map)# match ip address acl-test2 IOSFirewall(config-route-map)# exit IOSFirewall(config)# ip nat inside source static 192.168.17.1 10.1.108.251   route-map test1 IOSFirewall(config)# ip nat inside source static 192.168.17.1 10.1.108.252   route-map test2 

The configuration is somewhat involved, but it follows a hierarchy. The ip nat commands reference route maps, which reference access lists to match traffic.

After you enter the configuration, the NAT translation table looks like this:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global --- 10.1.108.251       192.168.17.1       ---                --- --- 10.1.108.252       192.168.17.1       ---                --- IOSFirewall# 

These entries look more like regular static NAT definitions in the output, with no hint about the underlying route map condition. You can add the verbose keyword to see specific flags for an entry. For example, the following output shows that the static NAT entry uses a route map when the inside local address passes through the firewall:

 IOSFirewall# show ip nat translations verbose Pro Inside global      Inside local       Outside local      Outside global --- 10.1.108.251       192.168.17.1       ---                ---     create 13:06:05, use 05:03:57 timeout:0, Map-Id(In): 0,     flags: static, route-map-static, use_count: 0, entry-id: 83, lc_entries: 0 

When the static entry is actually triggered, the route map generates a fully extended entry in addition to the simple static entry. For example, inside local host 192.168.17.1 has attempted to ping outside host address 10.1.111.3 in the following output:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global icmp 128.163.108.251:9 192.168.17.1:9     10.1.111.3:9       10.1.111.3:9 --- 10.1.108.251       192.168.17.1       ---                --- --- 10.1.108.252       192.168.17.1       ---                --- IOSFirewall# 

Port Static Translation Example

For the example shown in Figure 11-4, you can configure the port static translations on the IOS firewall with the following commands:

 IOSFirewall(config)# ip nat inside source static tcp 192.168.5.100 80 172.17.3.3  80 IOSFirewall(config)# ip nat inside source static tcp 192.168.5.101 25 172.17.3.3  25 IOSFirewall(config)# ip nat inside source static udp 192.168.5.102 53 172.17.3.3  53 IOSFirewall(config)# interface fastethernet 0/0 IOSFirewall(config-if)# description Inside NAT interface IOSFirewall(config-if)# ip address 192.168.5.1 255.255.255.0 IOSFirewall(config-if)# ip nat inside IOSFirewall(config-if)# exit IOSFirewall(config-if)# interface fastethernet 0/1 IOSFirewall(config-if)# description Outside NAT interface IOSFirewall(config-if)# ip address 172.17.3.1 255.255.255.0 IOSFirewall(config-if)# ip nat outside 

After this configuration, the NAT translation table looks like the following:

 IOSFirewall# show ip nat translations Pro Inside global      Inside local       Outside local      Outside global tcp 172.17.3.3:80      192.168.5.100:80   ---                --- tcp 172.17.3.3:25      192.168.5.100:25   ---                --- udp 172.17.3.3:53      192.168.5.100:53   ---                --- IOSFirewall# 

Using Dynamic Address Translations

Dynamic address translations can be used when local hosts share or "hide behind" one or more common global addresses. In this mode, one local address can't permanently reserve a global add-ress for translation. Instead, address translation occurs on a many-to-one basis, and translation entries are created only as they are needed. As soon as a translation entry is free from use, it is deleted and made available to other local hosts.

This type of translation is most useful for outbound connections, in which inside hosts are assigned a dynamic address or port number only as connections are made.

Dynamic translation does not allow unsolicited connections to reach inside hosts from the outside, however. This is because the address translations are not put into place until they are needed.

An IOS firewall can translate local addresses dynamically in two ways:

• Dynamic NAT Local addresses are translated into the next available global address in a pool. Translation occurs on a one-to-one basis. Therefore, it is possible to exhaust the pool of global addresses if a greater number of local hosts require translation at a given time.

• Dynamic PAT Local addresses are translated into a single global address; each connection is made unique by assigning the next available port number to the global address. Translation occurs on a one-to-many basis, because many local hosts share one common global address. In theory, one global address can support up to 64,000 different translations, because that many unique port numbers are available.

If both dynamic NAT and PAT are configured, an IOS firewall assigns a dynamic NAT entry first, until the entire address pool is exhausted. As soon as that occurs, dynamic PAT is used until a pool address becomes available again.

• Figure 11-5 illustrates how dynamic address translation can be used. Any host on the inside network 172.16.0.0/16 is translated to the next available global address in the pool 169.54.122.10 through 169.54.122.60. If all those addresses are currently in use with other translations, the firewall translates to the global address 169.54.122.1 (the outside interface address) with a dynamic global port number.

  Figure 11-5. Dynamic NAT and PAT Operation Across an IOS Firewall

  
  
  

• As the IOS firewall builds address translations, it maintains entries in a translation database, which can be displayed with the show ip nat translations command.

Follow these steps to configure dynamic address translation:

1.

(Optional) Configure an address pool for dynamic NAT.

a. (Optional) Define a pool of contiguous global IP addresses:

 IOSFirewall(config)# ip nat pool pool-name start-ip end-ip {netmask   netmask | prefix-length length} 

A single range of contiguous IP addresses is identified as a pool named pool-name, beginning with start-ip and ending with end-ip.

An address mask is specified as either a regular netmask in dotted notation or as a single number length representing the length of the subnet mask prefix. These values help the IOS firewall determine the actual subnet that contains the pool so that the network and broadcast addresses are not used for address translation.

b. (Optional) Define a pool of discontiguous ranges of IP addresses:

 IOSFirewall(config)#  ip nat pool pool-name {netmask netmask |   prefix-length length}(config-ipnat-pool) address start-ip1 end-ip1 (config-ipnat-pool) address start-ip2 end-ip2 (config-ipnat-pool) ... 

You can assign several ranges of IP addresses to a single NAT pool, even if they are not contiguous. In this case, only the pool name is specified, along with either the subnet mask or the prefix length.

The netmask or length is used to derive the network and broadcast addresses for any subnets defined by an address range. The network and broadcast addresses are reserved and can't be used in any translation entries.

The pool's individual ranges are defined with the address command, along with starting and ending IP addresses. You can repeat the address command to define multiple ranges.

2.

Define the conditions to trigger translation.

You can use an access list or route map as a dynamic NAT or PAT trigger. When a packet is permitted by a matching condition, a translation entry is created if one doesn't already exist. Then the packet undergoes address translation by that entry.

a. (Optional) Define conditions in an access list:

Standard numbered access control list (ACL) (acl-num is 1 to 99 or 1300 to 1999)	IOSFirewall(config)# access-list acl-num permit source-address wildcard-mask
Standard named ACL	[View full width] IOSFirewall(config)# ip access-list standard acl-name IOSFirewall(config-std-nacl)# permit {source-address wildcard-mask | host source-address} IOSFirewall(config-std-nacl)# exit
Extended numbered ACL(acl-num is 100 to 199 or 2600 to 2699)	[View full width] IOSFirewall(config)# access-list acl-num permit protocol source-address source-wildcard [operator value] destination-address destination-wildcard [operator value]
Extended named ACL	[View full width] IOSFirewall(config)# ip access-list extended acl-name IOSFirewall(config-ext-nacl)# permit protocol source-address source-wildcard [operator value] destination-address destination-wildcard [operator value] IOSFirewall(config-ext-nacl)# exit

If you are using a standard access list, the local address to be translated must be permitted by the access list, as defined by source-address and wildcard-mask. With an extended access list, you can permit the translation based on a combination of source and destination parameters.

b. (Optional) Define conditions in a route map.

Create the route map named map-name with the following command:

 IOSFirewall(config)# route-map map-name permit [statement-num] 

The statement numbers within a route map are automatically defined and incremented unless you specify a statement-num here.

Next, specify the translation parameters to match using one or more of the following commands:

 IOSFirewall(config-route-map)# match ip address {acl-num | acl-name} 

or

 IOSFirewall(config-route-map)# match ip next-hop {acl-num | acl-name} 

or

 IOSFirewall(config-route-map)# match interface type mod/num 

These match statements are used to identify the local IP address, next-hop router address, or outbound interface, respectively.

Matching conditions flag the packet for address translation. These matching conditions are useful if translation is needed into address spaces from several service providers. The matching conditions should be selected so that a unique service provider address space or interface is chosen.

3.

Apply the trigger to the dynamic NAT process.

a. (Optional) Use an access list:

 IOSFirewall(config)# ip nat inside source list {acl-num | acl-name}   pool pool-name [overload] 

The access list is used to trigger dynamic NAT using the pool of global addresses named pool-name.

If you provide the overload keyword, the firewall selects an available address from the pool and begins using dynamic PAT with it. Translations receive global port numbers with the global pool address until the port numbers are exhausted. The local port number is passed through, untranslated, as the global port number, as long as that port number isn't already being used in another translation for the same local address. If the port number is in use, a different global port number is chosen dynamically.

As soon as all the port numbers have been exhausted with one pool address, the next available pool address is used.

As an alternative, you can configure dynamic PAT using a single global addressthat of the outside NAT interface:

 IOSFirewall(config)# ip nat inside source list {acl-num | acl-name}   interface type mod/num overload 

The overload keyword is used to indicate the dynamic PAT translation. If you omit that keyword, the IOS firewall automatically adds it for you. Because a single IP address is given as the global address, dynamic PAT is assumed.

b. (Optional) Use a route map:

 IOSFirewall(config)# ip nat inside source route-map map-name pool   pool-name [overload]

When a local address is matched by the route map map-name, NAT is triggered to create a translation entry using an IP address from the pool pool-name as the global address.

You can use this command more than once to bind unique addressing from multiple service providers to the appropriate address pools. In this case, different route maps are used to identify the conditions for different service providers.

If you use the overload keyword, the firewall selects an available address from the pool and begins using dynamic PAT with it. Translations receive global port numbers with the global pool address until the port numbers are exhausted. When that happens, the next available pool address is used.

As an alternative, you can configure dynamic PAT using a single global addressthat of the outside NAT interface:

 IOSFirewall(config)# ip nat inside source route-map map-name interface   type mod/num overload 

The overload keyword is used to indicate the dynamic PAT translation. If you omit the overload keyword, the IOS firewall automatically adds it for you. Because a single IP address is given as the global address, dynamic PAT is assumed.

4.

Identify an inside NAT boundary interface:

 IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip nat inside 

An inside NAT interface is one where hosts using local addresses are located. You can repeat this command sequence to identify other inside NAT interfaces.

5.

Identify an outside NAT boundary interface:

 IOSFirewall(config)# interface type mod/num IOSFirewall(config-if)# ip nat outside 

An outside NAT interface is one where hosts using global addresses are located. You can repeat this command to define multiple outside NAT interfaces if address translation is needed toward multiple networks.

6.

(Optional) Tune the dynamic translation timers.

a. (Optional) Limit the total number of translations:

 IOSFirewall(config)# ip nat translation max-entries {number | host   ip-address number | list acl-id number}

You can limit the total number of translation table entries to number (1 to 2,147,483,647). By default, an unlimited number of entries is allowed. To return to the default, repeat the command beginning with the no keyword.

You can also use the host keyword to limit the number of translation entries that can be built concurrently for the host at ip-address. Use the list keyword to reference a numbered or named access list (standard or extended); translation entries that are permitted by the ACL are limited to number concurrent translation entries each.

b. (Optional) Adjust the translation idle timeout.

The IOS firewall maintains an idle timer for each type of translation table entry. Each time a packet matching a translation entry is forwarded, the idle timer is reset. As soon as the idle timer expires, that translation table entry is removed. Table 11-1 lists the commands to configure the idle timer values based on translation table entry type.

Table 11-1. Translation Table Entries: Idle Timer Configuration Commands and Default Values

Translation Type	Command Syntax	Default Value
Dynamic NAT entries	IOSFirewall(config)# ip nat translation timeout {seconds | never}	86,400 seconds (24 hours)
ICMP entries	IOSFirewall(config)# ip nat translation icmp-timeout {seconds | never}	60 seconds (1 minute)
DNS entries	IOSFirewall(config)# ip nat translation dns-timeout {seconds | never}	60 seconds (1 minute)
Specific UDP port entries	IOSFirewall(config)# ip nat translation port-timeout udp port {seconds | never}
All other UDP entries	IOSFirewall(config)# ip nat translation timeout {seconds | never}	300 seconds (5 minutes)
TCP entries from the SYN packet to the next packet	IOSFirewall(config)# ip nat translation syn-timeout {seconds | never}	60 seconds (1 minute)
TCP after FIN or RST packet	IOSFirewall(config)# ip nat translation finrst-timeout {seconds | never}	60 seconds (1 minute)
PPTP entries	IOSFirewall(config)# ip nat translation pptp-timeout {seconds | never}	86,400 seconds (24 hours)
Specific TCP port entries	IOSFirewall(config)# ip nat translation port-timeout tcp port {seconds | never}
All other TCP entries	IOSFirewall(config)# ip nat translation tcp-timeout {seconds | never}	86,400 seconds (24 hours)

Each idle time can be given as seconds (1 to 536,870 seconds). To specify an unlimited time, use 0 or the never keyword.

TIP

After a translation table entry has been created, you can display its various time stamps by using the show ip nat translations verbose command. For example, the following output shows a fully extended translation entry for an HTTP connection after the FIN flag has been sent to close the connection. The connection was created 00:00:27 seconds ago, it was last used 00:00:25 seconds ago, and 00:00:34 seconds are left in the idle timer:

 IOSFirewall# show ip nat translations verbose Pro Inside global      Inside local       Outside local      Outside global tcp 207.246.96.46:3294 192.168.199.56:3294 64.227.225.60:80  64.227.225.60:80     create 00:00:27, use 00:00:25, left 00:00:34, Map-Id(In): 1,     flags: extended, timing-out, use_count: 0 

Dynamic Address Translation Example

For the example shown in Figure 11-5, you can configure dynamic address translation on the IOS firewall with the following commands:

 IOSFirewall(config)# ip nat pool global-NAT-pool 169.54.122.10 169.54.122.60   netmask 255.255.255.0 IOSFirewall(config)# ip access-list standard NAT-trigger1 IOSFirewall(config-std-nacl)# permit 172.16.0.0 0.0.255.255 IOSFirewall(config-std-nacl)# exit IOSFirewall(config)# ip access-list standard NAT-trigger2 IOSFirewall(config-std-nacl)# permit 172.16.0.0 0.0.255.255 IOSFirewall(config-std-nacl)# exit IOSFirewall(config)# ip nat inside source list NAT-trigger1 pool global-NAT-pool IOSFirewall(config)# ip nat inside source list NAT-trigger2 interface fastethernet   0/0 overload IOSFirewall(config)# interface fastethernet 0/0 IOSFirewall(config-if)# ip nat outside IOSFirewall(config-if)# interface fastethernet 0/1 IOSFirewall(config-if)# ip nat inside 

Notice that the dynamic NAT and PAT configurations (the ip nat inside source commands) use two different access lists to trigger the translations. If you define multiple ip nat inside source list commands, you must use unique ACLs for each. Therefore, two ACLs are defined with exactly the same configuration and are applied to a dynamic NAT and dynamic PAT process.