Meet the New NAT on the ASA (8.3 or Higher)
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.
Also, a quick word of advise if I may...don't be a hater! What I mean by this is that you might have heard that Cisco has made a tremendous mistake in making these changes, and that the new approach is difficult or makes no sense. Well, if you need to learn about this new approach for your CCNP Security Certification, concentrating on those emotions is going to do NOTHING to help motivate you to study and comprehend the material.
So as I climb down off of my soap box, what are the changes with this “new” Network Address Translation? Well, I was first introduced to them by my co-authors of the CCNP Security FIREWALL 642-618 Official Cert Guide. Here is the overview:
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.
****************************************
The above information is edited by 10GTEK.
10GTEK TRANSCEIVERS CO., LTD (Hereinafter refered to as 10GTEK) is specialized in developing and manufacturing Fiber Optical Transceivers and High Performance Cables which are wildly applied in Datacom, Telecom and CATV, providing customers with top quality and cost effective products. Our High Speed Cables cover Passive SFP+ Cable, Active SFP+ Cable, QSFP+ cables, MiniSAS (SFF-8088) Cables, CX4 Cables, Harness cables, Breakout Cables, Patchcords. We also manufacture Fiber Optic Transceivers like 10G XFP, 10G SFP+, SFP DWDM/ CWDM, GBIC, etc. The prompt response and excellent customer support contribute to clients‘ full satisfaction.Today, 10GTEK has been growing fast in the optical field for its unique and competitve excellence which has got a high attention from datacom and telecom.
This article reader also like:Cisco Live 2012 Recap :: San Diego, CA
