Hey folks! 👋 Just wrapped up a migration project where we moved from Cisco ASA firewalls to Palo Alto NGFWs, and I wanted to share some of the "gotchas" we ran into. It's a common jump, and while PAN is fantastic for visibility and app-layer control, the config translation isn't always 1:1.
First big hurdle: **security policy logic.** On the ASA, you're used to thinking in terms of source/destination/service in an ACL. Palo Alto uses Security Policy rules, but they also have the concept of **Applications** as a first-class object. You can't just copy-paste port numbers.
- We had a rule like `permit tcp any any eq 443` on the ASA. On PAN, if you just specify service `tcp/443`, you'll miss all the app-layer context. Better to use `application-default` or specifically allow the `ssl` application.
- Pro tip: Use the built-in Policy Optimizer post-migration. It'll show you rules that are using ports vs. apps and help you tighten them up.
Second pitfall: **NAT translation.** ASA uses `static` and `global` commands. PAN separates it into NAT Policy rules and Security Policy rules. The order of operations is different! PAN does:
1. Destination NAT (if applicable)
2. Security Policy check
3. Source NAT (if applicable)
We messed up by putting the source NAT rule in the wrong spot and had traffic failing. Here's a basic example of a source NAT rule on PAN that tripped us up:
```yaml
rule_name: "Outbound-NAT"
from_zone: [trust]
to_zone: [untrust]
source_address: [192.168.1.0/24]
translated_address:
source:
dynamic-ip-and-port:
interface-address: ethernet1/1
```
Third, **monitoring the transition.** Don't just set it and forget it! I set up a Datadog dashboard to compare traffic flows and dropped packets between the old and new firewalls during the cutover. Seeing those graphs side-by-side saved us when a legacy app stopped working (turned out it used a non-standard port for HTTP that our app-ID policy blocked).
Finally, **object naming.** On the ASA, you might use numbered ACLs. PAN loves named objects (address objects, service objects). Take the time to create descriptive names—it'll make your policies so much easier to read and manage later.
Anyone else been through this migration? What was your biggest surprise? I've got some more screenshots of our monitoring setup during the transition if anyone's interested.
Dashboards or it didn't happen.
Great write-up, user319. I've seen a lot of teams hit that same wall with the application vs. port distinction. The Policy Optimizer is a lifesaver, but one thing I'd add: don't run it too early. Give your traffic a week or two to settle so it actually sees the app signatures. Otherwise you'll get a bunch of false cleanup suggestions and waste time chasing ghosts.
The NAT order of operations is definitely a bigger gotcha than most people expect. On the ASA, NAT happens almost as an afterthought inside the flow. On PAN, that destination NAT runs before the security policy lookup, which can totally break your rule logic if you're still thinking in ASA terms. I've had to redo zoning more than once because of that.
One more thing on the NAT side: PAN's bi-directional policies mean you really need to be careful with your Source and Destination zones in the NAT rule. If you just mirror the old ASA static command you might end up with asymmetric routing or a policy that doesn't match at all. Have you run into any weirdness with the virtual router or interface assignments during the migration?
Keep it real, keep it kind.
You're spot on about the application vs port mindset being the first real hurdle. But I've seen teams lean too hard on `application-default` too, which can open things up wider than the original ASA rule intended. That old `permit tcp any any eq 443` was often just lazy admin work.
A bigger gripe I have is how PAN's visibility can become a crutch. Yes, you can *eventually* use the Policy Optimizer, but if you start migrating rules on a Friday afternoon, you're flying blind until App-ID builds a baseline. You almost need a parallel run period, which the migration guides never seem to budget time for.
And don't get me started on the SSL application. It's a massive category. If you just swap your port 443 rule for 'ssl', you might be surprised what traffic your security team starts asking about on Monday.
That's a great starting point on the policy mindset shift. I'd push back slightly on using `application-default` as a blanket fix for those port-based rules though. In a migration, you're often inheriting sloppy legacy rules where the original intent is lost. Blindly switching to app-default can inadvertently permit applications the business never wanted, just because they happened to be using that port.
For example, we found an old 'permit tcp any host X eq 80' rule that, when migrated to use `application-default` for web-browsing, suddenly allowed a handful of web-based file-sharing apps the security team had explicitly blocked elsewhere. It took weeks to untangle. The Policy Optimizer helps, but it's reactive. You need a human to decide the business intent for each old, overly-broad rule before you flip that switch.
Your point on NAT order is the real killer. It's not just a logic puzzle - it changes how you design your security zones and address objects entirely. If you've built your rulebase with the original destination IP, but PAN does the NAT first, your rule simply won't match. It forces a complete rethink of the rulebase topology, not just a translation.
buyer beware, but buy smart