# Check Point, ASA & FortiGate → Palo Alto, with proof

Source: https://ai.techclick.in/blog_paloalto_migration_checkpoint_asa_fortigate
Markdown: https://ai.techclick.in/blog_paloalto_migration_checkpoint_asa_fortigate.md
Publisher: Techclick Infosec Pvt Ltd

Export Check Point, Cisco ASA, and FortiGate configs, convert to PAN-OS, map zones, cut over with proof, then App-ID using Policy Optimizer.

Quick answer (say this in an interview)

   A firewall migration is a  language rewrite , not a file copy. Export the vendor’s documented file, convert  like-for-like  onto a matching PAN-OS base, map interfaces to  named zones , prove sessions in  Monitor → Logs → Traffic , then move ports to App-ID with  Policy Optimizer . Expedition can type objects; it cannot invent the implicit ASA permit or the missing Check Point route file.

## Why this migration fails on Saturday

   Hero · three languages, one NGFW

   The converter moves objects. You still have to rewrite how the box  thinks : security-level vs zone vs interface-pair.

 Check Point, Cisco ASA, and FortiGate all keep “who may talk.” They do not keep it the same way. ASA can allow inside→DMZ because security-level 100 is higher than 50. Check Point can hide the real rule across policy layers and NAT. FortiGate can hide destination NAT inside a VIP while the policy still says the public IP.

 PAN-OS is zone-based and  denies all interzone traffic  until a Security rule allows it. If you only import objects, Saturday’s outage is already scheduled.

   Classic ticket

   “Expedition said 0 errors. Users on VLAN 20 cannot reach 10.20.8.15. Traffic log is empty.” Empty log usually means the packet never matched a session you expected — wrong zone, wrong virtual router, or implicit deny — not “PAN is broken.”

## Mental model: translate, then improve

   Feel · six-phase pipeline

   Two jobs, in this order: (1) make the new box behave like the old one, (2) then make it a real NGFW with App-ID.

 Hold two jobs in your head.  Job 1 — translate:  same IPs, same ports, same NAT direction, same VPN peers, traffic still flows.  Job 2 — improve:  replace “tcp/443 any” with the applications you actually saw, attach Security profiles, turn on decryption only after the path is proven.

 Palo Alto’s own best-practice guide says the first phase is a  like-for-like  port-based policy on PAN-OS, then  Policy Optimizer  converts those rules to applications. Do not App-ID the entire internet on the cutover night.

   Say this out loud

   The tool types. I decide zones, NAT direction, and when App-ID is safe. If I skip the route file or the implicit ASA permit, the XML can still be “valid.”

#### Hard word · Zone

 A named security boundary bound to one or more interfaces. Policy is zone-to-zone, not “GigabitEthernet0/1.”

#### Hard word · Like-for-like

 The first imported Security policy still uses services/ports so Saturday traffic matches Friday traffic.

#### Hard word · Policy Optimizer

 PAN-OS view that shows which applications a port-based rule actually saw, so you can replace the port safely.

#### Hard word · Expedition

 Palo Alto’s old migration VM. Useful parsers. End of Life January 2025. TAC does not support it.

## The six-phase path (flowchart first)

   Flow 1 · migrate, then harden

       Six-phase firewall migration to PAN-OS

- 1 Audit what must live 2 Map IF → zone → VR 3 Convert like-for-like 4 Review NAT / VPN / unused 5 Pilot one VLAN / one VPN 6 Cut prove logs After traffic is stable → Policy Optimizer (Job 2). Not on the cutover night. Read left → right. Diamond of death is skipping Map: a converted rule with the wrong zone is a silent deny. Decision feel · level vs zone vs pair ASA thinks in security-levels. Check Point thinks in layers and gateways. FortiGate thinks in interface pairs / VIPs. PAN-OS asks: source zone, dest zone, app, user. ## Which source file to bring If the file is wrong, every later click is theatre. These are the files Palo Alto’s Expedition export guide documents — still the right inputs even if a human or Migration Factory does the typing. Source What you export Also collect What the tool will not invent Check Point ≥ R80 ShowPolicyPackage .tar.gz (JSON/HTML snapshot) Route table: netstat -nr or show route all Which policy package is actually installed on the gateway; inline layer order Check Point  R80, Cisco ASA 8.2–9.6 (and Firepower in ASA syntax), FortiGate 4.0/5.0/6.0 for address/service/security/NAT/L3/static routes. VPN is marked for Cisco ASA only in that table. Anything outside the matrix is a rebuild, not a surprise “success.” Expedition after January 2025 Palo Alto ended support for Expedition 1 and 2 in January 2025. TAC does not support the tool. Their public alternatives are Strata Cloud Manager cleanup/optimization for SCM-managed configs, plus Professional Services / Migration Factory . If you still run a local VM, keep it offline , treat XML as a draft, and never expose it to the internet. Source: pan.dev/expedition and the LiveCommunity EoL note. ## Click the vendor — then do it Click your source. Side A is only the export. Side B is convert + zone map. Side C is PAN-OS load and proof. Same three sides for every vendor. 1 · Check Point 2 · Cisco ASA 3 · FortiGate ### Side A — Export Check Point Primary source: Expedition Export · Checkpoint and Check Point ShowPolicyPackage . #### R80+ : run ShowPolicyPackage on the management server Expedition documents tool v2.0.6 . On many R80+ Jumbo systems the wrapper is already there: Check Point management (expert / wrapper) $MDS_FWDIR/scripts/web_api_show_package.sh $MDS_FWDIR/scripts/web_api_show_package.sh -k Standard $MDS_FWDIR/scripts/web_api_show_package.sh -k Standard -d "Corp-Domain" Output is a .tar.gz . Use domain name or CMA IP , not CMA name. Pull the package that is installed on the gateway , not an old unused package.

- #### Collect the route file (mandatory for zone math) On the gateway: netstat -nr or show route all . Expedition uses this to guess zones. No route file → wrong zones → Saturday deny.

- #### Pre-R80 : pull $FWDIR/conf files objects_5_0.C (or objects.C ), Policy.W / rulebases_5_0.fws , plus the same route file. On Provider-1, switch context to the right CMA first.

### Side A — Export Cisco ASA

   Primary source:  Expedition Export · Cisco .

- #### Turn paging off, dump the running config ASA CLI terminal pager 0 more system:running-config ! or: show running Save as .txt . If you leave paging on, the file is silently truncated and NAT/VPN objects vanish.

- #### Multi-context: every context, then system changeto context   , dump again, then changeto system . One context is not “the firewall.”

- #### Write down what the converter cannot see Pre-shared keys, whether same-security-traffic permit inter-interface is on, and every security-level pair that has no ACL (implicit allow). Those pairs need explicit PAN-OS rules.

### Side A — Export FortiGate

   Primary source:  Expedition Export · Fortinet .

- #### GUI backup to the PC Go to Admin → Configuration → Backup . Choose Local PC (or USB). You get a readable .conf . Newer FortiOS builds may show the same action under System → Config → Backup — same file type; do not invent a third format.

- #### VDOMs: pick the VDOM you are actually replacing If VDOMs are enabled, Expedition says choose VDOM configuration (VDOM Config) and the VDOM name. A global-only backup is the wrong lab.

- #### Inventory VIPs and NAT mode before convert Write every VIP (public IP → real server) and whether the box is in central NAT or policy NAT. On PAN-OS you will recreate destination NAT and a Security rule that uses the pre-NAT zone / post-NAT address the way PAN-OS expects.

       https://203.0.113.10/ng · Admin / Configuration / Backup

       Training mock · not live

         Admin → Configuration → Backup

### Backup configuration

            Destination  Local PC

            Scope  VDOM Config · root

          File that must land on the laptop  FGT-ROOT-20260817.conf

          Cancel  Backup

     Documented path from Palo Alto Expedition Export (Fortinet). Click  Backup  in the lab, then checksum the .conf before you leave the change window.

### Side B — Convert and map (all three sources)

 Primary source:  Migrate a Port-Based Policy to PAN-OS Using Expedition .

- #### Create a project and import the vendor file Inspect format, required files, and parser logs. If Check Point imported zero rules, you likely fed HTML instead of the .tar.gz , or the wrong package name.

- #### Import a PAN-OS base that matches the target version Factory default or an Iron-Skillet Day-1 XML for the same PAN-OS major version you will run. Do not merge a 9.1 export onto a 11.1 box and hope.

- #### Clean before you merge Remove or replace non-TCP/UDP “services” (ping/ICMP become applications). Delete unused and duplicate objects. Drop disabled rules. Rename interfaces to PAN names ( ethernet1/1 , not port1 ).

- #### Rename zones to the job they do Expedition auto-assigns zone names. Change them to trust , untrust , dmz (or your standard) and bind them to the right interfaces. Check the virtual router for static routes — bulk-migrate if there are many; type them if there are three.

- #### Merge onto the base, then export New box: Generate XML & Set Output, import, load. Existing box: load config partial over SSH so you do not wipe management. Clear ARP on adjacent switches if the MAC is about to change ( clear arp all on PAN-OS).

     https://192.0.2.50 · Expedition project (offline VM)

     Training mock · not live

       Projects → Mumbai-DC-Cutover → Import

### Import source + PAN-OS base

          Source vendor  Checkpoint ≥ R80

          Source file  Standard.tar.gz + routes.txt

          Base config  PA-3410 · PAN-OS 11.1 factory / Iron-Skillet

          Parser status  Rules 186 · NAT 24 · unused objects 41

        Open logs  Merge to base

   Training mock of the Expedition project workflow in the official best-practice article. Keep this VM  offline  after the January 2025 EoL.

### Side C — Load on PAN-OS and prove it

 Primary source: same Expedition best-practice page, then  Policy Optimizer .

- #### Commit the like-for-like policy Confirm Network → Interfaces and Network → Zones match the spreadsheet from phase 2. Management profile still allows your jump host.

- #### Pilot one path before the building One VLAN or one IPSec peer. Generate traffic. Open Monitor → Logs → Traffic . You want Rule, From Zone, To Zone, App, Action = allow, bytes > 0.

- #### Only then open Policy Optimizer Policies → Security → Policy Optimizer . Start with rules that saw a small, stable set of well-known apps. Replace the service with those applications (often application-default ). Leave noisy port-80/443 rules until you have a week of logs.

     https://fw.lab.example.com · Policies / Security / Policy Optimizer

     Training mock · not live

       Policies → Security → Policy Optimizer → No App Specified

### No App Specified

        Rule (example lab names)  allow-trust-untrust-web · service tcp/80,443 · apps seen: ssl, web-browsing

        Safe next click  Convert to apps: ssl, web-browsing · service application-default

        Compare  Convert

   After like-for-like is green. This is Job 2. Source: Palo Alto “Migrate to Application-Based Policy Using Policy Optimizer.”

   Need the exact click for Zones after import?
    Network → Zones  — each zone type Layer3, interfaces attached. Then  Policies → Security  — Source Zone / Dest Zone must match those names. A rule that still says zone  Inside  while the interface sits in  trust  will never hit.

## After go-live: packet to log

   Flow 2 · runtime on PAN-OS

       Packet path after cutover

- Host 10.20.8.50 Ingress zone trust / ethernet1/2 NAT then policy dest NAT first Security rule zone / app / action Traffic log Rule · Zone · App · Action If the log is empty, the session never formed. Check zone + VR + routing before you add another any-any rule. Ops · proof cockpit Cutover is not “commit succeeded.” Cutover is a green Traffic log on the pilot path plus the rollback file still in your pocket. ## Traps and the proof checklist What you see Likely cause First fix Proof Inside → DMZ dead, no deny log ASA implicit security-level allow was never written as a PAN rule Add explicit trust→dmz Security rule; check interzone-default Traffic log: Rule name + allow + bytes Check Point import is empty Wrong package, HTML instead of .tar.gz , or no R80 ShowPolicyPackage Re-run web_api_show_package.sh -k   Parser shows rule count > 0 Zones look random No route file on Check Point; FortiGate port names left as port1 Import netstat -nr ; rename interfaces to ethernet1/x Network → Zones matches the spreadsheet Inbound VIP works, return path uses private IP FortiGate VIP / bidirectional NAT not paired on PAN Destination NAT + Security rule using PAN NAT semantics Session table shows bidirectional NAT Everything on tcp/443 breaks after “App-ID cleanup” Job 2 done on night 1; Policy Optimizer not given time Revert those rules to service; convert only stable apps Policy Optimizer “apps seen” is a short, known list Expedition VM on a LAN with a browser EoL software, known critical bugs historically, no TAC Isolate / power off after export; prefer PS / Migration Factory / SCM VM has no default route to the internet Pilot checklist (print this) Source file checksum stored with the change ticket

- Zone spreadsheet: old IF / security-level / VDOM → PAN interface / zone / VR

- Implicit ASA paths listed as new Security rules

- NAT pairs (especially FortiGate VIP) tested both directions

- One VPN peer or one VLAN piloted

- Traffic log: Rule, From/To Zone, App, Action, bytes

- Rollback: previous PAN-OS config saved, old gateway still powered for fallback

- App-ID conversion scheduled after a quiet week, not tonight

   Unsafe vs safe

    Unsafe:  import, commit, delete the old firewall, then discover interzone-default.  Safe:  convert → review NAT/VPN/unused → pilot one path → cut → watch logs → Policy Optimizer later.

## Knowledge check

   Six judgment calls. Pick the first fix a sober L2 would do on Saturday.

       Q1
       ASA 5525-X used security-level 100 (inside), 50 (dmz), 0 (outside). No ACL covered inside→dmz. After a clean convert, inside users cannot reach DMZ and the Traffic log is quiet. What failed?

           Address objects never convert from ASA, so the destinations are empty
           PAN-OS has no implicit higher-to-lower permit; interzone-default is denying and you never wrote the zone-to-zone allow
           You must enable App-ID on every rule before any traffic can pass
           Expedition always strips DMZ interfaces; rebuild Layer 2 only

       Correct:  b . Re-read “Why this migration fails” and the ASA Side A implicit-allow note. PAN-OS is deny-between-zones until you allow it.

       Q2
       You are migrating a Check Point R81.10 SmartConsole policy. Which pair is the documented Expedition input?

           Only  objects_5_0.C  from $FWDIR/conf — R80+ still uses that file alone
           A screenshot PDF of SmartConsole plus a routing Excel
           ShowPolicyPackage  .tar.gz  for the installed package, plus a gateway route file
           cpinfo only — Expedition parses cpinfo natively

       Correct:  c . Re-read Side A Check Point. Pre-R80 uses objects_5_0.C; R80+ uses ShowPolicyPackage. The route file drives zone calculation.

       Q3
       Leadership asks you to “just run Expedition on a public jump host, TAC will support us.” What is the accurate answer?

           Expedition 2 is fully TAC-supported through 2027 if you have Premium support
           Expedition 1 and 2 are EoL from January 2025; TAC does not support them; keep any leftover VM offline and prefer SCM / Migration Factory / PS
           You must use Expedition online so it can download App-ID
           FortiConverter is the official Palo Alto replacement

       Correct:  b . Re-read the Expedition EoL callout. FortiConverter is Fortinet’s tool toward FortiOS, not toward PAN-OS.

       Q4
       FortiGate VIP 203.0.113.20 → 10.20.8.20. After convert, inbound hits the server but the server’s replies leave with 10.20.8.20. First place to look?

           PAN destination NAT plus the Security rule that matches how PAN evaluates pre/post-NAT addresses — VIP is not a 1:1 clone
           Enable security-level 100 on the PAN untrust zone
           Delete all NAT and rely on Policy Optimizer
           Change the server default gateway to the old FortiGate

       Correct:  a . Re-read FortiGate Side A step 3 and the VIP trap row. Do not invent ASA security-levels on PAN-OS.

       Q5
       The like-for-like policy is passing. An engineer wants to set every tcp/443 rule to  any  application tonight “because we bought App-ID.” What do you do?

           Agree — like-for-like is wasted work once App-ID licenses are active
           Use Policy Optimizer after you have apps-seen on stable rules; leave noisy web rules on service until the set is known
           Disable all Security profiles first, then set application any
           Replace Expedition with Iron-Skillet and drop the customer rulebase

       Correct:  b . Re-read the mental model and Side C. Palo Alto’s own guide is like-for-like first, Policy Optimizer second.

       Q6
       Check Point convert finished, but Expedition zones do not match the live gateways. Which missing file is called out for zone calculation?

           The SmartEvent database
           A route file from the gateway ( netstat -nr  or  show route all )
           The ICA certificate pack
           cp.license

       Correct:  b . Re-read Check Point Side A step 2. Expedition documents the route file specifically for zone calculations.

       Check answers
       Reset

## Sources

- Palo Alto — Expedition 2.0 overview, EoL note, vendor matrix: pan.dev/expedition/docs

- Palo Alto — vendor export recipes (Check Point, Cisco, Fortinet): expedition_export

- Palo Alto — like-for-like then Policy Optimizer: Migrate a Port-Based Policy Using Expedition and Policy Optimizer

- Palo Alto LiveCommunity — Expedition EoL + SCM / Migration Factory: EoL announcement

- Check Point — ShowPolicyPackage: github.com/CheckPointSW/ShowPolicyPackage

- Migration questions: fwmigrate@paloaltonetworks.com

 Related:  Check Point → Palo Alto (zones, NAT, App-ID)  ·
 Firewall migration playbook (multi-destination)  ·
 PAN-OS Security policy  ·
 Zones, interfaces, VR  ·
 PAN-OS NAT  ·
 Check Point vs Palo Alto vs Fortinet  ·
 ASA interview

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt