> Source: [sk115416](https://support.checkpoint.com/results/sk/sk115416) # sk115416 - How to migrate a competitor's database to Check Point with SmartMove | Property | Value | |----------|-------| | Solution ID | sk115416 | | Date Created | 2017-01-09 | | Last Modified | 2026-03-31 | | Technical Level | General | | Products | Security Gateway, Security Management Server, Multi-Domain Security Management Server | | Versions | R81.20, R81.10 (EOS), R81.20, R81 (EOS), R81.10 (EOS), R81 (EOS), R81 (EOS), R81.10 (EOS), R81.20 | | OS | Gaia | ## Solution ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/SmartMove_banner.jpg) **Table of Contents:** 1. Introduction 2. Requirements 3. Downloads 4. Instructions for Migrating Configuration from 3rd party Vendors * Cisco/FirePower * Juniper * Fortinet * Palo Alto Networks 5. How to Complete the Migration 6. Appendix 7. Revision History Click Here to Show the Entire Article (1) Introduction {#Introduction} -------------------------------- > Moving to Check Point is a very "SmartMove". Check Point understands that migrating a security database is a security-level critical mission for your organization. The Check Point SmartMove Tool converts a 3rd party database with a firewall security policy and NAT to a Check Point database. > > The SmartMove Tool is automated for a smooth transition to Check Point with minimal disruptions. > > **Notes:** > > * Database migration to Check Point may result in errors, information loss, or policy discrepancies. You are responsible for reviewing the migrated policy to ensure it meets your specific requirements. Check Point is not liable for issues arising from the migration process. > > For any questions, contact [Check Point CheckMates](https://community.checkpoint.com/message/6476-re-smartmove-convert-cisco-asa-policy-to-check-point?commentID=6476). > > The SmartMove Tool is not expected to impact the Customer's 3rd party device in any way. The Customer acknowledges that he/she has the sole responsibility for adequate protection and backup of data used in connection with the SmartMove Tool and he/she will not make a claim against Check Point for lost data, re-run time, inaccurate output, work delays or lost profits resulting from the SmartMove Tool. (2) Requirements {#Requirements} -------------------------------- > |----------------------------------------------------------------|--------------------------------------------------------------------------------------------| > | Machine | Requirements | > | PC running the SmartMove tool | * Windows 7 and above * Microsoft .NET framework 4.5 and above * Administrative privileges | > | Check Point Management Server (Smart-1 Cloud is not supported) | * R80.10 and above | > | Check Point Security Gateway | * R80.10 and above | > > **Notes:** > > 1. Additional requirements for each specific vendor are listed in the "Instructions for Migrating Configuration from 3rd party Vendors" section (section 5) below. > 2. In these steps, "management server" is the Security Management Server or the Multi-Domain Server. After you complete these steps, review the results and complete the migration. > 3. Recommended to use SmatConnector and optimized policy (the `cp_objects_opt.json` file) > 4. To assure smooth conversion of your data, it is recommended to contact Check Point Professional Services. > 5. SmartMove does not support direct migration to Smart-1 Cloud. You can migrate to an on-premises Management Server and then connect it to Smart-1 Cloud. (3) Downloads {#Downloads} -------------------------- * [Click here](https://github.com/CheckPointSW/SmartMove) to see the open source repository. * [Click here](https://support.checkpoint.com/results/download/55183 "SmartMove Tool") to download the Check Point SmartMove Tool. * For any questions please contact [Check Point CheckMates](https://community.checkpoint.com/message/6476-re-smartmove-convert-cisco-asa-policy-to-check-point?commentID=6476). (4) Instructions for Migrating Configuration from 3rd party Vendors {#Instructions for vendors} ----------------------------------------------------------------------------------------------- Click on the relevant logo to see the instructions for a specific vendor: |----------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------| | ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/Cisco_logo.jpg "Click here to see migration instructions for Cisco") | ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/Juniper_logo.png "Click here to see migration instructions for Juniper") | ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk132112/fortinet1807250137.png "Click here to see migration instructions for Fortinet") | ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/palo1904210427.png "Click here to see migration instructions for Fortinet") | * ### (4-A) Instructions for migrating Cisco/FirePower configuration {#Instructions for vendors - Cisco} Show / Hide this section #### Supported Cisco Appliances: {#Toggle_migrating_Cisco} |----------------------|-----------------------| | Supported Appliances | Supported Software | | Cisco ASA /FirePower | Version 8.3 and above | #### Limitations for Cisco ASA/FirePower: |----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Cisco ACL outbound rules are not converted (user is alerted). | | The order of the Cisco object NAT rules is not fully preserved after the migration to Check Point's NAT policy. | | The configuration file name must contain fewer than 15 characters (used as a converted policy package name). | | DHCP and DAIP interfaces are not supported (see relevant pre/post migration tasks). | | Only Firewall and NAT policies are converted | | Check Point time and time group objects have name length limited to 11 characters. SmartMove will rename such objects (all renamed objects are recorded in a report) | | FirePower ASA only support | #### Cisco configuration migration: Before you run SmartMove, replace DHCP / DAIP interfaces with static IP addresses on your cisco Gateway. 1. Get the Cisco configuration file from the gateway. See vendor documentation for "*show configuration*" commands. 2. **SSH:** " -\> "terminal pager 0" -\>show running-config" **ASDM:** On the ASDM we need to drive to **Tools** \> **Backup Configurations** , select **running-configuration** , browse the folder where we would like to save the ASA configuration, click **Backup** and wait until you get the confirmation message. After this is done, we get a `*.zip` file with the ASA configuration. 3. Get the configuration file 4. Analyze the original configuration file. Make sure it is of the expected supported version. 5. Download SmartMove from Check Point's Download Center. 6. Extract the SmartMove archive file to a new folder on your desktop. 7. Run the executable: SmartMove.exe 8. Accept the End User License Agreement. 9. In the "Select the vendor for conversion" field, select the vendor. 10. In configuration file, select the configuration file to migrate. 11. In Target Folder, select the migration output path. 12. Check Convert NAT configuration if you want to convert the NAT rule base 13. (Optional) If you want optimize migration process, you have to check "Do not import unused objects" checkbox. During optimized migration SmartMove does not migrate (create) unused objects. 14. Click **Go**. 15. Refer to the next section. #### Reading the results of Cisco configuration migration: Once the configuration conversion completes, the Conversion Results will be displayed. where: * **Configuration File** This is the link to the original Cisco file in HTML format. If some lines caused conversion issues, these lines are marked with colors. All conversion issues are summarized at the bottom of the file. Explanation about lines marked with different colors: * **Parsed commands** - Commands that were parsed and converted from Cisco to Check Point without any issue. * **Skipped commands** - Commands that were parsed, but NOT converted from Cisco to Check Point, because they are irrelevant for Check Point configuration. * **Unknown commands** - Commands that are totally ignored from conversion process. They may be relevant and essential for conversion or require manual investigation, but currently are not recognized nor supported. * **Commands with conversion error** - Commands that caused a severe conversion incident and must be fixed to successfully complete the migration (for example: duplicated object names). * **Commands with conversion notification** - Commands that caused a conversion incident and were automatically remediated, or require further attention (for example: Cisco Inspect policy rules, interface anti-spoofing settings, invalid object name). * **Converted Policy Preview** These are the links to HTML reports that show the Check Point Rule Base. Make sure you read these reports before you import real data to a real Check Point Management Server. This section shows the following reports: * **Converted Policy** - Direct translation of policy rules from Cisco to Check Point. * **Converted optimized Policy** - Check Point rules are merged *when possible* to optimize the policy and make the Rule Base more readable. * **Converted NAT Policy** - Check Point NAT Rule Base.
{#Instructions for vendors - Cisco} * ### (4-B) Instructions for migrating Juniper configuration Show / Hide this section {#Instructions for vendors - Juniper} #### Supported Juniper Gateways: {#Toggle_migrating_Juniper} |-----------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------| | Supported Gateway | Supported OS | | [Juniper SRX Series](https://www.juniper.net/us/en/products-services/security/srx-series/) | Junos OS version 12.1 and above | | [Juniper SSG Series](https://www.juniper.net/documentation/en_US/release-independent/screenos/information-products/pathway-pages/ssg-series/product/index.html) | ScreenOS version 6.3 (R19B/R22) and above |
**These features are not supported**: |----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Juniper/Junos OS | | Junos OS IPv6 objects/rules are not converted (user is alerted) | | IPSec configuration is included in the policy and routed site-to-site (rules in policy will need to be fixed manually) | | Dynamic IP configuration on interface | | Firewall filter (access list) for Control-plane security (only Security Management zone is supported) | | Dynamic NAT with range addresses as destination (range will be converted to first IP address) | | Multiple addresses in NAT Pool (only the first address\\range\\subnet will be used) | | Multi routing instance configuration - only single routing instance is supported | | Check Point time and time group objects have name length limited to 11 characters. SmartMove will rename such objects (all renamed objects are recorded in a report) | | The configuration file name must contain fewer than 15 characters (used as a converted policy package name). | | Juniper/ScreenOS SSG | | l2/tunnel zones | | Wildcards, e.g objects with complex wildcards (0.255.0.255) will not be created | | ScreenOS IPv6 objects/rules are not converted (user is alerted) | | The order of the ScreenOS NAT rules is not fully preserved after the migration to Check Point's NAT policy | | Converted process supports only one Virtual Routing environment per conversion process | | Interface base NAT based on routing decision is not supported | | Multi-pool NAT | | Multiple Vsys converting, converting can be implemented per single Vsys section from config file | | The configuration file name must contain fewer than 15 characters (used as a converted policy package name). | | Check Point time and time group objects have name length limited to 11 characters. SmartMove will rename such objects (all renamed objects are recorded in a report) | #### Juniper configuration migration: 1. Get the Juniper configuration file from the gateway. See vendor documentation for "show configuration" commands. * From Junos OS: get the configuration file in **XML** format * Junos OS Firewall: SSH: `cli` `show configuration | display xml | no-more | save .xml` * From ScreenOS: get the configuration file in **CLI** format. * NetScreen Firewall: SSH: `get config all` 2. Copy the Juniper configuration file to your desktop. 3. Analyze the original Juniper configuration file. 4. Perform the pre-migration tasks: 1. Replace DHCP / DAIP interfaces with static IP addresses. 5. Analyze the original configuration file. Make sure it is of the expected supported version. 6. Download SmartMove from Check Point's Download Center. 7. Extract the SmartMove archive file to a new folder on your desktop. 8. Run the executable: SmartMove.exe 9. Accept the End User License Agreement. 10. In the "Select the vendor for conversion" field, select the vendor. 11. In configuration file, select the configuration file to migrate. 12. In Target Folder, select the migration output path. 13. Check Convert NAT configuration if you want to convert the NAT rule base 14. (Optional) If you want optimize migration process, you have to check "Do not import unused objects" checkbox. During optimized migration SmartMove does not migrate (create) unused objects. 15. Click **Go**. 16. Refer to the next section. #### Reading the results of Juniper configuration migration: Once the configuration conversion completes, the Conversion Results will be displayed. where: * **Configuration File** This is the link to the original Juniper configuration file in HTML format. If some lines caused conversion issues, these lines are marked with colors. All conversion issues are summarized at the bottom of the file. Explanation about lines marked with different colors: * **Parsed commands** - Commands that were parsed and converted from Juniper to Check Point without any issue. * **Commands with conversion error** - Commands that caused a severe conversion incident and must be fixed to successfully complete the migration (for example: duplicated object names). * **Commands with conversion notification** - Commands that caused a conversion incident and were automatically remediated, or require further attention. * **Converted Policy Preview** These are the links to HTML reports that show the Check Point Rule Base. Make sure you read these reports before you import real data to a real Check Point Management Server. This section shows the following reports: * **Converted Policy** - Direct translation of policy rules from Juniper to Check Point. * **Converted NAT Policy** - Check Point NAT Rule Base.
{#Instructions for vendors - Juniper} * ### (4-C) Instructions for migrating Fortinet configuration {#Fortinet} Show / Hide this section ### Supported Fortinet Gateways: {#Toggle_migrating_Fortinet} |---------------------------------------------------------------------|-----------------------| | Supported Gateway | Supported OS | | [FortiOS](https://www.fortinet.com/products/fortigate/fortios.html) | version 5.x and above | ### Limitations for FortiGate: |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **General** | | The configuration file name must contain fewer than 15 characters (used as a converted policy package name). | | SmartMove supports migration from FortiGate configuration files. The tool does not support migration from FortiManager configuration files. | | Only Firewall, NAT and Users/Groups configuration (AD) will be converted (including network objects, services, and schedules). | | FortiGate Central SNAT rules will not be converted. | | FortiGate Policy Routes will not be migrated, nor will they be taken into consideration during the creation of Check Point NAT rules. | | When FortiGate IPv4 Policy contains "ANY" in at least one Source Interface or Destination Interface, or in both (the FortiGate policy is in Global View mode), the migrated Check Point Policy will preserve the same rule order, and the rules will not be part of a Sublayer policy. This might require hardening the policy manually and placing the rules in sublayers. | | **Objects** | | SmartMove does not convert FortiGate IPv6 objects. | | SmartMove does not convert Internet service objects, nor does it create rules with these objects. | | SmartMove does not convert Geo objects, nor does it create rules with these objects. | | One FortiGate service may point to both UDP and TCP services simultaneously. The conversion process splits them in order to separate TCP and UDP services in Check Point. | | SmartMove tries to preserve the original names of objects, but this is not always possible in the following situations: 1. The FortiGate object name contains symbols not allowed by or reserved for use by Check Point. SmartMove will rename such objects (all renamed objects are recorded in a report). 2. FortiGate object names are case-insensitive, but Check Point names are case-sensitive duplicated. When this happens, SmartMove will rename the objects (all rename objects are recorded in a report). 3. The FortiGate object name conflicts with Check Point predefined object, but not completely the same object. SmartMove will rename such objects (all renamed objects are recorded in a report). 4. FortiGate VIP object contains several addresses. SmartMove creates two objects for every VIP object: _extip (points to extip value for the original VIP object) and _mappedip (points to the mapped value for original VIP object). All rename objects are recorded in a report). 5. Check Point time and time group objects have name length limited to 11 characters. SmartMove will rename such objects (all renamed objects are recorded in a report) | | During the object creation process, converted objects are not created when they conflict with an existing object in the Check Point database. Errors are reported by corresponding scripts. Refer to the "Troubleshooting" and "Known Errors" sections below for more details. | | During object group creation process, converted groups are not created when the object used inside the created rule is ambiguous. For example, this would happen if you specified an object name in a group that pointed to several objects of different types with the same name. Errors are reported by corresponding scripts. Refer to the "Troubleshooting" and "Known Errors" sections below for more details. | | SmartMove creates a Check Point zone object for every FortiGate interface and FortiGate zone object. SmartMove uses the following convention for zone names: for interfaces, SmartMove concatenates the interface alias name with the interface name (separating them with an underscore character); for zones, SmartMove uses the original zone names. | | **NAT Rules** | | NAT rules are not created when VIP objects are used in the source address. | | The order of FortiGate NAT rules is not fully preserved after the migration to Check Point's NAT policy. | | NAT rules are created only for UDP/TCP services or groups of UDP/TCP services. | | NAT rules are not created for FQDN objects, | | NAT rules are not created when a zone is used in a source or destination interface because SmartMove cannot find automatically which interface (address) is used for NAT purposes. | | **Users** | | SmartMove cannot create LDAP account unit objects that are needed for the user configuration process. You will need to create this object manually and provide the name of this object to SmartMove for conversion. | | **Firewall Rules** | | During the creation process, converted rules are not created if the object use inside the created rule is ambiguous. For example, if you specify an object name in a rule that points to several objects of different types with the same name. Errors are reported in the corresponding scripts. For more details, refer to the "Troubleshooting" and "Known Errors" sections below. | ### FortiGate configuration migration: **Before Running SmartMove:** 1. Export the configuration file from FortiGate. To do this, get the ForitGate configuration file from the Gateway. The recommended procedure is to use the backup configuration file, which can be downloaded using the menu on the bottom right (see image below) with user name (like admin), then Configuration, then Backup. 2. Specify scope of the configuration to export: **Global** (export configuration for all domains) or **VDOM** (for one specific domain). **In UI:** \* Do not encrypt the configuration file (step #6) **In SSH:** `show full-configuration` 3. Click **OK** and specify the folder in which to store the FortiGate configuration file.
![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk132112/fortigate%2011807180146.png) **How to run SmartMove:** 1. Get the FortiGate configuration file (see instructions above in section "Before running SmartMove". 2. Analyze the original configuration file. Make sure it is of the expected supported version. 3. Download SmartMove from Check Point's Download Center. 4. Extract the SmartMove archive file to a new folder on your desktop. 5. Run the executable: SmartMove.exe 6. Accept the End User License Agreement. 7. In the "Select the vendor for conversion" field, select the vendor. 8. In configuration file, select the configuration file to migrate. 9. In Target Folder, select the migration output path. 10. Check Convert NAT configuration if you want to convert the NAT rule base 11. (Optional) If you want optimize migration process, you have to check "Do not import unused objects" checkbox. During optimized migration SmartMove does not migrate (create) unused objects. 12. (Optional) To migrate user configuration parameters, you have to check the "Convert user configuration" checkbox. It is mandatory to specify the LDAP Account unit in the "LDAP Account Unit" textbox. The LDAP account unit has to be created in advance 13. Click **Go**. 14. Refer to the next section. #### Reading migration results: When you run SmartMove, the window shows **conversion results**: ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk132112/fortigate%2031807180151.png) * **Configuration File**: Link to the original FortiGate file. * **Conversion Warnings**: Link to HTML conversion report that contains warning messages generated by SmartMove during the configuration of the file conversation: For example, messages when SmartMove renames objects during conversation. For FortiGate configurations with virtual domains (VDOMs), this link points to an HTML report from which you can choose a report for a specific domain. * **Conversion Errors**: Link to HTML conversion report that contains error messages generated by SmartMove during the configuration of the file conversation: For example, messages when SmartMove cannot convert objects. For FortiGate configurations with virtual domains (VDOMs), this link points to an HTML report from which you can choose a report for a specific domain. * **Converted Policy Preview**: HTML report that shows the Check Point Rule Base. Make sure you read this report before you import real data to a real Check Point server. This report shows direct translation, optimized rule base, and converted NAT policy. * **Converted Policy**: Direct translation of policy rules from FortiGate to Check Point. * **Converted NAT Policy**: Check Point's NAT Rule Base. * ### (4-D) Instructions for migrating Palo Alto Networks (PAN) configuration {#PAN} Show / Hide this section ### Supported Palo Alto Network Gateways {#Toggle_PAN} |----------------------------------------------------------|-----------------------| | Supported Gateway | Supported OS | | [Palo Alto OS](https://docs.paloaltonetworks.com/pan-os) | Version 7.x and above |
### Limitations for Palo Alto Networks |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **General** | | The configuration file name must contain fewer than 15 characters (used as a converted policy package name). | | Only Objects, Firewall, NAT, and Application configurations are converted. | | Every object created (converted) by the SmartMove tool has the "PaloAlto" tag. | | **Objects** | | PAN nptv6 not converted. | | During conversion, SmartMove tries to preserve original names for objects, but in some situations this is not possible. Consider the following situations: 1. The PAN object name contains symbols not allowed by or reserved for use by Check Point. SmartMove will rename such objects (all renamed objects are recorded in a report). 2. PAN object names are case-insensitive, but Check Point names are case-sensitive duplicated. SmartMove will rename such objects (all renamed objects are recorded in a report). 3. The PAN object name conflicts with a Check Point predefined object, but is not exactly the same object. SmartMove will rename such objects (all renamed objects are recorded in a report). | | Check Point time- and time-group objects have a name length limited to 11 characters. SmartMove will rename such objects (all renamed objects are recorded in a report). | | During the object creation process, converted objects are not created when they conflict with an existing object in the Check Point database. Such objects are not created, and the errors are reported by corresponding scripts. For more details, refer to the "Troubleshooting" and "Known Errors" sections below. | | During the creation of object groups, converted groups are not created when the object's use in the created rule is ambiguous: for example, when you specify an object name in a group that could point to several objects of different types with the same name. Errors are reported by corresponding scripts. Refer to the "Troubleshooting" and "Known Errors" sections below for more details. | | **Firewall Rules** | | A PAN firewall rule base that does not contain 'ANY' in the source/destination zone will be converted to a Check Point Layer-based policy. | | A PAN firewall rule base that contains 'ANY' in the source/destination zone will be converted to a flat policy. | | **Services** | | To comply with Check Point's service name restrictions, SmartMove adds service types and underscores to PAN service names that begin with numbers. | | **Applications** | | The following objects are converted: Applications and Application Groups. | | Applications are converted with a special mapping file (**PA_Apps_CP.csv** ) packaged with SmartMove distribution. The tool maps PAN applications to Check Point applications. When mapping is not found, SmarMove generates a warning in a report. The mapping file contains three columns: 1. **palo_app**: The PAN application to be converted 2. **cp_app**: The Check Point application to be mapped to the corresponding PAN application. 3. **cp_service**: The Check Point service used to map the corresponding PAN application when no suitable Check Point application can be used. This file can be adjusted manually to map custom applications, to map unknown applications, or to adjust mapping according to your needs. Use a semicolon (;) as a separator for fields. | | Application Filters will not be converted. | | Application Groups converted by SmartMove will contain only applications that have corresponding mapping. | | **Applications \& Services** | | On a PAN firewall rule that contains both applications and services, only the applications will be imported with their Check Point default application ports. | | **Users** | | Only Active Directory Users/Groups will be converted. | | When users exist in a PAN firewall rule, a Check Point access rule will be created that would contain the users/groups \& source address objects. | | **URL Categories in PAN Firewall Rules** | | URL Categories in PAN firewall rules are not converted. | | A message with the relevant rules and URL categories will be logged in the warning file ('config_file_name_warnings.html) after you run SmartMove. | | **NAT Rules** | | The order of the PAN NAT rules is not fully preserved after the migration to Check Point's NAT policy. | | NAT rules are created only for UDP/TCP services or groups of UDP/TCP services. | | NAT rules are not created for groups with mixed TCP/UDP services. | | NAT rules are not created for FQDN objects. | | **Panorama** | | Device Group Hierarchy - only one level of device group hierarchy is imported | | Local firewall rules are not import | ### Before Running SmartMove 1. Enable **Application \& URL Filtering** in a policy (it does not need to be in use, but must be enabled so that management is aware of application control objects). ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/1pan1904210531.bmp) 2. Make sure the application control database is up-to-date. ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/2pan1904210532.bmp) ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/3pan1904210532.bmp) 3. Export the configuration file from the PAN appliance. ### To export a PAN standalone configuration file 1. Get the PAN configuration file from the Security Gateway. The recommended procedure is to use the export configuration file that can be downloaded using the following menu path: 2. **PAN-OS:** In UI: Refer to Step 2 "Export configuration version". 3. **Panorama:** In UI: Refer to Step 2 "Export Panorama and devices config bundle". ### How to run SmartMove 1. Get the PAN configuration file (see the instructions above in the "Before you run SmartMove" section). 2. Analyze the original configuration file. Make sure it is of the expected supported version. 3. Download SmartMove from Check Point's Download Center. 4. Extract the SmartMove archive file to a new folder on your desktop. 5. Run the executable: SmartMove.exe 6. Accept the End User License Agreement. 7. In the "Select the vendor for conversion" field, select the vendor. 8. In configuration file, select the configuration file to migrate. 9. In Target Folder, select the migration output path. 10. Check Convert NAT configuration if you want to convert the NAT rule base 11. (Optional) If you want optimize migration process, you have to check "Do not import unused objects" checkbox. During optimized migration SmartMove does not migrate (create) unused objects. 12. (Optional) To migrate user configuration parameters, you have to check the "Convert user configuration" checkbox. It is mandatory to specify the LDAP Account unit in the "LDAP Account Unit" textbox. The LDAP account unit has to be created in advance 13. Click **Go**. 14. Refer to the next section. ### Reading the migration results ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk115416/6pan1904210541.bmp) * **Configuration File -\> Original File** - Link to the original PAN file. * **Conversion Warnings** - Link to an HTML conversion report that contains warning messages generated by SmartMove during configuration file conversation: for example, messages when SmartMove renames objects during conversion. For PAN configurations with virtual systems (vsys), this link points to an HTML report from which you can choose a report for a specific domain. * **Conversion Errors** - Link to an HTML conversion report that contains error messages generated by SmartMove during the configuration file conversation: for example, messages when SmartMove cannot convert objects. For PAN configurations with virtual systems (vsys), this link points to an HTML report from which you can choose a report for a specific virtual system. * **Converted Policy Preview** - An HTML report that shows the Check Point Rule Base. Make sure you read this before you import real data to a real Check Point server. This report shows the following: direct translation, optimized rule base, and converted NAT policy. * **Converted Policy** - Direct translation of policy rules from PAN to Check Point. * **Converted NAT Policy** - Check Point NAT Rule Base.
**Known errors when completing the migration from Palo Alto Networks** |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **You might see the following script processing errors when you import PAN objects with bash scripts:** | | `/bin/sh^M: bad interpreter: No such file or directory.` Convert your script files with the dos2unix command to change from DOS to Unix line endings. | | `mgmt_cli add <....> code: "err_validation_failed"message: "Validation failed with 1 error"errors:- message: "More than one object named '' exists."` This error indicates that the script is trying to create an object with an object name that already exists in the Check Point database. Currently, there is no possibility for SmartMove to process such errors. You will need to recreate such objects manually. | | `mgmt_cli add <..> code: "generic_err_object_field_not_unique"message: "Requested object name [] is not unique."` This error indicates that script is trying to create an object group with an object name that is ambiguous for Check Point. For example, the script tries to create a group with an object name pointing to several objects with the same name but of different types. Currently, there is no possibility for SmartMove to specify the type of object more specifically. You will need to recreate this object group manually. | | `mgmt_cli add access-rule <...> code: "generic_err_object_field_not_unique" message: "Requested object name [] is not unique."` This error indicates that script is trying to create a rule with an object name that is ambiguous for Check Point. For example, the script tries to create a rule with VNC in the service field, but Check Point has VNC both as a service and as an application. Currently, there is no possibility for SmartMove to specify the type of object more specifically because of API limitation. You should recreate this rule manually. | (5) How to Complete the Migration {#How to Complete the Migration} ------------------------------------------------------------------ Show / Hide this section Everyone can run the SmartMove Tool, **but make sure the next steps are performed by an experienced security or system administrator.** **To complete migration:** 1. Review the output for issues, policy reports and ensure not issues. 2. if there are issues, fix it and run the utility again. 3. Connect to the command line on the Check Point Management Server. 4. Login to Expert mode. 5. Unset the TMOUT environment variable (`unset TMOUT`) 6. Confirm Gaia Default port is 443. To check the port number of Gaia run the command (`api status`). In case the API Gaia port is different than port 443 (for example 4434), run the following command: `export MGMT_CLI_PORT=4434`. 7. Copy the `smartconnect_.tar.gz` file 8. Unpack the archive package on the Security Management server (or any other server if you want to run it remotely). Use the '`tar zxvf smartconnect_.tar.gz`' command. 9. Make the *smartconnect.py* file executable in the Linux/Gaia environment. Use the '`chmod a+x smartconnector.py`' command. Run the smartconnector.py command to start the migration process (All parameters and command examples are specified in Appendix A below). 10. Log in to SmartConsole. 11. Perform the post-migration tasks: 1. Configure the Zones in the relevant interfaces. 2. Configure Anti-Spoofing settings. 3. Configure DHCP/DAIP interfaces back to the correct settings. 4. Configure DHCP services according to [sk104114](https://support.checkpoint.com/results/sk/sk104114). 5. Fix time-range objects referenced by converted rules. 12. Make sure the imported configuration is correct for your environment. 13. Install policy. 14. Monitor the Security Gateway. Make sure it behaves in the same way as the original converted Gateway ### Troubleshooting {#Toggle_Complete_the_Migration} For every converted rule, SmartMove adds information about the original rule identifier. You can view it in the SmartConsole GUI in rule details ("Additional Rule Info" field). For every converted NAT rule, SmartMove adds information about the original rule identifier. You can view it in the SmartConsole GUI in the NAT rule comments field. **Notes** |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | When several object candidates exist for replacing imported objects, the scripts use the following selection priority rules: 1. Depending on parameter value '`--replace-from-global-first`', Global or Local domain objects receive higher priority. 2. For services, services without protocol value defined, get more priority as more general services. 3. When replacement objects have the same priority, first found is used. | | Since python scripts use Check Point Management API if you run the import remotely, make sure you have changed the Management API settings for addresses allowed to use API remotely (by default, API queries are allowed only from address 127.0.0.1). The current status can be checked with the 'api status' command. | | Since python scripts are implemented using python script language, make sure the python engine path is configured in the **PATH** environment variable. It is configured by default in versions R80.20 and above. In version R80.10, you must manually add the folder containing the python engine to the **PATH** environment variable. | | During the import process, the script creates log file `smartconnector.log` with all processing information that could be used to track or debug script activities. | (6) Appendix {#Appendix} ------------------------ Show / Hide this section > **Added support to run SmartMove from the CLI** > > Usage: > > `SmartMove.exe [-s config_file_name] [-v vendor] [-t target_folder] [-d domain] [-n] [-l LDAP_Account_unit] [-k]` > > Mandatory flags: > > |-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------| > | Flag | Description | > | `-s ""` `--source ""` | Full path to the vendor configuration file | > | `-v ` `--vendor ` | Vendor for conversion. Supported options: * `CiscoASA` * `FirePower` * `JuniperSRX` * `JuniperSSG` * `FortiNet` * `PaloAlto` * `Panorama` | > > Optional flags: > > |----------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | Flag | Description | > | `-t ""` `--target ""` | Migration output folder. | > | `-d` `--domain` | Only for CiscoASA, FirePower, JuniperSRX, and JuniperSSG. Domain name. | > | `-n {true | false}` `--nat {true | false}` | Convert NAT configuration. Enabled by default. | > | `-l` `--ldap` | Only for FortiNet, PaloAlto, and Panorama. LDAP Account unit for convert user configuration option. | > | `-k {true | false}` `--skip {true | false}` | Only for FortiNet, PaloAlto, and Panorama. Do not import unused objects. Enabled by default. | > | `-f {JSON | TEXT}` `--format {JSON | TEXT}` | Format of the output file. Default: `JSON`. | > | `--asa-spread-acl-remarks {true | false}` | Only for Cisco. This allows the import of comments in a Cisco configuration to be applied to multiple access control entries. Without this flag, Smartmove would only apply the comment to the first imported rule. This creates a situation where all rules have comments stating which change control request was used to make the policy change. | > | `-i {true | false}` `--interactive {true | false}` | Interactive mode provides a better user experience. Enabled by default. | > > Example: > > `SmartMove.exe -s "D:\SmartMove\Content\config.txt" -v CiscoASA - t "D:\SmartMove\Content" -n true -k false -f json` > > **Note: This section is relevant to migrations with Python only.** > NOTE: SmartConnector runs according to `https://github.com/CheckPointSW/cp_mgmt_api_python_sdk` > **User MUST add the library.** > > The following parameters are accepted by the *smartconnector.py* script: > > |-----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------| > | Flag | Description | > | `-h` `--help` | Show this help message and exit. | > | `-r` `--root` | Mandatory. For a logged in administrator that wants to receive SuperUser permissions. Additional login credentials are not required. | > | `-u ` `--user ` | Mandatory. User name. | > | `-m ` `--management ` | Management server IP address or name. Default: 127.0.0.1 | > | `--port ` | Management server port. Default: 443 | > | `-p ` `--password ` | User password. | > | `-f ` `--file ` | File with Check Point objects and rules (in the JSON format) used for import. Default: `cp_objects.json` | > | `-t ` `--threshold ` | Parameter specifies maximum number of Check Point objects/rules to add before starting publish operation. Default: 100 | > | `-d ` `--domain ` | The name/uid of the Domain you want to log into on an MDS server. | > | `--replace-from-global-first {true | false}` | The argument indicates that SmartConnector should use 'Global' objects at first. By default, it uses 'Local' objects. Default: `false` | > | `-k ` `--key ` | API key. Example: `python smartconnector.py -k -f cp_objects.json -m 1.1.1.1` | > | `-c ` `--context ` | Context. Default context: `web_api` Example: `python smartconnector.py -c 4111926a-297c-41c5-8ed2-cf3ff9b37984/web_api` | > > You should always specify "`-u`" or "`-r`" parameter. Use of one of these parameters is mandatory. > > **Command examples:** > > **Example 1:** `smartconnector.py -r` > > This command starts the import against the local management server (127.0.0.1) with a trusted root connection. The import file used is*cp_objects.json*. Running as root must be executed on the target Security Management. > > **Example 2:** `smartconnector.py -r -d domain1` > > This command starts the import in an MDM environment against the local MDS server (127.0.0.1) with a trusted root connection, and imports the object and rules to domain1. The import file used is *cp_objects.json*. > > **Example 3:** `smartconnector.py -u fwadmin -p mypass -m 10.0.0.1` > > This command starts the import against the Security Management server with IP address 10.0.0.1 using the following admin credentials: specified username, "fwadmin", and password "mypass". The import file used is *cp_objects.json*. (7) Revision History {#Revision History} ---------------------------------------- Show / Hide this section |-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Date | Description | | 06 Oct 2024 | * Added the note that SmartMove does not support direct migration to Smart-1 Cloud | | 03 Sep 2024 | * Improved HTML formatting | | 26 Oct 2022 | * Added new logic to optimize policy by comments for Cisco and Firepower. Optimizes the security policy rulebase by merging several rules from the same sub-policy into a single rule. Two rules can be merged into one rule if: * CiscoASA and FirePower vendors: both rules can be merged if they have the same comments. * both rules have the same action, and * both rules are enabled or disabled, and * both rules have source and destination columns negated or not, and * both rules have the same time objects, and * either one of the following is true: * both the source and destination columns match * both the source and service columns match * both the destination and service columns match * Added a new command line to optimize by comment: -obc \| --optimize-by-comments. * Added slicing of conversion comments (custom-fields.field-1) up to 250 characters. * Fixed juniper crash. * Added an option to smartconnector to re-use groups by name, flag name: reuse-group-name true\|false \[default\]. * JuniperSRX: parsing groups tag. | | 01 Sep 2022 | * Updated deprecated NuGet: System.Windows.Interactivity.WPF to Microsoft.Xaml.Behaviors.Wpf * Updated SmartConnector to use SDK: follow * Fixed Cisco network objects with class 32, converted to Check Point host * Cisco allows to use (.) * PAN-OS: fix the bug with infinite recursion * Cisco fix: add an error message for topology errors * Cisco Optimized NAT - Multithreading * Update Check Point Logos **NOTE** : SmartConnector runs according to Users **MUST** add the library | | 13 July 2022 | * Enhance converting handling for large files * Enhance parsing time * Change Check Point logo * Change the SmartMove version to version v9.X * Juniper: Enhance parsing version * SmartAnalyze Fortinet: fix `.conf` file extension * Change filename length to 15 instead of 20 * SmartAnalyze added for Cisco and Firepower new file extensions: `.cfg` and `.txt` (same, same as SmartMove) * Fortinet fix bug with creating config files * Cisco ASA: fixed issue with `cisco_object` * Fortinet: changing the logic for creating zones (VDOM mode) * Fixed a bug with parsing the panorama file * Cisco ASA: allowing special characters to be used as part of `nameif` * Enabled by default creation of service group * Fortinet fixe different errors with config parsing * Juniper Juno-OS add fixed rules with "any" * Fortinet add support for access roles (convert user configuration) for VDOM mode | | 08 June 2022 | * Improved this article | | 07 June 2022 | * PAN: prevent crash in case use tap interface * Improved this article | | 11 May 2022 | * SmartAnalyze support for all vendors | | 10 Apr 2022 | * Merge comments for optimized policy: Fortinet, PaloAlto, Juniper * Disable by default creation of service groups * Remove non-English chars * Hide from message window debug information * Fix for skip creating services * Fix filtering of files for Fortinet * Merge changes for SmartAnalyze: Cisco (ASA, FirePower) * Merge bugfixes for SmartAnalyze: issue with unused rules calculations | | 09 Feb 2022 | * SmartAnalyze for Cisco ASA | | 02 Feb 2022 | * UI and UX updates * Changed fonts of labels * Changed icon for error window * Changes for displaying links to files - if they don't exist will be hidden * Changed Cisco and Fortinet warnings and errors, break into two sections instead of one * Added Domain option for Cisco and Fortinet - only used for Shell scripts | | 18 Jan 2022 | * Added user-agent parameter for SmartConnector * Juniper ScreenOS Fixed an issue if the list of services contains service "any" remove rest statuses in this list except it * Juniper ScreenOS can get a service and any at the same time, in Check Point we will use any * Shell script leaks: Bugfixes for empty enable list and hiding non-existed report files links * Update config files formats for FirePower and Fortigate * Fixed window and mouse behavior when exception thrown | | 29 Dec 2021 | * Added skip unused objects option to firepower vendor * Added optimized policy for firepower vendor | | 23 Dec 2021 | * Added skip unused objects option to Junos OS vendor * Added skip unused objects option for ScreenOS vendor | | 16 Dec 2021 | * Added optimization to Junos OS vendor * Added command line support for smart analyze | | 14 Dec 2021 | * Added optimization for Juniper SRX * Updated `cp_mgmt_api_python_sdk` | | 08 Dec 2021 | * PAN IPv6 support * PAN optimized policy * BugFix: Network Object mapping IPv4,IPv6 * SmartAnalyze: Fortinet is only supported | | 25 October 2021 | * Updated `cp_mgmt_api_python_sdk` * **Domain objects that already exist are imported with '_1' suffix** * Domain objects 'Name' is the fqdn that is meaningful for dns etc. * Changed to forcibly not rename and skip any domains that already exist This means any rules with the FQDN will use the already existing object * **GroupWithExclusion does not have any \['Members'\]** * The GroupWithExclusion has an \['Include'\] and \['Except'\] but no \['Members'\] * Added a check for when the code reached the processGroupWithMembers function to skip it if it is a GroupWithExclusion * **'any' not accepted as an object for rules** * On multiple occasions, get 'WARN: Requested object \[any\] not found' * Fixed the replace od all instances of "any" with "Any" in the cp_objects.json file * The change changes the default any object from "any" to "Any" | | 19 October 2021 | * Updated deprecated words for naming - according to [sk40179](https://support.checkpoint.com/results/sk/sk40179) * FortiGate: * Fixes for comparing types of objects * Fixed incorrect work of option "Do not import unused objects" * SmartConnector: * Fix for using existing time groups and objects * Added auto-renaming for objects with invalid names * Map network object to correct one found in checkpoint database | | 19 September 2021 | * Cisco FirePower support - ASA syntax support * Cisco optimized comments rules optimization support - clarify which rules optimized and add it into comments * ScreenOS parser removing incorrect values from an array * Cisco flag "`--asa-spread-acl-remarks`" works via the commands line instead of UI | | 06 July 2021 | * SmartConnector: added the flag "`-c`" / "`--context`" for context support (by default context is "web_api") Usage example: *python smartconnector.py -c 4111926a-297c-41c5-8ed2-cf3ff9b37984/web_api* | | 30 June 2021 | * Updated the cp_mgmt_api_python_sdk * SmartConnector : added the flag "`-k`"/ "`--key`" for login by API key. Usage example: *python smartconnector.py -k api_key -f cp_objects.json -m 1.1.1.1* | | 16 June 2021 | * Added support to run SmartMove in the CLI | | 25 May 2021 | * Cisco IPv6 support * SmartConnector * Improve detection of sub-layers name duplications * Improve group members list handling * Improve networks with subnet-mask (IPv4 \& IPv6) * Added support for Cisco Global rules support as shared sub-policy * Validate max packages number for processing according to [sk154435](https://support.checkpoint.com/results/sk/sk154435) (Error code: 2000232) | | 30 Dec 2020 | * Juniper time object support | | 20 Dec 2020 | * Panorama support: * Accepts only tgz * Support policy per: DeviceGroup \& Individual device * Do not support Local device rules: * SmartConnector supported added * Fixes for PAN-OS \& Panorama: * Changes regarding DNS_UDP/DNS_TCP * Add support for FQDN to be inside network groups * NAT rules were not properly created for some specific conditions * Fixed object names (sometimes object names contain postfix "_" when it doesn't need) * Added logic to remove duplicate "drop all" rules and disable "allow all" rules * Changes to allow Check Point applications with one dash like "Desknet's" * Split application and service groups (don't add service to application groups) * Remove the mapping for application ghostsurt | | 09 Dec 2020 | * Added Cisco Global rules support as shared sub-policy (supported only with Option 1 - Bash Scripts) * Enhancement of Cisco NAT rules - validation of NAT duplication scenario | | 07 May 2020 | * Added SmartConnector support for ALL vendors | | 19 May 2019 | * Added Palo Alto Networks (PAN) configuration | | 22 Aug 2018 | * Added Fortinet migration configuration | | 01 Nov 2017 | * Improved design of this article * Added "Table of Contents" * Added instructions for migrating Juniper configuration * Added "Revision History" section | | 22 Oct 2017 | * Added requirements for Security Gateway - R80.10 and above | | 02 Aug 2017 | * Added link to contact Check Point Check Mates forum for any questions | | 30 Jul 2017 | * Added link to YouTube video | | 10 Jun 2017 | * Improved text in "Limitations" section * Improved all instructions | | 04 Jun 2017 | * Updated the requirement for Microsoft .NET framework - version 4.5 and above * Added requirement for administrative privileges on PC to run SmartMove tool * Improved description of the Conversion Results screen | | 29 May 2017 | * Improved description of the Conversion Results screen | | 25 May 2017 | * Added requirement for Microsoft .NET framework version 4.5 on PC to run SmartMove tool | | 25 May 2017 | * Improved all instructions | | 18 May 2017 | * First public release of this article | --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content