Expedition API when migrating Checkpoint to VSYS - zone issues

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Expedition API when migrating Checkpoint to VSYS - zone issues



I'm having a project for migrating several Checkpoint clusters to Palo Alto Vsys.

I'm using Expedition version: 1.0.106 (the issue also resides in earlier versions).


I'm hitting an issue when migrating the zones.

1.Interfaces, virtual router and zones will be directly configured on the related gateway using API.

2.Security policy and NAT will be loaded into the Panorama's specific devicegroup.


The issues is at stage 1.

>migrating and configuring the interfaces using API works fine.

>migrating and configuring the VR using the API works fine.

>However the migration of zones isn't working at all.

The zones (L3) has an interface associated which is also migrated and for which the creation (by API) worked out fine.


The API error output: 

{"6":{"device":"UTRFWONE5","status":"fail","text":"<msg><line><![CDATA[ zone -> Zone27 -> network -> layer3 \\'ae2.313\\' is not a valid reference]]><\/line><line><![CDATA[ zone -> Zone27 -> network -> layer3 is invalid]]><\/line><\/msg>","date":"2018-10-16 05:51:22"}}

I confirm in the situation above the interface: ae2.313 has been successfully configured using API.


=> Only when you detach all interfaces from ALL zones, export the config - merge - generate API cmds - send API cmds the zones are created.


Couple remarks:

-Interfaces can be mapped (manually) to the correct VSYS in the Expedition tool.

-Virtual routers cannot be mapped to a VSYS in the Expedition tool.

-Zones cannot be mapped to a VSYS  in the Expedition tool, but within the zone view you can select an extra column: vsys.

.... but it cannot be edited?


Would be good to have a solution on this one....

Thanks a lot,

Filip ElsenAPI callsAPI callsConfig mergeConfig merge




Have you send the Interfaces first?

Yes, sure. These are created using API.

Only the zone(s) - all of them - are causing issues.

Has this been validated, tested?


Thanks a lot,


I was able to recreate your issue and will file a report for review:


Workaround - to send the config via API calls to Panorama

-send the interfaces, ethernet and aggregate interfaces first

-send the zones (remove the AE interface first from the zone)

-on panorama edit the zone and add the AE as a member

after more testing and debugging found the issue is with PanOS and not with the API request being generated by Expedition.


This only applies to AE interfaces being added to a security zone.



Assumption is that the AE configuration has been completed in Expedition


From the API output manager

-send the interfaces

-send the virtual router

-remove the AE from the security zone

-send the zone


Transition to Panorama and add the AE to the appropriate security zone

Thanks for the update.

I'll try the proposed steps and will come back asap.

What's the ETA?


Thanks a lot,


Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!