Migration Considerations - Cisco ASA and Security Zones

L1 Bithead

When doing firewall migrations, it's important to take into account the fundamental technology differences between platforms.

Security Zones

Best practice dictates that it's prudent to make as few changes as possible during migrations- the more changes you make the more risk is introduced.  However, not everything can be directly converted from one technology platform to another without making some modifications.  For instance, Palo Alto Networks uses security zones but Cisco does not.  Security zones are a core part of Palo Alto Networks security architecture and understanding how Migration Tool 3 applies zones will help to ensure your migration is both safe and successful.

In Cisco ASA you create access-lists and use access-groups to apply them to interfaces, either ‘in’ or sometimes ‘out’.  Here's a line from an example Cisco ASA config:

access-group inside_access in interface inside

To interpret: the access-list inside_access is applied on traffic that comes in on the interface named inside.  You could potentially (sometimes done erroneously) write an access-list entry in inside_access to allow traffic from the outside to go inside, but that would not be applied to inbound traffic because any such traffic doesn't ingress the firewall from the inside interface.

Migration Tool 3 will import Cisco ASA interface names as zones, so once you import this config, assuming everything worked as expected, you should have the inside zone and the entries in the inside_access ACL will now be Palo Alto Networks security policies.  The Migration Tool will also import the Cisco ASA static routing table from the config.  Here's where it gets tricky.

Essentially we want to mimic the behavior of the Cisco as much as possible to ensure a smooth transition.  To mimic the functionality of the Cisco, the source zone for any policies that were in the inside_access ACL should be inside. However, the migration tool uses route lookups from the imported config to determine source and destination zones in policies.  This means that often there are policies that will allow traffic when before they would have never been hit.

Here's a simplified example of how I often see this applied in the real world:

access-list inside_access extended permit object-group Important-Servers any

access-group inside_access in interface inside

object-group Important-Servers

description Mission Critical Servers

network-object host

network-object host

route (inside)

route (outside)

In Cisco, this would only allow access to any because access-list inside_access is only applied to traffic coming into the inside interface.  The Migration Tool however, will do route lookups for the objects in this ACL entry and apply a source zone of not only inside but also outside, which now means has access to any as well.

To fix this, we want to override the zone assignments done by Migration Tool 3 to make the source zone match the interface name where the access-group is applied.

Conversely, if the access group is like this:

access-group inbound out interface inside

Then the destination zone for each access-list entry in inbound should be inside.  I see these less often, but some people still have "out" access-groups.

Fortunately, making mass changes in Migration Tool 3 is relatively simple using the "Multi-Edit" function.  You can select all of the rules that have a particular access list and easily change all of their source or destination zones at the same time.  Additionally, you can run "Auto-Zone" and specify how you wish the tool to apply zones.  One option available is to match the access-list, which is converted to a Palo Alto Networks tag.

L7 Applicator


take a look here Hotfix Release Notes  for changes introduced on 21th April 2015. The tool will manage this inbound and outbound changes on the zones automatically. djipp check this out !!

L1 Bithead

Nice work alestevez, thanks!

L0 Member

as a side note, I've published a script https://github.com/splitbrains/Clear-dminline to convert the DMinline objects to nice objects