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.

Tags: Check Point, cisco, firewall configuration migration, Juniper Netscreen, NAT, Network Address Translation

This entry was posted on Monday, October 3rd, 2011 at 3:19 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.