In this series of posts, we examine some of the challenges involved in migrating firewall configurations between different firewall platforms and discuss some strategies for approaching these issues.  The first post introduced the basic firewall configuration elements that have to be migrated and discussed some of the issues in converting routing table entries, and network and service objects.  The second post, we examined some of the issues involved in migrating ACL or filtering rules.  In this post, we will discuss the challenges of migrating network address translation (NAT) rules.

Converting Network Address Translation Rules

The basic semantics of an address translation rule involve specifying the original source, destination, and service and the corresponding translated source, translated destination, and translated service.  When an IP packet is found that matches the original elements, the firewall modifies the packet with the translated values.  In Static NAT, you specify a fixed one-to-one mapping on source, destination, and/or service.  In Dynamic NAT, you specify a mapping between multiple (typically) private or internal addresses and one or more public or external IP addresses drawn from an address pool.  A specify form of this is dynamic port address translation, where internal IP addresses are mapped to a single external IP address and a dynamically assigned port value.  Sometimes an Identity NAT (where the addresses are _not_ translated) is used to exclude certain connections from translation when their sources and/or destinations fall within the address ranges specified in more general NAT rules.

All firewall platforms support the above features; how they are implemented differ significantly from platform to platform. In most of the firewall platforms, the address translation rules are implemented separately from filtering rules. The Juniper Netscreen platform combines filtering and address translation rules, which poses it’s own set of challenges.

In Cisco firewalls until ASA 8.3, it was not possible to specify both source and destination translation in a single NAT rule. You had to specify different NAT statements, some of them bidirectional (Static NAT statements performing Source NAT from real IP to virtual IPin one direction and Destination NAT from virtual IP to real IP in the other direction) and have the device combine them into a Twice NAT rule. Moreover, the address translation syntax is quite complex with 6 to 7 variants for specifying NAT rules. Also because of the Twice NAT rule limitation, multiple NAT statements have to be combined to specify a single translation. You might combine Dynamic NAT with Static Source NAT, Static Source NAT with Static Destination NAT, NAT Exemption/Identity NAT with Static Destination NAT, etc., etc. Determining all of the possible combinations becomes very difficult as the number of NAT rules increases. In addition, it is possible that not all of the possible combinations created from the bidirectional rules are relevant and in actual use. It is necessary to examine the security rules to determine which combinations of NAT rules are actually used instead of converting all possible combinations.

With Check Point, it is possible to specify address translation on network objects on a global basis from which NAT rules are generated automatically. Rules are generated in both directions for Static NAT; doing Source NAT in one direction and Destination NAT in another direction. Check Point also combines these bidirectional rules to perform twice NAT, although these twice NAT combinations are not shown in the management console. However, Automatic NAT cannot be used to specify a Twice NAT rule to perform desired source and destination translation in a single rule. To override the Automatic NAT, Manual NAT can be used to specify Twice NAT or other rules and placed in front of Automatic NAT rules. When converting address translation to a Check Point target, it is far simpler to use Manual NAT.

In Juniper Netscreen firewalls, the address translations are specified as part of the security rules.  Address translation is specified for all rules that allow the traffic. This has the advantage of seeing the NAT information with rules that allow the traffic but if different address translation is required for different addresses, filtering rules have to be split to accommodate the different NAT specification. This also presents a significant problem when converting to the Juniper Netscreen platform from other platforms where the rules are kept separate. You have to find the overlaps between the filtering and address translation rules and then generate a combined rule. This might result in more rules on the target Netscreen firewall than are present in the source firewall in order to properly cover all of the combinations.

In the next blog post, we will examine the issue of validating the migrated policy in the target firewall.

One of the more difficult things to understand in a firewall is network address translation (NAT). There are so many varieties: NAT, PAT, twice-NAT, bidirectional NAT, dynamic NAT.  It’s difficult to keep them all straight.  You never know if a particular IP is mapped or real.  Does the IP in an ACL refer to an actual host or to the packet coming in from the Internet?

The recent release of Athena FirePAC v4.2 includes a new capability called the NAT Browser. This feature displays all of the address translations in your config in a very tabular format that makes it very easy to understand what translations are being applied to data traffic passing through your firewall.

You can find the NAT Browser in FirePAC by double-clicking on a firewall in your inventory.  This will open the Firewall Details view on the config and display the Security Rules tab.  Next to the Security Rules tab is the new NAT Browser tab.  Click on the screenshot below to see a full-size image.

The table depicts all of the address translations in the configuration in a standard format.  The Source, Destination, and Service columns indicate the original address and service values prior to the address translation being applied.  The Trns. Src. (translated source), Trns. Dst. (translated destination), and Trns. Svc. (translated service) columns indicate the address and service values after the address translation has been applied.  On the far right are shown the actual CLI commands in the configuration that apply the indicated translation. At the top of the view are fields that let you search the address translations for specified IP and port values.  You can search for either original or translated values.  Not only does this make it trivial to determine what translation will be applied to a given IP address, but you can determine the specific commands that make it so as well.

I expect you’ll find this new feature very useful in decyphering what’s going on inside your firewall.  Check it out and let me know what you think.

Although the 8.3 release of Cisco ASA contains many new firewall features, there are two significant changes that network engineers should be aware of. The first is the way NAT commands are specified; NAT configuration is now easier and flexible. This is a long overdue change and makes it significantly easier to maintain NAT policy containing hundreds of NAT rules. The second, moves the firewall engineers towards using real untranslated addresses in the filtering ACEs instead of addresses (mapped or real) as seen in the IP packets appearing at the ingress and egress interfaces of the firewall. This approach avoids the need to modify the filtering ACEs when there is a change in the mapped addresses.

For example,

static (dmz, outside) 12.12.12.12 192.168.1.12 netmask 255.255.255.255
access-list acl_outside extended permit tcp any host 12.12.12.12 eq https

is specified in ASA 8.3 as

object network corpwebsite
     host 192.168.1.12
nat (dmz, outside) static 12.12.12.12
access-list acl_outside extended permit tcp any object corpwebsite eq https

The firewall engineers are usually more familiar with the real IP addresses, handling change requests that come in to the network engineers often require figuring out the mapping from real IP address to mapped address, before investigating the ACEs using the mapped address and hence they might be more comfortable with using real IP addresses in the access-list entries.

So at the outset, this looks like a better approach; however this is a significant departure from how mapped addresses are used in filtering rules in not only prior Cisco versions but also other firewall vendors. Also this approach will not avoid changes to ACEs if the real address changes and the real address is used in the ACEs instead of an object as shown in the example above. Configurations that are being migrated to the 8.3 release should be carefully analyzed to see if the polices are migrated properly and make sure that overly broad policies or narrow policies are not created when there is a one-to-many or many to many NAT mappings of unequal sizes. Also the cumulative impact of NAT and ACL rules should be taken in account during migration; broader ACEs used with very specific NAT rules and specific ACEs used with very broad NAT rules.

Here is how the new NAT redesign makes it easier to specify the NAT commands when compared to the prior versions:

Fewer NAT commands to deal with: Engineers can use a relatively small number of commands to accomplish what they want; they do not have to learn myriad NAT syntactic variations like Regular Dynamic NAT/PAT, Regular NAT policy, NAT Exemption, Identify NAT, Static NAT/PAT, Static Policy NAT, Outside NAT, Bidirectional/Twice NAT using multiple NAT statements etc.,. In the ASA 8.3 release, engineers need to learn about only a couple of syntactic constructs: Network Object NAT and Twice NAT to specify NAT. Using Network Object NAT, engineers can specify dynamic or static NAT on an individual real IP address. Using Twice NAT, engineers can define the desired address or service translation based on any combination of matching source, destination and service in a single rule for any ingress, egress interfaces. Also engineers do not need to worry about adding explicit NAT exemption statements to allow traffic that do not need translation.

Network object dynamic and static nat

object network name
nat [(real_ifc,mapped_ifc)] dynamic
       {mapped_inline_host_ip [interface] | mapped_obj  [interface] | interface} [dns]

object network name
nat [(real_ifc,mapped_ifc)] static {mapped_inline_ip | mapped_obj | interface}
       {dns | service {tcp | udp} real_port mapped_port]

Twice NAT

nat [(real_ifc,mapped_ifc)] [line | {after-object [line]}]
    source dynamic {real_obj | any} {mapped_obj [interface] | interface}
    [destination static {mapped_obj | interface} {real_obj | any}]
    [service {mapped_dest_svc_obj real_dest_svc_obj}]
    [dns] [unidirectional] [inactive] [description desc]

nat [(real_ifc,mapped_ifc)] [line | {after-object [line]}]
    source static {real_obj | any} {mapped_obj | interface | any}
    [destination static {mapped_obj | interface} {real_obj | any}]
    [service {real_src_mapped_dest_svc_obj | any} mapped_src_real_dest_svc_obj]
    [dns] [unidirectional] [inactive] [description desc]

Control over order of NAT commands: The order in which the commands were assessed in prior versions depended on the type of NAT used, and in some cases, the order in which the commands appeared in the configuration. If the engineer wanted to add a new rule at a desired location or modify the order, it was really difficult. This has been simplified in the ASA 8.3 release. The NAT table in the 8.3 release contains 3 sections assessed in the following order: section 1 contains the twice NAT rules based on the order in which these commands appear in the configuration. It is possible to insert a new NAT command at any position using the “line” option. Section 2 contains the automatic rules generated by Cisco using a fairly simple internal order from the Network Object NAT definitions. Section 3 contains twice NAT rules that are specifically inserted after section 2 using “after-object line” twice NAT command option. This is simple when compared to the pretty complex ordering that engineers need to understand in the ASA versions 8.2 and prior.

Twice NAT in a single NAT command: In the prior versions, users have to use multiple NAT commands to perform both source and destination translation for a given IP packet. This also means that users had to be aware of any unintended bidirectional NAT rules that are formed because various NAT commands defined with in the configuration could be combined. For example, 2 static NAT statements or a static with nat/global commands could combine to perform twice NAT. The user had to be mindful of what are the possible twice NAT rules and whether those are assessed in the right order he intended. With the 8.3 release, it is now possible to specify both source and destination translation for any source, destination and service in a single rule and define any number of them in the order they want.

Besides the NAT redesign, the 8.3 release provides the following additional firewall features:

Interface independent Access policies: You can now configure access rules that are applied globally, as well as access rules that are applied to an interface. If the configuration specifies both a global access policy and interface-specific access policies, the interface-specific policies are evaluated before the global policy. This is somewhat similar to the Global policies available in the Juniper NetScreen firewall.

Basic Network and Service Objects: You can now create named network objects that you can use in place of a host, a subnet, or a range of IP addresses in your configuration and named service objects that you can use in place of a protocol and port in your configuration. You can then change the object definition in one place, without having to change any other part of your configuration. This avoids the need to use the object-group even for simple network or service objects and brings this feature in line with other firewall vendors like Check Point and Juniper NetScreen.

To summarize, ASA release 8.3 provides simplified and flexible NAT specification making it easy to maintain large NAT configurations.  Although this requires a learning curve at the beginning and requires some adjusting, managing NAT rules will be much easier. For customers using Cisco infrastructure, ASA 8.3 release provides significant benefits when deploying brand new firewalls. However, the requirement to use real IP addresses in the access list statements is a significant architecture change and would complicate the migration effort when attempting to migrate NAT configurations from prior versions. The migration of NAT configurations should be performed with close attention to the gaps created by the Cisco ASA 8.3 migration tool.

Athena FirePAC from Athena Security offers a migration tool that performs offline policy analysis for understanding the interactions between ACL, NAT and routing rules.  It is extremely useful when performing migrations between firewall versions or across vendor platforms.  Despite the availability of vendor provided conversion tools, the most critical step in the process is validating that the policies were migrated correctly.  Identifying where gaps were introduced so that they can be fixed is the primary benefit of Athena’s migration solution and it has proven to cut down the manual effort by at least 85%.  To learn more, read about Athena’s Migration Tool.