Zones vs. interfaces: the mental shift from ASA to PAN-OS
The syntax you can look up. The conceptual leap — from interface-and-security-level to zone-based policy, with different defaults — is what silently breaks traffic after a cutover.
The syntax differences between ASA and PAN-OS are easy to look up. The one that actually trips people up is conceptual: ASA thinks in interfaces, PAN-OS thinks in zones — and the default behavior between them is not the same. Migrate the rules faithfully but miss the model shift, and traffic that worked for years on the ASA quietly stops.
How the ASA thinks: interfaces and security levels
On an ASA, policy is bound to interfaces. Each interface has a nameif (inside, outside, dmz) and a security level from 0 to 100. You apply access-lists to an interface in a direction with access-group ACL in interface inside.
The part that matters for migration is the implicit behavior. By default, traffic from a higher-security interface to a lower one is permitted; lower to higher is denied. That's why plenty of ASA configs have no explicit rule allowing inside-to-outside — the security levels did it silently. Same-level traffic is denied unless you add same-security-traffic permit inter-interface.
PAN-OS has no security levels and no implicit high-to-low permit. Every flow you want is explicit. The traffic your ASA allowed because of security levels rather than an ACL has no corresponding rule to convert — so it silently breaks unless you add it.
How PAN-OS thinks: zones
In PAN-OS, an interface belongs to exactly one zone, and security policy is written zone-to-zone: from trust to untrust. Zones are the security boundary; a rule references source and destination zones, not interfaces.
Two defaults are different from the ASA and worth memorizing:
- Interzone traffic (zone A → zone B) is denied by default. There is no permissive security-level shortcut. If you don't write a rule, it drops.
- Intrazone traffic (within the same zone) is allowed by default. This one bites in the other direction — see below.
Mapping interfaces to zones is a design decision, not a copy
The instinct is one-zone-per-interface: inside→trust, outside→untrust, dmz→dmz. That's usually right and keeps the translation clean. But you have a choice ASA didn't give you: you can group several interfaces into one zone.
Do that carelessly and the intrazone default catches you. Put two interfaces that the ASA kept separate into a single PAN-OS zone, and traffic between them now flows by default — the segmentation you had is gone, silently, with no rule to show for it. If two segments were distinct on the ASA, keep them in distinct zones unless you deliberately want them to talk.
Direction and state
ASA rules are directional and per-interface: you think about which ACL is applied inbound vs. outbound on which interface. PAN-OS rules are directional by zone pair (from-zone, to-zone), and the firewall is stateful at the session level — you write the rule for the flow that initiates the session, and return traffic is allowed automatically. You don't write a matching reverse rule, and you don't apply policy "outbound" on the far interface. One rule per initiated flow, expressed as a zone pair.
A migration approach that doesn't lose traffic
The order that works:
- Design the zone model first. Decide which interfaces become which zones before you touch a single rule. Default to preserving ASA separation — one zone per distinct segment.
- Translate each access-group into from-zone/to-zone rules. The interface an ACL was applied to tells you the zone pair.
- Backfill the implicit permits. This is the step people skip. Walk the ASA's security-level relationships and write explicit PAN-OS rules for any flow that "just worked" without an ACL — inside-to-outside being the classic one.
- Re-check anything you collapsed into a shared zone for intrazone traffic you didn't intend to allow.
The rules are the mechanical part. The zone model is the part that determines whether the migrated firewall behaves like the old one. Get the model right first, and the policy falls into place around it — get it wrong, and you'll be chasing "it worked before the cutover" tickets for a week.
Written by Roman Dmytriv — network security engineer (CISSP), two decades securing and modernizing enterprise networks. More writing at blog.dmytriv.com, and I'm on LinkedIn.