Understanding Network Address Translation
Address translation substitutes the real address in a packet with a mapped address that is routable on the destination network. As part of the process, the device also records the substitution in a translation database; these records are known as “xlate” entries. The appropriate xlate entry must exist to allow address translation on return packets—the substitution of the original real address for the mapped address; this procedure is sometimes referred to as “untranslation.” Thus, network address translation (NAT) actually consists of two steps: the translation of a real address into a mapped address, and the reverse translation for returning traffic.
One of the main functions of NAT is to enable private IP networks to connect to the Internet. Network address translation replaces a private IP address with a public IP address, translating the private addresses in the internal network into legal, routable addresses that can be used on the public Internet. In this way, NAT conserves public addresses; for example, NAT rules can be configured to utilize only one public address for the entire network in communications with the outside world.
Other functions of NAT include:
-
Security – Keeping internal IP addresses hidden discourages direct attacks.
-
IP routing solutions – Overlapping IP addresses are not a problem.
-
Flexibility – You can change internal IP addressing schemes without affecting the public addresses available externally. For example, for a server accessible to the Internet, you can maintain a fixed IP address for Internet use, but internally, you can change the server address.
Cisco devices support both NAT, which provides a globally unique address for each outbound host session, and Port Address Translation (PAT), which provides the same single address combined with a unique port number, for up to 64,000 simultaneous outbound or inbound host sessions. The global addresses used for NAT come from a pool of addresses specifically designated for address translation. The unique global address that is used for PAT can be either one global address, or the IP address of a given interface.
The device translates an address when an existing NAT rule matches the specific traffic. If no NAT rule matches, processing for the packet continues. The exception is when you enable NAT control. NAT control requires that packets traversing from a higher security interface (inside) to a lower security interface (outside) match a NAT rule, or processing for the packet stops.
Cisco devices can perform NAT or PAT on both inbound and outbound connections. This ability to translate inbound addresses is called “Outside NAT” because addresses on the outside, or less secure, interface are translated to a usable inside IP address. Just as when you translate outbound traffic, you may choose dynamic NAT, static NAT, dynamic PAT, or static PAT. If necessary, you can use outside NAT together with inside NAT to translate the both source and destination IP addresses of a packet.
Note |
In this document, all types of translation are generally referred to as NAT; see Types of Address Translation for descriptions of the various types. When describing NAT, the terms inside and outside represent the security relationship between any two interfaces. The higher security level is inside and the lower security level is outside. |
The release of ASA version 8.3 provides a simplified, interface-independent approach to configuring network address translation, as compared to earlier ASA versions and other devices. See About “Simplified” NAT on ASA 8.3+ Devices for more information.
Cisco IOS Routers
PIX, FWSM, and ASA security devices
-
PIX, FWSM, and pre-8.3 ASA devices
-
ASA 8.3+ devices
Related Topics
Types of Address Translation
The following table briefly describes the various types of address translation.
Static NAT |
Fixed translation of real source addresses to specific mapped addresses—each source address is always translated to the same mapped address, regardless of IP protocol and port number. |
Static PAT |
Fixed translation of real source addresses with specific TCP or UDP port numbers, to specific mapped addresses and ports. That is, each source address/port is always translated to the same mapped address/port. |
Policy Static NAT |
Fixed translation of real source addresses to specific mapped addresses. Destination networks/hosts are also specified, and the service is always IP. |
Policy Static PAT |
Fixed translation of real source addresses with specific TCP or UDP port numbers, to specific mapped addresses and ports. Destination networks/hosts and services are also specified. |
Dynamic NAT |
Dynamic translation of real source addresses to mapped addresses obtained from a pool of shared addresses. Each source address can be mapped to any available address in the pool. |
Dynamic PAT |
Translation of real source addresses to a single mapped address; singularity is provided by dynamic translation of related port numbers. That is, each real address/port combination is translated to the same mapped address, but assigned a unique port. This is sometimes referred to as “overloading.” |
Policy Dynamic NAT |
Dynamic translation of specific source-address/destination-address/service combinations on a given interface, using a pool of shared addresses. Translation direction—outbound or inbound—is also specified. |
Identity NAT |
The specified address is translated to itself—that is, it is effectively not translated; applies to outbound connections only. Identity NAT is a particular type of Static NAT. |
NAT Exempt |
Translation is bypassed for specified source/destination address combinations; connections can be initiated in both the outbound and inbound directions. |
Note |
While certain of these types do not apply to ASA 8.3 and later devices, the ASA 8.3+ devices do provide a Dynamic NAT and PAT option, which is Dynamic NAT with a Dynamic PAT back-up feature. |
About “Simplified” NAT on ASA 8.3+ Devices
The release of ASA version 8.3 provides a simplified approach to configuring network address translation (NAT), as compared to earlier ASA versions and other devices. Configuration of NAT was simplified by replacing the earlier flow-based scheme with an “original packet” to “translated packet” approach.
All NAT rules on the device—static NAT, dynamic PAT, and dynamic NAT—are presented in a single table, and essentially the same dialog box is used to configure all NAT rules. The NAT rules are interface independent (that is, interfaces are optional), meaning the rules are independent of security levels also.
NAT rules are no longer dependent on security levels. A global address space consisting of all interfaces is available, and is specified using the keyword “any.” All Interface fields default to any, so unless a specific interface is provided, the rule is applicable to all interfaces.
Network Object NAT
You also can define NAT properties on Host, Address Range, and Network objects, such that corresponding NAT rules are applied automatically to the designated security device. Using these objects means you need enter the necessary IP addresses, services, ports, and optional interfaces only once. These automatically generated, object-based rules are referred to as “Network Object NAT” rules. Note that these rules cannot be created or deleted from the rules table; you must edit the appropriate objects in the Policy Object Manager. You can, however, edit these rules from the rules table after they have been defined for the network object. For more information, see Add or Edit Network/Host Dialog Box: NAT Tab.
Note |
Network Object NAT rules are not displayed in the Translation Rules table in Policy View because these rules are device-specific. |
The NAT Table
As mentioned, all NAT rules on a device are presented in a single table, which is divided into three sections: a “manual” section, the Network Object NAT rules section, and another manual-rules section. You can add, edit and order rules in both manual sections; the Network Object NAT rules are added and ordered automatically, and as mentioned, to edit these rules you must edit the related objects.
The NAT rules in the table are applied on a top-down, first-match basis. That is, a packet is translated only when it matches a NAT rule, and as soon as a match is made, regardless of its location or section, NAT rule processing stops.
You can use this table to organize and manage the manual rules—you can insert rules in any order, and you can re-order them. The two sections of manual rules are provided to let you order manual rules both before and after the automatic object rules.
Network Object NAT rules are automatically ordered such that static rules appear before dynamic rules. These two types are each further ordered as follows:
-
Fewest number of IP addresses – Rules for objects with one IP address are listed before those for objects with two addresses, which are before those with three addresses, and so on.
-
IP address numbers – For objects having the same number of IP addresses, the rules are arranged such that the IP addresses themselves are in numerical order, from lower to higher. For example, 10.1.1.1 rules are listed before 11.1.1.1 rules.
-
Object names – If the IP address is the same, the rules are ordered by alphabetizing the object names.
And remember, translation is based on the first matching rule.
Destination Translation
With manual static rules, in addition to source address translation, you also can configure destination address translation. Source and destination translation are defined at the same time, in the same dialog box. Again, while source translation can be static or dynamic, destination translation is always static, and is only available with manual rules.
Bi-directional or Twice NAT
When creating a manual static rule, you can select the “Bi-directional” option, which will produce an entry in the rules table that actually represents two static NAT rules, encompassing both translation directions. That is, a static rule is created for the specified source/translated address pairing, along with a mirror rule for the translated address/source pairing.
For example, if Bi-directional is chosen when you create a static rule with Host1 in the Source field and Host2 in the Translated field, two lines are added to the rules table: one with Host1 being translated to Host2, and one with Host2 being translated to Host1.
This is sometimes referred to as “Twice NAT” because only one look-up is required to fetch and process what is in effect two rules.
Many-to-one Addressing
Generally, static NAT rules are configured with one-to-one address mapping. However, you can now define static NAT rules in which many IP addresses map to a few or one IP address. Functionally, many-to-few is the same as many-to-one, but because the configuration is more complicated, we recommend creating a many-to-one rule for each address as needed.
Many-to-one addressing might be useful, for example, in a situation where a range of public IP addresses is used to reach a load balancer which redirects requests to an internal network.