Check Point to Palo Alto what actually has to move

Home · Blogs · Check Point → Palo Alto

The ticket

Friday 18:40. Finance cannot reach ERP. The Check Point gateway still has the old policy. The new Palo Alto pair is in path. Traffic log shows interzone-default deny from Trust to DMZ. Someone already “converted” 150 rules. Someone else says “it worked on Check Point, so NAT is fine.”

The dummy lab for this lesson: gateway cp-gw-01, Finance 10.20.30.0/24, DMZ web/ERP host 10.10.5.20 published as 203.0.113.50, Hide NAT for 10.10.0.0/16. About 150 Access Control rules and 40 NAT rules. Nobody has a zone map on paper.

Hero · stacked blades vs one zone / App / user policy

Mental model: layers vs one policy

Learn four words before you touch XML.

Zone. Every PAN-OS interface (or group of interfaces) belongs to a security zone. Every Security rule must name source zone and destination zone. Traffic between different zones is denied by the predefined interzone-default rule until you allow it. Check Point usually infers “inside vs outside” from topology and anti-spoofing, not from a required zone column on every rule.

App-ID. PAN-OS identifies the application (for example ssl, web-browsing, ms-rdp) instead of trusting the port. A converted service-https rule is still a port hole. The upgrade is naming the apps and setting Service to application-default.

Pre-NAT IP, post-NAT dest zone. On PAN-OS the firewall does a route lookup on the original destination, matches a NAT rule, then matches Security using the original addresses but the zone of the translated destination. Translation itself happens on egress. That is official PAN-OS NAT policy logic — not “security uses the private IP.”

Implied rules. Check Point pre-creates hidden accepts for control connections and, depending on Global Properties, DNS / ICMP / DHCP. PAN-OS has none of those extras. If you do not write them, management, monitoring, or name resolution dies at cutover.

The only safe order

Pipeline · export, clean, zone map, convert, parallel test, cutover

A mid-size rulebase (hundreds to a couple of thousand rules) commonly takes 8–14 weeks if you actually clean and prove it. A “weekend cutover” is how you inherit a PAN-OS box that still allows TCP/443 to any.

What you need before starting

$MDS_FWDIR/scripts/web_api_show_package.sh -v
$MDS_FWDIR/scripts/web_api_show_package.sh -k STANDARD
# MDS / Multi-Domain: domain name or CMA IP — not the CMA name
$MDS_FWDIR/scripts/web_api_show_package.sh -k STANDARD -d "Techclick-Lab-Domain"

Also save the gateway route table (netstat -nr or show route all) and ClusterXL state (cphaprob state). Expedition used the route file to guess zones. You still need it to design the zone map even if a human does the typing.

Blade → PAN-OS feature map

What tools convert vs what you do by hand

Palo Alto’s old converter was Expedition (the fifth generation of their Migration Tool). Its job was mechanical: turn a Check Point / Cisco / Fortinet / Juniper config into a PAN-OS starting XML so you had time to improve it. Expedition 1.x also added a machine-learning pass from traffic logs and a Best Practices Assessment. Expedition 2.0 added containers, an API, and automation around that same parser.

That product is gone as a supported path. The official notice: from January 2025 Palo Alto no longer supports Expedition, including all Expedition 1 and Expedition 2 branches. Core ideas (cleanup, App-ID from real logs, best-practice checks) were meant to land in newer products — for a PAN-OS box you already manage, that is Policy Optimizer plus Strata Cloud Manager cleanup, not a new Expedition VM. Vendor-specific questions still go to fwmigrate@paloaltonetworks.com.

Read the official parser matrix before anyone says “the tool will do VPN.” Check Point VPN was never ticked. Cisco ASA VPN was. App-ID and User-ID were never a checkbox on this table — they were later improvement work.

Source: pan.dev/expedition “Supported Vendor Matrix” (beta). A blank VPN cell is a rebuild, not a surprise failure. Anything outside this list (Mobile Access, Identity Awareness, HTTPS Inspection, ClusterXL, implied rules) was never claimed.

Runbook: export → convert → prove

Primary sources for these steps: Check Point ShowPolicyPackage README, R81 Implied Rules and NAT Policy topics, PAN-OS NAT policy rules, Virtual Wire, and Policy Optimizer.

Side A — Check Point (source of truth)

1. Export the package, not a screenshot

   Palo Alto’s Expedition export guide still documents the right inputs even though the converter is EOL. For Check Point R80+: ShowPolicyPackage v2.0.6 (or newer). On Jumbo management servers the wrapper is already there. Use the domain name or CMA IP on MDS — CMA name is not supported.

   R80+ — Expedition export guide

   $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 "Techclick-Lab-Domain"

   Output is a .tar.gz (HTML + JSON). Confirm NAT and HTTPS layers are inside. Then take a route file from the gateway — Expedition used it for zone calculations; you still need it to design zones:

   Gateway — route file for zone math

   netstat -nr
   # or
   show route all

   Pre-R80 files (if the management server is still R77 or older)

   Expedition’s export guide asks for four things from $FWDIR/conf (or the CMA /conf after switching context): objects_5_0.C (or objects.C on 4.x), <package>.W / rulebases_5_0.fws, and the same route file. On Provider-1/MDS, global objects come from $MDSDIR/conf on the master MDS. You still convert those objects by hand or through a current partner/PS path — Expedition will not ingest them as a supported tool.

2. Dump implied rules and NAT style

   Actions → Implied Rules. Note First / Before Last / Last. In Global Properties → Firewall, record which implied accepts are enabled. On each host/network object, note Automatic Static vs Hide NAT. Manual NAT rows override automatic ones — export those too.

3. Clean before you convert

   Hit-count zero, shadowed, and “temp allow” rules do not deserve a PAN-OS life. A dirty 2,000-rule base becomes a dirtier 2,000-rule PAN-OS base.

4. Inventory VPNs and identity

   List every community, encryption domain, and remote-access blade. List Identity Awareness sources (AD, Identity Collector, captive portal). Expedition’s official matrix left Check Point VPN blank — rebuild IKE/IPsec and GlobalProtect from this list, do not wait for a parser.

Side B — PAN-OS (target)

1. Build interfaces and zones with no policy yet

   Network → Interfaces, then Zones. Dummy map: ethernet1/1 Untrust, ethernet1/2 Trust, ethernet1/3 DMZ, HA on dedicated links. Put a Virtual Router on the L3 interfaces. Do not paste 150 rules onto unnamed zones.

2. Load a like-for-like draft

   Import converted objects and port-based rules. Rename interfaces to match Side B. Fix dest-NAT using the official split (next section). Add explicit management / DNS / NTP / monitoring rules that replaced implied rules.

3. Attach profiles, do not invent decrypt on day 0

   Objects → Security Profiles: one “standard” Vulnerability + Anti-Spyware + Antivirus + WildFire + URL profile. Attach to internet-bound allows. Leave SSL decryption off until the like-for-like path is proven — decryption is its own project.

4. Log the default deny

   Override interzone-default to log at session end. That log is how you find the next missing rule instead of guessing.

Side C — Parallel proof, then cutover

1. Insert without changing routing

   TAP: copy traffic, policy logs only. Virtual Wire: two interfaces bound as a bump-in-the-wire, no MAC/IP on those ports, Security/App-ID/NAT still apply. Official Virtual Wire doc: you can drop a firewall into an existing segment without redesigning neighbors. Use this beside the live Check Point.

2. Compare logs for days, not hours

   Monitor → Logs → Traffic on PAN-OS vs SmartLog on Check Point for Finance→ERP, internet Hide NAT, and one VPN. Mismatches now are cheaper than mismatches after the default route moves.

3. Move traffic by zone or site

   Change a routing instance or a VLAN, not the whole campus. Keep Check Point powered with a written rollback (swap cables / restore the old next hop).

4. Only then App-ID

   Policies → Security → Policy Optimizer → No App Specified. Sort by traffic. Clone a few port rules, keep dependencies (ssl, web-browsing), set Service to application-default, leave the port rule underneath until it is quiet.

Dest-NAT example (the care part)

NAT journey · arrive, lookup, translate on egress

Internet host 192.0.2.250 opens https://203.0.113.50. Dest NAT on the firewall sends that to ERP 10.10.5.20 in DMZ. This is the official one-to-one dest-NAT pattern.

Hide NAT for Finance to the internet is simpler: Security Trust → Untrust, source 10.20.30.0/24, dest any, then a source-NAT (usually Dynamic IP and Port) to the Untrust interface. U-turn (internal user hitting the public ERP IP) is a third rule pair — do not assume the inbound dest-NAT covers it.

First 72 hours: troubleshooting order

Hypercare · prove allows in logs, not in hope

When someone says “it worked on Check Point,” walk this order. Do not start with a reboot.

test security-policy-match from Untrust to DMZ source 192.0.2.250 destination 203.0.113.50 destination-port 443 protocol 6
test nat-policy-match from Untrust to Untrust source 192.0.2.250 destination 203.0.113.50 destination-port 443 protocol 6
show session all filter source 192.0.2.250 destination 203.0.113.50
show session id <ID>
show counter global filter delta yes

test security-policy-match does not walk the full packet path — it tells you which rule matches the fields you typed. Confirm the live session and the Traffic log before you declare victory. Device → Troubleshooting can run the same NAT/security tests from the GUI.

Traps and when not to go alone

If you have never touched PAN-OS: lab VM → convert 10 Check Point rules by hand (including one dest-NAT) → learn test security-policy-match → only then schedule a real window. That sequence is slower on the calendar and faster in production.

Sources

• PAN-OS 11.1 NAT Policy Rules — route lookup, NAT match, Security on pre-NAT addresses / post-NAT zones, translate on egress.
• Destination NAT Example — One-to-One Mapping — public dest IP in Security, DMZ dest zone.
• Migrate Port-Based to App-ID Based Security Policy Rules — Policy Optimizer, clone vs Match Usage, application-default.
• Virtual Wire Interfaces — bump-in-the-wire parallel insert.
• Create a Security Policy Rule — intrazone-default allow, interzone-default deny.
• Expedition 2.0 docs — EOL January 2025; Supported Vendor Matrix (Check Point VPN blank; Cisco ASA VPN ticked); contact fwmigrate@paloaltonetworks.com.
• Expedition Export — Check Point — ShowPolicyPackage v2.0.6, $MDS_FWDIR/scripts/web_api_show_package.sh, route file for zone calculations, MDS domain name or CMA IP.
• Expedition end-of-life announcement — support ends January 2025 for Expedition 1 and 2; functionality moving into newer products.
• Check Point R81 Implied Rules — Actions → Implied Rules; Global Properties → Firewall.
• Check Point R81 Configuring the NAT Policy — Automatic vs Manual NAT; Hide vs Static.
• CheckPointSW/ShowPolicyPackage — .tar.gz HTML+JSON export; R80+ wrapper script.

Related: PAN-OS NAT deep dive · Zones, interfaces, VR · Security policy fundamentals · Check Point / ASA / FortiGate overview · Check Point policy layers · Check Point Hide vs Static NAT · GlobalProtect · PAN-OS HA modes · Troubleshooting command center