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

info

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.

Method	EndPoint	Parameters
GET	https://<YourExpeditionIP>/api/v1/prepare/zip
Example	https://10.0.0.1/api/v1/prepare/zip

Example:

Python

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')

Php

//TODO

Go

echo "PREPARE NEW MIGRATION ZIP\n";

$url = 'https://'.$ip.'/api/v1/preoare/zip';

$curl = curl_init($url);

curl_setopt($curl, CURLOPT_HTTPHEADER, $hed);

curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);

curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

curl_setopt($curl, CURLOPT_HEADER, 0);

$response = curl_exec($curl);

$zipID = $response->Contents->response->data->content->expedition->resource->zipId

echo "$zipID.\n";

curl_close($curl);

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:

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

{

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

}

Cisco Switch

{

//TODO

}

Cisco ISR

{

//TODO

}

Checkpoint <R80

{

"objects": <objects file. Normally named 'Objects_5.C'>,

"policy": <policy file. Normally named 'PolicyName.W'>,

"rulebase": <rulebase file. Normally named 'rulebase_5_0.fws'>,

"routes": <routes file.>,

}

Checkpoint R80+

{

"config": <>

}

Fortinet

{

"config": file with the configuration file.'

}

Netscreen

{

"config": file with the configuration file.'

}

PFSense

{

//TODO

}

Sidewinder

{

//TODO

}

Sophos

{

//TODO

}

Sonicwall

{

"config": file with the configuration file.'

}

SRX

{

"config": file with the configuration file.'

}

Stonesoft

{

"config": <file with the configuration. Normally named 'exported_data.xml'>

}

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

print('UPLOAD PANOS FILE')

panosFile = open(panosPath, 'rb')

data = {'zipId':zipID,'vendor':'paloalto', 'name':'panosConfig'}

files = {'config':panosFile}

r = requests.post('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 = requests.post('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 = requests.post('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')

Php

//TODO

Go

//TODO

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.

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

print('DEFINE BASECONFIG')

data = {'zipId':zipID, 'resource':panosResource}

r = requests.post('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')

Php

//TODO

Go

//TODO

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

Method	EndPoint	Parameters
GET	https://<YourExpeditionIP>/api/v1/migration/defineBaseconfig	in body {     zipId: zip resource identified,     type : { 'panorama' | 'firewall' },     version: panos version }

Example:

Python

print('DEFINE BASECONFIG')

data = {'zipId':zipID, 'type':'panorama', 'version':'10.0'}

r = requests.post('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')

Php

//TODO

Go

//TODO

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.

Method	EndPoint	Parameters
GET	https://<YourExpeditionIP>/api/v1/migration/generateZip	in body { zipId: zip resource identified }

Example:

Python

print('CREATE ZIP')

data = {'zipId':zipID}

r = requests.post('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')

Php

//TODO

Go

//TODO

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.

Method	EndPoint	Parameters
GET	https://<YourExpeditionIP>/api/v1/migration/convert	in body {     resource: zip resource identified }

Example:

Python

print('CONVERT')

data = {'resource':zipResource}

r = requests.post('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')

Php

//TODO

Go

//TODO

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
Contents->response->data->content->expedition->resources->id.

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.

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

{

"firewalls": [

"ClusterSite1",

"ClusterSite2",

"Firewall1",

"Firewall2",

"Firewall3"

],

"policies": [

"Provider1",

"Provider2",

"Provider3",

"Provider4"

]

}

Checkpoint <R80

{

"policies": [

"policy1",

"policy2"

]

}

Checkpoint R80+

{

"policies": [

"policy1",

"policy2"

]

}

```