Play with the

Show nat detail

Show xlate

show running nat

show running object in-line | in x.y.z.c

show nat interface intname detail

An example of the Unified NAT Table on Cisco ASA

On our series of articles about ASA NAT, we mentioned that version 8.3 introduced a
complete new model for address translation. The main characteristics associated with this
new philosophy are summarized in the following:

 NAT is not mandatory anymore (as opposed to the nat-control model).

 NAT table is organized in 03 distinct sections: one for auto-NAT and two for manual
NAT (or twice NAT).

 Translation rules that involve source and destination simultaneously are now
defined in a single nat statement (using a manual NAT rule). These are the cases of
Dual NAT and all the variants of Policy NAT.

 Starting on version 8.3, the Access Control Entries (ACEs) refer to the Real IP
Address of the host and not to the translated address.

The figure brings a practical example of an ASA Unified NAT Table that contains rules in
each of the three sections. Remember that:

 Object NAT Rules are inserted into section 2

 By default, manual NAT rules are created within section 1. If you want to insert a nat
statement into section 3 you will need to use the after-auto parameter.

 The sections in the NAT table are processed in order.

Dealing with Identity NAT on ASA: pre and post 8.3
configuration models
Continuing our series of articles about Network Address Translation (NAT) on Cisco ASA,
we will now examine the behavior of Identity NAT.

When the nat-control model is in place (for ASA releases older than 8.3), an explicit answer
regarding NAT must be provided to the ASA algorithm, even if this answer is do not translate
( “no nat“). Among the NAT exemption techniques supported by ASA, there is one called
Identity NAT, which is typically used when most of the addresses are being translated and you
need to avoid translation for just a specific set of hosts.

Starting on 8.3 version, there is no such concept of nat-control, meaning that NAT
Exemption is not necessary anymore and the nat 0 (nat zero) configurations are completely
banned.

The reference topology shown in the figure was conceived to illustrate NAT
Exemption syntaxes for both the current and old (pre 8.3) models. In our environment, hosts
belonging to the 10.10.10.128/26 subnet are excluded from translation rules, irrespectively of
the destination being accessed. Although the intention here is to keep some source addresses
from being translated, the behaviors of the configurations are slightly different:

 The nat zero construction that refers directly to the IP address (instead of an ACL) is
unidirectional in essence and is not suited for address publishing. This means that the
10.10.10.128/26 stations will be able to start outbound connections but will not be
accessible from the out interface (even if you configure a permission within an ACL).

 Identity Static (static from X to X) is bidirectional and, as such, may be used for
address publishing. (You will still need to add a permission so that the real address
can be reached from the out interface).
  The NAT flags are distinct: both options have the identity flag set but nat zero is
deemed dynamic. (And that reinforces its unidirectional nature).

Migrating to ASA 8.3, 8.4 or higher ? Don’t rely blindly on

the automatic NAT migration script
As explained in a series of previous posts, it is indispensable to understand the NAT
philosophy change introduced by ASA 8.3 in order to profit from the new features (available
in 8.3 and higher). While the other articles focused on explaining the correspondence between
the pre and post 8.3 models, the current one will demonstrate the automatic migration script
in action when you upgrade ASA software on a 8.2 box that already contains NAT rules.

The Static Policy NAT and Static NAT configurations for the reference topology of Figure 1
are described below:

 The dmz client 10.10.10.150 is mapped to 172.18.18.150 when the destination is

172.16.16.200.

 For other out destinations, the same dmz client is statically translated to
172.16.16.150.
If you carefully look at the figure, you will notice that the IP addresses used in the ACL and
static rules of the 8.2-style configuration are converted to network objects, which are later
employed within the nat statements that characterize 8.3.

Although the migration script may be helpful for simple topologies that contains few
categories of NAT, it is really critical that you understand how to manually convert from the
original model to the new one. There are situations, such as those registered in Figure 2, in
which the script may not work. So do not rely blindly on it. I think it is really advisable to
invest some time on getting familiar with building the manual correspondence.
** Notes:

 If you plan to use the automatic migration script, it is really recommended that you
remove the nat-control command from your pre-8.3 configuration. This will avoid
the creation of many network objects during the conversion process.

 From 7.0 to 8.2 the default ASA operation mode is to consider NAT an optional
feature. This is accomplished with the no nat-control command, which is not
displayed in the show running-config listing. If you want to make sure that no nat-
control is in place, issue the show running-config all nat-control command.

Handling dual NAT on ASA: concurrent translation of

source and destination addresses
[ “What is actual is actual only for one time. And only for one place.” – T. S. Elliot ]

As a follow on to our analysis of ASA NAT, the current post examines another important use
case scenario: how to simultaneously translate source and destination addresses on a certain
connection through your firewall ? As usual, both the pre-8.3 and post-8.3 configurations are
covered so that you can use them to help on your migration tasks (in case your are still using
8.2 or earlier releases).

One remarkable difference between the old and new syntaxes resides in the fact that from 8.3
on you just need a single nat statement to produce the dual NAT effect. This is an
improvement with reference to the classic model, which required two rules (for instance two
static commands) to achieve the same result.

Some other key advantages of the model introduced by ASA 8.3 are listed below:
  When using manual NAT, the use of the sequence number (SEQ#) parameter
enables the precise control of the order in which translation rules are inserted in the
Unified NAT Table. This renders NAT processing much more predictable than the
original implementation.

 The capability of specifying source and destination mappings at once, makes

ASA NAT logic more similar to other vendors’, thus facilitating migration from
competitive offerings.

** Notes:

 It is very important that you get familiar with the order in which the real and mapped
addresses are defined in the nat and static commands.

 Remember that starting on 8.3, ASA ACLs refer to the real IP of the destination host
(as opposed to 8.2 and older versions, which use the translated IP).

 The ability to use global ACLs, introduced by version 8.3, is another factor that
may decrease the efforts when migrating from other vendors’ firewalls to ASA.

 If you need a detailed coverage of the NAT precedence rules (very important on pre-
8.3), please refer to Chapter 08 of the Cisco Firewalls title on the Cisco Press security
collection. For information about 8.3 NAT, consult the Appendix, NAT and ACL
changes in ASA 8.3, of the same book.

Configuring Dynamic Policy PAT on ASA: current and

legacy models
This post builds upon the previous discussions on the ASA NAT series to exemplify yet
another category of address translation: Dynamic Policy PAT. In this type of scenario, a set
of source addresses get mapped into a single global address when they need to reach specific
destinations.

In our reference topology, those dmz stations belonging to the 10.10.10.128/27 subnet are
port address translated to 172.16.16.125/32 when the destination is the out host
172.16.16.200. For different out hosts, the source IPs are not translated. Some important
points to highlight:

 It is important to observe that we are not translating the destination address. We are
just using the destination criteria to influence translation of the source addresses.

 In the pre-8.3 CLI the number “1” is the NAT_ID, which creates the
relationship between the nat and global commands.

 The original syntax (pre-8.3) employs an Access Control List (ACL) in conjunction
with the nat command to insert the destination-based rule.

 In the new model introduced by release 8.3, we use manual NAT to create any rules
that concurrently involve source and destination. This is the case for Policy NAT,
Policy PAT and Dual NAT. Unless you use the after-auto argument in the nat
command, manual translations are inserted in Section 1 of the Unified NAT Table.

** Notes:

 As in the basic PAT case (which does not take destination addresses into
account), ASA combines the global address (172. 16.16.125 in this case) with a
source port to correctly identify each internal host and deliver the return packets
accordingly.
  Manual NAT allows you to add a sequence number to each manual nat statement, so
that you can directly control the order of processing of the translation rules
(irrespectively of the NAT category in place). This is a major difference when
comparing to releases up to 8.2, for which you needed to know the intrinsic NAT
precedence rules.

Dynamic NAT on ASA: before and after release 8.3

[“All appeared new, and strange at first, inexpressibly rare and delightful and beautiful. I
was a little stranger, which at my entrance into the world was saluted and surrounded with
innumerable joys.” – Thomas Traherne]

After reading the article “NAT Evolution within Cisco ASA software” and applying that
knowledge to build static translations on ASA, it is now time to implement dynamic rules. As
we did before, to make life easier on migration tasks, the two configuration modes (pre and
post-8.3) are presented.

The figure below brings not only the old-style syntax but also the new options for a simple
topology, in which the internal addresses belonging to the 10.10.10.128/25 subnet are
translated to the range 172.16.16.129-172.16.16.254. In this arrangement, some facts deserve
special mention:

 In the legacy CLI the number “2” is the NAT_ID, which is used to establish the link
between the nat and global commands.

 For source-only translations, the nat statement (configured under the network object
definition) automatically places the rule in Section 2 of the Unified NAT Table.

 Given that manual NAT allows the creation of rules that simultaneously specify
translation of source and destination addresses, manual NAT can be “simplified”
to create source-only (or destination-only) rules. In this case the rule will be part of
Section 1 and there will be no reference to network object. Considering that the
sections in the NAT table are sequentially processed, the equivalent construction with
manual NAT takes precedence over Object NAT. (The exception is when you employ
the after-auto parameter in the nat command, thus sending the manual rule to Section
3).
Where’s my Static ? A basic example of the NAT model
introduced in Cisco ASA 8.3
[“Most of the change we think we see in life is due to truths being in and out of favour“. –
Robert Frost]

Yes… we know that. Adapting to change is frequently a challenge. If you invested time and
effort to learn a certain way of getting stuff to work, it is not that easy to accept newer forms
of accomplishing something similar (at least when you first see it).

Despite the reasons presented to justify the new Network Address Translation (NAT) model
introduced by version 8.3 of the ASA software, many people will think (and say): “just bring
back my static !” I understand that particular perspective but the key fact to be aware of is
that getting familiar with the new philosophy is vital to enable your organization to migrate to
8.3 and beyond (and profit from the most recent feature developments…)

While the previous article, “NAT Evolution within Cisco ASA software“, covered the main
differences between the three generations of the NAT functionality for ASA, the current post
has a simpler objective: to present a basic example of Static NAT, with the two possibles
syntaxes (pre and post-8.3). The topology and related commands to illustrate that are
summarized in the figure below.
 If you look carefully at
the output of show nat command, you will be able to notice that the translation just
configured generated a rule at Section 2 of the Unified NAT Table (an instance of the so called
Auto NAT or Object NAT). Some relevant comments about this type of arrangement follow:

 The real address is part of a network object definition. This object can be
later employed in other sections of the configuration, such as in an Access Control
Entry (ACE) or under an object-group definition.

 The mapped address is created by using a nat statement as a parameter of the network
object (previously used for the real address).

 A given Object NAT rule can be employed to translate either the source or the
destination address of a packet but not both at the same time. If you need to deal with
more complex requirements (Policy NAT or Dual NAT, for instance), Twice NAT will
be the adequate choice.

It is really advisable that you compare the old and modern ways of defining static NAT. It is
also a good idea to start planning the conversion of the configurations in your specific
environment. Future posts will illustrate more situations (dynamic PAT, Policy NAT and dual
NAT are planned topics). Stay tuned !

NAT Evolution within Cisco ASA Software

[ “There is nothing permanent except change” – Heraclitus ]

Given that Network Address Translation (NAT) is a baseline functionality on most firewall
implementations, it is really critical to understand NAT behavior (on your particular release)
before you start configuring access control rules. To help you in this task, the current post
briefly reviews how the NAT philosophy has changed through the history of Cisco Adaptive
Security Algorithm (ASA) software.
 1. Before release 7.0 (PIX product line) the only available option was the “nat-control”
model. When this model is in place, you are supposed to provide an explicit answer
regarding the use of NAT (even when you do not want the firewall to perform address
translation).

2. From 7.0 to 8.2, the default operation mode is no nat-control, meaning that NAT is
not mandatory anymore. If the intention is to restore the pre-7.0 behavior, you can
still issue the nat-control command.

3. Starting on ASA 8.3 release the NAT model was completely redesigned. The most
significant changes are listed below:

 There is no concept of nat-control anymore. NAT is simply an optional feature.

 8.3 and newer releases employ a brand new NAT syntax.

 NAT table is now divided in 03 sections, thus allowing a better control of NAT
precedence rules. These 03 sections (and their main characteristics) are illustrated in
the figure.

 Dual NAT rules (those that translate both source and destination simultaneously) are
now defined as a single statement.

 When NAT is in place, Access Control Entries (ACEs) refer to the Real Address (as
opposed to previous models which considered the translated address). This is a very
important difference to be aware of before you migrate to 8.3 and beyond.

It is important
to emphasize that if you are using a pre-8.3 ASA release, and need new features that were
added on 8.3 (or later), you will need to understand the newest NAT model (and convert the
rules accordingly). On the other hand, if you have a brand new appliance, it is advisable to
start with 8.3 (or 8.4) so that you avoid migrating NAT rules later…

More posts on this topic, presenting practical configuration (and conversion) examples, will
come soon. Stay tuned !

Twice NAT Example:

C i s c o A S A - Tw i c e N AT

Twice NAT allows you to NAT both the source and destination within a single rule.

Syntax:

nat (real_ifc, mapped_ifc) source static REAL-SRC MAPPED-SRC destination static REAL-DST MAPPED-DST

Scenario

A scenario where this type of configuration would be required is shown below. To ensure that any traffic originating from the
Internet isn't sent back out to its default gateway (asymmetrically routed) the source IP is translated to an IP within the range
of the inside segment (192.168.100.0/24). In turn ensuring the return traffic is sent back via the Cisco ASA.

EXAMPLE

Within this example we will perform both Static PAT along with Dynamic PAT to ensure that traffic to our SMTP
(192.168.100.200) server is not asymmetrically routed.
Here are some more details:

Static PAT - A static NAT is configured for the real server 192.168.100.200 to a translated address of 33.33.33.33 on port
TCP/25 (SMTP).

Dynamic PAT - A dynamic PAT is configured which translates all traffic coming in from the outside interface to the source IP
address of 192.168.100.100.

S Y N TA X

Below shows the required syntax:-

object network SERVER-33.33.33.33

host 33.33.33.33
object network SERVER-192.168.100.200
host 192.168.100.200
object service SMTP-SERVICE
service tcp destination eq 25
object network PAT-ADDRESS-100
host 192.168.100.100

nat (outside,inside) 1 source dynamic any PAT-ADDRESS-100 destination static SERVER-33.33.33.33 SERVER-
192.168.100.200 service SMTP-SERVICE SMTP-SERVICE