NAT Configuration on ASA 8.4+, Part 1

Series: NAT Configuration on ASA 8.4+

1. Part 1: Introduction and NAT Rule Organization
2. Part 2: CLI Configuration and Dynamic PAT
3. Part 3: Dynamic PAT Cont. with Pools, Flat, Round-Robin and Extended PAT
4. Part 4: Dynamic PAT With and Without Fallback

Note: This post was edited by Marilyn Outerbridge

At the initial rollout of ASA 8.3/8.4, one of the first things network engineers noticed was that the NAT configuration on the new code had changed drastically. The main concern was how one would upgrade ASA devices from a pre-8.3/8.4 code to a newer code. What would be the side effects of the upgrade; and most importantly, what functionality may “break” as a result?

Fast forward to 2015, ASA 8.2 upgrades to 8.4+ code should (hopefully) be less of a concern for engineers than deploying new firewalls with the current ASA code (8.4+). This series of blog posts will be a little different than most others on ASA 8.4 NAT. It will not look at the past or provide a way to migrate from older versions of ASA. The pertinent information is probably still here but the idea is to discuss the ASA 8.4+ NAT (hereafter called ASA NAT or just NAT) as independently as possible. As always, some comparisons will be too tempting to pass over.

With the introduction out of the way, it is time to take a look at NAT operations and the configuration of NAT on the ASA.

NAT Sections

The order of how an incoming or outgoing packet is matched against the NAT statements or rules is of utmost importance. To maintain order and determinism, ASA allots each configured NAT rule into one of the three sections:

• Section 1 – Manual NAT
  • Also called Twice NAT
• Section 2 – Auto NAT
  • Also called Network Object NAT
  • Hereafter NON in the blog post
• Section 3 – Manual NAT
  • Also called Manual NAT After Auto NAT
  • Also called Twice NAT After Auto NAT

Though this may look confusing at the outset, it is actually quite straightforward, providing the user much granularity when it comes to NAT configuration.

Essentially, any ingress packet is compared against the NAT rules configured on the firewall. The sections are extremely important because they determine the overarching order in which the packet will be matched against the configured rules.

The packet is first matched against each and every rule in Section 1. If it does not match any of the rules, it is then matched against each rule in Section 2. If there is still no match, the packet is further compared to each of the rules in Section 3. If a match again is not made, the packet is sent through without any NAT operations performed on it. Since the concept of nat-control is now archaic, it is in fact possible for the packet to pass through the ASA untouched by NAT rules.

Finally, there is an order to the statements or rules within the sections. The order of policies within each section is determined differently depending on which section the NAT statement is configured in. Ergo, it becomes important to understand the ordering of the rules inside the three sections.

Section 1

The rules in Section 1 have a line number associated with them. Just like an ASA ACL, a new rule configured with the same line number of a current rule will take that position and push (increment) every rule below that position by one number. Hence a rule inserted at position 3 will reorder the previous rules numbered 3, 4 and 5 to 4, 5 and 6.

Section 2

The concept of line numbers does not exist in Section 2 (Auto NAT or Network Object NAT section). The rules in this section are arranged automatically according to their type.

A static NAT rule is always preferred over a dynamic NAT rule. Thus, all the static NAT rules are encountered before all dynamic NAT rules.

Next comes the organization within these static and dynamic “subsections.”

One has to keep in mind that this section only contains source IP NAT rules. The ASA is therefore able to utilize the size of the configured real IP blocks to further order the rules. Blocks containing fewer numbers of real IPs float to the top of each sub-section (static and dynamic) followed by ever increasing block sizes.

As an example, a static NAT rule that translates the 192.168.13.0/26 will appear before a static NAT rule that translates the 192.168.13.0/24 block to an IP. This same example can be used for dynamic NAT rules.

Not that it matters, but blocks with identical sizes are arranged from lowest to highest numerically. Hence, 192.168.1.0/24 is placed before 192.168.2.0/24

Section 3

This section is identical to Section 1 in every way except for the fact that it has a lower preference than Section 2. As in Section 1, there is a line number associated with each rule in this section. The user can configure the line number for each rule in the CLI to create an ordered list of NAT statements the packet is matched against.

The Right Section for a NAT Statement

This decision is probably the most important decision of an ASA NAT administrator. And this is the one aspect where ASA 8.4+ code provides far greater granularity than the pre-8.3 code. In the 8.4+ code, any NAT statement can be inserted virtually anywhere in the hierarchy and one can literally micro-manage the NAT order of operations. The only restriction that the ASA seems to put on the configuration is the following:

The Policy NAT feature of ASA pre-8.3 can only be mimicked correctly in Section 1 or Section 3, i.e. only via Twice or Manual NAT

Most other types of NAT can be implemented either via Twice NAT or Network Object NAT although Twice NAT is the easier of the two for nearly all but one scenario (almost all of these scenarios will be covered by future blogs post in this series). Thus, the decision of where to place the NAT statement is left to the ASA NAT administrator. It is more an exercise in logic than anything else. The current NAT policies already configured on the ASA must be carefully examined to determine where to place the new NAT statement. This can be done by comparing the interesting traffic against all the existing rules. This part requires expertise and a deep understanding of NAT but not necessarily of the intricacies of the internal order of operations that was crucial to NAT configuration on pre-8.3 code.

Although further blogs in this series will go through various NAT scenarios, to close out the first blog post of the series, here is a look at what a fully configured ASA, with rules in every single NAT section would look like:

ASA1(config)# show nat detail
Manual NAT Policies (Section 1)
1 (inside) to (outside) source dynamic obj_192.168.13.0 interface
  translate_hits = 0, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.23.3/24
2 (inside) to (dmz1) source dynamic obj_192.168.13.0 interface
  translate_hits = 0, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.34.3/24

Auto NAT Policies (Section 2)
1 (inside) to (dmz1) source dynamic obj_192.168.13.0_dmz1 interface
  translate_hits = 1, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.34.3/24
2 (inside) to (outside) source dynamic obj_192.168.13.0_outside interface
  translate_hits = 3, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.23.3/24

Manual NAT Policies (Section 3)
1 (inside) to (outside) source dynamic obj_192.168.13.0 interface
  translate_hits = 0, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.23.3/24
2 (inside) to (dmz1) source dynamic obj_192.168.13.0 interface
  translate_hits = 0, untranslate_hits = 0
  Source - Origin: 192.168.13.0/24, Translated: 192.168.34.3/24