Migration Zip file
Choose language for code snippet
Python Php GoIn this section we present how to create a valid ZIP file that will provide original vendor's configuration files and mapping instructions to generate a valid converted PANOS XML file. In this case,t he Zip file will be created as a set of steps, uploading the different configuration files and providing required information for the devicegroup mappings.
#
The ZIP structureThe following is a representation of the structure of a ZIP contents. A mapping.json
file is mandatory at the root of
the zip file, and will be used to determine how the rest of the files in the zip are being used during the migration processes.
The
The mapping.json file
would represent the mapping structure used for performing the migration.
The following is an example that represents the migration of three configurations into different device groups
in a Panorama configuration:
#
Supported vendorsinfo
The valid vendor
values are:
- cp → Checkpoint < R80
- cp-r80 → Checkpoint > R80
- ciscoasa → Cisco ASA
- fortinet → Fortinet Fortigate
- netscreen → Juniper Netscreen
- sonicwall → Sonicwall
- srx → Juniper Junos
Coming soon:
- ciscoswitch → Cisco Switch
- ciscoisr → Cisco ISR
- pfsense → Pfsense
- sophos → Sophos
#
STEP 1: Initiate a Zip preparation for migrationIf we want to use the API to help us in the creation of a ZIP file, in which we will have to provide the files to be uploaded and their parameters for the migration, the first step will be to notify Expedition that we want to start preparing a ZIP file for migrations.
The following route is offered to preparing a ZIP resource that will contain all the required information for a migration. This call does not require yet paramters, but replies with a resouce IP that we will use to identify the final ZIP structure that will contain all the configs to be migrated.
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/prepare/zip | |
Example | https://10.0.0.1/api/v1/prepare/zip |
Example:
- Python
- Php
- Go
#
STEP 2: Uploading the configuration filesFor each device configuration that we would like to migrate to a PANOS device (NG Firewall or Panorama), we will upload the
set of config files
, specify thevendor
used and name
this configuration.
In case of migrating configurations into Panorama configs, the naming will be used to identify the device group
and templates
that would contain the result of that configuration migration.
The calls comply with the following structure:
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/upload | in body { data: { zipID : zip resource id returned in the prepare statement}, vendor : vendor to be migrated, name: name to be used for this configuration } files: [list of files *] } |
* Depending on the selected vendor, the list of files to be used in the migration differs. Please check the required list of files for each vendor.
- Cisco ASA
- Cisco Switch
- Cisco ISR
- Checkpoint <R80
- Checkpoint R80+
- Fortinet
- Netscreen
- PFSense
- Sidewinder
- Sophos
- Sonicwall
- SRX
- Stonesoft
Below we present a sample code for uploading configuration files for Cisco ASA and Fortinet vendors.
Notice that a response for each configuration set that is uploaded
responds with a resourceID that will later be used to refer to that set of configuration files and options.
- Python
- Php
- Go
#
STEP 3: Declaring the migration Baseconfig fileAfter uploading configuration files, we can define one of the PANOS configs to become a base config for the migration.
We will have to determine the zip resource that we are going to manipulate and the panos config that will become the base config, by providing the panos source identifier (panosResource
).
This means that other third vendor configurations will be included into the base config in the form of Device group
or virtual system
.
Only one PANOS configuration file can be defined as a base configuration. Notice that other PANOS configurations are not supported to be integrated into anotehr baseconfig yet.
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/migration/defineBaseconfig | in body { zipId: zip resource identified, resource : resource identifier for the PANOS config } |
Example:
- Python
- Php
- Go
#
STEP 3B: Declaring the migration Baseconfig versionIt is also possible to define a blank base configuration. In such case, we need to provide the type
of platform we are
going to migrate to, selecting between panorama
or firewall
and specify the version of the PANOS device, selecting between
major versions
starting with 8.1 (currently, 8.1, 9.0, 9.1 and 10.0);
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/migration/defineBaseconfig | in body { zipId: zip resource identified, type : { 'panorama' | 'firewall' }, version: panos version } |
Example:
- Python
- Php
- Go
#
STEP 4: Creating the migration Zip fileOnce all the different configuration files have been uploaded, a device configuration has been provided, it is time to request the generation of the zip file to later initiate its conversion into a PANOS config. In this case, we need to identify the zip resource ID that we want to get generated.
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/migration/generateZip | in body { zipId: zip resource identified } |
Example:
- Python
- Php
- Go
#
STEP 5: Requesting the migrationThe conversion of the created ZIP is performed via the URL request below. Notice that this task may require a set of time to be completed, therefore configuration migrations are executed by the Expedition agent and a a jobId will be informed for monitoring the task.
Method | EndPoint | Parameters |
---|---|---|
GET | https://<YourExpeditionIP>/api/v1/migration/convert | in body { resource: zip resource identified } |
Example:
- Python
- Php
- Go
#
STEP 6: Monitoring the migration taskThe migration of a configuration (or set of configurations) may take between some seconds and several minutes. Therefore, it will be necessary to monitor the
related jobId to determine when this task is completed and, then, obtain the resource id
that can be later be used to import it into a project
or download for pushing it into your PANOS device.
For information on how to monitor a running job, please refer to Managing Jobs section for more information.
Once the job is completed (state
= 1), the migrated PANOS configuration will be offered via a resourceID
.
Such resourceId can be collected via the JSON path
Contents->response->data->content->expedition->resources->id
.
#
APPENDIX: Obtaining Third party vendor's configuration informationTo assist you in the generation of the mapping.json file, we can call a discovery
method that would analyze a
configuration file and, depending on the vendor, will provide back a set of valid options.
For instance, given the exporte_data.xml Stonesoft configuration file, the method can list the declared Firewalls and Clusters in the configuration, and declared security policies.
Method | URL | Parameters |
---|---|---|
POST | https://<ExpIP>/api/v1/migration/discovery | in body {"vendor": "value", "config": "path to the config file", (if cp) "policy": "path to the policy file", (if cp) "objects": "path to the objects file", (if cp) "rulebase": "path to the rulebase file"} |
example | https://10.0.0.1/api/v1/migration/discovery | in body {"vendor": "stonesoft", "config": "/tmp/myMigrationFiles/cpProviders/exported_data.xml"} |
example | https://10.0.0.1/api/v1/migration/discovery | in body {"vendor": "cp", "policy": "/tmp/myMigrationFiles/cpProviders/policy.W", "objects": "/tmp/myMigrationFiles/cpBranches/objects.C", "rulebase": "/tmp/myMigrationFiles/cpBranches/rulebases_5_0.fws"} |
Depending on the vendor, more parameters can be given to discover sections within them. For instance, Checkpoint <R80 would also allow the fields
policy
(in replacement of config
), objects
and rulebase
.
Response example:
- Stonesoft
- Checkpoint <R80
- Checkpoint R80+