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
  6. How to Complete the Migration
  7. Disclaimer
  8. 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.

 

(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

Note: Additional requirements for each specific vendor are listed in the "(5) Instructions for Migrating Configuration from 3rd party Vendors" section.

 

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

    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. 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 "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:
    9. 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.

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

    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.

      • 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. (Optional) For Multi-Domain Security Management, in Import to a domain, enter the domain name (not the name of a Domain Management Server). 
    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
    7.  migration process, you have to check “Do not import unused objects” checkbox. During optimized migration SmartMove doesn’t migrate (create) unused objects.
    8. Click on Go

             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. 

(6) How to Complete the Migration

Show / Hide this section

Anyone can run SmartMove Tool, at any time. 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. Just in case, convert the bash scripts from DOS format 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. Run the bash scripts in the following order:
    1. bash script for creating objects
    2. bash script for creating Policy package
    3. bash script for creating optimized Policy package
    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 or both in any order.
  9. Login to SmartConsole.
  10. 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 correct settings.
    4. Fix time-range objects referenced by converted rules.
  11. Make sure the imported configuration is correct for your environment.
  12. Install policy.
  13. Monitor the Security Gateway. Make sure it behaves in the same way as the Cisco ASA router.

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, with which you can find errors during script processing.
    The Bash script for importing policy rules creates a failed_package.txt file, with which you can find errors during script processing.

 

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

 

 

(8) Revision History

Show / Hide revision history

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

 

Important Note: Refer to Third-Party Software Disclaimer.

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