Support Center > Search Results > SecureKnowledge Details
How to migrate a competitor's database to Check Point with SmartMove
Solution

 

Table of Contents:

  1. Introduction
  2. Requirements
  3. Downloads
  4. Demonstration - How to Run the SmartMove Tool
  5. Instructions for Migrating Configuration from 3rd party Vendors
    • Cisco
    • Juniper
    • Fortinet
    • Palo Alto Networks
  6. How to Complete the Migration
  7. Appendix
  8. Disclaimer
  9. Revision History

 

Click Here to Show the Entire Article

 

(1) 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.

Note: For any questions please contact Check Point CheckMates.

Note: Refer to the Third-Party Software Disclaimer

 

(2) 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
  • 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) Downloads

 

(4) Demonstration - How to Run the SmartMove Tool

 

(5) Instructions for Migrating Configuration from 3rd party Vendors

Click on the relevant logo to see the instructions for a specific vendor:

  • (5-A) Instructions for migrating Cisco configuration

    Show / Hide this section

    Supported Cisco Appliances:

    Supported Appliances Supported Software
    Cisco ASA Version 8.3 and above

    Limitations for Cisco ASA:

    • Cisco ACL outbound rules are not converted (user is alerted).
    • Cisco IPv6 objects 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 Cisco configuration filename will be used as the name of the converted Policy Package. Therefore, it must be less than 20 characters long.
    • DHCP and DAIP interfaces are not supported (see relevant pre/post migration tasks).
    • Only Firewall and NAT policies are converted.

    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. Copy the Cisco configuration file to your desktop.
    3. Analyze the original Cisco configuration file.
    4. Extract the SmartMove archive file to a new folder on your desktop.
    5. Run the executable: SmartMove.exe
    6. Read and accept the End User License Agreement.
    7. The SmartMove window opens:
      1. In the "Select the vendor for conversion" field, select "CiscoASA".
      2. In the "Cisco Configuration file" field, select the file to migrate.
      3. In the "Target folder" field, select the migration output folder.
      4. For Multi-Domain Security Management, in the "Import to a domain" field, enter the Domain name as it appears in SmartConsole
        (make sure you use the Domain name not the Domain Management Server name).
      5. Click on the GO button.


      Example:


    8. Refer to the next section.

    Reading the results of Cisco configuration migration:

    Once the configuration conversion completes, the Conversion Results will be displayed.

    Example:

    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.

    • Option 1 - Bash Scripts

      These are the links to scripts that need to be run on the Check Point Management Server after you review results and fix the issues.

      • bash script for creating objects - Creates all the objects but not the rules.

      • bash script for creating Policy package - Creates a policy package with NAT and Firewall rules.

      • bash script for creating optimized Policy package - Creates an optimized policy package when possible.

      Notes:

      • The script for creating objects needs to be run before running the script for creating Policy package, or script for creating optimized Policy package.
      • The script for creating Policy package and script for creating optimized Policy package are independent of each other and are optional - you can use either one of these scripts, or both scripts, in any order.


    • Option 2 - Python Archived Packages

      These are the archived packages that are created for Python script usage.
      Use this option in cases where you import Cisco configuration into an existing Check Point environment to handle possible duplications.

      • smartconnect_.tar.gz: archive with related scripts for use with Linux (and Gaia).
      • smartconnect_.zip: archive with related scripts for use with Windows.

      Notes:
      • Python 2.7.x should be installed on the system 
      • To complete migration, go to Section (6) How to Complete the Migration, chapter "To complete Migration with Python Script". 

    Note: To assure smooth conversion of your data, it is recommended to contact Check Point Professional Services by sending an e-mail to ps@checkpoint.com.



  • (5-B) Instructions for migrating Juniper configuration

    Show / Hide this section

    Supported Juniper Gateways:

    Supported Gateway Supported OS
    Juniper SRX Series JunosOS version 12.1 and above
    Juniper SSG Series ScreenOS version 6.3 (R19B/R22) and above

    Limitations for Juniper/JunosOS:

    The following features are not supported:

    • JunosOS 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

    Limitations for Juniper/ScreenOS SSG:

    The following features are not supported:
     
    • 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

    Juniper configuration migration:

    1. Get the Juniper configuration file from the gateway. See vendor documentation for "show configuration" commands.
      • From Junos: get the configuration file in XML format
      • From ScreenOS: get the configuration file in CLI format. 
    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. Extract the SmartMove archive file to a new folder on your desktop.
    6. Run the executable: SmartMove.exe
    7. Read and accept the End User License Agreement.
    8. The SmartMove window opens:
      1. In the "Select the vendor for conversion" field, select either "JuniperSRX" or "JuniperSSG".
      2. In the "Juniper XML configuration file" field, select the file to migrate.
      3. In the "Target folder" field, select the migration output folder.
      4. For Multi-Domain Security Management, in the "Import to a domain" field, enter the Domain name as it appears in SmartConsole
        (make sure you use the Domain name not the Domain Management Server name).
      5. Click on the GO button.
      Example:
    9. Refer to the next section.

    Reading the results of Juniper configuration migration:

    Once the configuration conversion completes, the Conversion Results will be displayed.

    Example:

    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.

      • Words: 4312

        Converted NAT Policy - Check Point NAT Rule Base.

    • Bash Scripts

      These are the links to scripts that need to be run on the Check Point Management Server after you review results and fix the issues.

      • bash script for creating objects - Creates all the objects but not the rules.

      • bash script for creating Policy package - Creates a policy package with NAT and Firewall rules.

      Notes:

      • The script for creating objects needs to be run before running the script for creating Policy package.

    Note: To assure smooth conversion of your data, it is recommended to contact Check Point Professional Services by sending an e-mail to ps@checkpoint.com.

  • (5-C) Instructions for migrating Fortinet configuration

    Show / Hide this section

    Supported Fortinet Gateways:

    Supported Gateway Supported OS
    FortiOS version 5.x and above

    Limitations for FortiGate:

    General
    • The FortiGate configuration file name must contain fewer than 20 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: 
      • 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).
      • 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).
      • 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).
      • 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).
      • 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).
    3. Click OK and specify the folder in which to store the FortiGate configuration file.



    How to run SmartMove:
    1. Get the FortiGate configuration file (see instructions above in section "Before running SmartMove".
    2. Analyze the original FortiGate configuration file. Make sure it is of the expected FortiGate 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.


    1. In the "Select the vendor for conversion" field, select "Fortinet FortiGate". 
    2. In FortiGate configuration file, select the configuration file to migrate. 
    3. In Target Folder, select the migration output path. 
    4. Check Convert NAT configuration if you want to convert Fortiget NAT rule base
    5. (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 (see image below).  
    6. (Optional) If you want optimize migration process, you have to check “Do not import unused objects” checkbox. During optimized migration SmartMove doesn’t migrate (create) unused objects.
    7. Click on Go
    Note: In Multi-Domain Security Management, in order to Import to a specific domain, you need to edit the *.sh scripts with your login credentials. The structure of the login in your file is: (mgmt_cli login -r true -v 1.1 > id.txt) change it to (mgmt_cli login -d "DomainNameAsShowninSmartDomainManager" user admin password vpn123 > id.txt) replace the user name and password with your own credentials.

             Reading migration results:

    When you run SmartMove, the window shows conversion results:

    • 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.
    • Bash Scripts: These scripts must be run on the Check Point Management Server after you review results and fix issues.
      • Bash script for creating objects: Creates all the objects but not the rules.
      • Bash script for creating policy package: Creates a policy package with NAT and Firewall rules.
        • Note: The Bash script for creating objects needs to be run before running the Bash script for creating Policy package. 
        • Note: To assure smooth conversion of your data, it is recommended that you contact Check Point Professional Services by sending an e-mail to ps@checkpoint.com. 
  • (5-D) Instructions for migrating Palo Alto Networks (PAN) configuration

    Show / Hide this section

    Supported Palo Alto Network Gateways

    Supported Gateway Supported OS
    Palo Alto OS Version 7.x and above

    Limitations for Palo Alto Networks

    General

    • The PAN configuration filename must have fewer than 20 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 IPv6 objects are not converted.
    • During conversion, SmartMove tries to preserve original names for objects, but in some situations this is not possible. Consider the following situations:
      • 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).
      • 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). 
      • 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:

    palo_app: The PAN application to be converted

    cp_app: The Check Point application to be mapped to the corresponding PAN application.

    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 Groups converted by SmartMove will contain only applications that have corresponding mapping. 
    • Application Filters will not be converted.

    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.

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

    2. Make sure the application control database is up-to-date.

    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: Device -> Setup -> Operations -> Export Configuration version
    2. From the drop-down box, select the version to export. Usually, the latest configuration version is used for export.

    3. Click on OK and specify the folder in which to store the PAN configuration file.

    To Export a PAN device configuration managed by PANORAMA

    1. Go to Device > Support or, on Panorama, Panorama > Support.
    2. Under Tech Support File, click on Generate Tech Support File.
    3. From the tech support zipped file. take merged-run.xml (opt\pancfg\mgmt\saved-configs)

    How to run SmartMove

    1. Get the PAN configuration file (see the instructions above in the "Before you run SmartMove" section).
    2. Download SmartMove from the Check Point Download Center.
    3. Extract the SmartMove archive file to a new folder on your desktop.
    4. Run the executable: SmartMove.exe

    5. Accept the End User License Agreement. The SmartMove window now opens: In the Select the vendor for conversion field, select PaloAlto PAN-OS.

    6. In the PAN configuration file, select the configuration file to migrate.

    7. In Target Folder, select the migration output path.

    8. Optional: If you want to migrate user configuration parameters, you must check the Convert user configuration checkbox and specify the LDAP Account unit in the LDAP Account Unit textbox. The LDAP account unit has to be created in advance.

    9. Optional: If you want to optimize the migration process, you must check the Do not import unused objects checkbox. During optimized migration, SmartMove does not migrate (create) unused objects.

    10. Click GO. 

    Reading the migration results

    • 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.
    • Bash Scripts - These scripts must be run on the Check Point Management Server after you review the results and fix possible issues.
    • Bash script for creating objects - Creates all the objects but not the rules.
    • Bash script for creating policy package - Creates a policy package with NAT and Firewall rules

    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 <object type> <....> code: "err_validation_failed"message: "Validation failed with 1 error"errors:- message: "More than one object named '<object name>' 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 <object group> <..> code: "generic_err_object_field_not_unique"message: "Requested object name [<object>] 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.


(6) 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 and policy reports.
  2. Copy the bash scripts to the Check Point Management Server.
  3. If the script files are not saved as a text, convert the bash scripts to UNIX format (dos2unix <script_name>).
  4. Connect to the command line on the Check Point Management Server.
  5. Login to Expert mode.
  6. Unset the TMOUT environment variable (unset TMOUT).
  7. Assign execute permission to the script files (chmod u+x <script_name>).
  8. Confirm Gaia Default port is 443. To check the port number of Gaia run the command (api status). Incase Api Gaia port is different than port 443 for example 4434, run the following command (export MGMT_CLI_PORT=4434).
  9. Run the bash scripts in the following order:
    1. bash script for creating objects
    2. bash script for creating a Policy package
    3. bash script for creating an optimized Policy package
    Notes:
    • The script for creating objects needs to be run before running the script for creating a Policy package or the script for creating an optimized Policy package.
    • The script for creating a Policy package and the script for creating an optimized Policy package are independent of each other and are optional: you can use either one or both, in any order.
  10. Login to SmartConsole.
  11. Perform the post-migration tasks:
    1. Attach the zones to the relevant interfaces.
    2. Add Anti-Spoofing settings, based on the output of the following command:
      ip verify reverse-path interface <interface_name>
    3. Set DHCP/DAIP interfaces back to the correct settings.
    4. 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 oringial converted Gateway

Troubleshooting

    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.

    The Bash script for importing objects creates a failed_objects.txt file, in which you can find errors during script processing.
    The Bash script for importing policy rules creates a failed_package.txt file, in which you can find errors during script processing.

To complete Migration with Python Script (relevant for Cisco only at the moment)

The SmartMove tool also generates a python script (delivered in an archived package) that imports converted objects and rules to the Check Point environment with the following advantages:

  • Import process can be run remotely without copying related files to management server.
  • Runtime errors/warnings related to duplicate objects are fixed during the import process.

In cases where you import Cisco configuration into an existing Check Point environment, it is recommended to complete migration with the Python script to handle possible duplication. Check Point supports the following duplication cases:
- Name
- IP (host)
- IP and Mask (network)
- IP range (address range)
- Port (TCP/UDP)  

  • During the import process, objects with duplicated names are renamed. 
  • When the import process detects that the imported objects' values (IP/Port) already exist on the target (Check Point) side, the script does not import the objects, but rather uses the existing one.

Note: All references of these objects in rules and groups are replaced accordingly.

To run the migration:

  1. Unpack the archive package on the Security Management server (or any other server if you want to run it remotely).
    - Use the 'tar xvfz smartconnect_.tar.gz' command to unpack the archive under Gaia/Linux.
  2. Make the smartconnect.py file executable in the Linux/Gaia environment.
    - Use the 'chmod a+x smartconnector.py' command to make smartconnector.py executable
  3. Run the smartconnector.py command to start the migration process (All parameters and command examples are specified in Appendix A below).
  4. Log into SmartConsole.
  5. Run post-migration tasks:
    1. Attach the zones to the relevant interfaces/
    2. Add anti-spoofing settings based on the command 'ip verify reverse-path interface interface_name'.
    3. Change DHCP/DAIP interfaces back to the correct settings.
    4. Fix time-range objects referenced by the converted rules.
  6. Make sure the imported configuration is correct for your environment.
  7. Install policy.
  8. Monitor the Security Gateway. Make sure it behaves in the same way as does the Cisco ASA router.

 

Note 1: When several object candidates exist for replacing imported objects, the scripts use the following selection priority rules:

  • Depending on parameter value '--replace-from-global-first' Global or Local domain objects receive higher priority.
  • For services, services without protocol value defined, get more priority as more general services
  • When replacement objects have the same priority, first found is used

Note 2: 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.

Note 3: Since python scripts are implemented using python script language, make sure the python engine is in the PATH: this is by default for version R80.20; in version R80.10, add a folder containing the python engine to the PATH variable so that the script will succeed.

Note 4: 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.

 

(7) Appendix

Show / Hide this section

Note: This appendix is relevant to Cisco migrations with Python only. 

The following parameters are accepted by the smartconnector.py script:

-h, --help show this help message and exit 
 -r, --root If administrator logged into the management server and wants to receive SuperUser permissions, 'login-as-root' feature might be used. In this case providing additional login credentials is not required 

 -u USER,

--user USER

User name 

 -m MANAGEMENT,

--management MANAGEMENT

 Management server IP address or name. Default: 127.0.0.1
 --port PORT  Management server port. Default: 443

 -p PASSWORD,

--password PASSWORD

 User password

 -f FILE,

--file FILE

 File with CheckPoint objects and rules (in json format) used for import. Default: cp_objects.json

 -t THRESHOLD,

--threshold THRESHOLD

 Parameter specifies maximum number of Check Point objects/rules to add before starting publish operation. Default: 100

-d DOMAIN,

--domain DOMAIN

The name/uid of the domain you want to log into in an MDS environment
--replace-from-global-first The argument indicates that SmartConnector should use 'Global' objects at first, by default, it uses 'Local' objects. Can have true or false value. Default: false

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.

 

(8) Disclaimer

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.

 

(9) Revision History

Show / Hide

Date Description
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 CheckMates 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

 


Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment