Tag Archives: NAT

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.

An example of the ASA Unified NAT Table

** Topics for Study:

** Related Posts:

Advertisements

1 Comment

Filed under English, Firewalls, Security

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

Identity NAT on ASA: configuration models

** Notes:

  • Considering that we are dealing with a source-only translation rule, we employed Object NAT for the 8.3 case. By revisiting the previous posts on the NAT series, can you build an equivalent configuration with Manual NAT ?
  • The show commands registered in the figure help characterize that NAT exemption is in place. Can you explain that ?

** Related Posts

2 Comments

Filed under English, Firewalls, Security

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.

Figure 1: ASA NAT - Migration Example 1

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.

Figure 2: Sample messages from the NAT automatic migration script

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

** Related Posts:

5 Comments

Filed under English, Firewalls, Security

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.

Handling dual NAT on ASA: before and after 8.3

** Topics for Study:

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

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

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.

Dynamic Policy PAT on ASA

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

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

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

Dynamic NAT on Cisco ASA

** Topics for Study:

** Related Posts:

Leave a comment

Filed under English, Firewalls, Security

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.

Implementing Static NAT on ASA: pre and post 8.3

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 !

** Topics for Study:

** Related Posts:

2 Comments

Filed under English, Firewalls, Security