Skip to main content

Migration Zip file

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.

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.

.+-- config.xml+-- mapping.json+-- _cpBranches|   +-- objects.C|   +-- ospf_dump.txt|   +-- policy.W|   +-- routes.txt|   +-- rulebases_5_0.fws+-- _cpInterent|   +-- config.txt|   +-- routes.txt+-- _cpProvides|   +-- exported_data.xml

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": "config.xml",      "type": "panorama",      "version": "10.0"     },  "configs":    [{        "name": "Branches",        "vendor": "cp",        "routes": "cpBranches/routes.txt",        "dynamicRoutes": "cpBranches/ospf_dump.txt",        "objects": "cpBranches/objects.C",        "policy": "cpBranches/policy.W",        "rulebase": "cpBranches/rulebases_5_0.fws"     },{        "name": "Internet-Access",        "vendor": "ciscoasa",        "routes": "cpInternet/routes.txt",        "objects":"cpInternet/config.txt"     },{        "name": "Providers",        "vendor": "stonesoft",        "config": "cpProviders/exported_data.xml",        "mapping":            [{"firewall": "ClusterSite1", "policy": "Provider1"},             {"firewall": "ClusterSite2", "policy": "Provider2"}],        "replacements":{          "comment": "not available yet",          "networks":            [              {"from": "10.0.0.0/24", "to": "10.0.23.0/24"},              {"from": "192.168.0.0/24", "to": "192.168.23.0/24"}            ],          "interfaces":            [              {"from": "CVI-4.321-10.0.0.1", "to": "ethernet1/7"}            ]             }    }]}
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

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.

MethodURLParameters
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:
{  "firewalls": [      "ClusterSite1",      "ClusterSite2",      "Firewall1",      "Firewall2",      "Firewall3"    ],  "policies": [      "Provider1",      "Provider2",      "Provider3",      "Provider4"   ]}
```