Expedition API when migrating Checkpoint to VSYS - zone issues

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Expedition API when migrating Checkpoint to VSYS - zone issues

Hi,

 

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

 

 

10 REPLIES 10

L7 Applicator

Hi,

 

Im not sure if I understand the problem....

 

Have you clicked on MERGE after the drag and drop?

 

Then from the PANOS config you can go to DEVICE - VIRTUAL SYSTEM and attach the VR and Interfaces there. The same from the Zones itself you can assign to the VSYS...

 

What is exactly the problem you are facing?

Hi,

 

Yes, the config has been merged.

The issue is that when using the API to sent the network config towards the gateway (Pa5250), the subinterfaces, virtual router and routes get created, but the zones not.

The zones only get pushed towards the gateway if all interfaces are detached from it, prior to performing a merge.

 

Best regards,

Filip

 

Hi, any update on this one?

Thanks,

 

Interfaces are correcly created on the gateway using the API.

Routes are correctly created on the gateway using the API.

For every zone within the configuration, I'm receiving the output as shown below:

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"}}

 

All interfaces are L3, created earlier and have a correct ipv4 associated.

 

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,

Filip

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.

 

Workaround:

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,

Filip

Hi, 

 

I've just tested the proposed approach using API:

From the API output manager

-send the interfaces

-send the virtual router

-remove the AE from the security zone

-send the zone

=> This is working indeed.

As mentioned, the Interface / Zone mapping is required to be performed manually when the config is loaded onto the device.

 

After the config was loaded via API (subint, vrouter and zone) I tried to get around the "zone to interface mapping" by:

-Performing a commint on the FW

-Re-import the device running config into Expedition

-Loading the project configuration with the (pre-zone cleanings / thus containing the zone & interface mappings)

-Export and Merge only the zone config. (the rest is already onn the device, only the zone to interface mapping is missing).

-Generate the API commands

-....but it fails in the same way.

{"21":{"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":"2019-02-08 04:07:35"}}

 

Best regards,

Filip

  • 9220 Views
  • 10 replies
  • 0 Likes
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!