“nat-control” versus “no nat-control”

ASA and PIX software version 7.0 introduced the configuration command nat-control which didn’t exist in previous versions of code. Although training course material for both the SNAF (Securing Networks with ASA Fundamentals) and SNAA (Securing Networks with ASA Advanced) assume that their audience will use this global configuration command, it should not be considered a “catch all” for all implementations.

The scenario depicted below is a crude approximation of what I encountered at a client location within the past 18 months. The objective of the consultation was to convert the site from using a PIX Firewall 506E (restricted to OS6.3 code) to using an ASA with version 7.x. Since the default behavior of PIX OS Code up to and including version 6.3 was effectively to enforce the use of configured nat, global and/or static config commands (essentially what nat-control does), the migration was most easily accomplished by moving the configuration over from the PIX to the ASA with a minimum of changes.

In hindsight (always 20-20 for consulting!) with the number of internal private networks and the distinct policies for connectivity between them, a simpler solution would probably have been to implement “no nat-control”. This solution would have the following advantages over using the one chosen:

1. Elimination of the numerous static (intf1,intf2) A.B.C.D A.B.C.D statements in the config made necessary by nat-control. These would need to be configured for ALL possible internal interface-to-interface combinations.


2. Troubleshooting such an implementation would be simpler, as using the security levels of the interfaces and access-lists would be all that would be required (vs needing the translation statements as well).


3. If full unrestricted access would be required, version 7.0 and above code supports the “same-security-traffic permit inter-interface” command which corresponds to a checkbox in ASDM entitled “Enable traffic between two or more interfaces with the same security level”. This could be enabled and at least two of the internal networks could be assigned the same security level thus eliminating the need for any ACLs.

Now that we have mentioned the advantages, to be fair we should list some of the caveats:

1. By using “no nat-control” the potential danger exists of having your private networks “leak” out to the Internet untranslated. Although your ISP (and others, hopefully!) won’t be able route back to these networks, it provides unnecessary visibility of the actual identity of your internal networks.


2. A recommended “fix” for the above problem would be not only to explicitly configure translation rules for ALL of the internal networks allowed access to the Internet but also to configure outbound access lists denying any private IP addresses exiting the outside interface.

Author: Doug McKillip

References
Configuring NAT Control