A common problem that network engineers encounter is ensuring that firewall policies are migrated properly when replacing an old firewall with new hardware and making associated structural changes to the network.  We recently helped a customer who was replacing an old Cisco PIX 525 and an FWSM with a new Cisco ASA 5550 firewall and combining several subnets that were previously connected to different network interfaces on the FWSM. We decided to use AthenaVerify, our network analysis product, to model the changes in the network and to identify differences in policies between the various subnets before and after the changes.

The digrams below are screenshots from AthenaVerify showing the structure of the network before the change and after the change.  In the original network, the PIX 525 has three network interfaces, connecting to a public network, a DMZ network, and an internal network.  The FWSM connects to the public network through a router and also has four additional internal subnets connected on different network interfaces.  In the migrated network, the PIX 525 and FWSM have been replaced by a single, four-port ASA 5550.

Original Network Topology

Migrated Network Topology

The migration process involved several steps.  The ASA was set up in a lab environment that replicated the structure of the migrated network.  A snapshot was taken of the configurations from the production devices.  The configuration from the PIX was used as the baseline for the ASA and then rules from the FWSM configuration were added to this baseline.  The original was modeled as a topology in AthenaVerify.  This was saved as a version and then the PIX and FWSM were deleted from the topology and replaced with the ASA to model the changes in the network.  Comparing the network policies between the different versions of the topology allowed us to easily identify policy differences.  Using AthenaVerify, we were able to quickly find the rules responsible for the policy differences and determine the appropriate corrections.  The rule changes were applied to the ASA and the updated configuration imported back into Verify.  This process was iterated until the policies converged, which happened quite quickly.

A complicating factor was that changes were being applied to the production devices during the period that the migrated configuration was being built.  This meant that corresponding changes had to be applied to the ASA as well.  The original topology had to be updated in AthenaVerify several times to reflect the changing nature of the production network.

Merging the rulesets from the PIX and FWSM onto the ASA caused some interesting problems.  We found that there were object definitions in the PIX and FWSM that had the same names but different definitions.  During the merge, the definitions from the PIX were preserved, causing policy differences in the rules that were migrated from the FWSM.  Using AthenaVerify, we were easily able to catch this problem.

We also found some allow policies in the FWSM that should not have been there; apparently there were some errors in the configuration.  This was not an issue in the original network because the connections were blocked in the PIX.  But after migration, the ASA was now allowing these connections and the policies had to be changed.  This was a good example of the difference between firewall policy and network policy.  Although the FWSM did (erroneously) allow these connections, the combination of devices in the network did not.  But, what was previously just a firewall policy became the network policy when the errors were propagated to the ASA in the migrated network.  These errors were fixed in the FWSM prior to the final migration to the ASA.

The outcome of this project was very successful.  Had this process been performed manually, it would have required extensive testing of each rule moved to the target firewall.  Finding the types of errors and conflicts that that were encountered would have been very difficult and taken a lot of time to get correct.  Using AthenaVerify made it very easy to identify the network policy differences between the original and migrated networks and to quickly determine what changes were required to preserve the network policy. A process that could have taken months to complete manually was finished in just a few days using AthenaVerify.  The customer reported being “extremely confident” that the changes had been made accurately and that the migrated policies were correct.