, , , ,

You might have heard about a dramatic redesign of Network Address Translation on the Cisco Adaptive Security Appliance (ASA). I thought I would take a moment here on my beloved Cisco Learning Network and provide readers with an overview of the new changes. Once you have an overview, you can dig deeper on your own. Should you get stuck – the CCNP Security or CCIE Security discussions can provide an excellent place for you to get your detailed questions answered immediately.

Network Objects

The implementation of NAT on an ASA running software version 8.3 or later is done through the use of network objects. A network object is different from an object group, as it defines a single IP address, range of addresses, network, or a Fully Qualified Domain Name (FQDN).

The host, range, or subnet that is defined by a network object is used to identify the real, non-translated, IP address in a NAT configuration.  A network object can also be used to define any available translation addresses.  You then refer to these objects in the NAT configuration

NAT Control

Another significant change in NAT with software versions 8.3 and higher is that NAT control is no longer a supported option! If a connection finds no translation rules, it passes through the ASA without translation, as long as the connection is allowed by configured access rules and policies (including default behaviors).

Integrating NAT with Other ASA Functions

Perhaps the most significant change is that when access control lists (ACLs), modular policy framework (MPF), AAA, Botnet traffic filters, and Web Cache Communications Protocol (WCCP) filters are applied to interfaces, they no longer need to refer to the translated addresses from NAT rules.  All rules now refer to the network object by its native IP address or assigned identifier.  Because a single host could have numerous translated addresses, depending on how many interfaces it communicated with, this radically reduces the complexity of configuration.

NAT “Direction”

The security levels of interfaces no longer matter in the configuration of NAT rules.  For example, there is no longer a concept of “Outside NAT” versus “Inside NAT.”  All NAT rules are configured the same way, regardless of whether the source is on a higher-security or lower-security interface than the destination.

NAT Rule Priority

Because NAT rules are now configured in an object-oriented manner, rather than all being configured globally, the NAT rule priority scheme for versions 8.2 and earlier no longer applies.  Versions 8.3 and higher now have a different structure for determining which NAT rule is applied to an address (or addresses) in a packet.

New NAT Options in OS Versions 8.3 and Higher

There is now an “any” option that can be used when defining ingress and egress interfaces in the NAT configuration.  This enables the creation of single-line translation rules that will apply to all interfaces, rather than one or more lines of configuration for each interface where a host required translation. This obviously results in more compact and user-friendly configuration.

You can configure translations as part of network object definitions, which are added to the configuration.  This is known as “Auto NAT”. Auto NAT reduces configuration complexity when only one translation policy is required for a host.

You can configure a single NAT rule that will translate both the source and destination addresses in a packet.  This is known as manual NAT or “twice NAT” because NAT can be performed twice, once on the source IP, and once on the destination IP.  While all manual NAT rules are thus twice NAT rules, the term “twice NAT” is more commonly used only if translations are actually occurring to both source and destination addresses.

Starting in OS version 8.3, it is now possible to configure a static translation for many-to-one translation (PAT).

You can group translation network objects (i.e. address pools) into an object group and use that object group in creating translation rules.

NAT rules can be defined as unidirectional, meaning only traffic sourced from a defined object can use the translation.  Connections toward the object must match a different NAT rule, or will not be translated.

Please do let me know any more information required on this. Thanks.


If you feel this article helped you to get some learning, please support by clicking below.