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.

When something goes wrong in a firewall, finding the problem can be difficult.  Manual review of a configuration or analyzing traffic flow is tedious, frustrating, and error-prone.  In particular, NAT rules can trip the unwary, as evidenced by the frequent posts on NAT problems in the Cisco Users forum. For Cisco users NAT can be specified in a multiplicity of ways, and the Cisco documentation is not always a model of clarity. Due to the complexity of the configuration or the complex interplay of NAT rules, not being able to clearly understand the effect of NAT on packet flow can result in unanticipated access or denial of legitimate access to the network.

Let’s take a look at a real-life example of NAT confusion that we found in the Cisco support forums.  Although it is a simple example in terms of NAT semantics, the user found its analysis difficult and confusing enough to post it.  In his example, the author has a simple three-port PIX firewall, with the inside interface bound to 10.1.10.2 and the DMZ interface bound to 192.168.1.2.  He wanted all packets from inside going to the DMZ to be NAT’ed to 192.168.1.254.  So a global NAT rule was inserted.  Below is a fragment of the ACL rules the configuration that frames the discussion.  The complete configuration can be viewed here.

access-list dmz permit tcp host 192.168.1.1 host 10.1.10.1
access-list dmz permit udp host 192.168.1.1 host 10.1.10.1
access-list dmz permit tcp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list dmz permit udp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp

Here are the NAT rules of interest.

global (dmz) 1 192.168.1.254
nat (inside) 0 access-list NO_NAT
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0

By examining the traffic flow data, the poster found that in fact no packets were being source-NAT’ed to 192.168.1.254.  The question is: why?

Using the Configuration Debugger tool in Athena FirePAC, it becomes very easy to determine the answer.  The Debug tool allows you to trace the flow of sets of packets through a firewall and determine precisely the ACL rules, NAT rules, and routes acting on each packet.   We’ll issue a debug query using the following parameters:

src=10.1.10.0/24, dst=192.168.1.0/24, svc=TCP

The Debug query result shows us that only two ACLs and the implied deny are involved in filtering these packets.  Here are the two ACL rules:

46 access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp
47 access-list inside permit tcp any any object-group web_svcs

The completed set of permitted packets that match these rules are identified by the Debug tool and shown in the following table.

As identified in this table, the NAT rules that apply here are shown below.

45: access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
64: nat (inside) 0 access-list NO_NAT
66 static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0 0 0

The Debug tool identifies the effect of these NAT rules, as shown in the following table.

Through this result, we see that any packets coming from the 10.1.10.0/24 network are being source NAT’ed to have the same source addresses as the original, although it happens because of different rules.  We also see that the NAT/global rule added to transform the source addresses of the packets originating from the inside interface do not have any effect because of the precedence in which the different types of NAT rules are applied in the Cisco PIX firewall.

The fix is relatively straight-forward.  The static rule at line 66 should be removed.  Once gone, the NAT/global rule will have the proper effect and all packets originating from the 10.1.10.0/24 network will be properly source NAT’ed, with the exception of packets with a source of 10.1.10.1, which will not be NAT’ed because of the NAT exemption rule at line 64.

As we have seen, the FirePAC Configuration Debugger is a very powerful tool for figuring out what’s going on inside a firewall configuration. It will identify the exact packets that are allowed for entire ranges of source and destination addresses and services and it will identify the specific rules that act upon each packet. The analysis is performed completely offline and does not require any data to be put on the network.  The solution is available now for all Cisco Security Appliances, Juniper Netscreen firewalls, and Check Point FW-1.