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 10.1.1.11
network-object host 209.165.201.3
route (inside) 10.0.0.0 255.0.0.0 10.0.0.1
route (outside) 0.0.0.0 0.0.0.0 1.1.1.1
In Cisco, this would only allow 10.1.1.11 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 209.165.201.3 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.
