Skip to main content

Migration Zip file

Choose language for code snippet

Python Php Go

In 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 structure#

The 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

.+-- panorama_baseConfig.xml+-- mapping.json+-- ciscoConfig|   +-- ciscoasa.txt+-- fortinet|   +-- FortinetDemoFinal.conf

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:

{  "baseConfig":{      "file": "panorama_baseConfig.xml",      "type": "panorama",      "version": "10.0"     },  "configs":    [{        "name": "ciscoConfig",        "vendor": "ciscoasa",        "config": "ciscoConfig/ciscoasa.txt",     },{        "name": "fortinet",        "vendor": "fortinet",        "config": "fortinet/FortinetDemoFinal.conf",     }]}

Supported vendors#


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 migration#

If 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.



print('PREPARE MIGRATION ZIP')r = requests.get('https://'+ip+'/api/v1/prepare/zip', data=data, verify=False, headers=hed)response=r.json()zipID = json.dumps(response['Contents']['response']['data']['content']['expedition']['resource']['zipId'])print(zipID+'\n')

STEP 2: Uploading the configuration files#

For 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:

GEThttps://<YourExpeditionIP>/api/v1/uploadin 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.

{  "config": file with the configuration file. Normally named 'configuration.txt'}

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.

print('UPLOAD PANOS FILE')panosFile       = open(panosPath, 'rb')data  = {'zipId':zipID,'vendor':'paloalto', 'name':'panosConfig'}files = {'config':panosFile}r ='https://'+ip+'/api/v1/upload', files=files, data=data, verify=False, headers=hed)response=r.json()panosResource = json.dumps(response['Contents']['response']['data']['content']['expedition']['resources']['id'])print(panosResource+'\n')
print('UPLOAD CISCO FILE')ciscoFile       = open(ciscoPath, 'rb')data  = {'zipId':zipID,'vendor':'ciscoasa','name':'ciscoConfig'}files = {'config':ciscoFile}r ='https://'+ip+'/api/v1/upload', files=files, data=data, verify=False, headers=hed)response=r.json()ciscoResource = json.dumps(response['Contents']['response']['data']['content']['expedition']['resources']['id'])print(path+'\n')
print('UPLOAD FORTINET FILE')fortinetFile       = open(fortinetPath, 'rb')data  = {'zipId':zipID,'vendor':'fortinet','name':'fortinet'}files = {'config':fortinetFile}r ='https://'+ip+'/api/v1/upload', files=files, data=data, verify=False, headers=hed)response=r.json()fortiResource = json.dumps(response['Contents']['response']['data']['content']['expedition']['resources']['name'])print(path+'\n')

STEP 3: Declaring the migration Baseconfig file#

After 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.

GEThttps://<YourExpeditionIP>/api/v1/migration/defineBaseconfigin body
    zipId: zip resource identified,
    resource : resource identifier for the PANOS config


print('DEFINE BASECONFIG')data  = {'zipId':zipID, 'resource':panosResource}r ='https://'+ip+'/api/v1/migration/defineBaseconfig', files=files, data=data, verify=False, headers=hed)response=r.json()messages = json.dumps(response['Contents']['response']['response-messages']['messages'])print(messages+'\n')

STEP 3B: Declaring the migration Baseconfig version#

It 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);

GEThttps://<YourExpeditionIP>/api/v1/migration/defineBaseconfigin body
    zipId: zip resource identified,
    type : { 'panorama' | 'firewall' },
    version: panos version


print('DEFINE BASECONFIG')data  = {'zipId':zipID, 'type':'panorama', 'version':'10.0'}r ='https://'+ip+'/api/v1/convertion/defineBaseconfig', files=files, data=data, verify=False, headers=hed)response=r.json()messages = json.dumps(response['Contents']['response']['response-messages']['messages'])print(messages+'\n')

STEP 4: Creating the migration Zip file#

Once 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.

GEThttps://<YourExpeditionIP>/api/v1/migration/generateZipin body
{ zipId: zip resource identified }


print('CREATE ZIP')data  = {'zipId':zipID}r ='https://'+ip+'/api/v1/migration/generateZip', files=files, data=data, verify=False, headers=hed)response=r.json()zipResource = json.dumps(response['Contents']['response']['data']['content']['expedition']['resources']['id'])print('Zip with id '+zipResource+' is prepared for migration\n')

STEP 5: Requesting the migration#

The 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.

GEThttps://<YourExpeditionIP>/api/v1/migration/convertin body
    resource: zip resource identified


print('CONVERT')data  = {'resource':zipResource}r ='https://'+ip+'/api/v1/migration/convert', data=data, verify=False, headers=hed)response=r.json()jobId = json.dumps(response['Contents']['response']['data']['content']['system']['jobs']['jobId'])print(jobId+'\n')

STEP 6: Monitoring the migration task#

The 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

APPENDIX: Obtaining Third party vendor's configuration information#

To 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.

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 in body
{"vendor": "stonesoft",
"config": "/tmp/myMigrationFiles/cpProviders/exported_data.xml"}
example 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:
{  "firewalls": [      "ClusterSite1",      "ClusterSite2",      "Firewall1",      "Firewall2",      "Firewall3"    ],  "policies": [      "Provider1",      "Provider2",      "Provider3",      "Provider4"   ]}