NAT Configuration on ASA 8.4+, Part 1

NetCraftsmen®

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

ASA 8.4 Meme

 

 

 

 

 

 

 

3 responses to “NAT Configuration on ASA 8.4+, Part 1

  1. Very good intro to the series, Nic. I have to say that if you speak to Cisco TAC, they recommend using auto-NAT (network object NAT) whenever possible and use manual NAT only when necessary. I see manual NAT useful for situations when you want to do Identity NAT (No NAT) or policy NAT where a you want to specify a specific source to a specific destination.

    Looking forward to the rest of your series.

  2. Thank you Keith. I have never opened an ASA NAT case with the TAC so I unfortunately cannot speak to their preference or their reasoning for that advice.

    The reason I consider Manual NAT to be a tad easier than Auto NAT is actually covered in the very next post in the series. Not going into too many details, I personally abhor the fact that Auto NAT keeps the two pieces of the configuration (source network and NAT rule) in entirely different parts of the running configuration. That makes the verification of Auto NAT via running configuration much harder/tedious than the verification of Manual NAT. Of course this is very subjective and another person may prefer the exact opposite. Note:- This is not even an issue if “show nat” is being used for verification.

    When it comes to functionality though, as you can see throughout the first post, as long as your logic is sound, it does not matter which section the statements go under. Following this maxim in production has never led me to any misconfigurations.

    Thanks for taking the time to read and I hope you keep reading further articles in the series.

  3. Nic,

    Thanks for the reply. I believe the TAC sentiment comes from the fact that the Auto NAT section is sorted automatically based on static vs dynamic, smaller subnets vs larger subnets, etc, but I could be wrong.

    I definitely agree with you about the Auto NAT rules being separated from their normal object configuration. It doesn’t make troubleshooting impossible, but it definitely adds time to the process.

    You’re very welcome and thanks for writing this. I’ll be keeping track! 🙂

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.