The process of separating a standalone installation could be broken down to a few high-level steps
- Do an upgrade_export of exisiting base and import it on a new server installed as both SG and SM (which will eventually be SM)
- Remove all security products on the standalone-object, leaving only management products enabled. Install database and Upgrade_export the new modified database.
- Reinstall the new server, now only with SM and import the database.
- Install the SG and establish SIC with the newly installed SM.
Read more for a bit more detailed description.
The first thing you should do is, of course, a full backup of the relevant configuration files of your standalone installation in case you need to revert back to the originial installation.
A few things to consider and arrange before starting the process:
- I find it feasible to install another standalone server where I import the exisiting configuration. This will enable me to perform the separation without interacting with the exisiting installation and therefore provides a comfortable fallback in case armageddon occurs.
- Since one will install a clone with much of the same products, you will need to separate the clone from the production network. Either by not configuring a default gateway or by directly connecting your computer to the clone, all depending on your setup.
If in doubt, keep to directly connected to your computer.
- You will also need to re-license your installation on support.checkpoint.com with central licenses linked to the IP-address of your new SM-server. Make sure you have the license file handy before reinstallation.
- If you will upgrade to a new version during migratation, be sure to download the migratation tools before starting.
- Upgrade_export from your exisitng standalone installation
- Upgrade_import to the newly installed clone server
- Connect to the server with SmartDashboard and verify the results of the import.
- In SmartDashboard
- On the standalone object, make sure that you remove all the products under the “network security” tab under “general properties” pane.
- File > Save
- Right-click standalone object and “convert to host”
- File > Save
- Policy > Install database
- Do an upgrade_export of the newly modified database.
- Connect to the SM using SmartDashboard and verify the SM-object does not have a “network security” tab.
- Import the modified database.
It is likely this will fail with error like “Database migration between standalone and management only machines is not supported”. This merely means you will have to go through the following steps:
- Copy the upgrade-export .tgz-file into a folder of its own.
- Extract the .tgz-file within this folder (tar zxvf MyUpgradeExportFile.tgz)
- Edit two files: configuration and configuration2 using vi
- Change :is_firewall_module (yes) to :is_firewall_module (no)
- Change :installed_products_registry_string (“FWManagement,FireWall,Primary”) to :installed_products_registry_string (“FWManagement,Primary”)
- Re-pack the tgz-file (rm MyUpgradeExportFile.tgz;tar zcvf MyEditedUpgradeExportFile.tgz *)
- Import the modified database with edited configuration-files.
- This could be the old standalone-server.
- Install, selecting only Security Gateway.
- Establish SIC with the newly installed SM and push policy.
Install the clone server with both security gateway and management server products.
Working on our clone of the standalone installation:
Reinstall our “clone”, but this time you will only install the “Management server” products. Configure with relevant IP.
The hostname needs to be identical to your standalone installation.
Install Security Gateway
Voila – you now have a distribued installation. =)
I need to perform this operation but there is a 3rd party certificate installed on the current standalone deployment.
I believe I need to keep the same hostname for the gateway and change it for the management.
Do you know if it is possible ?
Since you are using a third party and, what I assume is, an official certificate you would not have linked the common name of the certificate to the hostname of the device.
I have not tried moving a certificate from one gateway to another, but I do not see it should be a problem if you have all the certificate key files.
That make sense ! Thanks for your reply.
I would like to migrate from distributed installation to standalone installation. Are there any instrunctions for this? I have a Checkpoint Power-1 FW running R70.1 and then there are two management server PCs running Windows 2003 Server. I need to get rid of these Windows machines and use GUI clients for creating FW rules.
Thanks in advance!
I suppose it is possible, but I would not recommend doing so. Is there any special reason why you would opt for a stand-alone- over a distributed installation?
I’d rather re-install the Windows management module on Check Points own GAiA operating system (No need for Microsoft-licenses). If you choose this path, you can simply follow Check Points own install and upgrade guide (See migration / advanced migration).
its due to our lab re-organizing plans that drives me to get rid of the Windows PCs. They are also getting old and the hard disks are showing marks of breaking down soon. I think that your recommendation is just what I need. So if I understood correctly, I can install/migrate the management module to the Checkpoint Power-1 without re-installing everything from the beginning and the use GUI client to manage the rules. If I make the upgrade_export from the Windows management station, can I then do the upgrade_import at the Power-1 management module?
Yes, you will install the management server from scartch, choosing only management as product, run upgrade_export* on your old management station, then upgrade_import on your new management server and if you do not change and IP addresses or configuration, you do not need to reSIC your management-server and firewall.
* Note – If you are installing R77.20 Management station, download the R77.20 “migration tools” from Check Point and run those on your old management station – Rule of thumb is upgrade_export and upgrade_import ought to be run using the same version to avoid any problems (according to my own experience).