CP R80.30 GA Installation and Upgrade Guide PDF
CP R80.30 GA Installation and Upgrade Guide PDF
CP R80.30 GA Installation and Upgrade Guide PDF
INSTALLATION AND
UPGRADE GUIDE
R80.30
Protected
Certifications
For third party independent certification of Check Point products, see the Check Point
Certifications page
https://www.checkpoint.com/products-solutions/certified-check-point-solutions/.
Feedback
Check Point is engaged in a continuous effort to improve its documentation.
Please help us by sending your comments
mailto:[email protected]?subject=Feedback on Installation and
Upgrade Guide R80.30 .
Revision History
Date Description
19-December-2019 Updated Installing Full High Availability Cluster (on page 472)
Getting Started
In This Section:
Welcome ............................................................................................................. 11
R80.30 Documentation......................................................................................... 11
R80.30 Software Images ...................................................................................... 12
For New Check Point Customers ......................................................................... 12
Disk Space .......................................................................................................... 12
Product Deployment Scenarios............................................................................ 12
Welcome
Thank you for choosing Check Point Software Blades for your security solution. We hope that you
will be satisfied with this solution and our support services. Check Point products provide your
business with the most up to date and secure solutions available today.
Check Point also delivers worldwide technical services including educational, professional, and
support services through a network of Authorized Training Centers, Certified Support Partners,
and Check Point technical support personnel to ensure that you get the most out of your security
investment.
For additional information on the Internet Security Product Suite and other security solutions, go
to https://www.checkpoint.com https://www.checkpoint.com or call Check Point at 1(800)
429-4391. For additional technical information, visit the Check Point Support Center
https://supportcenter.checkpoint.com.
Welcome to the Check Point family. We look forward to meeting all of your current and future
network, application, and management security needs.
R80.30 Documentation
This guide is for administrators responsible for installing R80.30 on appliances and open servers
that run the Gaia Operating System.
To learn what is new in R80.30, see the R80.30 Release Notes
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_RN/html_frame
set.htm.
See the R80.30 Home Page SK http://supportcontent.checkpoint.com/solutions?id=sk144293 for
information about the R80.30 release.
Disk Space
When you install or upgrade R80.30, the installation or upgrade wizard makes sure that there is
sufficient space on the hard disk to install the Check Point products.
If there is not sufficient space on the hard disk, an error message is shown. The message states:
• The amount of disk space necessary to install the product.
• The directory where the product is installed.
• The amount of free disk space that is available in the directory.
To learn how to remove old Check Point packages and files, see sk91060
http://supportcontent.checkpoint.com/solutions?id=sk91060.
After there is sufficient disk space, install or upgrade the Check Point product.
Distributed Deployment
The Security Management Server (1) and the Security Gateway (3) are installed on different
computers, with a network connection (2).
Standalone Deployment
The Security Management Server (1) and the Security Gateway (3) are installed on the same
computer (2).
2 Immediately after the Pre-Upgrade Verifier (PUV) finishes successfully and does not show
you further suggestions:
• Save a second snapshot of your source system.
• Save a second backup of your source system.
• Collect a second CPinfo file from your source system.
3 Transfer the CPinfo file, snapshot, backup files, and exported database files to external
storage devices. Make sure to transfer the files in the binary mode.
Important notes about backing up and restoring in Management High Availability environment:
• To back up and restore a consistent environment, make sure to collect and restore the
backups and snapshots from all servers in the High Availability environment at the same time.
• Make sure other administrators do not make changes in SmartConsole until the backup
operation is completed.
For more information:
• About Gaia Backup and Gaia Snapshot, see the R80.30 Gaia Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Gaia_Admin
Guide/html_frameset.htm.
• About the migrate export and migrate import commands, see the R80.30 CLI Reference
Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_Referen
ceGuide/html_frameset.htm.
• About the mds_backup and mds_restore commands, see the R80.30 Multi-Domain Security
Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-Domai
nSecurityManagement_AdminGuide/html_frameset.htm.
• About Virtual Machine Snapshots, see the vendor documentation.
Step Description
1 Connect to the appliance using the serial console.
3 During boot, when prompted, press any key within 4 seconds to enter the Boot menu:
Loading the system
Press any key to see the boot menu [Booting in 5 seconds]
6 Run the Gaia First Time Configuration Wizard (on page 25).
To perform a clean install of the supported Gaia image with a bootable USB device:
Step Description
1 Download the Gaia Operating System Clean Install ISO file from the R80.30 Home Page SK.
3 Run the Gaia First Time Configuration Wizard (on page 25).
To perform a clean install of the supported Gaia image with the CPUSE:
See Installing Software Packages on Gaia (on page 118) and follow the applicable action plan for
the local installation.
5 Enter the BIOS and configure the DVD-ROM to be the first boot option.
10 After Gaia installs and before the reboot, disconnect the DVD-ROM from your Open Server.
12 Enter the BIOS and configure the Hard Disk to be the first boot option.
15 Run the Gaia First Time Configuration Wizard (on page 25).
To perform a clean install of the supported Gaia image with a bootable USB device:
Step Description
1 Download the Gaia Operating System ISO file from R80.30 Home Page SK.
Step Description
2 See sk65205 http://supportcontent.checkpoint.com/solutions?id=sk65205 to create a
bootable USB device.
Important - Always use the latest available build of the ISOmorphic Tool. If you use an
outdated build, the installation can fail.
3 Run the Gaia First Time Configuration Wizard (on page 25).
To perform a clean install of the supported Gaia image with the CPUSE:
See Installing Software Packages on Gaia (on page 118) and follow the applicable action plan for
the local installation.
Step Description
1 Prepares the USB with these pre-configured settings for a specified network interface:
• IP address
• Network mask
• Default gateway
2 Sends the USB drive to an administrator, who inserts the drive into the appliance and
reboots it.
The tool installs R77.20 (or above) and configures the appliance with the predefined
settings.
The LCD indicates a successful installation and interfaces blink in round-robin fashion.
Note - The ISOmorphic tool does not support unattended installation on open servers.
2 On your connected computer, configure a static IPv4 address in the same subnet as the
IPv4 address you configured during the Gaia installation.
3 On your connected computer, in a web browser, connect to the IPv4 address you
configured during the Gaia installation:
https://<IPv4_Address_of_Gaia>
5 Click Login.
The Check Point First Time Configuration Wizard opens.
Below you can find the description of the First Time Configuration Wizard windows and their fields.
If in the Deployment Options window, you selected Install from Check Point Cloud, the First Time
Configuration Wizard asks you to configure the connection to Check Point Cloud. These options
appear (applies only to Check Point appliances that you configured as a Security Gateway):
• Install major version - This option let you choose and install major versions available on
Check Point Cloud. The Gaia CPUSE performs the installation.
• Pull appliance configuration - This option lets you to apply initial deployment configuration
including different OS version on the appliance. You must prepare the initial deployment
configuration with the Zero Touch Cloud Service. For more information, see sk116375
http://supportcontent.checkpoint.com/solutions?id=sk116375.
Field Description
Interface By default, First Time Configuration Wizard selects the interface you
configured during the Gaia installation (for example, eth0).
Note - After you complete the First Time Configuration Wizard and reboot, you
can select another interface as the main Gaia Management Interface and
configure its IP settings.
Configure IPv4 Select how the Gaia Management Interface gets its IPv4 address:
• Manually - You configure the IPv4 settings in the next fields.
• Off - None.
IPv4 address Enter the desired IPv4 address.
Subnet mask Enter the applicable IPv4 subnet mask.
Default Gateway Enter the IPv4 address of the applicable default gateway.
Configure IPv6 Select how the Gaia Management Interface gets its IPv6 address:
• Manually - You configure the IPv6 settings in the next fields.
• Off - None.
IPv6 Address Enter the desired IPv6 address.
Mask Length Enter the applicable IPv6 mask length.
Default Gateway Enter the IPv6 address of the applicable default gateway.
Field Description
Interface Select the applicable interface on this computer.
Configure IPv4 Select how the applicable interface gets its IPv4 address:
• Manually - You configure the IPv4 settings in the next fields.
• Off - None.
IPv4 address Enter the desired IPv4 address.
Subnet mask Enter the applicable IPv4 subnet mask.
Configure IPv6 Optional. Select how the applicable interface gets its IPv6 address:
• Manually - You configure the IPv6 settings in the next fields.
• Off - None.
IPv6 Address Enter the desired IPv6 address.
Subnet Enter the applicable IPv6 subnet mask.
Field Description
Host Name Enter the desired distinct host name.
Domain Name Optional: Enter the applicable domain name.
Primary DNS Enter the applicable IPv4 address of the primary DNS server.
Server
Secondary DNS Optional: Enter the applicable IPv4 address of the secondary DNS server.
Server
Tertiary DNS Optional: Enter the applicable IPv4 address of the tertiary DNS server.
Server
Use a Proxy Optional: Select this option to configure the applicable Proxy server.
server
Address Enter the applicable IPv4 address or resolvable hostname of the Proxy server.
Port Enter the port number for the Proxy server.
Field Description
Set the time Select this option to configure the date and time settings manually.
manually
Date Select the correct date.
Time Select the correct time.
Time Zone Select the correct time zone.
Use Network Select this option to configure the date and time settings automatically with
Time Protocol NTP.
(NTP)
Primary NTP Enter the applicable IPv4 address or resolvable hostname of the primary NTP
server server.
Version Select the version of the NTP for the primary NTP server.
Secondary NTP Optional: Enter the applicable IPv4 address or resolvable hostname of the
server secondary NTP server.
Version Select the version of the NTP for the secondary NTP server.
Time Zone Select the correct time zone.
Field Description
Security Select this option to install:
Gateway and/or
• A Single Security Gateway.
Security
Management • A Cluster Member.
• A Security Management Server, including Management High Availability.
• An Endpoint Security Management Server.
• An Endpoint Policy Server.
• CloudGuard Controller.
• A dedicated single Log Server.
• A dedicated single SmartEvent Server.
• A Standalone.
Multi-Domain Select this option to install:
Server
• A Multi-Domain Security Management Server, including Management High
Availability.
• A dedicated single Multi-Domain Log Server.
Products window:
In this window, you continue to select which type of Check Point products you wish to install on the
Gaia computer.
If in the Installation Type window, you selected Security Gateway and/or Security Management,
these options appear:
Field Description
Security Select this option to install:
Gateway
• A single Security Gateway.
• A Cluster Member.
• A Standalone.
Security Select this option to install:
Management
• A Security Management Server, including Management High Availability.
• An Endpoint Security Management Server.
• An Endpoint Policy Server.
• CloudGuard Controller.
• A dedicated single Log Server.
• A dedicated single SmartEvent Server.
• A Standalone.
Unit is a part of a This option is available only if you selected Security Gateway.
cluster Select this option to install a cluster of dedicated Security Gateways, or a Full
High Availability Cluster.
Select the cluster type:
• ClusterXL - For a cluster of dedicated Security Gateways, or a Full High
Availability Cluster.
• VRRP Cluster - For a VRRP Cluster on Gaia.
Define Security Select Primary to install:
Management as
• A Security Management Server.
• An Endpoint Security Management Server.
• An Endpoint Policy Server.
• CloudGuard Controller.
Select Secondary to install:
• A Secondary Management Server in Management High Availability.
Select Log Server / SmartEvent only to install:
• A dedicated single Log Server.
• A dedicated single SmartEvent Server.
If in the Installation Type window, you selected Multi-Domain Server, these options appear:
Field Description
Primary Select this option to install a Primary Multi-Domain Server in Management
Multi-Domain High Availability.
Server
Secondary Select this option to install a Secondary Multi-Domain Server in Management
Multi-Domain High Availability.
Server
Multi-Domain Select this option to install a dedicated single Multi-Domain Log Server.
Log Server
Note - By default, the option Automatically download Blade Contracts and other important data
is enabled. See sk111080 http://supportcontent.checkpoint.com/solutions?id=sk111080.
Field Description
Yes Select this option, if this Security Gateway gets its IP address dynamically
(DAIP gateway).
No Select this option, if you wish to configure this Security Gateway with a static
IP address.
Field Description
Activation Key Enter the desired one-time activation key (between 4 and 127 characters
long).
Confirm Enter the same one-time activation key again.
Activation Key
Field Description
Use Gaia Select this option, if you wish to use the default Gaia administrator (admin).
administrator:
admin
Define a new Select this option, if you wish to configure an administrator username and
administrator password manually.
Field Description
Any IP Address Select this option to allow all computers to connect.
This machine Select this option to allow only a specific computer to connect.
By default, the First Time Configuration Wizard uses the IPv4 address of your
computer. You can change it to another IP address.
Network Select this option to allow an entire IPv4 subnet of computers to connect.
Enter the applicable subnet IPv4 address and subnet mask.
Range of IPv4 Select this option to allow a specific range of IPv4 addresses to connect.
addresses Enter the applicable start and end IPv4 addresses.
Field Description
Select leading Select the desired interface.
interface
Field Description
Any host Select this option to allow all computers to connect.
IP address Select this option to allow only a specific computer to connect.
By default, the First Time Configuration Wizard uses the IPv4 address of your
computer. You can change it to another IP address.
Notes:
• At the end of the First Time Configuration Wizard, the Gaia computer reboots and the
initialization process is performed in the background for several minutes.
• If you installed the Gaia computer as a Security Management Server or Multi-Domain Server,
only read-only access is possible with SmartConsole during this initialization time.
• To verify that the configuration is finished:
a) Connect to the command line on the Gaia computer.
b) Log in to the Expert mode.
c) Check that the bottom section of the /var/log/ftw_install.log file contains one of
these sentences: "installation succeeded" or "FTW: Complete".
Run:
# cat /var/log/ftw_install.log | egrep --color "installation succeeded|FTW:
Complete"
Syntax
• To list the command options, run one of these:
Form Command
Short form config_system -h
• To run the First Time Configuration Wizard from a specified configuration file, run one of
these:
Form Command
Short form config_system -f <Path and Filename>
Long form config_system --config-file <Path and Filename>
• To run the First Time Configuration Wizard from a specified configuration string, run one of
these:
Form Command
Short form config_system -s <String>
Long form config_system --config-string <String>
• To create a First Time Configuration Wizard Configuration file template in a specified path, run
one of these:
Form Command
Short form config_system -t <Path>
Long form config_system --create-template <Path>
If you do not have a configuration file, you can create a configuration template and fill in the
parameter values as necessary.
Before you run the First Time Configuration Wizard, you can validate the configuration file you
created.
Parameters
A configuration file contains the <parameter>=<value> pairs described in the table below.
Note - The config_system parameters can change from Gaia version to Gaia version. Run
config_system --help to see the available parameters.
You can change the IP address of the Gaia Management Interface after you run the Gaia First Time
Configuration Wizard.
• In Gaia Portal:
Step Description
1 In your web browser, connect the Gaia Portal to the current IP address of the Gaia
management interface:
https://<IP Address of Gaia Management Interface>
5 Click OK.
6 In the Interfaces section, select the Management Interface and click Edit.
8 Click OK.
• In Gaia Clish:
Step Description
1 Connect to the command line on the Gaia computer.
• Over SSH to the current IP address of the Gaia Management Interface
• Over a console
2 Log in to Gaia Clish.
Step Description
4 Select another Gaia Management Interface:
set management interface <Interface Name>
To see the size of the system-root and log partitions on an installed system:
Step Description
1 Connect to the command line on your Gaia computer.
3 Run:
df -h
Most of the remaining space on the disk is reserved for backup images and upgrades.
In Gaia Portal:
1. With a web browser, connect to Gaia Portal at:
https://<IP address of Gaia Management Interface>
2. From the navigation tree, click System Management > System Configuration.
3. In the IPv6 Support section, select On.
4. Click Apply.
5. When prompted, select Yes to reboot.
In Gaia Clish:
1. Connect to the command line on the Gaia computer.
2. Log in to Gaia Clish.
3. Enable the IPv6 support:
set ipv6-state on
4. Save the changes:
save config
5. Reboot:
reboot
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Management only.
b) In the Clustering section, in the Define Security Management as field, select
Primary.
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect.
• This machine - Allows only the single specified computer to connect.
• Network - Allows all computers on the specified network to connect.
• Range of IPv4 addresses - Allows all computers in the specified range to connect.
6 Click OK.
Step Description
1 In the SmartConsole, edit the object of the Security Management Server.
3 Select When disk space is below <number> Mbytes, start deleting old files.
5 Click OK.
2 Run the Gaia First Time Configuration Wizard (on page 25).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Management only.
b) In the Clustering section, in the Define Security Management as field, select
Secondary.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
3 Create a new Check Point Host object that represents the Secondary Security
Management Server in one of these ways:
• From the top toolbar, click the New ( ) > More > Check Point Host.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways & Servers > New Check Point Host.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Check Point Host.
Step Description
4 Click the General Properties page.
6 In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses.
10 Establish the Secure Internal Communication (SIC) between the Primary Security
Management Server and the Secondary Security Management Server:
a) In the Secure Internal Communication field, click Communication.
b) Enter the same Activation Key you entered during the First Time Configuration
Wizard of the Secondary Security Management Server.
c) Click Initialize. The Trust state field must show Established.
d) Click Close.
11 Click OK.
12 In the SmartConsole top left corner, click Menu > Install database.
14 Click Install.
15 Click OK.
16 In the SmartConsole top left corner, click Menu > Management High Availability.
Step Description
1 In the SmartConsole, edit the object of the Secondary Security Management Server.
3 Select When disk space is below <number> Mbytes, start deleting old files.
5 Click OK.
Step Description
1 Install the Gaia Operating System:
• Installing the Gaia Operating System on a Check Point Appliance (on page 18)
• Installing the Gaia Operating System on an Open Server (on page 20)
2 Run the Gaia First Time Configuration Wizard (on page 25).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Management only.
b) In the Clustering section, in the Define Security Management as field, select Log
Server / SmartEvent only.
• In the Security Management Administrator window, select one of these options:
• Use Gaia administrator
• Define a new administrator and configure it
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect.
• This machine - Allows only the single specified computer to connect.
• Network - Allows all computers on the specified network to connect.
• Range of IPv4 addresses - Allows all computers in the specified range to connect.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
3 Create a new Check Point Host object that represents the dedicated Log Server or
SmartEvent Server in one of these ways:
• From the top toolbar, click the New ( ) > More > Check Point Host.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways & Servers > New Check Point Host.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Check Point Host.
4 Click the General Properties page.
6 In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses.
9 Establish the Secure Internal Communication (SIC) between the Management Server and
this dedicated Log Server or SmartEvent Server:
a) In the Secure Internal Communication field, click Communication.
b) Enter the same Activation Key you entered during the First Time Configuration
Wizard of the dedicated Log Server or SmartEvent Server.
c) Click Initialize. The Trust state field must show Established.
d) Click Close.
Step Description
11 Click OK.
12 In the SmartConsole top left corner, click Menu > Install database.
14 Click Install.
15 Click OK.
Step Description
1 Connect with SmartConsole to the applicable Management Server that manages the
dedicated Log Server or SmartEvent Server.
4 Select When disk space is below <number> Mbytes, start deleting old files.
6 Click OK.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Multi-Domain Server.
• In the Installation Type window, select Primary Multi-Domain Server.
• In the Leading VIP Interfaces Configuration window, select the applicable interface.
• In the Multi-Domain Server GUI Clients window, select one of these options:
• Any host to allow all computers to connect
• IP address and enter the IPv4 address of the applicable allowed computer
• In the Security Management Administrator window, select one of these options:
• Use Gaia administrator
• Define a new administrator and configure it
2 Run the Gaia First Time Configuration Wizard (on page 25).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Multi-Domain Server.
• In the Installation Type window, select Secondary Multi-Domain Server.
• In the Leading VIP Interfaces Configuration window, select the applicable interface.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 From the left navigation panel, click Multi Domain > Domains.
7 Enter the same Activation Key you entered during the setup of First Time Configuration
Wizard of the Secondary Multi-Domain Server.
Step Description
8 Click OK.
14 Click OK.
Notes:
• The new Multi-Domain Server automatically synchronizes with all existing Multi-Domain
Servers and Multi-Domain Log Servers. The synchronization operation can take some time to
complete, during which a notification indicator shows in the task information area.
• It is not supported to move the Secondary Multi-Domain Server from one Management High
Availability environment to another Management High Availability environment. If you
disconnect the existing Secondary Multi-Domain Server from one Management High
Availability environment and connect it to another, you must install it again from scratch as a
Secondary Multi-Domain Server (Known Limitation PMTR-14327).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Multi-Domain Server.
• In the Installation Type window, select Multi-Domain Log Server.
• In the Leading VIP Interfaces Configuration window, select the applicable interface.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 From the left navigation panel, click Multi Domain > Domains.
3 From the top toolbar, click New > Multi-Domain Log Server.
7 Enter the same Activation Key you entered during the First Time Configuration Wizard of
the Multi-Domain Log Server.
8 Click OK.
Step Description
9 In the Platform section:
• In the OS field, select Gaia
• In the Version field, select R80.30
• In the Hardware field, select the applicable option
10 Click the Multi-Domain page.
16 Click OK.
Workflow:
1. Install the Endpoint Security Management Server.
2. Configure the Endpoint Security Management Server object in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Management only.
b) In the Clustering section, in the Define Security Management as field, select
Primary.
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect.
• This machine - Allows only the single specified computer to connect.
• Network - Allows all computers on the specified network to connect.
• Range of IPv4 addresses - Allows all computers in the specified range to connect.
6 Click OK.
7 In the SmartConsole top left corner, click Menu > Install database.
9 Click Install.
10 Click OK.
3 Create a new Check Point Host object that represents the Endpoint Policy Server in one of
these ways:
• From the top toolbar, click the New ( ) > More > Check Point Host.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways & Servers > New Check Point Host.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Check Point Host.
4 Click the General Properties page.
6 In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses.
Step Description
9 Establish the Secure Internal Communication (SIC) between the Endpoint Security
Management Server and the Endpoint Policy Server:
a) In the Secure Internal Communication field, click Communication.
b) Enter the same Activation Key you entered during the First Time Configuration
Wizard of this dedicated Log Server.
c) Click Initialize. The Trust state field must show Established.
d) Click Close.
10 Click OK.
11 In the SmartConsole top left corner, click Menu > Install database.
13 Click Install.
14 Click OK.
Service URL
Gaia Portal Defaul
https://<Gaia IP Address>
t
New https://<Gaia IP Address>:4434
SmartView Web Defaul
https://<Management Server IP Address>/smartview/
Application t
https://<Management Server IP
New
Address>:4434/smartview/
Management API Web
Services
Defaul https://<Management Server IP
https://sc1.checkpoint.
t Address>/web_api/<command>
com/documents/latest
/APIs/index.html
https://<Management Server IP
New
Address>:4434/web_api/<command>
If you disable the Endpoint Policy Management blade, the services connection port automatically
changes back to the default 443.
Workflow:
1. Install the CloudGuard Controller.
2. Enable the CloudGuard Controller.
3. Enable the Identity Awareness Software Blade on the applicable Security Gateways.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Management only.
b) In the Clustering section, in the Define Security Management as field, select
Primary.
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect.
• This machine - Allows only the single specified computer to connect.
• Network - Allows all computers on the specified network to connect.
• Range of IPv4 addresses - Allows all computers in the specified range to connect.
3 Run:
cloudguard on
Step 3 of 3: Enable the Identity Awareness Software Blade on the applicable Security
Gateways
Installing SmartConsole
In This Section:
Logging in to SmartConsole................................................................................. 68
Troubleshooting SmartConsole ........................................................................... 69
SmartConsole is a GUI client you use to manage the Check Point environment.
For SmartConsole requirements, see the R80.30 Release Notes
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_RN/html_frame
set.htm.
You can download the SmartConsole installation package from:
• R80.30 Home Page SK http://supportcontent.checkpoint.com/solutions?id=sk144293
• Check Point Support Center http://supportcenter.checkpoint.com
• Gaia Portal of your Security Management Server or Multi-Domain Server
To download SmartConsole package from the Gaia Portal of your Management Server:
Step Description
1 In your web browser, connect to:
https://<IP Address of Gaia Management Interface>
Logging in to SmartConsole
Step Description
1 Open the SmartConsole application.
4 Click Login.
5 If necessary, confirm the connection using the fingerprint generated during the
installation.
You see this only the first time that you log in from a SmartConsole client.
Troubleshooting SmartConsole
Make sure the SmartConsole client can access these ports on the Management Server:
• 18190
• 18264
• 19009
For more information, see:
• sk52421: Ports used by Check Point software
http://supportcontent.checkpoint.com/solutions?id=sk52421
• sk43401: How to completely disable FireWall Implied Rules
http://supportcontent.checkpoint.com/solutions?id=sk43401
Workflow:
1. Install the Security Gateway.
2. Configure the Security Gateway object in SmartConsole - in either Wizard Mode, or Classic
Mode.
3. Configure the applicable Access Control policy for the Security Gateway in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select the applicable option.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
Step Description
5 On the General Properties page:
a) In the Gateway name field, enter the desired name for this Security Gateway object.
b) In the Gateway platform field, select the correct hardware type.
c) In the Gateway IP address section, select the applicable option:
If you selected Static IP address, configure the same IPv4 and IPv6 addresses
that you configured on the Management Connection page of the Security
Gateway's First Time Configuration Wizard. Make sure the Security
Management Server or Multi-Domain Server can connect to these IP addresses.
If this Security Gateway receives its IP addresses from a DHCP server, click
Cancel and follow the procedure Step 2 of 3: Configure the Security Gateway
object in SmartConsole - Classic Mode below.
d) Click Next.
Step Description
8 If during the Wizard Mode, you selected Skip and initiate trusted communication later:
a) The Secure Internal Communication field shows Uninitialized.
b) Click Communication.
c) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
Select Small Office Appliance only for 1100, 1200R, and 1400 Check Point
appliances models.
d) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
e) Click Initialize.
Make sure the Certificate state field shows Established.
f) Click OK.
10 Click OK.
5 In the Name field, enter the desired name for this Security Gateway object.
Step Description
6 In the IPv4 address and IPv6 address fields, configure the same IPv4 and IPv6 addresses
that you configured on the Management Connection page of the Security Gateway's First
Time Configuration Wizard. Make sure the Security Management Server or Multi-Domain
Server can connect to these IP addresses.
If this Security Gateway receives its IP addresses from a DHCP server, select Dynamic
Address.
7 Establish the Secure Internal Communication (SIC) between the Management Server and
this Security Gateway:
a) Near the Secure Internal Communication field, click Communication.
b) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
Select Small Office Appliance only for 1100, 1200R, and 1400 Check Point
appliances models.
c) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
d) Click Initialize.
e) Click OK.
If the Certificate state field does not show Established, perform these steps:
a) Connect to the command line on the Security Gateway.
b) Make sure there is a physical connectivity between the Security Gateway and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
9 On the Network Security tab, enable the desired Software Blades.
Important - Do not select anything on the Management tab.
10 Click OK.
Step 3 of 3: Configure the applicable Access Control policy for the Security Gateway in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
Workflow:
1. Install the VSX Gateway.
2. Configure the VSX Gateway object in SmartConsole.
3. Configure the Virtual Devices on this VSX Gateway and their Security Policies in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select the applicable option.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
• From the top toolbar, click the New ( ) > VSX > Gateway.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > VSX > New Gateway.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > VSX > Gateway.
The VSX Gateway Wizard opens.
Step Description
4 On the VSX Gateway General Properties (Specify the object's basic settings) page:
a) In the Enter the VSX Gateway Name field, enter the desired name for this VSX
Gateway object.
b) In the Enter the VSX Gateway IPv4 field, enter the same IPv4 address that you
configured on the Management Connection page of the VSX Gateway's First Time
Configuration Wizard.
c) In the Enter the VSX Gateway IPv6 field, enter the same IPv6 address that you
configured on the Management Connection page of the VSX Gateway's First Time
Configuration Wizard.
d) In the Select the VSX Gateway Version field, select R80.30.
e) Click Next.
5 On the Virtual Systems Creation Templates (Select the Creation Template most suitable
for your VSX deployment) page:
a) Select the applicable template.
b) Click Next.
6B If the Trust State field does not show Trust established, perform these steps:
a) Connect to the command line on the VSX Gateway.
b) Make sure there is a physical connectivity between the VSX Gateway and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) On the VSX Gateway General Properties page, click Reset.
g) Click Initialize.
Step Description
8 On the Virtual Network Device Configuration (Specify the object's basic settings) page:
a) You can select Create a Virtual Network Device and configure the first desired
Virtual Network Device at this time (we recommend to do this later) - Virtual Switch
or Virtual Router.
b) Click Next.
9 On the VSX Gateway Management (Specify the management access rules) page:
a) Examine the default access rules.
b) Select the applicable default access rules.
c) Configure the applicable source objects, if needed.
d) Click Next.
Important - These access rules apply only to the VSX Gateway (context of VS0), which is
not intended to pass any "production" traffic.
14 Enable the desired Software Blades for the VSX Gateway object itself (context of VS0).
Refer to:
• sk79700: VSX supported features on R75.40VS and above
http://supportcontent.checkpoint.com/solutions?id=sk79700
• sk106496: Software Blades updates on VSX R75.40VS and above - FAQ
http://supportcontent.checkpoint.com/solutions?id=sk106496
• Applicable Administration Guides on the R80.30 Home Page
http://supportcontent.checkpoint.com/solutions?id=sk144293.
15 Click OK to push the updated VSX Configuration.
Click View Report for more information.
Step Description
16 Examine the VSX configuration:
a) Connect to the command line on the VSX Gateway.
b) Log in to the Expert mode.
c) Run: vsx stat -v
Step 3 of 3: Configure the Virtual Devices and their Security Policies in SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server, or each Target Domain
Management Server that should manage each Virtual Device.
Workflow:
1. Install the Cluster Members.
2. Configure the ClusterXL Cluster object in SmartConsole - in either Wizard Mode, or Classic
Mode.
3. Configure the applicable Access Control policy for the ClusterXL Cluster in SmartConsole.
4. Examine the cluster configuration.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, select these two options:
Unit is a part of a cluster
ClusterXL
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
Step Description
3 Create a new Cluster object in one of these ways:
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
6 On the Cluster members' properties page, add the objects for the Cluster Members.
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this Cluster Member object.
c) Configure the main physical IP address(es) for this Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
Note - You can configure the Cluster Virtual IP address to be on a different network
than the physical IP addresses of the Cluster Members. In this case, you must
configure the required static routes on the Cluster Members.
d) In the Activation Key and Confirm Activation Key fields, enter the same Activation
Key you entered during the Cluster Member's First Time Configuration Wizard.
e) Click Initialize.
f) Click OK.
g) Repeat Steps a-f to add the second Cluster Member, and so on.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
7 On the Cluster Topology pages, configure the roles of the cluster interfaces:
a) Examine the IPv4 Network Address at the top of the page.
b) Select the applicable role:
For cluster traffic interfaces, select Representing a cluster interface and
configure the Cluster Virtual IPv4 address and its Net Mask.
Note - You can configure the Cluster Virtual IP address to be on a different
network than the physical IP addresses of the Cluster Members. In this case,
you must configure the required static routes on the Cluster Members.
For cluster synchronization interfaces, select Cluster Synchronization and
select Primary only. Check Point cluster supports only one synchronization
network.
For interfaces that do not pass the traffic between the connected networks,
select Private use of each member (don't monitor members interfaces).
c) Click Next.
Step Description
10 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
14 On the Network Management page:
a) Select each interface and click Edit. The Network: <Name of Interface> window
opens.
b) From the left navigation tree, click the General page.
c) In the General section, in the Network Type field, select the applicable type:
For cluster traffic interfaces, select Cluster. Make sure the Cluster Virtual IPv4
address and its Net Mask are correct.
For cluster synchronization interfaces, select Sync or Cluster+Sync (we do not
recommend this configuration). Check Point cluster supports only one
synchronization network.
For interfaces that do not pass the traffic between the connected networks,
select Private.
d) In the Member IPs section, make sure the IPv4 address and its Net Mask are
correct on each Cluster Member.
Note - For cluster traffic interfaces, you can configure the Cluster Virtual IP
address to be on a different network than the physical IP addresses of the Cluster
Members. In this case, you must configure the required static routes on the Cluster
Members.
e) In the Topology section:
Make sure the settings are correct in the Leads To and Security Zone fields.
Make sure to enable the Anti-Spoofing.
15 Click OK.
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Creation window, click Classic Mode.
The Gateway Cluster Properties window opens.
Step Description
5 On the General Properties page > Machine section:
a) In the Name field, enter the desired name for this ClusterXL object.
b) In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
6 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
10 On the Network Management page:
a) Select each interface and click Edit. The Network: <Name of Interface> window
opens.
b) From the left navigation tree, click the General page.
c) In the General section, in the Network Type field, select the applicable type:
For cluster traffic interfaces, select Cluster. Make sure the Cluster Virtual IPv4
address and its Net Mask are correct.
For cluster synchronization interfaces, select Sync or Cluster+Sync (we do not
recommend this configuration). Check Point cluster supports only one
synchronization network.
For interfaces that do not pass the traffic between the connected networks,
select Private.
d) In the Member IPs section, make sure the IPv4 address and its Net Mask are
correct on each Cluster Member.
Note - For cluster traffic interfaces, you can configure the Cluster Virtual IP
address to be on a different network than the physical IP addresses of the Cluster
Members. In this case, you must configure the required static routes on the Cluster
Members.
e) In the Topology section:
Make sure the settings are correct in the Leads To and Security Zone fields.
Make sure to enable the Anti-Spoofing.
11 Click OK.
Step 3 of 4: Configure the applicable Access Control policy for the ClusterXL in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this ClusterXL Cluster.
Step Description
4 Create the applicable Access Control rules.
Workflow:
1. Install the VSX Cluster Members.
2. Configure the VSX Cluster object in SmartConsole.
3. Configure the Virtual Devices on this VSX Cluster and their Security Policies in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, select these two options:
Unit is a part of a cluster
ClusterXL
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
Step Description
1 Connect with SmartConsole to the Security Management Server or Main Domain
Management Server that should manage this VSX Cluster.
Step Description
3 Create a new VSX Cluster object in one of these ways:
• From the top toolbar, click the New ( ) > VSX > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > VSX > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > VSX > Cluster.
4 On the VSX Cluster General Properties (Specify the object's basic settings) page:
a) In the Enter the VSX Cluster Name field, enter the desired name for this VSX
Cluster object.
b) In the Enter the VSX Cluster IPv4 field, enter the Cluster Virtual IPv4 address that
is configured on the Dedicated Management Interfaces (DMI).
c) In the Enter the VSX Cluster IPv6 field, enter the Cluster Virtual IPv6 address that
is configured on the Dedicated Management Interfaces (DMI).
d) In the Select the VSX Cluster Version field, select R80.30.
e) In the Select the VSX Cluster Platform field, select the applicable VSX Cluster
mode:
ClusterXL (for High Availability)
ClusterXL Virtual System Load Sharing
f) Click Next.
5 On the Virtual Systems Creation Templates (Select the Creation Template most suitable
for your VSX deployment) page:
a) Select the applicable template.
b) Click Next.
6A On the VSX Cluster Members (Define the members of this VSX Cluster) page, add the
objects for the VSX Cluster Members:
a) Click Add.
b) In the Cluster Member Name field, enter the desired name for this Cluster Member
object.
c) In the Cluster Member IPv4 Address field, enter the IPv4 address of the Dedicated
Management Interface (DMI).
d) In the Enter the VSX Gateway IPv6 field, enter the applicable IPv6 address.
e) In the Activation Key and Confirm Activation Key fields, enter the same Activation
Key you entered during the Cluster Member's First Time Configuration Wizard.
f) Click Initialize.
g) Click OK.
h) Repeat Steps a-f to add the second VSX Cluster Member, and so on.
Step Description
6B If the Trust State field does not show Trust established, perform these steps:
a) Connect to the command line on the VSX Cluster Member.
b) Make sure there is a physical connectivity between the VSX Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) On the VSX Cluster General Properties page, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
9 On the Virtual Network Device Configuration (Specify the object's basic settings) page:
a) You can select Create a Virtual Network Device and configure the first desired
Virtual Network Device at this time (we recommend to do this later) - Virtual Switch
or Virtual Router.
b) Click Next.
10 On the VSX Gateway Management (Specify the management access rules) page:
a) Examine the default access rules.
b) Select the applicable default access rules.
c) Configure the applicable source objects, if needed.
d) Click Next.
Important - These access rules apply only to the VSX Gateway (context of VS0), which is
not intended to pass any "production" traffic.
Step Description
11 On the VSX Gateway Creation Finalization page:
a) Click Finish and wait for the operation to finish.
b) Click View Report for more information.
c) Click Close.
Step Description
18 Examine the VSX and cluster configuration:
a) Connect to the command line on each VSX Cluster Member.
b) Examine the VSX configuration:
In Expert mode, run:
vsx stat -v
c) Examine the cluster state in one of these ways:
In Gaia Clish, run:
set virtual-system 0
show cluster state
In Expert mode, run:
vsenv 0
cphaprob state
d) Examine the cluster interfaces in one of these ways:
In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
In Expert mode, run:
vsenv 0
cphaprob -a if
Step 3 of 3: Configure the Virtual Devices and their Security Policies in SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server, or each Target Domain
Management Server that should manage each Virtual Device.
Step Description
5 Examine the VSX and cluster configuration:
a) Connect to the command line on each VSX Cluster Member.
b) Examine the VSX configuration:
In Expert mode, run:
vsx stat -v
c) Examine the cluster state in one of these ways:
In Gaia Clish, run:
set virtual-system 0
show cluster state
In Expert mode, run:
vsenv 0
cphaprob state
d) Examine the cluster interfaces in one of these ways:
In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
In Expert mode, run:
vsenv 0
cphaprob -a if
Workflow:
1. Install the VRRP Cluster Members.
2. Perform the initial VRRP configuration in Gaia on the VRRP Cluster Members.
3. Configure the VRRP Cluster object in SmartConsole - in either Wizard Mode, or Classic Mode.
4. Configure the applicable Access Control policy for the VRRP Cluster in SmartConsole.
5. Examine the cluster configuration.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, select these two options:
Unit is a part of a cluster
VRRP Cluster
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
Step 2 of 5: Perform the initial VRRP configuration in Gaia on the VRRP Cluster
Members
Configure the VRRP in Gaia on both Cluster Members.
Follow the instructions in the R80.30 Gaia Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Gaia_AdminGui
de/html_frameset.htm - Chapter High Availability.
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
Step Description
6 On the Cluster members' properties page, add the objects for the Cluster Members.
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this VRRP Cluster Member object.
c) Configure the main physical IP address(es) for this object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
Note - You can configure the Cluster Virtual IP address to be on a different network
than the physical IP addresses of the Cluster Members. In this case, you must
configure the required static routes on the Cluster Members.
d) In the Activation Key and Confirm Activation Key fields, enter the same Activation
Key you entered during the Cluster Member's First Time Configuration Wizard.
e) Click Initialize.
f) Click OK.
g) Repeat Steps a-f to add the second VRRP Cluster Member.
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
7 On the Cluster Topology pages, configure the roles of the cluster interfaces:
a) Examine the IPv4 Network Address at the top of the page.
b) Select the applicable role:
For cluster traffic interfaces, select Representing a cluster interface and
configure the Cluster Virtual IPv4 address and its Net Mask.
Note - You can configure the Cluster Virtual IP address to be on a different
network than the physical IP addresses of the Cluster Members. In this case,
you must configure the required static routes on the Cluster Members.
For cluster synchronization interfaces, select Cluster Synchronization and
select Primary only. Check Point cluster supports only one synchronization
network.
For interfaces that do not pass the traffic between the connected networks,
select Private use of each member (don't monitor members interfaces).
c) Click Next.
10 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
12 On the Cluster Members page:
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this VRRP Cluster Member object.
c) Configure the main physical IP address(es) for this VRRP Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
Note - You can configure the Cluster Virtual IP address to be on a different network
than the physical IP addresses of the Cluster Members. In this case, you must
configure the required static routes on the Cluster Members.
d) Click Communication.
e) In the One-time password and Confirm one-time password fields, enter the same
Activation Key you entered during the Cluster Member's First Time Configuration
Wizard.
f) Click Initialize.
g) Click Close.
h) Click OK.
i) Repeat Steps a-h to add the second Cluster Member.
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
13 On the ClusterXL and VRRP page:
a) In the select the cluster mode and configuration section, select High Availability
and VRRP.
b) In the Tracking section, select the desired option.
c) In the Advanced Settings section, although all these settings are optional, we
recommend to select them:
Use State Synchronization
Hide Cluster Members outgoing traffic behind the Cluster IP Address
Forward Cluster incoming traffic to Cluster Members IP Addresses
15 Click OK.
Step Description
3 Create a new Cluster object in one of these ways:
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Cluster Creation window, click Classic Mode.
The Gateway Cluster Properties window opens.
6 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
8 On the Cluster Members page:
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this VRRP Cluster Member object.
c) Configure the main physical IP address(es) for this VRRP Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the <Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
Note - You can configure the Cluster Virtual IP address to be on a different network
than the physical IP addresses of the Cluster Members. In this case, you must
configure the required static routes on the Cluster Members.
d) Click Communication.
e) In the One-time password and Confirm one-time password fields, enter the same
Activation Key you entered during the Cluster Member's First Time Configuration
Wizard.
f) Click Initialize.
g) Click Close.
h) Click OK.
i) Repeat Steps a-h to add the second Cluster Member.
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
9 On the ClusterXL and VRRP page:
a) In the select the cluster mode and configuration section, select High Availability
and VRRP.
b) In the Tracking section, select the desired option.
c) In the Advanced Settings section, although all these settings are optional, we
recommend to select them:
Use State Synchronization
Hide Cluster Members outgoing traffic behind the Cluster IP Address
Forward Cluster incoming traffic to Cluster Members IP Addresses
11 Click OK.
Step 4 of 5: Configure the applicable Access Control policy for the VRRP Cluster in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this VRRP Cluster.
Step Description
3 Examine the cluster interfaces in one of these ways:
• In Gaia Clish, run:
show cluster members interfaces all
• In Expert mode, run:
cphaprob -a if
Installing a Standalone
In This Section:
Configuring a Standalone in Standard Mode....................................................... 109
Configuring a Standalone in Quick Setup Mode .................................................. 112
In a Standalone deployment, a Check Point computer runs both the Security Gateway and Security
Management Server products.
Important:
• These instructions apply only to Check Point Appliances that support a Standalone
deployment.
• These instructions apply to all Open Servers.
• These instructions apply to Virtual Machines.
See the R80.30 Release Notes http://downloads.checkpoint.com/dc/download.htm?ID=78043 for
the requirements for a Standalone deployment.
You can configure a Check Point Standalone deployment using one of these methods:
Method Description
Standard (on Supported on Check Point appliances (that support a Standalone deployment),
page 109) Open Servers, and Virtual Machines that meet the requirements listed in the
Release Notes.
Quick Setup Supported only on Check Point appliances (that support a Standalone
(on page 112) deployment).
Installs a Standalone on a Check Point appliance in Bridge Mode.
For more information on Gaia Quick Standalone Setup on Check Point
appliances, see sk102231
http://supportcontent.checkpoint.com/solutions?id=sk102231.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select both Security Gateway and Security Management.
b) In the Clustering section:
Clear Unit is a part of a cluster, type.
In the Define Security Management as field, select Primary.
• In the Security Management Administrator window, select one of these options:
• Use Gaia administrator
• Define a new administrator and configure it
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect
• This machine - Allows only the single specified computer to connect
• Network - Allows all computers on the specified network to connect
• Range of IPv4 addresses - Allows all computers in the specified range to connect
Step Description
3 Open the Standalone object.
Check Point Gateway properties window opens on the General Properties page.
7 Click OK.
Step 3 of 3: Configure the applicable Access Control policy for the Standalone in
SmartConsole
Step Description
1 Connect with SmartConsole to the Standalone.
Post-Installation Configuration
After the installation is complete, and you rebooted the Check Point computer:
• Configure the applicable settings in the Check Point Configuration Tool.
• Check the recommended and available software packages in CPUSE (on page 118).
The Check Point Configuration Tool lets you configure these settings:
Check Point computer Commands Available Configuration Options
Security Management cpconfig (1) Licenses and contracts
Server, (2) Administrator
Dedicated Log Server, (3) GUI Clients
Dedicated SmartEvent (4) SNMP Extension
Server (5) Random Pool
(6) Certificate Authority
(7) Certificate's Fingerprint
(8) Automatic start of Check Point
Products
(9) Exit
(13) Exit
(11) Exit
(3) GUI Clients Configure the computers that are allowed to Connect
with SmartConsole to this server.
(5) Random Pool Configure the random data to be used for various
cryptographic operations on this server.
(7) Certificate's Show the SIC certificate's fingerprint for this server.
Fingerprint
This fingerprint verifies the identity of this server when
you connect to it with SmartConsole for the first time.
(3) Random Pool Configure the random data to be used for various
cryptographic operations on this server.
(5) Certificate's Show the SIC certificate's fingerprint for this server.
Fingerprint
This fingerprint verifies the identity of this server when
you connect to it with SmartConsole for the first time.
(7) GUI clients Configure the computers that are allowed to Connect
with SmartConsole to this server.
(11) IPv6 Support for R80.30 Multi-Domain Server does not support IPv6.
Multi-Domain Server
Do not use this option (Known Limitation PMTR-14989).
(4) Random Pool Configure the random data to be used for various
cryptographic operations on this server.
(5) Secure Internal Reset and configure the one-time activation key
Communication (between 4 and 127 characters long) for Secure Internal
Communication (SIC) with a Management Server.
For more information, see the R80.30 Security
Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAd
minGuides/EN/CP_R80.30_SecurityManagement_Admi
nGuide/html_frameset.htm.
(6) Enable cluster membership Configure this Security Gateway as part of a Check
for this gateway Point cluster.
(6) Disable cluster For more information, see the R80.30 ClusterXL
membership for this gateway
Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAd
minGuides/EN/CP_R80.30_ClusterXL_AdminGuide/htm
l_frameset.htm.
(7) Enable Check Point Per Configure the VSX Virtual System Load Sharing on this
Virtual System State VSX Gateway.
(7) Disable Check Point Per For more information, see the R80.30 VSX
Virtual System State
Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAd
minGuides/EN/CP_R80.30_VSX_AdminGuide/html_fram
eset.htm
(10) Automatic start of Check Select which of the installed Check Point products start
Point Products automatically during boot.
This option is for Check Point Support use.
Installation Description
Local You use the CPUSE (sk92449
http://supportcontent.checkpoint.com/solutions?id=sk92449) on each Gaia
computer to install the applicable packages.
Central You use the Central Deployment Tool (sk111158
http://supportcontent.checkpoint.com/solutions?id=sk111158) on the
Management Server to deploy the applicable packages to the desired managed
Security Gateways and Clusters.
You can See the instructions for a Gaia computer that is not
perform connected to the Internet.
an offline
installation.
To install Software Packages centrally, from the Management Server on each managed
Security Gateway and Cluster Member
Use the Central Deployment Tool. See sk111158
http://supportcontent.checkpoint.com/solutions?id=sk111158 for detailed steps.
c) Install the modified Firewall policy on the R7x Security Gateway or Cluster.
d) If later you upgrade this R7x Security Gateway or Cluster to R80.10 or higher, delete this
explicit rule.
• On your Security Management Servers, Multi-Domain Servers, Domain Management Servers,
Multi-Domain Log Servers, Domain Log Servers, Log Servers, and SmartEvent Servers:
Make a copy of all custom configurations in the applicable directories and files.
The upgrade process replaces all existing files with default files. You must not copy the
customized configuration files from the current version to the upgraded version, because
these files can be unique for each version. You must make all the desired custom
configurations again after the upgrade.
List of the applicable directories:
• $FWDIR/lib/
• $FWDIR/conf/
• $CVPNDIR/conf/
• /opt/CP*/lib/
• /opt/CP*/conf/
• $MDSDIR/conf/
• $MDSDIR/customers/<Name_of_Domain>/CP*/lib/
• $MDSDIR/customers/<Name_of_Domain>/CP*/conf/
• For your Management Servers in High Availability configuration, plan the upgrade:
Management Supported Upgrades
Server
Security From R80.X to R80.30:
Management
1. Upgrade the Primary Security Management Server.
Servers
2. Upgrade the Secondary Security Management Server.
From R7X to R80.30:
1. Upgrade the Primary Security Management Server.
2. Perform a clean install of the Secondary Security Management Server.
3. Connect the Secondary Security Management Server to the Primary
Security Management Server.
• Before you upgrade a Multi-Domain Server, we recommend the steps below to optimize the
upgrade process:
Step Description
1 Delete all unused Threat Prevention Profiles on the Global Domain:
On R80.x Multi-Domain Server:
a) Connect with SmartConsole to the Global Domain.
b) From the left navigation panel, click Security Policies.
c) Open every policy.
d) In the top section, click Threat Prevention.
e) In the bottom section Threat Tools, click Profiles.
f) Delete all unused Threat Prevention Profiles.
g) Publish the session.
h) Close SmartConsole.
On R77.x Multi-Domain Server:
a) Connect with SmartDashboard to the Global Domain.
b) Go to Threat Prevention tab.
c) From the left tree, click Profiles.
d) Delete all unused Threat Prevention Profiles.
e) Save the changes (click File > Save).
f) Close SmartDashboard.
• Make sure you have valid licenses installed on all applicable Check Point computers - source
and target.
• Make sure you have a valid Service Contract that includes software upgrades and major
releases registered to your Check Point User Center account (on page 135).
Installation and Upgrade Guide R80.30 | 124
The contract file is stored on the Management Server and downloaded to Check Point Security
Gateways during the upgrade process.
For more on Service Contracts, see sk33089
http://supportcontent.checkpoint.com/solutions?id=sk33089.
• Before you start an upgrade or migration procedure on your Management Servers, you must
close all GUI clients (SmartConsole applications) connected to your Check Point computers.
• Before you start an upgrade of your Security Gateway and Cluster Members, you must upgrade
the Management Server.
• On Smart-1 appliances with Multi-Domain Server or Multi-Domain Log Server installed, if you
configured an interface other than Mgmt as the Leading interface, the upgrade process or
clean install process (with CPUSE) configures the interface Mgmt to be the Leading interface.
To configure another interface as the Leading interface after the upgrade, see sk107336
http://supportcontent.checkpoint.com/solutions?id=sk107336.
• $PPKDIR/boot/modules/simkern.conf
• $PPKDIR/boot/modules/sim_aff.conf
• /var/ace/sdconf.rec
• /var/ace/sdopts.rec
• /var/ace/sdstatus.12
• /var/ace/securid
• Make sure you have a valid Service Contract that includes software upgrades and major
releases registered to your Check Point User Center account (on page 135).
The contract file is stored on the Management Server and downloaded to Check Point Security
Gateways during the upgrade process.
For more on Service Contracts, see sk33089
http://supportcontent.checkpoint.com/solutions?id=sk33089.
Prerequisites:
• Make sure you use the latest version of this document (see the Important Information page for
links).
• See the R80.30 Release Notes
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_RN/html_fra
meset.htm for:
• Supported upgrade paths
• Minimum hardware and operating system requirements
• Supported Security Gateways
• Make sure to read all applicable known limitations in the R80.30 Known Limitations SK
http://supportcontent.checkpoint.com/solutions?id=sk122486.
• Before starting an upgrade of your Security Gateway and Cluster Members, you must upgrade
the Management Server.
Procedure:
Step Description
1 Open these files on the Management Server and write down all custom changes in the
applicable files:
• Apache configuration:
$CVPNDIR/conf/httpd.conf
$CVPNDIR/conf/includes/*
• Local certificates:
$CVPNDIR/var/ssl/ca-bundle/*
• RSA configuration:
/var/ace/sdconf.rec
Step Description
• Mobile Access Portal configuration (run these commands in Expert mode to see the
applicable files):
• # find $CVPNDIR/ -name *.php -type f -exec ls {} \;
• # find $CVPNDIR/ -name *.gif -type f -exec ls {} \;
• # find $CVPNDIR/ -name *.jpg -type f -exec ls {} \;
2 Upgrade the Management Server to R80.30 using one of the supported methods (on page
131).
3 Update the Mobile Access Endpoint Compliance:
a) In SmartConsole, from the left navigation panel, click Security Policies.
b) In the Shared Policies section, click Mobile Access > Open Mobile Access Policy in
SmartDashboard.
c) In SmartDashboard, click Mobile Access tab > open Endpoint Security On Demand
> click Endpoint Compliance Updates > click Update Databases Now.
d) Close SmartDashboard.
4 Manually edit the default files on the upgraded the Management Server to include your
custom changes.
Note - During the upgrade, vSEC Controller R80.10 or below does not communicate with the Data
Centers. Therefore, Data Center objects are not updated on the vSEC Controller or the Security
Gateways.
Upgrade Methods
In This Section:
Upgrade with CPUSE ......................................................................................... 132
Advanced Upgrade of Management Servers and Log Servers ............................. 132
Migrating and Upgrading of Management Servers and Log Servers.................... 133
Gradual Upgrade of R7x Multi-Domain Server.................................................... 134
You can use this method to upgrade your Security Gateways and Cluster Members:
Computer CPUSE
Security Gateways, Supported (on page 132)
VSX Gateways,
Cluster Members
You can use these methods to upgrade your Management Servers and Log Servers:
Dedicated SmartEvent Server Supported (on Supported (on Supported (on Not applicable
page 132) page 132) page 133)
Important:
• Upgrade with CPUSE is supported only on Check Point computers that currently run Gaia
Operating System.
• Before you upgrade your Security Gateways and Cluster Members, you must upgrade your
Management Servers that manage them.
• You must upgrade your dedicated Log Servers and SmartEvent Servers to the same version as
the Management Servers that manage them.
You must upgrade your Management Servers before you can upgrade these dedicated servers.
• You must upgrade your Multi-Domain Log Servers to the same version as the Multi-Domain
Servers that manage them.
• Gradual Upgrade is supported only from R7x versions.
Step Description
3 Get the R80.30 Check Point computer:
• If the current Check Point computer runs on Gaia, you can upgrade it to R80.30.
• If the current Check Point computer runs an operating system other than Gaia, you
must perform a clean install of the R80.30.
4 Import the entire management database.
Contract Verification
Before you upgrade your Management Server to R80.30, you must have a valid Support Contract
that includes software upgrades and major releases registered to your Check Point User Center
account. By verifying your status with the User Center, the contract file enables you to remain
compliant with current Check Point licensing standards.
As in all upgrade procedures, first upgrade your Security Management Server or Multi-Domain
Server before upgrading the Security Gateways.
When you upgrade a Management Server, the upgrade process checks to see whether a Contract
File is already present. If not, you can download a Contract File from the Check Point User Center
(manually, or in SmartUpdate) and import it.
If the Contract File does not cover the Management Server, a message informs you that the
Management Server is not eligible for upgrade. The absence of a valid Contract File does not
prevent upgrade. You can download a valid Contract File later.
Option Description
Download a If you have Internet access and a valid User Center
contract file from https://usercenter.checkpoint.com account, download a Contract File
the User Center directly from your User Center account:
Import a local If the Management Server does not have Internet access:
contract file
a) On a computer with Internet access, log in to your User Center
https://usercenter.checkpoint.com account.
b) In the top menu, click Assets/Info > Download Contract File and
follow the instructions on the screen.
c) Transfer the downloaded contract file to your Management Server.
d) Select Import a local contracts file.
e) Enter the full path to the location where you stored the contract file.
Continue without Select this option, if you intend to get and install a valid Contract File later.
contract Note that at this point your managed Security Gateways are not strictly
information eligible for an upgrade. You may be in violation of your Check Point
Licensing Agreement, as shown in the final message of the upgrade
process.
The most important files in the Management Server Migration Tool package:
Package Description
migrate.conf Holds configuration settings for Advanced Upgrade / Database
Migration.
migrate Exports and imports the management database and applicable
Check Point configuration:
• ./migrate export
• ./migrate import
ips_upgrade_tool Runs the IPS database upgrade.
pre_upgrade_verifier Analyzes compatibility of the currently installed configuration with
the version, to which you upgrade. It gives a report on the actions to
take before and after the upgrade.
This tool is required only when you upgrade from R77.30 (or lower)
version to R80.30.
Package Description
puv_report_generator Runs at the end of pre_upgrade_verifier and converts the text
report file to an HTML file.
This tool is required only when you upgrade from R77.30 (or lower)
version to R80.30.
Note - This is required only when you upgrade from R77.30 (or lower) version to R80.30.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Upgrade the Security Management Server with CPUSE
2. Install the R80.30 SmartConsole
3. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
4. Install the management database
5. Install the Event Policy
6. Test the functionality
Step 3 of 6: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export the
entire management database
3. Get the R80.30 Security Management Server
4. On the R80.30 Security Management Server, import the databases
5. Install the R80.30 SmartConsole
6. Install the licenses and change the IP address of the R80.30 Security Management Server
7. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
8. Install the management database
9. Install the Event Policy
10. Test the functionality
2 Transfer the R80.30 Management Server Migration Tool package to the current Security
Management Server to some directory (for example,
/var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 10: On the current Security Management Server, run the Pre-Upgrade Verifier
and export the entire management database
Step Description
1 Connect to the command line on the current Security Management Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@MGMT:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@MGMT:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) In a Management High Availability environment, if you made changes,
synchronize the Management Servers immediately after these changes.
iii) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate export [-l | -x] [-n] /<Full
Path>/<Name of Exported File>
• If Endpoint Policy Management blade is enabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate export [-l | -x] [-n]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>
For details, see:
• The R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_
ReferenceGuide/html_frameset.htm - Chapter Security Management Server
Commands - Section migrate.
• sk133312 http://supportcontent.checkpoint.com/solutions?id=sk133312.
7 This step applies only to R7x and R80 versions.
If SmartEvent Software Blade is enabled, then export the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
9 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
• If you upgrade from R80 (or higher) version to R80.30, then these options are available:
• The IP addresses of the source and target Security Management Servers can be the same.
If in the future you need to have a different IP address on the R80.30 Security Management
Server, you can change it. For applicable procedures, see sk40993
Installation and Upgrade Guide R80.30 | 145
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutio
ndetails=&solutionid=sk40993&js_peid=P-114a7bc3b09-10006&partition=General&product
=Security and sk65451 http://supportcontent.checkpoint.com/solutions?id=sk65451.
Note that you have to issue licenses for the new IP address.
• The IP addresses of the source and target Security Management Servers can be different.
Note that you have to issue licenses for the new IP address.
You must install the new licenses only after you import the databases.
• If you upgrade from R77.30 (or lower) version to R80.30, then the IP addresses of the source
and target Security Management Servers must be the same.
If you need to have a different IP address on the R80.30 Security Management Server, you can
change it only after the upgrade procedure. Note that you have to issue licenses for the new IP
address.
Step 4 of 10: On the R80.30 Security Management Server, import the databases
Step Description
1 Connect to the command line on the R80.30 Security Management Server.
3 Transfer the exported databases from an external storage to the R80.30 Security
Management Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Security
Management Server:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
6 Import the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate import [-l | -x] [-n] /<Full
Path>/<Name of Exported File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate import [-l | -x] [-n]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
For details, see:
• The R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_
ReferenceGuide/html_frameset.htm - Chapter Security Management Server
Commands - Section migrate.
• sk133312 http://supportcontent.checkpoint.com/solutions?id=sk133312.
If you upgrade from R80 (or higher) version, and the IP addresses of the source and target
Security Management Servers are different:
a) Issue licenses for the new IP address in your Check Point User Center account.
b) Install the new licenses on the R80.30 Security Management Server.
If you upgrade from R77.30 (or lower) version to R80.30, then the IP addresses of the
source and target Security Management Servers must be the same.
• If you need to have a different IP address on the R80.30 Security Management Server,
you can change it only after the upgrade procedure. Note that you have to issue
licenses for the new IP address.
7 This step applies only if you upgraded from R7x and R80 versions.
If SmartEvent Software Blade is enabled, then import the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
Step 6 of 10: Install the licenses and change the IP address of the R80.30 Security
Management Server
Scenario Instructions
You upgraded from R80 Follow these steps:
(or higher) version to
1. Issue licenses for the new IP address in your Check Point User
R80.30, and the IP
Center https://usercenter.checkpoint.com account.
addresses of the
source and target 2. Install the new licenses on the R80.30 Security Management Server.
Security Management
Servers are different
Scenario Instructions
You upgraded from Follow these steps (based on sk40993
R77.30 (or lower) https://supportcenter.checkpoint.com/supportcenter/portal?eventSubm
version to R80.30 and it_doGoviewsolutiondetails=&solutionid=sk40993&js_peid=P-114a7bc3b
need to have a different 09-10006&partition=General&product=Security):
IP address on the
1. Issue licenses for the new IP address in your Check Point User
R80.30 Security
Center https://usercenter.checkpoint.com account.
Management Server
2. Perform the required changes in the SmartConsole:
a) Connect with SmartConsole to the Security Management Server.
b) From the left navigation panel, click Gateways & Servers.
c) Open the Security Management Server object.
d) On the General Properties page, change the current IP address
to the new IP address.
e) On the Network Management page, edit the applicable interface
and change the current IP address to the new IP address.
f) Click OK.
g) Publish the session.
h) Close the SmartConsole.
3. Stop the Check Point services:
a) Connect to the command line.
b) Log in to either Gaia Clish, or Expert mode.
c) Run: cpstop
4. Perform the required changes in Gaia OS:
a) Connect to either Gaia Portal, or Gaia Clish.
b) Edit the applicable interface and change the current IP address
to the new IP address.
You can perform this change in either Gaia Portal, or Gaia Clish.
For details, see R80.30 Gaia Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/E
N/CP_R80.30_Gaia_AdminGuide/html_frameset.htm.
Note: If this Security Management Server has only one interface,
then your HTTPS and SSH connection to this Security Management
Server is interrupted when you change its IP address. You need to
connect again. To avoid this interruption, connect to the Security
Management Server over the serial console.
5. Install the new licenses on the R80.30 Security Management Server.
You can do this either in the CLI with the cplic put command, or in
the Gaia Portal.
6. Start the Check Point services:
a) Connect to the command line.
b) Log in to either Gaia Clish, or Expert mode.
c) Run: cpstart Installation and Upgrade Guide R80.30 | 149
Note - Make sure that there is connectivity between the Security Management Server and the
managed Security Gateways in your network.
Step 7 of 10: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export the
entire management database
3. Install a new R80.30 Security Management Server
4. On the R80.30 Security Management Server, import the databases
5. Install the R80.30 SmartConsole
6. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
7. Install the management database
8. Install the Event Policy
9. Test the functionality
10. Disconnect the old Security Management Server from the network
2 Transfer the R80.30 Management Server Migration Tool package to the current Security
Management Server to some directory (for example,
/var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 11: On the current Security Management Server, run the Pre-Upgrade Verifier
and export the entire management database
Step Description
1 Connect to the command line on the current Security Management Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@MGMT:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@MGMT:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) In a Management High Availability environment, if you made changes,
synchronize the Management Servers immediately after these changes.
iii) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate export [-l | -x] [-n] /<Full
Path>/<Name of Exported File>
• If Endpoint Policy Management blade is enabled on this Security Management Server:
[Expert@MGMT:0]# yes | nohup ./migrate export [-l | -x] [-n]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>
For details, see:
• The R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_
ReferenceGuide/html_frameset.htm - Chapter Security Management Server
Commands - Section migrate.
• sk133312 http://supportcontent.checkpoint.com/solutions?id=sk133312.
7 This step applies only to R7x and R80 versions.
If SmartEvent Software Blade is enabled, then export the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
9 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 11: On the R80.30 Security Management Server, import the databases
Step Description
1 Connect to the command line on the R80.30 Security Management Server.
Step Description
2 Log in to the Expert mode.
3 Transfer the exported databases from an external storage to the R80.30 Security
Management Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Security
Management Server:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
8 Restart the Check Point services:
[Expert@MGMT:0]# cpstop
[Expert@MGMT:0]# cpstart
Step 6 of 11: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
Step Description
7 Wait for these messages to appear:
SmartEvent Policy Installer installation complete
SmartEvent Policy Installer installation succeeded
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
Step 10 of 11: Disconnect the old Security Management Server from the network
Step 11 of 11: Connect the new Security Management Server to the network
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
2 Upgrade the Secondary Security Management Server with one of the supported methods:
• CPUSE (on page 140)
• Advanced Upgrade (on page 143)
• Migration (on page 152)
3 Get the R80.30 SmartConsole. See Installing SmartConsole (on page 68).
4 Connect with the SmartConsole to the R80.30 Primary Security Management Server.
Step Description
5 Make sure SIC communication works correctly with the Secondary Security Management
Server:
a) Open the Secondary Security Management Server object.
b) On the General Properties page, click Communication.
c) Click Test SIC Status.
The SIC Status must show Communicating.
d) Click Close.
e) Click OK.
2 Perform a clean install of the R80.30 on the Secondary Security Management Server (on
page 48).
3 Get the R80.30 SmartConsole. See Installing SmartConsole (on page 68).
4 Connect with the SmartConsole to the R80.30 Primary Security Management Server.
5 Make sure SIC communication works correctly with the Secondary Security Management
Server:
a) Open the Secondary Security Management Server object.
b) On the General Properties page, click Communication.
c) Click Reset.
d) Click Initialize.
e) Click Close.
f) Click OK.
Step Description
7 Install the Event Policy:
Important - This step applies only if the SmartEvent Correlation Unit Software Blade is
enabled on the R80.30 Security Management Servers.
a) In the SmartConsole, from the left navigation panel, click Logs & Monitor.
b) At the top, click + to open a new tab.
c) In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
d) In the top left corner, click Menu > Actions > Install Event Policy.
e) Confirm.
f) Wait for these messages to appear:
SmartEvent Policy Installer installation complete
SmartEvent Policy Installer installation succeeded
g) Click Close.
h) Close the Legacy SmartEvent client.
3 Before you upgrade a dedicated Log Server or Endpoint Policy Server, you must upgrade
the applicable Management Server that manages it.
4 You must upgrade your Security Management Servers, Multi-Domain Servers, and
Endpoint Security Management Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the Log Server or
Endpoint Policy Server.
Workflow:
1. Upgrade the Log Server with CPUSE
2. Install the management database
3. Install the Event Policy
4. Test the functionality on R80.30 Log Server
5. Test the functionality on R80.30 Management Server
Step Description
2 In the top left corner, click Menu > Install database.
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
3 Before you upgrade a dedicated Log Server or Endpoint Policy Server, you must upgrade
the applicable Management Server that manages it.
4 You must upgrade your Security Management Servers, Multi-Domain Servers, and
Endpoint Security Management Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the Log Server or
Endpoint Policy Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Log Server, run the Pre-Upgrade Verifier and export the entire management
database
3. Get the R80.30 Log Server
4. On the R80.30 Log Server, import the database
5. Install the management database
6. Install the Event Policy
7. Test the functionality on R80.30 Log Server
8. Test the functionality on R80.30 Management Server
Step Description
2 Transfer the R80.30 Management Server Migration Tool package to the current Log
Server to some directory (for example, /var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 8: On the current Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
1 Connect to the command line on the current Log Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@LogServer:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@MGMT:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) Run the Pre-Upgrade Verifier again.
8 Transfer the exported database from the current Log Server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target R80.30 Log Servers must be the same. If you need to
have a different IP address on the R80.30 Log Server, you can change it only after the upgrade
procedure. Note that you have to issue licenses for the new IP address. For applicable
procedures, see sk40993
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetail
s=&solutionid=sk40993&js_peid=P-114a7bc3b09-10006&partition=General&product=Security and
sk65451 http://supportcontent.checkpoint.com/solutions?id=sk65451.
3 Transfer the exported database from an external storage to the R80.30 Log Server, to
some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Restart the Check Point services:
[Expert@LogServer:0]# cpstop
[Expert@LogServer:0]# cpstart
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
3 Before you upgrade a dedicated Log Server or Endpoint Policy Server, you must upgrade
the applicable Management Server that manages it.
4 You must upgrade your Security Management Servers, Multi-Domain Servers, and
Endpoint Security Management Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the Log Server or
Endpoint Policy Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Log Server, run the Pre-Upgrade Verifier and export the entire management
database
3. Install a new R80.30 Log Server
4. On the R80.30 Log Server, import the database
5. Install the management database
6. Install the Event Policy
7. Test the functionality on R80.30 Log Server
8. Test the functionality on R80.30 Management Server
Step Description
2 Transfer the R80.30 Management Server Migration Tool package to the current Log
Server to some directory (for example, /var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 8: On the current Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
1 Connect to the command line on the current Log Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@LogServer:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@MGMT:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) Run the Pre-Upgrade Verifier again.
8 Transfer the exported database from the current Log Server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
3 Transfer the exported database from an external storage to the R80.30 Log Server, to
some directory.
Note - Make sure to transfer the file in the binary mode.
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the applicable
Management Server that manages it.
4 You must upgrade your Security Management Servers and Multi-Domain Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the SmartEvent
Server.
Workflow:
1. Upgrade the SmartEvent Server with CPUSE
2. Install the management database
3. Install the Event Policy
4. Test the functionality on R80.30 SmartEvent Server
5. Test the functionality on R80.30 Management Server
Step Description
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the applicable
Management Server that manages it.
4 You must upgrade your Security Management Servers and Multi-Domain Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the SmartEvent
Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current SmartEvent Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Get the R80.30 SmartEvent Server
4. On the R80.30 SmartEvent Server, import the database
5. Install the management database
6. Install the Event Policy
7. Test the functionality on R80.30 SmartEvent Server
8. Test the functionality on R80.30 Management Server
2 Transfer the R80.30 Management Server Migration Tool package to the current
SmartEvent Server to some directory (for example,
/var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 8: On the current SmartEvent Server, run the Pre-Upgrade Verifier and export
the entire management database
Step Description
1 Connect to the command line on the current SmartEvent Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@SmartEventServer:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@SmartEventServer:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) Run the Pre-Upgrade Verifier again.
9 Transfer the exported database from the current SmartEvent Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target R80.30 SmartEvent Servers must be the same. If you
need to have a different IP address on the R80.30 SmartEvent Server, you can change it only after
the upgrade procedure. Note that you have to issue licenses for the new IP address. For
applicable procedures, see sk40993
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetail
s=&solutionid=sk40993&js_peid=P-114a7bc3b09-10006&partition=General&product=Security and
sk65451 http://supportcontent.checkpoint.com/solutions?id=sk65451.
3 Transfer the exported database from an external storage to the R80.30 SmartEvent Server,
to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Restart the Check Point services:
[Expert@SmartEvent:0]# cpstop
[Expert@SmartEvent:0]# cpstart
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the applicable
Management Server that manages it.
4 You must upgrade your Security Management Servers and Multi-Domain Servers.
5 You must close all GUI clients (SmartConsole applications) connected to the SmartEvent
Server.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current SmartEvent Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Install a new R80.30 SmartEvent Server
4. On the R80.30 SmartEvent Server, import the database
5. Install the management database
6. Install the Event Policy
7. Test the functionality on R80.30 SmartEvent Server
8. Test the functionality on R80.30 Management Server
2 Transfer the R80.30 Management Server Migration Tool package to the current
SmartEvent Server to some directory (for example,
/var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 8: On the current SmartEvent Server, run the Pre-Upgrade Verifier and export
the entire management database
Step Description
1 Connect to the command line on the current SmartEvent Server.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@SmartEventServer:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@SmartEventServer:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) Run the Pre-Upgrade Verifier again.
9 Transfer the exported database from the current SmartEvent Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
3 Transfer the exported database from an external storage to the R80.30 SmartEvent Server,
to some directory.
Note - Make sure to transfer the file in the binary mode.
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the dedicated R80.30 SmartEvent Server.
3 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
4 In the top left corner, click Menu > Actions > Install Event Policy.
5 Confirm.
7 Click Close.
2 Make sure the configuration was upgraded correctly and it works as expected.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Get the required upgrade tools
2. Upgrade the Security Management Server with CPUSE
3. Install the R80.30 SmartConsole
4. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
5. Install the management database
6. Install the Event Policy
Installation and Upgrade Guide R80.30 | 189
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MGMT:0]#
Step 4 of 7: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
Installation and Upgrade Guide R80.30 | 190
Step Description
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Security Management Server
2. On the R80.20.M1 / R80.20.M2 Security Management Server, run the Pre-Upgrade Verifier and
export the entire management database
3. Perform clean install of the R80.30 Security Management Server
4. Get the required upgrade tools on the R80.30 Security Management Server
5. On the R80.30 Security Management Server, import the databases
Installation and Upgrade Guide R80.30 | 192
Step 1 of 11: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Security
Management Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MGMT:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 11: On the R80.20.M1 / R80.20.M2 Security Management Server, run the
Pre-Upgrade Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Security Management Server.
Step Description
3 Run the Pre-Upgrade Verifier.
• If this Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# $FWDIR/scripts/migrate_server verify -v R80.30
• If this Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# $FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
4 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
• -l - Exports the Check Point logs without log indexes in the $FWDIR/log/ directory.
Note - The command can export only closed logs (to which the information is not
currently written).
• -x - Exports the Check Point logs with their log indexes in the $FWDIR/log/
directory. Note - The command can export only closed logs (to which the information is
not currently written).
• --exclude-uepm-postgres-db - Does not back up the PostgreSQL database
during the export operation.
• --include-uepm-msi-files - Backs up the MSI files from the Endpoint Security
Management Server during the export operation.
7 Calculate the MD5 for the exported database files:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
8 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 3 of 11: Perform clean install of the R80.30 Security Management Server
Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the R80.30 Security Management Server from scratch. (on page 45)
Important - These options are available:
• The IP addresses of the source and target Security Management Servers can be the same.
If in the future you need to have a different IP address on the R80.30 Security Management
Server, you can change it.
For applicable procedures, see sk40993
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutionde
tails=&solutionid=sk40993&js_peid=P-114a7bc3b09-10006&partition=General&product=Securi
ty and sk65451 http://supportcontent.checkpoint.com/solutions?id=sk65451.
Note that you have to issue licenses for the new IP address.
• The IP addresses of the source and target Security Management Servers can be different.
Note that you have to issue licenses for the new IP address.
You must install the new licenses only after you import the databases.
Step 4 of 11: Get the required upgrade tools on the R80.30 Security Management Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
Step Description
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MGMT:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 5 of 11: On the R80.30 Security Management Server, import the databases
Step Description
1 Connect to the command line on the R80.30 Security Management Server.
3 Transfer the exported databases from an external storage to the R80.30 Security
Management Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Security
Management Server:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
6 Import the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Note - The migrate_server import command automatically restarts Check Point
services (performs cpstop and cpstart).
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
• -l - Imports the Check Point logs without log indexes in the $FWDIR/log/ directory.
• -x - Imports the Check Point logs with their log indexes in the $FWDIR/log/
directory.
• --exclude-uepm-postgres-db - Does not restore the PostgreSQL database during
the import operation.
• --include-uepm-msi-files - Restores the MSI files from the Endpoint Security
Management Server during the import operation.
Step 7 of 11: Install the new licenses, if the R80.30 Security Management Server has a
different IP address than the source Security Management Server
If the IP addresses of the source and target Security Management Servers are different, follow
these steps:
Step Description
1 Issue licenses for the new IP address in your Check Point User Center
https://usercenter.checkpoint.com account.
3 Wait for a couple of minutes for the Security Management Server to detect the new
licenses.
Alternatively, restart Check Point services:
[Expert@MGMT:0]# cpstop
[Expert@MGMT:0]# cpstart
Step 8 of 11: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
Step Description
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Security Management Server
2. On the R80.20.M1 / R80.20.M2 Security Management Server, run the Pre-Upgrade Verifier and
export the entire management database
3. Install a new R80.30 Security Management Server
4. Get the required upgrade tools on the new R80.30 Security Management Server
5. On the R80.30 Security Management Server, import the databases
Installation and Upgrade Guide R80.30 | 201
Step 1 of 13: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Security
Management Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MGMT:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 13: On the R80.20.M1 / R80.20.M2 Security Management Server, run the
Pre-Upgrade Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Security Management Server.
Step Description
3 Run the Pre-Upgrade Verifier.
• If this Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# $FWDIR/scripts/migrate_server verify -v R80.30
• If this Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# $FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
4 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
• -l - Exports the Check Point logs without log indexes in the $FWDIR/log/ directory.
Note - The command can export only closed logs (to which the information is not
currently written).
• -x - Exports the Check Point logs with their log indexes in the $FWDIR/log/
directory. Note - The command can export only closed logs (to which the information is
not currently written).
• --exclude-uepm-postgres-db - Does not back up the PostgreSQL database
during the export operation.
• --include-uepm-msi-files - Backs up the MSI files from the Endpoint Security
Management Server during the export operation.
7 Calculate the MD5 for the exported database files:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
8 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 13: Get the required upgrade tools on the new R80.30 Security Management
Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MGMT:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MGMT:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 5 of 13: On the R80.30 Security Management Server, import the databases
Step Description
1 Connect to the command line on the R80.30 Security Management Server.
3 Transfer the exported databases from an external storage to the R80.30 Security
Management Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Security
Management Server:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
6 Import the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Note - The migrate_server import command automatically restarts Check Point
services (performs cpstop and cpstart).
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
• -l - Imports the Check Point logs without log indexes in the $FWDIR/log/ directory.
• -x - Imports the Check Point logs with their log indexes in the $FWDIR/log/
directory.
• --exclude-uepm-postgres-db - Does not restore the PostgreSQL database during
the import operation.
• --include-uepm-msi-files - Restores the MSI files from the Endpoint Security
Management Server during the import operation.
Step 7 of 13: Install the new licenses, if the R80.30 Security Management Server has a
different IP address than the source Security Management Server
If the IP addresses of the source and target Security Management Servers are different, follow
these steps:
Step Description
1 Issue licenses for the new IP address in your Check Point User Center
https://usercenter.checkpoint.com account.
3 Wait for a couple of minutes for the Security Management Server to detect the new
licenses.
Alternatively, restart Check Point services:
[Expert@MGMT:0]# cpstop
[Expert@MGMT:0]# cpstart
Step 8 of 13: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
Step Description
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
Step 12 of 13: Disconnect the old R80.20.M1 / R80.20.M2 Security Management Server
from the network
Step 13 of 13: Connect the new R80.30 Security Management Server to the network
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
2 Upgrade the Secondary Security Management Server with one of the supported methods:
• CPUSE (on page 189)
• Advanced Upgrade (on page 192)
• Migration (on page 201)
3 Get the R80.30 SmartConsole. See Installing SmartConsole (on page 68).
Step Description
5 Make sure SIC communication works correctly with the Secondary Security Management
Server:
a) Open the Secondary Security Management Server object.
b) On the General Properties page, click Communication.
Upgrading Multi-Domain
In This Section:
Upgrading one Multi-Domain Server from R80.20, R80.10, and lower ................. 213
Upgrading one Multi-Domain Server from R80.20.M1 or R80.20.M2 ................... 238
Upgrading Multi-Domain Servers in High Availability from R80.20, R80.10, and lower 258
Upgrading Multi-Domain Servers in High Availability from R80.20.M1 or R80.20.M2289
Upgrading a Multi-Domain Log Server from R80.20, R80.10, and lower .............. 333
Upgrading a Multi-Domain Log Server from R80.20.M1 or R80.20.M2................. 351
Note - You must upgrade the Multi-Domain Server before you can upgrade the Multi-Domain Log
Server, dedicated Log Servers, and dedicated SmartEvent Servers.
For configuration information, see the R80.30 Multi-Domain Security Management Administration
Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm.
Step Description
4 In Multi-Domain Server R80 or R80.10 with enabled vSEC Controller:
a) Connect with SmartConsole to the Global Domain.
b) Delete all global Data Centers objects.
c) Assign the modified Global Policies.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Upgrade the Multi-Domain Server with CPUSE
2. Install the R80.30 SmartConsole
3. Install the management database
4. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
5. Upgrade the attributes of all managed objects in all Domain Management Servers
6. Test the functionality
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 4 of 6: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• Upgrading a Multi-Domain Log Server (on page 333)
Installation and Upgrade Guide R80.30 | 214
Step 5 of 6: Upgrade the attributes of all managed objects in all Domain Management
Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
Step Description
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Get the R80.30 installation image
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Get the R80.30 Multi-Domain Server
4. On the R80.30 Multi-Domain Server, import the entire management database
5. Install the R80.30 SmartConsole
6. Install the management database
7. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
8. Upgrade the attributes of all managed objects in all Domain Management Servers
9. Test the functionality
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 9: On the current Multi-Domain Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@MDS:0]# mdsstart
b) Follow the instructions in the report.
c) Connect with SmartConsole to the Global Domain that is currently in the Active
state.
d) Reassign the Global Policy on all Domains.
e) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
f) Stop all Check Point services again:
[Expert@MDS:0]# mdsstop
g) Run the installation script again:
[Expert@MDS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
Step Description
15 Transfer the exported database from the current Multi-Domain Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target Multi-Domain Servers must be the same. If you need to
have a different IP address on the R80.30 Multi-Domain Server, you can change it only after the
upgrade procedure. Note that you have to issue licenses for the new IP address. For applicable
procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 7 of 9: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• Upgrading a Multi-Domain Log Server (on page 333)
• Upgrading a Dedicated Log Server (on page 162)
• Upgrading a Dedicated SmartEvent Server (on page 175)
Step 8 of 9: Upgrade the attributes of all managed objects in all Domain Management
Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
Step Description
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Get the R80.30 installation image
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Install a new R80.30 Multi-Domain Server
4. On the new R80.30 Multi-Domain Server, import the entire management database
5. Install the R80.30 SmartConsole
6. On the new R80.30 Multi-Domain Server, install the management database
7. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
8. On the new R80.30 Multi-Domain Server, upgrade the attributes of all managed objects in all
Domain Management Servers
9. Test the functionality
Installation and Upgrade Guide R80.30 | 224
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 11: On the current Multi-Domain Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@MDS:0]# mdsstart
b) Follow the instructions in the report.
c) Connect with SmartConsole to the Global Domain that is currently in the Active
state.
d) Reassign the Global Policy on all Domains.
e) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
f) Stop all Check Point services again:
[Expert@MDS:0]# mdsstop
g) Run the installation script again:
[Expert@MDS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
Step Description
15 Transfer the exported database from the current Multi-Domain Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 11: On the new R80.30 Multi-Domain Server, import the entire management
database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step 6 of 11: On the new R80.30 Multi-Domain Server, install the management database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 7 of 11: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• Upgrading a Multi-Domain Log Server (on page 333)
• Upgrading a Dedicated Log Server (on page 162)
• Upgrading a Dedicated SmartEvent Server (on page 175)
Step 8 of 11: On the new R80.30 Multi-Domain Server, upgrade the attributes of all
managed objects in all Domain Management Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
Step Description
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
Step 10 of 11: Disconnect the old Multi-Domain Server from the network
This upgrade method is supported only when you upgrade from R7x versions.
We recommend to upgrade the entire Multi-Domain Server at once with one of these methods:
• Upgrading one Multi-Domain Server from R80.20, R80.10, and lower with CPUSE (on page
213)
• Upgrading one Multi-Domain Server from R80.20, R80.10, and lower with Advanced Upgrade
(on page 217)
Because upgrade of the entire Multi-Domain Server at once is the default recommended method,
use the Gradual Migration of Domain Management Servers only in these cases:
• The entire Multi-Domain Server cannot be upgraded at once because of a business impact.
• During the upgrade, you need to rename some or all of the Domain Management Servers.
• In Multi-Domain Server High Availability deployment, you need to change the number of
Domain Management Servers on Multi-Domain Servers.
Workflow:
1. Perform a Clean Install of a target R80.30 Multi-Domain Server
2. Create the corresponding Domain Management Servers (but do not start or configure anything
in them)
3. Export the Global Policies from the R7x Multi-Domain Server
4. Import the R7x Global Policies on the R80.30 Multi-Domain Server
5. On the R7x Multi-Domain Server, export the entire management database from the applicable
source Domain Management Servers one by one
6. Transfer the exported R7x Domain Management Server management databases to the R80.30
Multi-Domain Server
7. On the target R80.30 Multi-Domain Server, import the entire management database to the
applicable target Domain Management Servers one by one
8. Configure the Multi-Domain Server administrators and GUI clients
9. Reset SIC, create a new ICA, and establish SIC Trust with managed Security Gateways
10. Rebuild the status of Global VPN communities after the gradual upgrade
11. Configure the VPN keys
12. Test the functionality
Step 3 of 12: Export the Global Policies from the R7x Multi-Domain Server
Export the R7x global management database as described in Migrating Global Policies from R7x
Multi-Domain Server (on page 505).
Step 4 of 12: Import the R7x Global Policies on the R80.30 Multi-Domain Server
Import the R7x global management database as described in Migrating Global Policies from R7x
Multi-Domain Server (on page 505).
Step 5 of 12: On the R7x Multi-Domain Server, export the entire management database
from the applicable source Domain Management Servers one by one
Step Description
1 Connect to the command line on the current Multi-Domain Server.
4 Go to the directory, where you put the R80.30 Management Server Migration Tool
package:
[Expert@R7x_MDS:0]# cd /var/log/path_to_upgrade_tools/
Step Description
5 Extract the R80.30 Management Server Migration Tool package:
[Expert@R7x_MDS:0]# tar zxvf <Name of Management Server Migration Tool
Package>.tgz
7 Export the entire management database from each applicable Domain Management
Server:
[Expert@R7x_MDS:0]# yes | nohup ./migrate export [-l | -x] /<Full
Path>/<Name of R7x Domain Exported File>
For details, see the R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_Ref
erenceGuide/html_frameset.htm - Chapter Security Management Server Commands -
Section migrate.
9 Transfer each exported Domain Management Server database from the current
Multi-Domain Server to an external storage:
/<Full Path>/<Name of R7x Domain Exported File>.tgz
Note - Make sure to transfer the files in the binary mode.
Step 6 of 12: Transfer the exported R7x Domain Management Server management
databases to the R80.30 Multi-Domain Server
Step Description
1 Transfer the exported R7x Domain Management Server management databases from an
external storage to the R80.30 Multi-Domain Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
2 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the R7x Multi-Domain Server:
[[email protected]_MDS:0]# md5sum /<Full Path>/<Name of R7x Domain Exported
File>.tgz
Step 7 of 12: On the target R80.30 Multi-Domain Server, import the entire management
database to the applicable target Domain Management Servers one by one
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
5 Import the R7x Domain Management Server management databases one by one:
[[email protected]_MDS:0]# cma_migrate /<Full Path>/<Name of R7x Domain
Exported File>.tgz /<Full Path>/<$FWDIR Directory of the New Domain Management
Server>/
Example:
[[email protected]_MDS:0]# cma_migrate /var/log/orig_R7x_database.tgz
/opt/CPmds-R80.30/customers/MyDomain3/CPsuite-R80.30/fw1/
Note - This command updates the database schema before it imports. First, the command
runs pre-upgrade verification. If no errors are found, migration continues. If there are
errors, you must fix them on the source R7x Domain Management Server according to
instructions in the error messages. Then do this procedure again.
6 Start the new Domain Management Server with the imported R7x management database:
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
7 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step 8 of 12: Configure the Multi-Domain Server administrators and GUI clients
The gradual upgrade does not keep all data.
You must manually redefine and reassign the Multi-Domain Server administrators and GUI clients
to Domains after the gradual upgrade.
Step Description
1 Run the mdsconfig (on page 113) command and configure the options Administrators
and GUI clients.
Step Description
2 See the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-Do
mainSecurityManagement_AdminGuide/html_frameset.htm - Chapter Managing Domains
- Section Creating a New Domain - Subsection Assigning Trusted Clients to Domains.
Step 9 of 12: Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Note - This step applies if the new R80.30 Domain Management Server has a different IPv4
address than the R7x Domain Management Server.
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Stop the new Domain Management Server, into which you migrated the management
database from an R7x Domain Management Server:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
Step Description
9 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
10 Establish the Secure Internal Communication (SIC) between the Management Server and
the managed Security Gateways:
a) Reset SIC on each Security Gateway that was managed by the original R7x Domain
Management Server.
For detailed procedure, see sk65764: How to reset SIC
http://supportcontent.checkpoint.com/solutions?id=sk65764.
b) Connect with SmartConsole to the new Domain Management Server.
c) Open the object of each Security Gateway.
d) Establish SIC Trust with of each Security Gateway.
e) Install the Access Control Policy on each Security Gateway.
Step 10 of 12: Rebuild the status of Global VPN communities after the gradual upgrade
The gradual upgrade does not keep all data.
Step Description
1 Connect to the command on the R80.30 Multi-Domain Server.
There can be an issue with the IKE certificates after you migrate the management database, if a
VPN tunnel is established between a Check Point Security Gateway and an externally managed,
third-party gateway.
The VPN Security Gateway presents its IKE certificate to its peer. The third-party gateway uses the
FQDN of the certificate to retrieve the host name and IP address of the Certificate Authority. If the
IKE certificate was issued by a Check Point Internal CA, the FQDN contains the host name of the
original Management Server. The peer gateway will fail to contact the original server and will not
accept the certificate.
To fix:
• Update the external DNS server to resolve the host name to the IP address of the applicable
Domain Management Server.
• Revoke the IKE certificate for the gateway and create a new one.
2 Make sure the management database and configuration were upgraded correctly on each
Domain Management Server.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Get the required upgrade tools
2. Upgrade the Multi-Domain Server with CPUSE
3. Install the R80.30 SmartConsole
Installation and Upgrade Guide R80.30 | 238
Step 1 of 7: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step Description
1 Connect with SmartConsole to each Domain Management Server.
Step Description
2 In the top left corner, click Menu > Install database.
4 Click Install.
5 Click OK.
Step 5 of 7: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step 6 of 7: Upgrade the attributes of all managed objects in all Domain Management
Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain Server
2. On the R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier and export
the entire management database
3. Perform clean install of the R80.30 Multi-Domain Server
4. Get the required upgrade tools on the R80.30 Multi-Domain Server
5. On the R80.30 Multi-Domain Server, import the entire management database
6. Install the R80.30 SmartConsole
7. Install the management database
8. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
9. Upgrade the attributes of all managed objects in all Domain Management Servers
10. Test the functionality
Step 1 of 10: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 10: On the R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade
Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
4 Run the Pre-Upgrade Verifier.
• If this Multi-Domain Server is connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
• If this Multi-Domain Server is not connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
5 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step Description
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 10: Get the required upgrade tools on the R80.30 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
Step 5 of 10: On the R80.30 Multi-Domain Server, import the entire management
database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 8 of 10: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step 9 of 10: Upgrade the attributes of all managed objects in all Domain Management
Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain Server
2. On the R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier and export
the entire management database
3. Perform clean install of the new R80.30 Multi-Domain Server
4. Get the required upgrade tools on the new R80.30 Multi-Domain Server
5. On the new R80.30 Multi-Domain Server, import the entire management database
6. Install the R80.30 SmartConsole
7. On the new R80.30 Multi-Domain Server, install the management database
8. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
9. On the new R80.30 Multi-Domain Server, upgrade the attributes of all managed objects in all
Domain Management Servers
10. Test the functionality
11. Disconnect the old Multi-Domain Server from the network
Installation and Upgrade Guide R80.30 | 250
Step 1 of 12: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 12: On the R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade
Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
4 Run the Pre-Upgrade Verifier.
• If this Multi-Domain Server is connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
• If this Multi-Domain Server is not connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
5 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step Description
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 3 of 12: Perform clean install of the new R80.30 Multi-Domain Server
Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the R80.30 Multi-Domain Server from scratch (on page 54).
Important:
The IP addresses of the source and target Multi-Domain Servers must be the same. If you need to
have a different IP address on the R80.30 Multi-Domain Server, you can change it only after the
upgrade procedure. Note that you have to issue licenses for the new IP address. For applicable
procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 4 of 12: Get the required upgrade tools on the new R80.30 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
Step 5 of 12: On the new R80.30 Multi-Domain Server, import the entire management
database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 8 of 12: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Server manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step 9 of 12: Upgrade the attributes of all managed objects in all Domain Management
Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
Step 11 of 12: Disconnect the old Multi-Domain Server from the network
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-Domain
Server to be the Primary
2. Upgrade the Primary Multi-Domain Server with CPUSE
3. Install the R80.30 SmartConsole
4. On the Primary Multi-Domain Server, install the management database
5. Upgrade the Secondary Multi-Domain Server with CPUSE
6. On the Secondary Multi-Domain Server, install the management database
7. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
Installation and Upgrade Guide R80.30 | 259
8. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
9. Test the functionality
Step 1 of 9: If the Primary Multi-Domain Server is not available, promote the Secondary
Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
Step Description
5 Click OK.
Step 7 of 9: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manage Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Servers:
• Upgrading a Multi-Domain Log Server (on page 333)
• Upgrading a Dedicated Log Server (on page 162)
• Upgrading a Dedicated SmartEvent Server (on page 175)
Step Description
1 Connect to the command line every Multi-Domain Server that has at least one Active
Domain Management Server.
Step Description
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
Step Description
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-Domain
Server to be the Primary
2. Get the R80.30 installation image
3. On the current Primary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
4. Get the Primary R80.30 Multi-Domain Server
5. On the Primary R80.30 Multi-Domain Server, import the entire management database
6. Install the R80.30 SmartConsole
7. On the Primary R80.30 Multi-Domain Server, install the management database
8. On the current Secondary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
9. Get the Secondary R80.30 Multi-Domain Server
Installation and Upgrade Guide R80.30 | 264
10. On the Secondary R80.30 Multi-Domain Server, import the entire management database
11. On the Secondary R80.30 Multi-Domain Server, install the management database
12. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
13. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
14. Test the functionality
Step 1 of 14: If the Primary Multi-Domain Server is not available, promote the
Secondary Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 3 of 14: On the current Primary Multi-Domain Server, run the Pre-Upgrade Verifier
and export the entire management database
Step Description
1 Connect to the command line the current Primary Multi-Domain Server.
Step Description
8 Run the installation script:
[Expert@PrimaryMDS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
Step Description
12 Answer the interactive questions:
Would you like to proceed with the export now [yes/no] ? yes
Please enter target directory for your Multi-Domain Server export
(or 'Q' to quit): /var/log
Do you plan to import to a version newer than R80.30 [yes/no] ? no
Using migrate_tools from disk.
Do you wish to export the log database [yes/no] ? yes (or no)
Note - If you enter no in the question "Do you wish to export the log database",
the configuration is still exported.
16 Transfer the exported database from the current Primary Multi-Domain Server to an
external storage:
/var/log/Primary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target Multi-Domain Servers must be the same. If you need to
have a different IP address on the R80.30 Multi-Domain Server, you can change it only after the
upgrade procedure. Note that you have to issue licenses for the new IP address. For applicable
procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 5 of 14: On the Primary R80.30 Multi-Domain Server, import the entire
management database
Step Description
1 Connect to the command line on the Primary R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the Primary R80.30
Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@PrimaryMDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@PrimaryMDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[Expert@PrimaryMDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[Expert@PrimaryMDS:0]# mdsstat
Step 7 of 14: On the Primary R80.30 Multi-Domain Server, install the management
database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
Step Description
2 In the top left corner, click Menu > Install database.
4 Click Install.
5 Click OK.
Step 8 of 14: On the current Secondary Multi-Domain Server, run the Pre-Upgrade
Verifier and export the entire management database
Step Description
1 Connect to the command line the current Secondary Multi-Domain Server.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@SecondaryMDS:0]# mdsstart
b) Follow the instructions in the report.
c) Connect with SmartConsole to the Global Domain that is currently in the Active
state.
d) Reassign the Global Policy on all Domains.
e) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
f) Stop all Check Point services again:
[Expert@SecondaryMDS:0]# mdsstop
g) Run the installation script again:
[Expert@SecondaryMDS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
Step Description
15 Rename the exported file:
[Expert@SecondaryMDS:0]# mv -v
/var/log/{,Secondary_}exported_mds.<DDMMYYYY-HHMMSS>.tgz
16 Transfer the exported database from the current Secondary Multi-Domain Server to an
external storage:
/var/log/Secondary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target Multi-Domain Servers must be the same. If you need to
have a different IP address on the R80.30 Multi-Domain Server, you can change it only after the
upgrade procedure. Note that you have to issue licenses for the new IP address. For applicable
procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 10 of 14: On the Secondary R80.30 Multi-Domain Server, import the entire
management database
Notes:
These preliminary steps apply to a Multi-Site setup, in which some of the Domain Management
Servers are Active on the Primary Multi-Domain Server, and some of the Domain Management
Servers are Active on the Secondary Multi-Domain Servers.
Note - This example assumes that you already upgraded the Primary Multi-Domain Server and
one of the Secondary Multi-Domain Servers with Active Domain Management Servers on it.
1. Before you can import the entire management database on the second Secondary
Multi-Domain Server:
a) Connect with SmartConsole to each of the upgraded Multi-Domain Servers:
The Primary Multi-Domain Server
The first Secondary Multi-Domain Server
b) Make sure the High Availability status for each Multi-Domain Server with the other
upgraded Multi-Domain Servers is OK.
In case of a failure, you must resolve it before you can import the database.
c) Import the entire management database on the second Secondary Multi-Domain Server.
2. Before you can import the entire management database on the third Secondary Multi-Domain
Server:
a) Connect with SmartConsole to each of the upgraded Multi-Domain Servers:
The Primary Multi-Domain Server
The first Secondary Multi-Domain Server
The second Secondary Multi-Domain Server
b) Make sure the High Availability status for each Multi-Domain Server with the other
upgraded Multi-Domain Servers is OK.
In case of a failure, you must resolve it before you can import the database.
c) Import the entire management database on the third Secondary Multi-Domain Server.
Repeat the above test on all other Secondary Multi-Domain Servers before you import the entire
management database on them.
Procedure:
Step Description
1 Connect to the command line the Secondary R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the Secondary R80.30
Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@SecondaryMDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@SecondaryMDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[Expert@SecondaryMDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[Expert@SecondaryMDS:0]# mdsstat
Step 11 of 14: On the Secondary R80.30 Multi-Domain Server, install the management
database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 12 of 14: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manage Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• Upgrading a Multi-Domain Log Server (on page 333)
• Upgrading a Dedicated Log Server (on page 162)
• Upgrading a Dedicated SmartEvent Server (on page 175)
Step 13 of 14: On every Multi-Domain Server with Active Domain Management Servers,
upgrade the attributes of all managed objects in all Domain Management Servers
To determine which Multi-Domain Servers run Active Domain Management Servers:
1. Connect with SmartConsole to an Multi-Domain Server to the MDS context.
2. From the left navigation panel, click Multi Domain > Domains.
Step Description
1 Connect to the command line every Multi-Domain Server that has at least one Active
Domain Management Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
Step Description
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were imported correctly.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-Domain
Server to be the Primary
2. Get the R80.30 installation image
3. On the current Primary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
4. Install another Primary R80.30 Multi-Domain Server
5. On the Primary R80.30 Multi-Domain Server, import the entire management database
6. Install the R80.30 SmartConsole
7. On the Primary R80.30 Multi-Domain Server, install the management database
8. On the current Secondary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
9. Install another Secondary R80.30 Multi-Domain Server
Installation and Upgrade Guide R80.30 | 276
10. On the Secondary R80.30 Multi-Domain Server, import the entire management database
11. On the Secondary R80.30 Multi-Domain Server, install the management database
12. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
13. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
14. Test the functionality
15. Disconnect the old Multi-Domain Servers from the network
16. Connect the new Multi-Domain Servers to the network
Step 1 of 16: If the Primary Multi-Domain Server is not available, promote the
Secondary Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 3 of 16: On the current Primary Multi-Domain Server, run the Pre-Upgrade Verifier
and export the entire management database
Step Description
1 Connect to the command line the current Primary Multi-Domain Server.
Step Description
7 Go to the installation folder in the ISO:
[Expert@PrimaryMDS:0]# cd /mnt/cdrom/linux/p1_install/
Step Description
12 Answer the interactive questions:
Would you like to proceed with the export now [yes/no] ? yes
Please enter target directory for your Multi-Domain Server export
(or 'Q' to quit): /var/log
Do you plan to import to a version newer than R80.30 [yes/no] ? no
Using migrate_tools from disk.
Do you wish to export the log database [yes/no] ? yes (or no)
Note - If you enter no in the question "Do you wish to export the log database",
the configuration is still exported.
16 Transfer the exported database from the current Primary Multi-Domain Server to an
external storage:
/var/log/Primary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 5 of 16: On the Primary R80.30 Multi-Domain Server, import the entire
management database
Step Description
1 Connect to the command line on the Primary R80.30 Multi-Domain Server.
Step Description
3 Log in to the Expert mode.
4 Transfer the exported database from an external storage to the Primary R80.30
Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@PrimaryMDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@PrimaryMDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[Expert@PrimaryMDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[Expert@PrimaryMDS:0]# mdsstat
Step 7 of 16: On the Primary R80.30 Multi-Domain Server, install the management
database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
Step Description
5 Click OK.
Step 8 of 16: On the current Secondary Multi-Domain Server, run the Pre-Upgrade
Verifier and export the entire management database
Step Description
1 Connect to the command line the current Secondary Multi-Domain Server.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@SecondaryMDS:0]# mdsstart
b) Follow the instructions in the report.
c) Connect with SmartConsole to the Global Domain that is currently in the Active
state.
d) Reassign the Global Policy on all Domains.
e) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
f) Stop all Check Point services again:
[Expert@SecondaryMDS:0]# mdsstop
g) Run the installation script again:
[Expert@SecondaryMDS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
Step Description
15 Rename the exported file:
[Expert@SecondaryMDS:0]# mv -v
/var/log/{,Secondary_}exported_mds.<DDMMYYYY-HHMMSS>.tgz
16 Transfer the exported database from the current Secondary Multi-Domain Server to an
external storage:
/var/log/Secondary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 10 of 16: On the Secondary R80.30 Multi-Domain Server, import the entire
management database
Notes:
These preliminary steps apply to a Multi-Site setup, in which some of the Domain Management
Servers are Active on the Primary Multi-Domain Server, and some of the Domain Management
Servers are Active on the Secondary Multi-Domain Servers.
Note - This example assumes that you already upgraded the Primary Multi-Domain Server and
one of the Secondary Multi-Domain Servers with Active Domain Management Servers on it.
1. Before you can import the entire management database on the second Secondary
Multi-Domain Server:
a) Connect with SmartConsole to each of the upgraded Multi-Domain Servers:
The Primary Multi-Domain Server
The first Secondary Multi-Domain Server
b) Make sure the High Availability status for each Multi-Domain Server with the other
upgraded Multi-Domain Servers is OK.
In case of a failure, you must resolve it before you can import the database.
c) Import the entire management database on the second Secondary Multi-Domain Server.
2. Before you can import the entire management database on the third Secondary Multi-Domain
Server:
a) Connect with SmartConsole to each of the upgraded Multi-Domain Servers:
The Primary Multi-Domain Server
The first Secondary Multi-Domain Server
The second Secondary Multi-Domain Server
Installation and Upgrade Guide R80.30 | 283
b) Make sure the High Availability status for each Multi-Domain Server with the other
upgraded Multi-Domain Servers is OK.
In case of a failure, you must resolve it before you can import the database.
c) Import the entire management database on the third Secondary Multi-Domain Server.
Repeat the above test on all other Secondary Multi-Domain Servers before you import the entire
management database on them.
Procedure:
Step Description
1 Connect to the command line the Secondary R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the Secondary R80.30
Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@SecondaryMDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@SecondaryMDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[Expert@SecondaryMDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[Expert@SecondaryMDS:0]# mdsstat
Step 11 of 16: On the Secondary R80.30 Multi-Domain Server, install the management
database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 12 of 16: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manages Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• Upgrading a Multi-Domain Log Server (on page 333)
• Upgrading a Dedicated Log Server (on page 162)
• Upgrading a Dedicated SmartEvent Server (on page 175)
Step 13 of 16: On every Multi-Domain Server with Active Domain Management Servers,
upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
5 Go to the main MDS context:
[Expert@MDS:0]# mdsenv
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDS:0]# mdsstop
[Expert@MDS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
8 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were imported correctly.
Installation and Upgrade Guide R80.30 | 286
Step Description
3 Test the Management High Availability functionality.
Step 15 of 16: Disconnect the old Multi-Domain Servers from the network
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-Domain
Server to be the Primary
2. Get the required upgrade tools on the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server
3. Upgrade the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server with CPUSE
4. Install the R80.30 SmartConsole
5. On the Primary R80.30 Multi-Domain Server, install the management database
6. Perform a clean install of the R80.30 on the Secondary Multi-Domain Server
7. Get the required upgrade tools on the Secondary R80.30 Multi-Domain Server
8. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
9. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
10. Test the functionality
Step 1 of 10: If the Primary Multi-Domain Server is not available, promote the
Secondary Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
Step 2 of 10: Get the required upgrade tools on the Primary R80.20.M1 / R80.20.M2
Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 3 of 10: Upgrade the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server with
CPUSE
See Installing Software Packages on Gaia (on page 118) and follow the applicable action plan for
the local installation.
Step 5 of 10: On the Primary R80.30 Multi-Domain Server, install the management
database
Note - This is the Known Limitation 01287041
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 6 of 10: Perform a clean install of the R80.30 on the Secondary Multi-Domain
Server
Step Description
1 See the R80.30 Release Notes
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_RN/html
_frameset.htm for requirements.
2 Perform a clean install of the Secondary R80.30 Multi-Domain Server (on page 56).
Important:
The IP addresses of the source and target Multi-Domain Servers must be the same. If you need to
have a different IP address on the R80.30 Multi-Domain Server, you can change it only after the
upgrade procedure. Note that you have to issue licenses for the new IP address. For applicable
procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 7 of 10: Get the required upgrade tools on the Secondary R80.30 Multi-Domain
Server
Note - This step is needed only to be able to export the entire management database (for backup
purposes) with the latest upgrade tools.
Installation and Upgrade Guide R80.30 | 291
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 8 of 10: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manage Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Servers:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step 9 of 10: On every Multi-Domain Server with Active Domain Management Servers,
upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server is not available, promote the
Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server to be the Primary
2. Make sure the Global Domain is Active on the Primary R80.20.M1 / R80.20.M2 Multi-Domain
Server
3. Get the required upgrade tools on the Primary and the Secondary R80.20.M1 / R80.20.M2
Multi-Domain Server
4. On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier
5. On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier
6. On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the entire management
database
7. On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the entire management
database
8. Perform clean install of the R80.30 Primary Multi-Domain Server
9. Get the required upgrade tools on the Primary R80.30 Multi-Domain Server
Installation and Upgrade Guide R80.30 | 295
10. On the Primary R80.30 Multi-Domain Server, import the entire management database
11. Perform clean install of the R80.30 Secondary Multi-Domain Server
12. Get the required upgrade tools on the Secondary R80.30 Multi-Domain Server
13. On the Secondary R80.30 Multi-Domain Server, import the entire management database
14. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
15. Install the R80.30 SmartConsole
16. Install the management database
17. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
18. Test the functionality
Step 1 of 18: If the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server is not available,
promote the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
Step 2 of 18: Make sure the Global Domain is Active on the Primary R80.20.M1 /
R80.20.M2 Multi-Domain Server
Step Description
1 Connect with SmartConsole to the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server.
2 From the left navigation panel, click Multi Domain > Domains.
The table shows Domains and Multi-Domain Servers:
• Every column shows a Multi-Domain Server.
• Active Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are
marked with a solid black "barrel" icon.
• Standby Domain Management Servers (for a <tp_domain) on a Multi-Domain Server
are marked with an empty "barrel" icon.
3 In the leftmost column Domains, examine the bottom row Global for the Primary
Multi-Domain Server.
If the Global Domain is in the Standby state on the Primary Multi-Domain Server (marked
with an empty "barrel" icon), then make it Active:
a) Right-click on the Primary Multi-Domain Server and click Connect to Domain
Server. High Availability Status window opens.
b) In the section Connected To, click Actions > Set Active.
c) Click Yes to confirm.
d) Wait for the full synchronization to complete.
e) Close SmartConsole.
Step 3 of 18: Get the required upgrade tools on the Primary and the Secondary
R80.20.M1 / R80.20.M2 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 4 of 18: On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the
Pre-Upgrade Verifier
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
4 Run the Pre-Upgrade Verifier.
• If this Multi-Domain Server is connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
• If this Multi-Domain Server is not connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
5 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step 5 of 18: On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the
Pre-Upgrade Verifier
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step 6 of 18: On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the
entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 7 of 18: On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the
entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 8 of 18: Perform clean install of the R80.30 Primary Multi-Domain Server
Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the R80.30 Multi-Domain Server from scratch (on page 55).
Important:
The IP addresses of the source R80.20.M1 / R80.20.M2 and target R80.30 Multi-Domain Servers
can be different. If you need to have a different IP address on the target R80.30 Multi-Domain
Server, you must create a special JSON configuration file before you import the management
database from the source R80.20.M1 or R80.20.M2 Multi-Domain Server. Note that you have to
issue licenses for the new IP address. You must use the same JSON configuration file on all
servers in the same Multi-Domain Security Management environment.
Step 9 of 18: Get the required upgrade tools on the Primary R80.30 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 10 of 18: On the Primary R80.30 Multi-Domain Server, import the entire
management database you exported from the Primary R80.20.M1 or R80.20.M2
Multi-Domain Server
Prerequisites:
If you installed the target R80.30 Multi-Domain Server with a different IP address than the source
R80.20.M1 or R80.20.M2 Multi-Domain Server, you must create a special JSON configuration file
before you import the management database from the source R80.20.M1 or R80.20.M2
Multi-Domain Server. Note that you have to issue licenses for the new IP address.
Important Notes:
• If none of the servers in the same Multi-Domain Security Management environment change
their original IP addresses, you do not need to create the special JSON configuration.
Installation and Upgrade Guide R80.30 | 301
• You must use the same JSON configuration file on all servers in the same Multi-Domain
Security Management environment. Even if only one of the servers migrates to a new IP
address, all the servers must get this configuration file for the import process.
To create the JSON configuration file:
Step Description
1 Connect to the command line on the target R80.30 Multi-Domain Server.
3 Create the /var/log/mdss.json file that contains every server migrated to a new IP
address.
• Format for migrating only the Primary Multi-Domain Server to a new IP address:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers to
new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers, and
the Multi-Domain Log Server to new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"},{"name":"<Name of
R80.20.M1 or R80.20.M2 Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of R80.30 Multi-Domain
Log Server"}]
Step Description
Example:
There are 3 servers in the Multi-Domain Security Management environment - the Primary
Multi-Domain Server, the Secondary Multi-Domain Server, and the Multi-Domain Log
Server. Both the Primary and the Secondary Multi-Domain Servers are migrated to new IP
addresses. The Multi-Domain Log Server remains with the original IP address.
a) The current IPv4 address of the source Primary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.21
b) The current IPv4 address of the source Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.22
c) The name of the source Primary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MyPrimaryMultiDomainServer
d) The name of the source Secondary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MySecondaryMultiDomainServer
e) The new IPv4 address of the target Primary R80.30 Multi-Domain Server is:
172.30.40.51
f) The new IPv4 address of the target Secondary R80.30 Multi-Domain Server is:
172.30.40.52
g) The required syntax for the JSON configuration file you must use on both the
Primary and the Secondary Multi-Domain Servers, and on the Multi-Domain Log
Server:
[{"name":"MyPrimaryMultiDomainServer","newIpAddress4":"172.30
.40.51"},{"name":"MySecondaryMultiDomainServer","newIpAddress
4":"172.30.40.52"}]
Clarification - All servers in this environment must get this information.
Procedure:
Step Description
1 Connect to the command line the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
5 Make sure the transferred file is not corrupted.
Calculate the MD5 for the transferred file and compare it to the MD5 that you calculated
on the original Multi-Domain Server:
[Expert@MDS:0]# md5sum /<Full Path>/<Name of Exported File>.tgz
Step 11 of 18: Perform a clean install of the R80.30 on the Secondary Multi-Domain
Server
Perform the clean install in one of these ways (do not perform initial configuration in
Installation and Upgrade Guide R80.30 | 304
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the Secondary R80.30 Multi-Domain Server from scratch (on page 56).
Important:
The IP addresses of the source R80.20.M1 / R80.20.M2 and target R80.30 Multi-Domain Servers
can be different. If you need to have a different IP address on the target R80.30 Multi-Domain
Server, you must create a special JSON configuration file before you import the management
database from the source R80.20.M1 or R80.20.M2 Multi-Domain Server. Note that you have to
issue licenses for the new IP address. You must use the same JSON configuration file on all
servers in the same Multi-Domain Security Management environment.
Step 12 of 18: Get the required upgrade tools on the Secondary R80.30 Multi-Domain
Server
Note - This step is needed only to be able to export the entire management database (for backup
purposes) with the latest upgrade tools.
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step 13 of 18: On the Secondary R80.30 Multi-Domain Server, import the entire
management database you exported from the Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server
Prerequisites:
If you installed the target R80.30 Multi-Domain Server with a different IP address than the source
R80.20.M1 or R80.20.M2 Multi-Domain Server, you must create a special JSON configuration file
before you import the management database from the source R80.20.M1 or R80.20.M2
Multi-Domain Server. Note that you have to issue licenses for the new IP address.
Important Notes:
• If none of the servers in the same Multi-Domain Security Management environment change
their original IP addresses, you do not need to create the special JSON configuration.
• You must use the same JSON configuration file on all servers in the same Multi-Domain
Security Management environment. Even if only one of the servers migrates to a new IP
address, all the servers must get this configuration file for the import process.
To create the JSON configuration file:
Step Description
1 Connect to the command line on the target R80.30 Multi-Domain Server.
Step Description
2 Log in to the Expert mode.
3 Create the /var/log/mdss.json file that contains every server migrated to a new IP
address.
• Format for migrating only the Primary Multi-Domain Server to a new IP address:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers to
new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers, and
the Multi-Domain Log Server to new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"},{"name":"<Name of
R80.20.M1 or R80.20.M2 Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of R80.30 Multi-Domain
Log Server"}]
Step Description
Example:
There are 3 servers in the Multi-Domain Security Management environment - the Primary
Multi-Domain Server, the Secondary Multi-Domain Server, and the Multi-Domain Log
Server. Both the Primary and the Secondary Multi-Domain Servers are migrated to new IP
addresses. The Multi-Domain Log Server remains with the original IP address.
a) The current IPv4 address of the source Primary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.21
b) The current IPv4 address of the source Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.22
c) The name of the source Primary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MyPrimaryMultiDomainServer
d) The name of the source Secondary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MySecondaryMultiDomainServer
e) The new IPv4 address of the target Primary R80.30 Multi-Domain Server is:
172.30.40.51
f) The new IPv4 address of the target Secondary R80.30 Multi-Domain Server is:
172.30.40.52
g) The required syntax for the JSON configuration file you must use on both the
Primary and the Secondary Multi-Domain Servers, and on the Multi-Domain Log
Server:
[{"name":"MyPrimaryMultiDomainServer","newIpAddress4":"172.30
.40.51"},{"name":"MySecondaryMultiDomainServer","newIpAddress
4":"172.30.40.52"}]
Clarification - All servers in this environment must get this information.
Procedure:
Step Description
1 Connect to the command line the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
5 Make sure the transferred file is not corrupted.
Calculate the MD5 for the transferred file and compare it to the MD5 that you calculated
on the original Multi-Domain Server:
[Expert@MDS:0]# md5sum /<Full Path>/<Name of Exported File>.tgz
Step 14 of 18: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manage Multi-Domain Log Servers, dedicated Log Servers, or
Installation and Upgrade Guide R80.30 | 309
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 17 of 18: On every Multi-Domain Server with Active Domain Management Servers,
upgrade the attributes of all managed objects in all Domain Management Servers
To determine which Multi-Domain Servers run Active Domain Management Servers:
1. Connect with SmartConsole to an Multi-Domain Server to the MDS context.
2. From the left navigation panel, click Multi Domain > Domains.
The table shows Domains and Multi-Domain Servers:
• Every column shows a Multi-Domain Server.
• Active Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are marked
with a solid black "barrel" icon.
• Standby Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are
marked with an empty "barrel" icon.
Procedure:
Step Description
1 Connect to the command line every Multi-Domain Server that has at least one Active
Domain Management Server.
Step Description
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were imported correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Servers.
Workflow:
1. If the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server is not available, promote the
Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server to be the Primary
2. Make sure the Global Domain is Active on the Primary R80.20.M1 / R80.20.M2 Multi-Domain
Server
3. Get the required upgrade tools on the Primary and the Secondary R80.20.M1 / R80.20.M2
Multi-Domain Server
4. On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier
5. On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the Pre-Upgrade Verifier
6. On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the entire management
database
7. On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the entire management
database
8. Perform clean install of another R80.30 Primary Multi-Domain Server
9. Get the required upgrade tools on the Primary R80.30 Multi-Domain Server
Installation and Upgrade Guide R80.30 | 313
10. On the Primary R80.30 Multi-Domain Server, import the entire management database
11. Perform clean install of another R80.30 Secondary Multi-Domain Server
12. Get the required upgrade tools on the Secondary R80.30 Multi-Domain Server
13. On the Secondary R80.30 Multi-Domain Server, import the entire management database
14. Upgrade the Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent
Servers
15. Install the R80.30 SmartConsole
16. Install the management database
17. On every Multi-Domain Server with Active Domain Management Servers, upgrade the
attributes of all managed objects in all Domain Management Servers
18. Test the functionality
Step 1 of 18: If the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server is not available,
promote the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server to be the Primary
For instructions, see the R80.30 Multi-Domain Security Management Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_Multi-DomainSe
curityManagement_AdminGuide/html_frameset.htm - Chapter Working with High Availability -
Section Failure Recovery - Subsection Promoting the Secondary Multi-Domain Server to Primary.
Step 2 of 18: Make sure the Global Domain is Active on the Primary R80.20.M1 /
R80.20.M2 Multi-Domain Server
Step Description
1 Connect with SmartConsole to the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server.
2 From the left navigation panel, click Multi Domain > Domains.
The table shows Domains and Multi-Domain Servers:
• Every column shows a Multi-Domain Server.
• Active Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are
marked with a solid black "barrel" icon.
• Standby Domain Management Servers (for a <tp_domain) on a Multi-Domain Server
are marked with an empty "barrel" icon.
3 In the leftmost column Domains, examine the bottom row Global for the Primary
Multi-Domain Server.
If the Global Domain is in the Standby state on the Primary Multi-Domain Server (marked
with an empty "barrel" icon), then make it Active:
a) Right-click on the Primary Multi-Domain Server and click Connect to Domain
Server. High Availability Status window opens.
b) In the section Connected To, click Actions > Set Active.
c) Click Yes to confirm.
d) Wait for the full synchronization to complete.
e) Close SmartConsole.
Step 3 of 18: Get the required upgrade tools on the Primary and the Secondary
R80.20.M1 / R80.20.M2 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 4 of 18: On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the
Pre-Upgrade Verifier
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
4 Run the Pre-Upgrade Verifier.
• If this Multi-Domain Server is connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
• If this Multi-Domain Server is not connected to the Internet, run:
[Expert@MDS:0]# $MDS_FWDIR/scripts/migrate_server verify -v R80.30
-skip_upgrade_tools_check
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
5 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
Step 5 of 18: On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, run the
Pre-Upgrade Verifier
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step 6 of 18: On the Primary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the
entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 7 of 18: On the Secondary R80.20.M1 / R80.20.M2 Multi-Domain Server, export the
entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Server.
Step Description
2 Log in with the superuser credentials.
9 Transfer the exported databases from the current Multi-Domain Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 8 of 18: Perform clean install of another R80.30 Primary Multi-Domain Server
Perform a clean install of the R80.30 Multi-Domain Server (on page 54) on another computer (do
not perform initial configuration in SmartConsole).
Important:
The IP addresses of the source R80.20.M1 / R80.20.M2 and target R80.30 Multi-Domain Servers
can be different. If you need to have a different IP address on the target R80.30 Multi-Domain
Server, you must create a special JSON configuration file before you import the management
database from the source R80.20.M1 or R80.20.M2 Multi-Domain Server. Note that you have to
issue licenses for the new IP address. You must use the same JSON configuration file on all
servers in the same Multi-Domain Security Management environment.
Step 9 of 18: Get the required upgrade tools on the Primary R80.30 Multi-Domain Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 10 of 18: On the Primary R80.30 Multi-Domain Server, import the entire
management database you exported from the Primary R80.20.M1 or R80.20.M2
Multi-Domain Server
Prerequisites:
If you installed the target R80.30 Multi-Domain Server with a different IP address than the source
R80.20.M1 or R80.20.M2 Multi-Domain Server, you must create a special JSON configuration file
before you import the management database from the source R80.20.M1 or R80.20.M2
Multi-Domain Server. Note that you have to issue licenses for the new IP address.
Important Notes:
• If none of the servers in the same Multi-Domain Security Management environment change
their original IP addresses, you do not need to create the special JSON configuration.
• You must use the same JSON configuration file on all servers in the same Multi-Domain
Security Management environment. Even if only one of the servers migrates to a new IP
address, all the servers must get this configuration file for the import process.
Step Description
1 Connect to the command line on the target R80.30 Multi-Domain Server.
3 Create the /var/log/mdss.json file that contains every server migrated to a new IP
address.
• Format for migrating only the Primary Multi-Domain Server to a new IP address:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers to
new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers, and
the Multi-Domain Log Server to new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"},{"name":"<Name of
R80.20.M1 or R80.20.M2 Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of R80.30 Multi-Domain
Log Server"}]
Step Description
Example:
There are 3 servers in the Multi-Domain Security Management environment - the Primary
Multi-Domain Server, the Secondary Multi-Domain Server, and the Multi-Domain Log
Server. Both the Primary and the Secondary Multi-Domain Servers are migrated to new IP
addresses. The Multi-Domain Log Server remains with the original IP address.
a) The current IPv4 address of the source Primary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.21
b) The current IPv4 address of the source Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.22
c) The name of the source Primary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MyPrimaryMultiDomainServer
d) The name of the source Secondary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MySecondaryMultiDomainServer
e) The new IPv4 address of the target Primary R80.30 Multi-Domain Server is:
172.30.40.51
f) The new IPv4 address of the target Secondary R80.30 Multi-Domain Server is:
172.30.40.52
g) The required syntax for the JSON configuration file you must use on both the
Primary and the Secondary Multi-Domain Servers, and on the Multi-Domain Log
Server:
[{"name":"MyPrimaryMultiDomainServer","newIpAddress4":"172.30
.40.51"},{"name":"MySecondaryMultiDomainServer","newIpAddress
4":"172.30.40.52"}]
Clarification - All servers in this environment must get this information.
Procedure:
Step Description
1 Connect to the command line the R80.30 Multi-Domain Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
5 Make sure the transferred file is not corrupted.
Calculate the MD5 for the transferred file and compare it to the MD5 that you calculated
on the original Multi-Domain Server:
[Expert@MDS:0]# md5sum /<Full Path>/<Name of Exported File>.tgz
Step 11 of 18: Perform clean install of another R80.30 Secondary Multi-Domain Server
Perform a clean install of the Secondary R80.30 Multi-Domain Server (on page 56) on another
computer (do not perform initial configuration in SmartConsole).
Installation and Upgrade Guide R80.30 | 322
Important:
The IP addresses of the source R80.20.M1 / R80.20.M2 and target R80.30 Multi-Domain Servers
can be different. If you need to have a different IP address on the target R80.30 Multi-Domain
Server, you must create a special JSON configuration file before you import the management
database from the source R80.20.M1 or R80.20.M2 Multi-Domain Server. Note that you have to
issue licenses for the new IP address. You must use the same JSON configuration file on all
servers in the same Multi-Domain Security Management environment.
Step 12 of 18: Get the required upgrade tools on the Secondary R80.30 Multi-Domain
Server
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
Step Description
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
Step 13 of 18: On the Secondary R80.30 Multi-Domain Server, import the entire
management database you exported from the Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server
Prerequisites:
If you installed the target R80.30 Multi-Domain Server with a different IP address than the source
R80.20.M1 or R80.20.M2 Multi-Domain Server, you must create a special JSON configuration file
before you import the management database from the source R80.20.M1 or R80.20.M2
Multi-Domain Server. Note that you have to issue licenses for the new IP address.
Important Notes:
• If none of the servers in the same Multi-Domain Security Management environment change
their original IP addresses, you do not need to create the special JSON configuration.
• You must use the same JSON configuration file on all servers in the same Multi-Domain
Security Management environment. Even if only one of the servers migrates to a new IP
address, all the servers must get this configuration file for the import process.
To create the JSON configuration file:
Step Description
1 Connect to the command line on the target R80.30 Multi-Domain Server.
Step Description
3 Create the /var/log/mdss.json file that contains every server migrated to a new IP
address.
• Format for migrating only the Primary Multi-Domain Server to a new IP address:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers to
new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers, and
the Multi-Domain Log Server to new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"},{"name":"<Name of
R80.20.M1 or R80.20.M2 Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of R80.30 Multi-Domain
Log Server"}]
Step Description
Example:
There are 3 servers in the Multi-Domain Security Management environment - the Primary
Multi-Domain Server, the Secondary Multi-Domain Server, and the Multi-Domain Log
Server. Both the Primary and the Secondary Multi-Domain Servers are migrated to new IP
addresses. The Multi-Domain Log Server remains with the original IP address.
a) The current IPv4 address of the source Primary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.21
b) The current IPv4 address of the source Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.22
c) The name of the source Primary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MyPrimaryMultiDomainServer
d) The name of the source Secondary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MySecondaryMultiDomainServer
e) The new IPv4 address of the target Primary R80.30 Multi-Domain Server is:
172.30.40.51
f) The new IPv4 address of the target Secondary R80.30 Multi-Domain Server is:
172.30.40.52
g) The required syntax for the JSON configuration file you must use on both the
Primary and the Secondary Multi-Domain Servers, and on the Multi-Domain Log
Server:
[{"name":"MyPrimaryMultiDomainServer","newIpAddress4":"172.30
.40.51"},{"name":"MySecondaryMultiDomainServer","newIpAddress
4":"172.30.40.52"}]
Clarification - All servers in this environment must get this information.
Procedure:
If you installed the target R80.30 Multi-Domain Server with a different IP address than the source
R80.20.M1 or R80.20.M2 Multi-Domain Server, you must create a special JSON configuration file
before you import the management database from the source R80.20.M1 or R80.20.M2
Multi-Domain Server. Note that you have to issue licenses for the new IP address.
Important Notes:
• If none of the servers in the same Multi-Domain Security Management environment change
their original IP addresses, you do not need to create the special JSON configuration.
• You must use the same JSON configuration file on all servers in the same Multi-Domain
Security Management environment. Even if only one of the servers migrates to a new IP
address, all the servers must get this configuration file for the import process.
Step Description
1 Connect to the command line on the target R80.30 Multi-Domain Server.
3 Create the /var/log/mdss.json file that contains every server migrated to a new IP
address.
• Format for migrating only the Primary Multi-Domain Server to a new IP address:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers to
new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"}]
• Format for migrating both the Primary and the Secondary Multi-Domain Servers, and
the Multi-Domain Log Server to new IP addresses:
[{"name":"<Name of Primary R80.20.M1 or R80.20.M2 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of Primary R80.30
Multi-Domain Server>"},{"name":"<Name of Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.30 Multi-Domain Server>"},{"name":"<Name of
R80.20.M1 or R80.20.M2 Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of R80.30 Multi-Domain
Log Server"}]
Step Description
Example:
There are 3 servers in the Multi-Domain Security Management environment - the Primary
Multi-Domain Server, the Secondary Multi-Domain Server, and the Multi-Domain Log
Server. Both the Primary and the Secondary Multi-Domain Servers are migrated to new IP
addresses. The Multi-Domain Log Server remains with the original IP address.
a) The current IPv4 address of the source Primary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.21
b) The current IPv4 address of the source Secondary R80.20.M1 or R80.20.M2
Multi-Domain Server is:
192.168.10.22
c) The name of the source Primary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MyPrimaryMultiDomainServer
d) The name of the source Secondary R80.20.M1 or R80.20.M2 Multi-Domain Server
object in SmartConsole is:
MySecondaryMultiDomainServer
e) The new IPv4 address of the target Primary R80.30 Multi-Domain Server is:
172.30.40.51
f) The new IPv4 address of the target Secondary R80.30 Multi-Domain Server is:
172.30.40.52
g) The required syntax for the JSON configuration file you must use on both the
Primary and the Secondary Multi-Domain Servers, and on the Multi-Domain Log
Server:
[{"name":"MyPrimaryMultiDomainServer","newIpAddress4":"172.30
.40.51"},{"name":"MySecondaryMultiDomainServer","newIpAddress
4":"172.30.40.52"}]
Clarification - All servers in this environment must get this information.
Step 14 of 18: Upgrade the Multi-Domain Log Server, dedicated Log Servers, and
dedicated SmartEvent Servers
If your Multi-Domain Servers manage Multi-Domain Log Servers, dedicated Log Servers, or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Multi-Domain Server:
• For Multi-Domain Log Servers - see Upgrading a Multi-Domain Log Server from R80.20.M1 or
R80.20.M2 (on page 351)
• For Log Servers and SmartEvent Servers - see Upgrading a Management Server or Log Server
from R80.20.M1 or R80.20.M2 (on page 188)
Step Description
1 Connect with SmartConsole to each Domain Management Server.
4 Click Install.
5 Click OK.
Step 17 of 18: On every Multi-Domain Server with Active Domain Management Servers,
upgrade the attributes of all managed objects in all Domain Management Servers
To determine which Multi-Domain Servers run Active Domain Management Servers:
1. Connect with SmartConsole to an Multi-Domain Server to the MDS context.
2. From the left navigation panel, click Multi Domain > Domains.
The table shows Domains and Multi-Domain Servers:
• Every column shows a Multi-Domain Server.
• Active Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are marked
with a solid black "barrel" icon.
• Standby Domain Management Servers (for a <tp_domain) on a Multi-Domain Server are
marked with an empty "barrel" icon.
Procedure:
Step Description
1 Connect to the command line every Multi-Domain Server that has at least one Active
Domain Management Server.
Step Description
4 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at once:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL
• You can perform this action on one Multi-Domain Server at a time with this command:
[Expert@MDS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Server>
7 Make sure that on all Domain Management Servers, none of the required daemons (FWM,
FWD, CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down",
wait for 5-10 minutes, restart that Domain Management Server and check again. Run
these three commands:
[Expert@MDS:0]# mdsstop_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstart_customer <IP Address or Name of Domain Management
Server>
[Expert@MDS:0]# mdsstat
2 Make sure the management database and configuration were imported correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Upgrade the Multi-Domain Log Server with CPUSE
2. Install the management database
3. Upgrade the attributes of all managed objects in all Domain Log Servers
4. Test the functionality on R80.30 Multi-Domain Log Server
5. Test the functionality on R80.30 Multi-Domain Server
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
4 Click Install.
Step Description
5 Click OK.
Step 3 of 5: Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
Step Description
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDLS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDLS:0]# mdsstop
[Expert@MDLS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
8 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
2 Make sure the configuration was upgraded correctly and it works as expected.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Get the R80.30 installation image
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Get the R80.30 Multi-Domain Log Server
4. On the R80.30 Multi-Domain Log Server, import the entire management database
5. Install the management database
6. Upgrade the attributes of all managed objects in all Domain Log Servers
7. Test the functionality on R80.30 Multi-Domain Log Server
8. Test the functionality on R80.30 Multi-Domain Server
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 8: On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Log Server.
Step Description
2 Log in with the superuser credentials.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@MDLS:0]# mdsstart
b) Follow the instructions in the report.
c) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
d) Stop all Check Point services again:
[Expert@MDLS:0]# mdsstop
e) Run the installation script again:
[Expert@MDLS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
15 Transfer the exported database from the current Multi-Domain Log Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP addresses of the source and target R80.30 Multi-Domain Log Servers must be the same. If
you need to have a different IP address on the R80.30 Multi-Domain Log Server, you can change it
only after the upgrade procedure. Note that you have to issue licenses for the new IP address. For
applicable procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 4 of 8: On the R80.30 Multi-Domain Log Server, import the entire management
database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain Log
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
7 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
4 Click Install.
5 Click OK.
Step 6 of 8: Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
Step Description
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDLS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDLS:0]# mdsstop
[Expert@MDLS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
Step Description
8 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
2 Make sure the configuration was upgraded correctly and it works as expected.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Get the R80.30 installation image
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the entire
management database
3. Install a new R80.30 Multi-Domain Log Server
4. On the new R80.30 Multi-Domain Log Server, import the entire management database
5. Install the management database
6. On the new R80.30 Multi-Domain Log Server, upgrade the attributes of all managed objects in
all Domain Log Servers
7. Test the functionality on R80.30 Multi-Domain Log Server
8. Test the functionality on R80.30 Multi-Domain Server
9. Disconnect the old Multi-Domain Log Server from the network
10. Connect the new Multi-Domain Log Server to the network
2 Transfer the R80.30 ISO file to the current Multi-Domain Server to some directory (for
example, /var/log/path_to_iso/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 10: On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Log Server.
Step Description
10 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Start all Check Point services:
[Expert@MDLS:0]# mdsstart
b) Follow the instructions in the report.
c) In a Management High Availability environment R77.30 and lower, if you made
changes, synchronize the Domain Management Servers immediately after these
changes (in R80 and above, this synchronization occurs automatically).
d) Stop all Check Point services again:
[Expert@MDLS:0]# mdsstop
e) Run the installation script again:
[Expert@MDLS:0]# ./mds_setup
This menu shows:
(1) Run Pre-upgrade verification only [recommended before
upgrade]
(2) Backup current Multi-Domain Server
(3) Export current Multi-Domain Server
Or 'Q' to quit.
15 Transfer the exported database from the current Multi-Domain Log Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 10: On the new R80.30 Multi-Domain Log Server, import the entire
management database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain Log
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
7 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
4 Click Install.
5 Click OK.
Step 6 of 10: On the new R80.30 Multi-Domain Log Server, upgrade the attributes of all
managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
7 This step applies only if you upgraded from the R77.30 version:
Allow the database synchronization to run:
[Expert@MDLS:0]# $CPDIR/bin/cpprod_util CPPROD_SetValue "FW1/6.0"
AfterUpgradeDbsyncIndication 1 1 0
Restart the Check Point services:
[Expert@MDLS:0]# mdsstop
[Expert@MDLS:0]# mdsstart
For more information, see sk121718
http://supportcontent.checkpoint.com/solutions?id=sk121718.
8 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
2 Make sure the configuration was upgraded correctly and it works as expected.
Step 9 of 10: Disconnect the old Multi-Domain Log Server from the network
Step 10 of 10: Connect the new Multi-Domain Log Server to the network
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Get the required upgrade tools
2. Upgrade the Multi-Domain Log Server with CPUSE
3. Install the management database
4. Upgrade the attributes of all managed objects in all Domain Log Servers
5. Test the functionality on R80.30 Multi-Domain Log Server
6. Test the functionality on R80.30 Multi-Domain Server
Step 1 of 6: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Log Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
Step Description
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDLS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
4 Click Install.
5 Click OK.
Step 4 of 6: Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
Step Description
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
7 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
Step Description
2 Make sure the configuration was upgraded correctly and it works as expected.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain Log Server
2. On the R80.20.M1 / R80.20.M2 Multi-Domain Log Server, run the Pre-Upgrade Verifier and
export the entire management database
3. Perform clean install of the R80.30 Multi-Domain Log Server
4. Get the required upgrade tools on the R80.30 Multi-Domain Log Server
5. On the R80.30 Multi-Domain Log Server, import the entire management database
6. Install the R80.30 SmartConsole
7. Install the management database
8. Upgrade the attributes of all managed objects in all Domain Log Servers
9. Test the functionality on R80.30 Multi-Domain Log Server
10. Test the functionality on R80.30 Multi-Domain Server
Step 1 of 10: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Log Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
Step Description
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDLS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 10: On the R80.20.M1 / R80.20.M2 Multi-Domain Log Server, run the
Pre-Upgrade Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Log Server.
Step Description
6 Go to the $MDS_FWDIR/scripts/ directory:
[Expert@MDLS:0]# cd $MDS_FWDIR/scripts
9 Transfer the exported databases from the current Multi-Domain Log Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 3 of 10: Perform clean install of the R80.30 Multi-Domain Log Server
Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the R80.30 Multi-Domain Log Server from scratch (on page 58).
Important:
The IP addresses of the source and target R80.30 Multi-Domain Log Servers must be the same. If
you need to have a different IP address on the R80.30 Multi-Domain Log Server, you can change it
only after the upgrade procedure. Note that you have to issue licenses for the new IP address. For
applicable procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Installation and Upgrade Guide R80.30 | 358
Step 4 of 10: Get the required upgrade tools on the R80.30 Multi-Domain Log Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDLS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 5 of 10: On the R80.30 Multi-Domain Log Server, import the entire management
database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain Log
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
6 Go to the $MDS_FWDIR/scripts/ directory:
[Expert@MDLS:0]# cd $MDS_FWDIR/scripts/
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
Step Description
3 Select all objects.
4 Click Install.
5 Click OK.
Step 8 of 10: Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
Step Description
7 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
2 Make sure the configuration was upgraded correctly and it works as expected.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
Workflow:
1. Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain Log Server
2. On the R80.20.M1 / R80.20.M2 Multi-Domain Log Server, run the Pre-Upgrade Verifier and
export the entire management database
3. Perform clean install of the new R80.30 Multi-Domain Log Server
4. Get the required upgrade tools on the new R80.30 Multi-Domain Log Server
5. On the new R80.30 Multi-Domain Log Server, import the entire management database
6. Install the R80.30 SmartConsole
7. On the new R80.30 Multi-Domain Log Server, install the management database
8. On the new R80.30 Multi-Domain Log Server, upgrade the attributes of all managed objects in
all Domain Log Servers
9. Test the functionality on R80.30 Multi-Domain Log Server
10. Test the functionality on R80.30 Multi-Domain Server
11. Disconnect the old Multi-Domain Log Server from the network
12. Connect the new Multi-Domain Log Server to the network
Step 1 of 12: Get the required upgrade tools on the R80.20.M1 / R80.20.M2 Multi-Domain
Log Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
Step Description
2 Install the required upgrade tools with CPUSE.
See Installing Software Packages on Gaia (on page 118) and follow the applicable action
plan for the local offline installation.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDLS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 2 of 12: On the R80.20.M1 / R80.20.M2 Multi-Domain Log Server, run the
Pre-Upgrade Verifier and export the entire management database
Step Description
1 Connect to the command line on the current Multi-Domain Log Server.
Step Description
5 Read the Pre-Upgrade Verifier output.
If you need to fix errors:
a) Follow the instructions in the report.
b) Run the Pre-Upgrade Verifier again.
9 Transfer the exported databases from the current Multi-Domain Log Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 3 of 12: Perform clean install of the new R80.30 Multi-Domain Log Server
Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
• Install the R80.30 with the CPUSE (on page 118) - select the R80.30 package and perform
Clean Install. See sk92449 http://supportcontent.checkpoint.com/solutions?id=sk92449 for
detailed steps.
• Install the R80.30 Multi-Domain Log Server from scratch (on page 58).
Installation and Upgrade Guide R80.30 | 365
Important:
The IP addresses of the source and target R80.30 Multi-Domain Log Servers must be the same. If
you need to have a different IP address on the R80.30 Multi-Domain Log Server, you can change it
only after the upgrade procedure. Note that you have to issue licenses for the new IP address. For
applicable procedure, see sk74020 http://supportcontent.checkpoint.com/solutions?id=sk74020.
Step 4 of 12: Get the required upgrade tools on the new R80.30 Multi-Domain Log
Server
Step Description
1 Download the required upgrade tools (on page 136) from sk135172
http://supportcontent.checkpoint.com/solutions?id=sk135172.
Note - This is a CPUSE Offline package.
3 Make sure the package is installed. Run this command in the Expert mode:
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
The output must show the same build number you see in the name of the downloaded
package.
Example:
Name of the downloaded package: ngm_upgrade_wrapper_992000043_1.tgz
[Expert@MDLS:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R80.30
BuildNumber 1
992000043
[Expert@MDLS:0]#
Note - The command migrate_server from these upgrade tools always tries to connect to
Check Point Cloud over the Internet. This is to make sure you always have the latest version of
these upgrade tools installed. If the connection to Check Point Cloud fails, this message appears:
"Timeout. Failed to retrieve Upgrade Tools package. To download the package
manually, refer to sk135172."
Step 5 of 12: On the new R80.30 Multi-Domain Log Server, import the entire
management database
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Transfer the exported database from an external storage to the R80.30 Multi-Domain Log
Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step Description
5 Make sure the transferred file is not corrupted.
Calculate the MD5 for the transferred file and compare it to the MD5 that you calculated
on the original Multi-Domain Log Server:
[Expert@MDLS:0]# md5sum /<Full Path>/<Name of Exported File>.tgz
Step Description
1 Connect with SmartConsole to each R80.30 Domain Management Server that manages the
Domain Log Server.
4 Click Install.
5 Click OK.
Step 8 of 12: Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Log Server.
4 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
• Because the command prompts you for a 'yes/no' for each Domain and each object in
the Domain, you can explicitly provide the 'yes' answer to all questions with this
command:
[Expert@MDLS:0]# yes | $MDSDIR/scripts/mds_fix_cmas_clms_version
-c ALL
• You can perform this action on one Multi-Domain Log Server at a time with this
command:
[Expert@MDLS:0]# $MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
-n <Name of Multi-Domain Log Server>
7 Make sure that on all Domain Log Servers, none of the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "down" (the "pnd" state is acceptable):
[Expert@MDLS:0]# mdsstat
If some of the required daemons on a Domain Log Server are in the state "down", wait for
5-10 minutes, restart that Domain Log Server and check again. Run these three
commands:
[Expert@MDLS:0]# mdsstop_customer <IP Address or Name of Domain Log Server>
[Expert@MDLS:0]# mdsstart_customer <IP Address or Name of Domain Log
Server>
[Expert@MDLS:0]# mdsstat
2 Make sure the configuration was upgraded correctly and it works as expected.
Step 11 of 12: Disconnect the old Multi-Domain Server from the network
4 Upgrade the licenses on the Security Gateway, if needed. See Working with Licenses (on
page 613).
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade. The upgrade process replaces all existing files
with default files. If you have custom configurations on the Security Gateway, they are lost
during the upgrade. As a result, different issues can occur in the upgraded Security
Gateway.
Workflow:
1. Upgrade the Security Gateway with CPUSE
2. In SmartConsole, change the version of the Security Gateway object
3. In SmartConsole, install the Access Control Policy
4. Test the functionality
4 From the left navigation tree, click the General Properties page.
Step Description
5 In the Platform section > Version field, select R80.30.
6 Click OK.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Security Gateway to make sure it inspects the traffic as
expected.
4 Upgrade the licenses on the VSX Gateway, if needed. See Working with Licenses (on page
613).
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade. The upgrade process replaces all existing files
with default files. If you have custom configurations on the Security Gateway, they are lost
during the upgrade. As a result, different issues can occur in the upgraded Security
Gateway.
Workflow:
1. On the Management Server, upgrade the configuration of the VSX Gateway object to R80.30
2. Upgrade the VSX Gateway with CPUSE
3. In SmartConsole, install the Access Control Policy
4. Test the functionality
Step 1 of 4: On the Management Server, upgrade the configuration of the VSX Gateway
object to R80.30
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Gateway.
3 On a Multi-Domain Server, go to the context of the Main Domain Management Server that
manages this VSX Gateway object:
mdsenv <IP Address or Name of Main Domain Management Server>
Step Description
4 Upgrade the configuration of the VSX Gateway object to R80.30:
4A Run:
vsx_util upgrade
This command is interactive.
4D Select R80.30.
5 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this VSX Gateway.
8 From the left navigation tree, click the General Properties page.
9 Make sure in the Platform section, the Version field shows R80.30.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from the Virtual Systems on this VSX Gateway to make sure they inspect
the traffic as expected.
4 Upgrade the licenses on the Cluster Members, if needed. See Working with Licenses (on
page 613).
5 If you upgrade a VSX Cluster, then on the Management Server, upgrade the configuration
of the VSX Cluster object to R80.30.
6 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade. The upgrade process replaces all existing files
with default files. If you have custom configurations on the Cluster Members, they are lost
during the upgrade. As a result, different issues can occur in the upgraded cluster. Cluster
Members can stop detecting each other, Cluster Members can move to undesired state,
and traffic can be dropped.
7 Make sure the configuration and the values of the required kernel parameters are the
same on all Cluster Members. Log in to the Expert mode on each Cluster Member and run
the applicable commands.
Note - For more information, see sk25977
http://supportcontent.checkpoint.com/solutions?id=sk25977.
Step Description
• On Security Gateway R77.30:
# cphaconf cluster_id get
Examine the value of the cluster_id
Option Instructions
1 Perform these steps:
1. Connect over the console to the Cluster Member.
2. Physically disconnect the Cluster Member from the network (unplug all cables).
For more information, see sk42096: Cluster member is stuck in 'Ready' state
http://supportcontent.checkpoint.com/solutions?id=sk42096.
Cluster Control Protocol (CCP) packets between Cluster Members that run different
software versions during the upgrade:
We do not recommend to connect interfaces of multiple clusters to the same network segment
(same VLAN, same switch). For more information about issues in this topology, see sk25977:
Connecting multiple clusters to the same network segment (same VLAN, same switch)
http://supportcontent.checkpoint.com/solutions?id=sk25977.
In R80.10 and above, the Cluster Members automatically set the value of the 5th byte of the Source
MAC address (MAC magic) in all types of CCP packets (CCP Delta Sync packets, CCP Health Check
packets, forwarded packets).
When you upgrade the current Cluster Members to R80.10 or above, the upgraded Cluster
Members (after you install the Access Control policy on them for the first time) automatically set
the value of the 5th byte of the CCP Source MAC address to the same value they detect in the 5th
byte of the CCP Source MAC address from the old Cluster Members of the same cluster.
Example for a cluster upgrade from R77.20
1. You configured these values for the required kernel parameters:
• fwha_mac_magic = 200
• fwha_mac_forward_magic = 201
2. When you upgrade the Cluster Members to R80.10 or above, the upgraded Cluster Members
automatically set:
• MAC magic = 200
• MAC forward magic = 201
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
Workflow:
1. On each Cluster Member - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
2. In SmartConsole - Change the version of the cluster object
3. In SmartConsole - Install the Access Control Policy
4. On each Cluster Member - Examine the cluster state
5. Test the functionality
Note - You must reboot the Cluster Member after the upgrade or clean install.
4 From the left navigation tree, click the General Properties page.
6 If you performed a Clean Install of R80.30 on the Cluster Member, then establish the
Secure Internal Communication (SIC) between the Management Server and this Cluster
Member:
a) From the left tree, click Cluster Members.
b) Select the Cluster Member object.
c) Click Edit.
d) On the General tab, click the Communication button.
e) Click Reset.
f) In the One-time password field, enter the same Activation Key you entered during
the First Time Configuration Wizard of the Cluster Member.
g) In the Confirm one-time password field, enter the same Activation Key again.
h) Click Initialize.
i) The Trust state field must shows Trust established.
j) Click Close to close the Communication window.
k) Click OK to close the Cluster Member Properties window.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Cluster to make sure it inspects the traffic as expected.
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
Workflow:
1. On the Management Server - Upgrade the configuration of the VSX Cluster object to R80.30
2. On each VSX Cluster Member - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
3. In SmartConsole - Install the Access Control Policy
4. On each VSX Cluster Member - Examine the VSX state
5. On each VSX Cluster Member - Examine the cluster state
6. Test the functionality
Step 1 of 6: On the Management Server - Upgrade the configuration of the VSX Cluster
object to R80.30
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Cluster.
3 On a Multi-Domain Server, go to the context of the Main Domain Management Server that
manages this VSX Cluster:
mdsenv <IP Address or Name of Main Domain Management Server>
4A Run:
vsx_util upgrade
This command is interactive.
Step Description
4B Enter these details to log in to the management database:
• IP address of the Security Management Server or Main Domain Management Server
that manages this VSX Cluster
• Management Server administrator's username
• Management Server administrator's password
4C Select your VSX Cluster.
4D Select R80.30.
5 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this VSX Cluster.
8 From the left navigation tree, click the General Properties page.
9 Make sure in the Platform section, the Version field shows R80.30.
Step 2 of 6: On each VSX Cluster Member - Upgrade to R80.30 with CPUSE, or perform a
Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
5 The Access Control Policy successfully installs on all the VSX Cluster Members.
Step Description
3 Examine the VSX state:
vsenv 0
vsx stat -v
Notes:
• Make sure all the configured Virtual Devices are loaded.
• Make sure all Virtual Systems and Virtual Routers have policy and SIC.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from Virtual Systems on this VSX Cluster to make sure they inspect the
traffic as expected.
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
The procedure below describes an example cluster with three Cluster Members M1, M2 and M3.
However, you can use it for clusters that consist of two or more Cluster Members.
Workflow:
1. On each Cluster Member - Change the CCP mode to Broadcast
2. On the Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
3. On the Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
4. In SmartConsole - Change the version of the cluster object
5. In SmartConsole - Install the Access Control Policy
6. On each Cluster Member - Examine the cluster state
7. On the old Cluster Member M1 - Stop all Check Point services
8. On the upgraded Cluster Members M2 and M3 - Examine the cluster state
9. On the old Cluster Member M1 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
10. In SmartConsole - Establish SIC with the former old Cluster Member M1
11. In SmartConsole - Install the Access Control Policy
12. On each Cluster Member - Examine the cluster state
Step 1 of 14: On each Cluster Member - Change the CCP mode to Broadcast
To avoid possible problems with switches around the cluster during the upgrade, we recommend
to change the Cluster Control Protocol (CCP) mode to Broadcast.
Step Description
1 Connect to the command line on each Cluster Member.
Step 2 of 14: On the Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a
Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a ClusterXL Cluster (on page 82), or Installing a
scratch VRRP Cluster (on page 98).
In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the same IP
address as was used by the previous Cluster Member (prior to
the upgrade).
Note - You must reboot the Cluster Member after the upgrade or clean install.
Step 3 of 14: On the Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a
Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Clean Install of R80.30 See Installing a ClusterXL Cluster (on page 82), or Installing a
VRRP Cluster (on page 98).
In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the same IP
address as was used by the previous Cluster Member (prior to
the upgrade).
Note - You must reboot the Cluster Member after the upgrade or clean install.
4 From the left navigation tree, click the General Properties page.
6 If you performed a Clean Install of R80.30 on the Cluster Member, then establish the
Secure Internal Communication (SIC) between the Management Server and this Cluster
Member:
a) From the left tree, click Cluster Members.
b) Select the Cluster Member object.
c) Click Edit.
d) On the General tab, click the Communication button.
e) Click Reset.
f) In the One-time password field, enter the same Activation Key you entered during
the First Time Configuration Wizard of the Cluster Member.
g) In the Confirm one-time password field, enter the same Activation Key again.
h) Click Initialize.
i) The Trust state field must shows Trust established.
j) Click Close to close the Communication window.
k) Click OK to close the Cluster Member Properties window.
Step Description
7 Click OK to close the Gateway Cluster Properties window.
3 The Access Control Policy successfully installs on the upgraded Cluster Members M2 and
M3.
The Access Control Policy installation fails on the old Cluster Member M1 with a warning.
Ignore this warning.
Step 7 of 14: On the old Cluster Member M1 - Stop all Check Point services
Step Description
1 Connect to the command line on the Cluster Member M1.
Step Description
2 Stop all Check Point services:
cpstop
Notes:
• This forces a controlled cluster failover from the old Cluster Member M1 to one of the
upgraded Cluster Members.
• At this moment, all connections that were initiated through the old Cluster Member M1
are dropped (because Cluster Members with different software versions cannot
synchronize).
Step 8 of 14: On the upgraded Cluster Members M2 and M3 - Examine the cluster state
Step Description
1 Connect to the command line on each Cluster Member.
Step 9 of 14: On the old Cluster Member M1 - Upgrade to R80.30 with CPUSE, or perform
a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Clean Install of R80.30 See Installing a ClusterXL Cluster (on page 82), or Installing a
VRRP Cluster (on page 98).
In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the same IP
address as was used by the previous Cluster Member (prior to
the upgrade).
Note - You must reboot the Cluster Member after the upgrade or clean install.
Step 10 of 14: In SmartConsole - Establish SIC with the former old Cluster Member M1
This step is required only if you performed a Clean Install of R80.30 on this Cluster Member.
Step Description
1 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this Cluster.
6 Click Edit.
8 Click Reset.
9 In the One-time password field, enter the same Activation Key you entered during the First
Time Configuration Wizard of the Cluster Member.
10 In the Confirm one-time password field, enter the same Activation Key again.
11 Click Initialize.
Step Description
5 The Access Control Policy successfully installs on all the Cluster Members.
Step 13 of 14: On each Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each Cluster Member.
Step Description
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Cluster to make sure it inspects the traffic as expected.
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
The procedure below describes an example VSX Cluster with three Cluster Members M1, M2 and
M3. However, you can use it for clusters that consist of two or more Cluster Members.
Workflow:
1. On the Management Server - Upgrade the configuration of the VSX Cluster object to R80.30
2. On each VSX Cluster Member - Change the CCP mode to Broadcast
Installation and Upgrade Guide R80.30 | 402
3. On the VSX Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
4. On the VSX Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
5. In SmartConsole - Install the Access Control Policy
6. On each VSX Cluster Member - Examine the cluster state
7. On the old VSX Cluster Member M1 - Stop all Check Point services
8. On the upgraded VSX Cluster Members M2 and M3 - Examine the cluster state
9. On the old VSX Cluster Member M1 - Upgrade to R80.30 with CPUSE, or perform a Clean
Install of R80.30
10. In SmartConsole - Install the Access Control Policy
11. On each VSX Cluster Member - Examine the VSX state
12. On each VSX Cluster Member - Examine the cluster state
13. On each VSX Cluster Member - Change the CCP mode to Auto
14. Test the functionality
Step 1 of 14: On the Management Server - Upgrade the configuration of the VSX Cluster
object to R80.30
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Cluster.
3 On a Multi-Domain Server, go to the context of the Main Domain Management Server that
manages this VSX Cluster:
mdsenv <IP Address or Name of Main Domain Management Server>
4A Run:
vsx_util upgrade
This command is interactive.
4D Select R80.30.
Step Description
4E For auditing purposes, save the vsx_util log file:
• On a Security Management Server:
/opt/CPsuite-R80.30/fw1/log/vsx_util_YYYYMMDD_HH_MM.log
• On a Multi-Domain Server:
/opt/CPmds-R80.30/customers/<Name_of_Domain>/CPsuite-R80.30/fw1/l
og/vsx_util_YYYYMMDD_HH_MM.log
5 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this VSX Cluster.
8 From the left navigation tree, click the General Properties page.
9 Make sure in the Platform section, the Version field shows R80.30.
Step 2 of 14: On each VSX Cluster Member - Change the CCP mode to Broadcast
To avoid possible problems with switches around the VSX Cluster during the upgrade, we
recommend changing the Cluster Control Protocol (CCP) mode to Broadcast.
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 3 of 14: On the VSX Cluster Member M2 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a VSX Cluster (on page 92).
scratch 1. In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the
same IP address as was used by the previous VSX Cluster
Member (prior to the upgrade).
2. After you complete the Gaia First Time Configuration Wizard
and reboot, run the vsx_util reconfigure command on
the Management Server to push the VSX configuration to the
VSX Cluster Member. You must enter the same Activation
Key you entered during the First Time Configuration Wizard
of the VSX Cluster Member.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
Step 4 of 14: On the VSX Cluster Member M3 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
5 The Access Control Policy successfully installs on the upgraded VSX Cluster Members M2
and M3.
The Access Control Policy installation fails on the old VSX Cluster Member M1 with a
warning. Ignore this warning.
Step 6 of 14: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
2 Examine the cluster state:
• In Gaia Clish (R80.20 and above), run:
set virtual-system 0
show cluster state
• In Expert mode, run:
vsenv 0
cphaprob state
Notes:
• The cluster states of the upgraded VSX Cluster Members M2 and M3 are Ready.
• The cluster state of the old VSX Cluster Member M1 is Active Attention.
Step 7 of 14: On the old VSX Cluster Member M1 - Stop all Check Point services
Step Description
1 Connect to the command line on the old VSX Cluster Member M1.
Step 8 of 14: On the upgraded VSX Cluster Members M2 and M3 - Examine the cluster
state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 9 of 14: On the old VSX Cluster Member M1 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a VSX Cluster (on page 92).
scratch 1. In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the
same IP address as was used by the previous VSX Cluster
Member (prior to the upgrade).
2. After you complete the Gaia First Time Configuration Wizard
and reboot, run the vsx_util reconfigure command on
the Management Server to push the VSX configuration to the
VSX Cluster Member. You must enter the same Activation
Key you entered during the First Time Configuration Wizard
of the VSX Cluster Member.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
5 The Access Control Policy successfully installs on all the VSX Cluster Members.
Step 11 of 14: On each VSX Cluster Member - Examine the VSX state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 12 of 14: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 13 of 14: On each VSX Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
2 Change the CCP mode:
• In Gaia Clish, run:
set virtual-system 0
set cluster member ccp auto
save config
• In Expert mode, run:
vsenv 0
cphaconf set_ccp auto
Notes:
• This change does not require a reboot.
• This change applies immediately and survives reboot.
3 Make sure the CCP mode is set to Auto:
• In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
• In Expert mode, run:
vsenv 0
cphaprob -a if
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from Virtual Systems on this VSX Cluster to make sure they inspect the
traffic as expected.
Use the Connectivity Upgrade (CU) method to upgrade a Security Gateway cluster or a VSX
Cluster. This procedure lets you upgrade the cluster without a loss of connectivity (connection
failover is guaranteed).
Important - This upgrade method supports Cluster Members in High Availability mode only.
6 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
Upgrade to version
Upgrade from version R77.20 R77.20DR R77.30 R77.30DR R80.10 R80.20 (*)
CU with
R80.10 x x x x x
DR
CU with CU with
R77.30DR x x x x
DR DR
CU with CU with
R77.30 x x x x
DR DR
CU with CU with CU with
R77.20DR x x CU
DR DR DR
CU with CU with CU with
R77.20 x x CU
DR DR DR
CU with CU with CU with
R77.10 x x CU
DR DR DR
CU with CU with CU with
R77 x x CU
DR DR DR
CU with CU with CU with CU with
R76 CU CU
DR DR DR DR
CU with CU with CU with CU with
R75.47 CU CU
DR DR DR DR
CU with CU with CU with CU with
R75.46 CU CU
DR DR DR DR
CU with CU with CU with CU with
R75.40VS CU CU
DR DR DR DR
Notes:
• For supported upgrade paths, see the Release Notes for the version, to which you wish to
upgrade.
• For upgrade action plans, during which the Dynamic Routing information is synchronized, see
sk107042 http://supportcontent.checkpoint.com/solutions?id=sk107042.
• "R77.20DR" denotes R77.20 with Take 200 (or higher) of R77.20 Jumbo Hotfix Accumulator
(sk101975 http://supportcontent.checkpoint.com/solutions?id=sk101975).
• "R77.30DR" denotes R77.30 with Take 198 (or higher) of R77.30 Jumbo Hotfix Accumulator
(sk106162 http://supportcontent.checkpoint.com/solutions?id=sk106162).
• "x" denotes that such upgrade path is not supported.
• "CU" denotes Connectivity Upgrade, during which the Dynamic Routing information is not
synchronized.
• "CU with DR" denotes Connectivity Upgrade, during which the Dynamic Routing information is
synchronized.
• Notes for VRRP Clusters on Gaia:
• To upgrade a VRRP Cluster to R80.20 with the Connectivity Upgrade, you must install the
R80.20 Jumbo Hotfix Accumulator
http://supportcontent.checkpoint.com/solutions?id=sk137592 - Take 17 and above (to
resolve PMTR-23850)
• Connectivity Upgrade without Dynamic Routing synchronization supports:
upgrades to R80.20 and above
upgrades to R80.10
upgrades to "R77.30DR"
upgrades to "R77.20DR"
• Connectivity Upgrade with Dynamic Routing synchronization supports only:
upgrades from R80.10 to R80.20, and above
upgrades from R77.30 to R80.10, and above
• FTP Control connections with NAT do not survive the Connectivity Upgrade.
• IPv6 connections do not survive the Connectivity Upgrade.
• Threat Emulation connections do not survive the Connectivity Upgrade.
• VPN connections that originate from a DAIP Gateway, do not survive the Connectivity Upgrade.
• When traffic passes through a VSX Cluster in Bridge mode, a connection might fail after the
cluster failover to an upgraded VSX Cluster Member.
Workaround: Set the value of the Forward Delay parameter for Bridge interface to 1 (one). See
sk66531 https://supportcenter.checkpoint.com/solution?id=sk66531.
• If a session that is authenticated with the Identity Awareness Software Blade is open when you
start the Connectivity Upgrade, the session is terminated.
• To upgrade a VRRP Cluster to R80.20 with the Connectivity Upgrade, you must install the
R80.20 Jumbo Hotfix Accumulator
http://supportcontent.checkpoint.com/solutions?id=sk137592 - Take 17 and above (to resolve
PMTR-23850).
• In the Connectivity Upgrade with Dynamic Routing synchronization:
• CU to R77.20DR, R77.30DR, R80.10 or above: Dynamic Routing synchronization is available
only for cluster-supported protocols. For detailed information, refer to sk98226: Dynamic
Routing and VRRP Features on Gaia OS
http://supportcontent.checkpoint.com/solutions?id=sk98226.
• Configure BGP graceful restart to keep BGP routes during failover.
• For VRRP Clusters, Dynamic Routing synchronization is supported only:
from R80.10 to next versions
from R77.30 to R80.10, and above
• For VRRP Clusters, configure OSPF Graceful Restart to keep dynamic routes during the
failover.
The procedure below describes an example High Availability cluster with three members M1, M2
and M3. However, it can be used for clusters that consist of two or more members.
Step 2 of 19: On the Standby cluster member M2 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE (on page 372).
• For clean install instructions, see Installing a ClusterXL Cluster (on page 82), or Installing a
VRRP Cluster (on page 98).
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Known Limitations (on page
415).
Step 3 of 19: On the Standby cluster member M3 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE (on page 372).
• For clean install instructions, see Installing a ClusterXL Cluster (on page 82), or Installing a
VRRP Cluster (on page 98).
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Known Limitations (on page
415).
Step 4 of 19: In SmartConsole - Modify the Cluster object and install the Access Control
Policy
Step Description
1 Connect with SmartConsole to the R80.30 Security Management Server or Domain
Management Server that manages this cluster.
4 From the left navigation tree, click the General Properties page.
6 Click OK.
9 The Access Control Policy successfully installs on the upgraded cluster members M2 and
M3.
The Access Control Policy installation fails on the old cluster member M1 with a warning.
Ignore this warning.
Step 6 of 19: Stop all, except one, of the upgraded Standby cluster members
Step Description
1 Connect to the command line on all the upgraded cluster members (for example, M3),
except one (for example, M2).
2 Stop all Check Point services on all the upgraded members (for example, M3), except one
(for example, M2):
cpstop
Step 8 of 19: On the working upgraded cluster member - Start the Connectivity Upgrade
Step Description
1 Connect to the command line on the working upgraded cluster member M2.
Step Description
3 Start the Connectivity Upgrade:
• If you wish to synchronize the dynamic routing information during the upgrade:
cphacu start
• If you do not wish to synchronize the dynamic routing information during the upgrade:
cphacu start no_dr
Step 9 of 19: On the old cluster member - Make sure it handles the traffic
Step Description
1 Connect to the command line on the Active old cluster member M1.
Step 10 of 19: On the working upgraded cluster member - Make sure the Connectivity
Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the working upgraded cluster member M2, this
message shows:
Connectivity upgrade status: Ready for Failover
Step 11 of 19: On the stopped upgraded cluster member - Start all Check Point services
Step Description
1 Connect to the command line on the stopped upgraded cluster members (in our example,
M3).
Step 13 of 19: On the Active old cluster member - Stop all Check Point services
Step Description
1 Connect to the command line on the Active old cluster member M1.
Step 14 of 19: On the upgraded cluster members - Examine the cluster state and make
sure the Active handles the traffic
Step Description
1 Connect to the command line on the upgraded cluster members M2 and M3.
Step 15 of 19: On the former Active old cluster member - Upgrade to R80.30 with
CPUSE, or perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE (on page 372).
• For clean install instructions, see Installing a ClusterXL Cluster (on page 82), or Installing a
VRRP Cluster (on page 98).
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Known Limitations (on page
415).
5 The Access Control Policy successfully installs on all the cluster members.
Step 18 of 19: On each cluster member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each cluster member.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Cluster to make sure it inspects the traffic as expected.
Step 1 of 20: On the Management Server - Upgrade the configuration of the VSX Cluster
object to R80.30
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Cluster.
3 On a Multi-Domain Server, switch to the context of the Main Domain Management Server
that manages this VSX Cluster object:
mdsenv <IP Address or Name of Main Domain Management Server>
4A Run:
vsx_util upgrade
This command is interactive.
Step Description
4B Enter these details to log in to the management database:
• IP address of the Security Management Server or Main Domain Management Server
that manages this VSX Gateway
• Management Server administrator's username
• Management Server administrator's password
4C Select your VSX Cluster.
5 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this VSX Cluster.
8 From the left navigation tree, click the General Properties page.
9 Make sure in the Platform section, the Version field shows R80.30.
2 Transfer the upgrade image to the current VSX Cluster Members to some directory (for
example, /var/log/path_to_upgrade_image/).
Note - Make sure to transfer the file in the binary mode.
Step 3 of 20: On each VSX Cluster Member - Examine the cluster state and get the
Cluster Member IDs
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
2 Log in to the Expert mode.
Step 4 of 20: On all VSX Cluster Members with higher Cluster Member IDs - Upgrade to
R80.30 with CPUSE, or perform a Clean Install of R80.30
Upgrade or perform Clean Install on all of the VSX Cluster Members (in our example, M2 and M3),
except for the VSX Cluster Member with the lowest Cluster Member ID (in our example, M1).
• For upgrade instructions (recommended), see Upgrading a VSX Gateway with CPUSE (on page
374).
Note that you already upgraded the configuration of the VSX Cluster object to R80.30.
• For clean install instructions, see Installing a VSX Cluster (on page 92).
Notes:
• You must reboot the VSX Cluster Member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Limitations (on page 415).
5 The Access Control Policy successfully installs on the upgraded VSX Cluster Members M2
and M3.
The Access Control Policy installation fails on the old VSX Cluster Member M1 with a
warning. Ignore this warning.
Step 6 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 7 of 20: Stop all, except one, of the upgraded VSX Cluster Members
Step Description
1 Connect to the command line on all the upgraded VSX Cluster Members M2 and M3.
2 Stop all Check Point services on all upgraded members (for example, M3), except one (for
example, M2):
cpstop
Step 8 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 9 of 20: On the working upgraded VSX Cluster Member - Start the Connectivity
Upgrade
Step Description
1 Connect to the command line on the working upgraded VSX Cluster Member M2.
Step 10 of 20: On the old VSX Cluster Member - Make sure it handles the traffic
Step Description
1 Connect to the command line on the Active old VSX Cluster Member M1.
Step 11 of 20: On the working upgraded VSX Cluster Member - Make sure the
Connectivity Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the working upgraded VSX Cluster Member M2,
this message shows:
Connectivity upgrade status: Ready for Failover
Step 12 of 20: On the stopped upgraded VSX Cluster Members - Start all Check Point
services
Step Description
1 Connect to the command line on the stopped upgraded VSX Cluster Members (in our
example, M3).
Step 13 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 14 of 20: On the Active old VSX Cluster Member - Stop all Check Point services
Step Description
1 Connect to the command line on the Active old VSX Cluster Member M1.
Step 15 of 20: On the upgraded VSX Cluster Members - Examine the cluster state and
make sure the Active handles the traffic
Step Description
1 Connect to the command line on the upgraded VSX Cluster Members M2 and M3.
Step Description
2 Examine the cluster state:
• In Gaia Clish, run:
set virtual-system 0
show cluster state
• In Expert mode, run:
vsenv 0
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are: one is Active, the other is
Standby.
• The cluster state of the old member M1 is either ClusterXL is inactive, or the machine
is down, or Down.
3 Make sure the Active upgraded member handles the traffic:
cphacu stat
4 Make sure to stop the Connectivity Upgrade on the Active upgraded member.
Log in to the Expert mode and run:
cphacu stop
Step 16 of 20: On the former Active old VSX Cluster Member - Upgrade to R80.30 with
CPUSE, or perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a VSX Gateway with CPUSE (on page 374).
Note that you already upgraded the configuration of the VSX Cluster object to R80.30.
• For clean install instructions, see Installing a Security Gateway (on page 70).
Notes:
• You must reboot the VSX Cluster Member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Limitations (on page 415).
Step Description
4 In the Install Policy window:
a) In the Policy field, select the applicable Access Control Policy that is called:
<Name_of_VSX_Cluster_object>_VSX
b) In the Install Mode section, select these two options:
Install on each selected gateway independently
For gateway clusters, if installation on a cluster member fails, do not install
on that cluster
c) Click Install.
5 The Access Control Policy successfully installs on all the VSX Cluster Members.
Step 18 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each cluster member.
Step 19 of 20: On each VSX Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
3 Make sure the CCP mode is set to Auto:
• In Gaia Clish, run:
show cluster members interfaces all
• In Expert mode, run:
cphaprob -a if
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from Virtual Systems on this VSX Cluster to make sure they inspect the
traffic as expected.
Step 1 of 24: On each VRRP Cluster Member - Examine the VRRP state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 2 of 24: On the VRRP Master cluster member M1 - Examine the Critical Devices
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 3 of 24: On the VRRP Master cluster member M1 - Enable the Monitor Firewall
State feature
Enable the Monitor Firewall State feature (if not already enabled) in one of these ways:
Where Instructions
In Gaia Clish Run:
1. set vrrp monitor-firewall on
2. save config
Step 4 of 24: On the VRRP Master cluster member M1 - Make sure it is still the VRRP
Master:
Where Instructions
In Gaia Clish Run:
show vrrp summary
Step 6 of 24: On the VRRP Backup cluster member M2 - Upgrade to R80.30 with CPUSE,
or perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE (on page 372)
• For clean install instructions, see Installing a VRRP Cluster (on page 98).
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• You must disable the preemptive mode (if it is enabled).
• Configure dynamic routing based on the Connectivity Upgrade Limitations (on page 415).
Step 7 of 24: On the upgraded VRRP Cluster Member M2 - Install the R80.20 Jumbo
Hotfix Accumulator
You must install Take 17 and above.
Follow the instructions in sk137592 http://supportcontent.checkpoint.com/solutions?id=sk137592.
Step 8 of 24: In SmartConsole - Modify the Cluster object and install the Access Control
Policy
Step Description
1 Connect with SmartConsole to the R80.30 Security Management Server or Domain
Management Server that manages this VRRP Cluster.
Step Description
2 From the left navigation panel, click Gateways & Servers.
4 From the left navigation tree, click the General Properties page.
6 Click OK.
9 The Access Control Policy successfully installs on the upgraded cluster member M2.
The Access Control Policy installation fails on the old cluster member M1 with a warning.
Ignore this warning.
Step 9 of 24: On each VRRP Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 10 of 24: On each VRRP Cluster Member - Examine the VRRP state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step Description
3 Examine the VRRP state:
show vrrp
Notes:
• Make sure that all the interfaces on the old VRRP Cluster Member are in the VRRP
Master state.
• Make sure that all the interfaces on the upgraded VRRP Cluster Member are in the
VRRP Backup state.
Step 11 of 24: On the upgraded VRRP Cluster Member M2 - Start the Connectivity
Upgrade
Step Description
1 Connect to the command line on the upgraded VRRP Cluster Member M2.
Step 12 of 24: On the old VRRP Cluster Member M1 - Make sure it handles the traffic
Step Description
1 Connect to the command line on the old VRRP Cluster Member M1.
Step 13 of 24: On the upgraded VRRP Cluster Member M2 - Make sure the Connectivity
Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the upgraded VRRP Cluster Member M2, this
message shows:
Connectivity upgrade status: Ready for Failover
Step Description
2 If you synchronized the Dynamic Routing information:
a) Connect to the command line on both the upgraded VRRP Cluster Member M2 and
on the old VRRP Cluster Member M1.
b) Log in to Gaia Clish.
c) Examine the routes:
show route summary
Make sure that the dynamic routes on the upgraded VRRP Cluster Member M2 match the
dynamic routes on the old VRRP Cluster Member M1.
Step 14 of 24: On each VRRP Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 15 of 24: On each VRRP Cluster Member - Examine the VRRP state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 16 of 24: On the old VRRP Cluster Member M1 - Stop all Check Point services
Step Description
1 Connect to the command line on the old VRRP Cluster Member M1.
Step 17 of 24: On the upgraded VRRP Cluster Member M2 - Examine the cluster state
and make sure it handles the traffic
Step Description
1 Connect to the command line on the upgraded VRRP Cluster Member M2.
Step 18 of 24: On the old VRRP Cluster Member M1 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE (on page 372).
• For clean install instructions, see Installing a VRRP Cluster (on page 98).
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Limitations (on page 415).
Step 19 of 24: On the upgraded VRRP Cluster Member M1 - Install the R80.20 Jumbo
Hotfix Accumulator
You must install Take 17 and above.
You must install the same Take you installed on the VRRP Cluster Member M2.
Follow the instructions in sk137592 http://supportcontent.checkpoint.com/solutions?id=sk137592.
5 The Access Control Policy successfully installs on all the cluster members.
Step 21 of 24: On each VRRP Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step 22 of 24: On each VRRP Cluster Member - Examine the VRRP state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
Step Description
3 Examine the VRRP state:
show vrrp
Notes:
• Make sure that all the interfaces on one VRRP Cluster Member are in the VRRP Master
state.
• Make sure that all the interfaces on the other VRRP Cluster Member are in the VRRP
Backup state.
Step 23 of 24: On each VRRP Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each VRRP Cluster Member.
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this VRRP Cluster to make sure it inspects the traffic as expected.
Error Description
Failed to get kernel parameter ### CU could not retrieve the kernel parameter,
which can happen if CU is on the old Cluster
Member.
You must specify the Sync IP and the The user did not pass the sync IP and Cluster
member Id of the old member Member ID to the CU script.
Invalid IP address The IP address passed to the CU script is not in
valid format.
The member Id must be between 1-4 An invalid Cluster Member ID was passed to the
CU script.
Only a single instance of The CU script is already running, and the user
connectivity upgrade can run at a time is trying to run CU again.
Run the ps auxw | cphacu command to make
sure that the CU script is running and wait until
CU finishes running.
Failed to get member state CU could not get the cluster state of the local
Cluster Member.
Run cphaprob state command on the local
Cluster Member and make sure that the output
shows the state of the local Cluster Member.
Connectivity upgrade failed since the CU only runs, if the state of the new Cluster
local member is not in Ready state Member is in the Ready state.
CU examines many times, if the Cluster
Member is in the Ready state.
If the Cluster Member is still not in the Ready
state, then the CU script exits.
Connectivity upgrade failed since For Security Gateways only: CU only runs, if the
Synchronization PNote is set to Critical Device Synchronization reports its state
problem as OK.
CU examines many times, if the Critical Device
Synchronization reports its state as OK.
If the Critical Device Synchronization reports
its state as PROBLEM, then the CU script exits.
If you get this error, install policy on this cluster
and run the cphacu script again.
Error Description
Connectivity upgrade failed because When CU starts, the two Cluster Members
CPHAPROB cannot see the old member's begin to communicate, and the new Cluster
state. Member sees the old Cluster Member as
Active.
Check communication on the Sync interface,
and make sure that the MAC Magic
Configuration is correct.
Failed to enable Connectivity Upgrade CU could not update the kernel about the status
of this kernel parameter.
Failed to get fwha_version
Failed to get This can happen, if you run CU on a version that
fwha_cu_override_last_heard_ccp_ver does not support CU.
sion of the other member
Failed to get
fwha_cu_last_heard_ccp_version of
the other member
Failed to initialize full sync for VS CU failed to start a Full Sync for this Virtual
###; Connectivity Upgrade failed System, which synchronizes the connections
from the old Cluster Member to the new
Cluster Member.
Failed to run fullsync for VS ###; The Full Sync started, but did not finish for this
Connectivity Upgrade failed Virtual System.
This means that some of the connections were
not synchronized.
Failed to run cphacu state for VS ### The script cphacu state failed to show the
current CU state for this Virtual System.
Error printing connections table per CU failed to print the connection table summary
vs for each Virtual System.
Use the Optimal Service Upgrade (OSU) method to upgrade a Security Gateway Cluster or a VSX
Cluster. This procedure lets you upgrade the cluster with a minimum loss of connectivity.
When you upgrade the cluster, two Cluster Members are used to process the network traffic. New
connections that are opened during the upgrade procedure are maintained after the upgrade is
finished. Connections that were opened on the old version are discarded after the upgrade.
Upgrade to version
Upgrade from version R76 R77 R77.10 R77.20 R77.30 R80.10 R80.20
R80.10 x x x x x x Yes
R77.30 x x x x x Yes Yes
R77.20 x x x x Yes Yes Yes
R77.10 x x x Yes Yes Yes Yes
R77 x x Yes Yes Yes Yes Yes
R76 x Yes Yes Yes Yes Yes Yes
R75.40VS Yes Yes Yes Yes Yes Yes Yes
Notes:
• For supported upgrade paths, see the Release Notes for the version, to which you wish to
upgrade.
• "x" denotes that Optimal Service Upgrade does not support this upgrade.
• "Yes" denotes that Optimal Service Upgrade supports this upgrade path.
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
The procedure below describes an example cluster with three Cluster Members M1, M2 and M3.
However, you can use it for clusters that consist of two or more Cluster Members.
Workflow:
1. On the Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
2. On the Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
3. In SmartConsole - Change the version of the cluster object
4. In SmartConsole - Install the Access Control Policy
5. On each Cluster Member - Examine the cluster state
6. Disconnect the upgraded Cluster Members M2 and M3 from their networks
Step 1 of 20: On the Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a
Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a ClusterXL Cluster (on page 82), or Installing a
scratch VRRP Cluster (on page 98).
In the Gaia First Time Configuration Wizard, for the Management
Connection IP address, you must use the same IP address as was
used by the previous Cluster Member (prior to the upgrade).
Note - You must reboot the Cluster Member after the upgrade or clean install.
Step 2 of 20: On the Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a
Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Note - You must reboot the Cluster Member after the upgrade or clean install.
4 From the left navigation tree, click the General Properties page.
6 If you performed a Clean Install of R80.30 on the Cluster Member, then establish the
Secure Internal Communication (SIC) between the Management Server and this Cluster
Member:
a) From the left tree, click Cluster Members.
b) Select the Cluster Member object.
c) Click Edit.
d) On the General tab, click the Communication button.
e) Click Reset.
f) In the One-time password field, enter the same Activation Key you entered during
the First Time Configuration Wizard of the Cluster Member.
g) In the Confirm one-time password field, enter the same Activation Key again.
h) Click Initialize.
i) The Trust state field must shows Trust established.
j) Click Close to close the Communication window.
k) Click OK to close the Cluster Member Properties window.
3 The Access Control Policy successfully installs on the upgraded Cluster Members M2 and
M3.
The Access Control Policy installation fails on the old Cluster Member M1 with a warning.
Ignore this warning.
Step 6 of 20: Disconnect the upgraded Cluster Members M2 and M3 from their networks
Step Description
1 Select one Cluster Member M1 to process the current connections.
2 Completely disconnect all other Cluster Members M2 and M3 from their networks (this
includes the Management Server).
Step 7 of 20: On one of the upgraded Cluster Members M2 connect the Sync cable
Step Description
1 Connect the cable between the Sync interface on one of the upgraded Cluster Members
M2 and the Sync interface on the old Cluster Member M1.
Step Description
2 Make sure traffic can pass between the Sync interfaces (for example, pings).
Step 8 of 20: On the old Cluster Member M1 - Start the Optimal Service Upgrade
Step Description
1 Connect to the command line on the old Cluster Member M1.
Step 9 of 20: On the connected upgraded Cluster Member M2 - Start the Optimal Service
Upgrade
Step Description
1 Connect to the command line on the connected upgraded Cluster Member M2.
Step 10 of 20: On the old Cluster Member M1 - Stop the Optimal Service Upgrade
Step Description
1 Connect to the command line on the old Cluster Member M1.
4 When the old Cluster Member does not have many connections (in your opinion), stop the
Optimal Service Upgrade:
[Expert@MemberOld:0]# cphaosu finish
Step 11 of 20: On the connected upgraded Cluster Member M2 - Stop the Optimal
Service Upgrade
Step Description
1 Connect to the command line on the connected upgraded Cluster Member M2.
Step Description
4 Stop the Optimal Service Upgrade:
[Expert@MemberNew:0]# cphaosu finish
Step 12 of 20: Disconnect the old Cluster Member M1 from its networks
Completely disconnect the old Cluster Member M1 from its networks (this includes the
Management Server).
4 Connect the upgraded Cluster Member M2 to all its network (this includes the
Management Server)
4 Connect the upgraded Cluster Member M3 to all its network (this includes the
Management Server)
Step 15 of 20: On the old Cluster Member M1 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a ClusterXL Cluster (on page 82), or Installing a
scratch VRRP Cluster (on page 98).
In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the same IP
address as was used by the previous Cluster Member (prior to
the upgrade).
Note - You must reboot the Cluster Member after the upgrade or clean install.
Step 16 of 20: In SmartConsole - Establish SIC with the former old Cluster Member M1
This step is required only if you performed a Clean Install of R80.30 on this Cluster Member.
Step Description
1 Connect with the SmartConsole to the R80.30 Security Management Server or Main
Domain Management Server that manages this Cluster.
6 Click Edit.
8 Click Reset.
9 In the One-time password field, enter the same Activation Key you entered during the First
Time Configuration Wizard of the Cluster Member.
10 In the Confirm one-time password field, enter the same Activation Key again.
11 Click Initialize.
Step Description
12 The Trust state field must shows Trust established.
5 The Access Control Policy successfully installs on all the Cluster Members.
Step 19 of 20: On each Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each Cluster Member.
Step Description
2 Change the CCP mode:
• In Gaia Clish, run:
set cluster member ccp auto
save config
• In Expert mode, run:
cphaconf set_ccp auto
Notes:
• This change does not require a reboot.
• This change applies immediately and survives reboot.
3 Make sure the CCP mode is set to Auto:
• In Gaia Clish, run:
show cluster members interfaces all
• In Expert mode, run:
cphaprob -a if
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Cluster to make sure it inspects the traffic as expected.
5 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.
The procedure below describes an example VSX Cluster with three Cluster Members M1, M2 and
M3. However, you can use it for clusters that consist of two or more Cluster Members.
Workflow:
1. On the Management Server - Upgrade the configuration of the VSX Cluster object to R80.30
2. On the VSX Cluster Member M2 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
3. On the VSX Cluster Member M3 - Upgrade to R80.30 with CPUSE, or perform a Clean Install of
R80.30
4. In SmartConsole - Install the Access Control Policy
5. On each VSX Cluster Member - Examine the cluster state
6. Disconnect the upgraded VSX Cluster Members M2 and M3 from their networks
7. On one of the upgraded VSX Cluster Members M2 connect the Sync cable
8. On the old VSX Cluster Member M1 - Start the Optimal Service Upgrade
9. On the connected upgraded VSX Cluster Member M2 - Start the Optimal Service Upgrade
10. On the old VSX Cluster Member M1 - Stop the Optimal Service Upgrade
11. On the connected upgraded VSX Cluster Member M2 - Stop the Optimal Service Upgrade
12. Disconnect the old VSX Cluster Member M1 from its networks
13. Reconnect the upgraded VSX Cluster Member M2 to its networks
14. Reconnect the upgraded VSX Cluster Member M3 to its networks
15. On the old VSX Cluster Member M1 - Upgrade with CPUSE, or perform a Clean Install
16. In SmartConsole - Install the Access Control Policy
17. On each VSX Cluster Member - Examine the VSX state
18. On each VSX Cluster Member - Examine the cluster state
19. On each VSX Cluster Member - Change the CCP mode to Auto
20. Test the functionality
Step 1 of 20: On the Management Server - Upgrade the configuration of the VSX Cluster
object to R80.30
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Cluster.
3 On a Multi-Domain Server, go to the context of the Main Domain Management Server that
manages this VSX Cluster object:
mdsenv <IP Address or Name of Main Domain Management Server>
4A Run:
vsx_util upgrade
This command is interactive.
4D Select R80.30.
5 Connect with SmartConsole to the R80.30 Security Management Server or Main Domain
Management Server that manages this VSX Cluster.
Step Description
7 Open the VSX Cluster object.
8 From the left navigation tree, click the General Properties page.
9 Make sure in the Platform section, the Version field shows R80.30.
Step 2 of 20: On the VSX Cluster Member M2 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Clean Install of R80.30 from See Installing a VSX Cluster (on page 92).
scratch 1. In the Gaia First Time Configuration Wizard, for the
Management Connection IP address, you must use the
same IP address as was used by the previous VSX Cluster
Member (prior to the upgrade).
2. After you complete the Gaia First Time Configuration Wizard
and reboot, run the vsx_util reconfigure command on
the Management Server to push the VSX configuration to the
VSX Cluster Member. You must enter the same Activation
Key you entered during the First Time Configuration Wizard
of the VSX Cluster Member.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
Step 3 of 20: On the VSX Cluster Member M3 - Upgrade to R80.30 with CPUSE, or
perform a Clean Install of R80.30
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
5 The Access Control Policy successfully installs on the upgraded VSX Cluster Members M2
and M3.
The Access Control Policy installation fails on the old VSX Cluster Member M1 with a
warning. Ignore this warning.
Step 5 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 6 of 20: Disconnect the upgraded VSX Cluster Members M2 and M3 from their
networks
Step Description
1 Select one VSX Cluster Member M1 to process the current connections.
2 Completely disconnect all other VSX Cluster Members M2 and M3 from their networks
(this includes the Management Server).
Step 7 of 20: On one of the upgraded VSX Cluster Members M2 connect the Sync cable
Step Description
1 Connect the cable between the Sync interface on one of the upgraded VSX Cluster
Members M2 and the Sync interface on the old VSX Cluster Member M1.
2 Make sure traffic can pass between the Sync interfaces (for example, pings).
Step 8 of 20: On the old VSX Cluster Member M1 - Start the Optimal Service Upgrade
Step Description
1 Connect to the command line on the old VSX Cluster Member M1.
Step 9 of 20: On the connected upgraded VSX Cluster Member M2 - Start the Optimal
Service Upgrade
Step Description
1 Connect to the command line on the connected upgraded VSX Cluster Member M2.
Step 10 of 20: On the old VSX Cluster Member M1 - Stop the Optimal Service Upgrade
Step Description
1 Connect to the command line on the old VSX Cluster Member M1.
4 When the old VSX Cluster Member does not have many connections (in your opinion), stop
the Optimal Service Upgrade:
[Expert@MemberOld:0]# cphaosu finish
Step 11 of 20: On the connected upgraded VSX Cluster Member M2 - Stop the Optimal
Service Upgrade
Step Description
1 Connect to the command line on the connected upgraded VSX Cluster Member M2.
Step 12 of 20: Disconnect the old VSX Cluster Member M1 from its networks
Completely disconnect the old VSX Cluster Member M1 from its networks (this includes the
Management Server).
Step 13 of 20: Reconnect the upgraded VSX Cluster Member M2 to its networks
Step Description
1 Connect to the command line on the upgraded VSX Cluster Member M2.
Step Description
3 Stop the cluster:
[Expert@MemberNew:0]# cphastop
4 Connect the upgraded VSX Cluster Member M2 to all its network (this includes the
Management Server)
Step 14 of 20: Reconnect the upgraded VSX Cluster Member M3 to its networks
Step Description
1 Connect to the command line on the upgraded VSX Cluster Member M3.
4 Connect the upgraded VSX Cluster Member M3 to all its network (this includes the
Management Server)
Step 15 of 20: On the old VSX Cluster Member M1 - Upgrade with CPUSE, or perform a
Clean Install
Upgrade or perform Clean Install for all the VSX Cluster Members (in our example, M2 and M3),
except for the VSX Cluster Member with the lowest Cluster Member ID (in our example, M1).
Installation Method Instructions
Upgrade to R80.30 with CPUSE See Installing Software Packages on Gaia (on page 118).
Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Upgrade.
Clean Install of R80.30 with See Installing Software Packages on Gaia (on page 118).
CPUSE Follow the applicable action plan for the local or central
installation.
Select the R80.30 package and perform Clean Install.
Note - You must reboot the VSX Cluster Member after the upgrade or clean install.
5 The Access Control Policy successfully installs on all the VSX Cluster Members.
Step 17 of 20: On each VSX Cluster Member - Examine the VSX state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
3 Examine the VSX state:
vsenv 0
vsx stat -v
Notes:
• Make sure all the configured Virtual Devices are loaded.
• Make sure all Virtual Systems and Virtual Routers have policy and SIC.
Step 18 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step 19 of 20: On each VSX Cluster Member - Change the CCP mode to Auto
Step Description
1 Connect to the command line on each VSX Cluster Member.
Step Description
3 Make sure the CCP mode is set to Auto:
• In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
• In Expert mode, run:
vsenv 0
cphaprob -a if
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from Virtual Systems on this VSX Cluster to make sure they inspect the
traffic as expected.
For information on ClusterXL functionality, see the R80.30 ClusterXL Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_ClusterXL_Admi
nGuide/html_frameset.htm.
For information on Security Management Servers, see the R80.30 Security Management
Administration Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_SecurityManage
ment_AdminGuide/html_frameset.htm.
Important - SmartEvent Server is not supported in Management High Availability and Full High
Availability Cluster environments (sk25164
http://supportcontent.checkpoint.com/solutions?id=sk25164). For these environments, install a
Dedicated SmartEvent Server (on page 51).
Step 1 of 4: Install first Full High Availability Cluster Member that runs the Primary
Security Management Server
Step Description
1 Install the Gaia Operating System:
• Installing the Gaia Operating System on a Check Point Appliance (on page 18)
• Installing the Gaia Operating System on an Open Server (on page 20)
2 Run the Gaia First Time Configuration Wizard (on page 25).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select both Security Gateway and Security Management.
b) In the Clustering section:
Clear Unit is a part of a cluster, type.
In the Define Security Management as field, select Primary.
• In the Security Management Administrator window, select one of these options:
• Use Gaia administrator
• Define a new administrator and configure it
• In the Security Management GUI Clients window, configure the applicable allowed
computers:
• Any IP Address - Allows all computers to connect
• This machine - Allows only the single specified computer to connect
• Network - Allows all computers on the specified network to connect
• Range of IPv4 addresses - Allows all computers in the specified range to connect
5 In the left navigation tree, click Network Management > Network Interfaces.
Configure all required interfaces with applicable unique IP addresses.
Step Description
6 Install the R80.30 SmartConsole (on page 68).
Step 2 of 4: Install second Full High Availability Cluster Member that runs the
Secondary Security Management Server
Step Description
1 Install the Gaia Operating System:
• Installing the Gaia Operating System on a Check Point Appliance (on page 18)
• Installing the Gaia Operating System on an Open Server (on page 20)
2 Run the Gaia First Time Configuration Wizard (on page 25).
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select both Security Gateway and Security Management.
b) In the Clustering section:
Clear Unit is a part of a cluster, type.
In the Define Security Management as field, select Secondary.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
4 In your web browser, connect to the Gaia Portal at:
https://<IP address of Gaia Management interface>
5 In the left navigation tree, click Network Management > Network Interfaces.
Configure all required interfaces with applicable unique IP addresses.
3 In the left navigation tree, click Network Management > Network Interfaces.
Step Description
5 Make sure the Link Status on the synchronization interfaces is Up.
4 Click Next.
5 Configure the settings for the Full High Availability Cluster Member that runs the
Secondary Security Management Server:
a) In the Secondary Member Name field, enter the hostname that you entered during
the First Time Configuration Wizard.
b) In the Secondary Member Name IP Address field, enter the IP address of the Gaia
Management Interface that you entered during the First Time Configuration Wizard.
c) Enter and confirm the SIC Activation Key that you entered during the First Time
Configuration Wizard.
6 Click Next.
Step Description
10 Click Finish.
11 Install policy on the primary. Only after policy install can the primary sync with the
secondary.
Step Description
1 Install a dedicated Log Server (on page 51).
2 Connect with SmartConsole to the Full High Availability Cluster Member that runs the
Primary Security Management Server.
5 From the left navigation tree, click Logs > Additional Logging Configuration.
6 Select Forward log files to Log Server and select the object of the dedicated Log Server.
7 In the Log forwarding schedule field, select or define a Scheduled Event object.
8 Click OK.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Standalone.
Workflow:
1. Upgrade the Security Management Server with CPUSE
2. Install the R80.30 SmartConsole
3. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
4. Install the management database
5. Install the Event Policy
6. Install the Security Policy
7. Test the functionality
Step 3 of 7: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the R80.30 Standalone.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Standalone.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Standalone, run the Pre-Upgrade Verifier and export the entire management
database
3. Get the R80.30 Standalone
4. On the R80.30 Standalone, import the databases
5. Install the R80.30 SmartConsole
6. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
7. Install the management database
8. Install the Event Policy
9. Install the Security Policy
10. Test the functionality
Step Description
2 Transfer the R80.30 Management Server Migration Tool package to the current
Standalone to some directory (for example, /var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 10: On the current Standalone, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
1 Connect to the command line on the current Standalone.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@SA:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@SA:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) In a Management High Availability environment, if you made changes,
synchronize the Management Servers immediately after these changes.
iii) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Standalone:
[Expert@SA:0]# yes | nohup ./migrate export [-l | -x] [-n] /<Full
Path>/<Name of Exported File>
• If Endpoint Policy Management blade is enabled on this Standalone:
[Expert@SA:0]# yes | nohup ./migrate export [-l | -x] [-n]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>
For details, see:
• The R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_
ReferenceGuide/html_frameset.htm - Chapter Security Management Server
Commands - Section migrate.
• sk133312 http://supportcontent.checkpoint.com/solutions?id=sk133312.
7 This step applies only to R7x and R80 versions.
If SmartEvent Software Blade is enabled, then export the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
9 Transfer the exported databases from the current Standalone to an external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
Important:
The IP address of the source and target Standalone must be the same. If you need to have a
different IP address on the R80.30 Standalone, you can change it only after the upgrade
procedure. Note that you have to issue licenses for the new IP address.
3 Transfer the exported databases from an external storage to the R80.30 Standalone, to
some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Standalone:
[Expert@SA:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
7 This step applies only if you upgraded from R7x and R80 versions.
If SmartEvent Software Blade is enabled, then import the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
Step 6 of 10: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Standalone manages dedicated Log Servers or SmartEvent Servers, you must upgrade
these dedicated servers to the same version as the Standalone:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the R80.30 Standalone.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
Step Description
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Standalone.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the current Standalone, run the Pre-Upgrade Verifier and export the entire management
database
3. Install a new R80.30 Standalone
4. On the R80.30 Standalone, import the databases
5. Install the R80.30 SmartConsole
6. Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
7. Install the management database
8. Install the Event Policy
9. Install the Security Policy
10. Test the functionality
11. Disconnect the old Standalone from the network
12. Connect the new Standalone to the network
2 Transfer the R80.30 Management Server Migration Tool package to the current Standalone
to some directory (for example, /var/log/path_to_upgrade_tools/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 12: On the current Standalone, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
1 Connect to the command line on the current Standalone.
3 Go to the directory, where you put the R80.30 upgrade tools package:
[Expert@SA:0]# cd /var/log/path_to_upgrade_tools/
5 Important - This step applies only when you upgrade from R77.30 (or lower).
Run the Pre-Upgrade Verifier (PUV).
a) Run this command and use the applicable syntax based on the instructions on the
screen:
[Expert@SA:0]# ./pre_upgrade_verifier -h
b) Read the Pre-Upgrade Verifier output.
If you need to fix errors:
i) Follow the instructions in the report.
ii) In a Management High Availability environment, if you made changes,
synchronize the Management Servers immediately after these changes.
iii) Run the Pre-Upgrade Verifier again.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Standalone:
[Expert@SA:0]# yes | nohup ./migrate export [-l | -x] [-n] /<Full
Path>/<Name of Exported File>
• If Endpoint Policy Management blade is enabled on this Standalone:
[Expert@SA:0]# yes | nohup ./migrate export [-l | -x] [-n]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>
For details, see:
• The R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_
ReferenceGuide/html_frameset.htm - Chapter Security Management Server
Commands - Section migrate.
• sk133312 http://supportcontent.checkpoint.com/solutions?id=sk133312.
7 This step applies only to R7x and R80 versions.
If SmartEvent Software Blade is enabled, then export the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
9 Transfer the exported databases from the current Standalone to an external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
2 Perform a clean install of the R80.30 Standalone (on page 109) on another computer.
Important:
The IP address of the source and target Standalone must be the same. If you need to have a
different IP address on the R80.30 Standalone, you can change it only after the upgrade
procedure. Note that you have to issue licenses for the new IP address.
Step Description
2 Log in to the Expert mode.
3 Transfer the exported databases from an external storage to the R80.30 Standalone, to
some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Standalone:
[Expert@SA:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
8 Restart the Check Point services:
[Expert@SA:0]# cpstop
[Expert@SA:0]# cpstart
Step 6 of 12: Upgrade the dedicated Log Servers and dedicated SmartEvent Servers
If your Security Management Server manages dedicated Log Servers or SmartEvent Servers, you
must upgrade these dedicated servers to the same version as the Security Management Server:
• Upgrading a Dedicated Log Server from R80.20, R80.10, and lower (on page 162)
• Upgrading a Dedicated SmartEvent Server from R80.20, R80.10, and lower (on page 175)
4 Click Install.
5 Click OK.
Step Description
1 Connect with SmartConsole to the R80.30 Standalone.
2 In the SmartConsole, from the left navigation panel, click Logs & Monitor.
4 In the bottom left corner, in the External Apps section, click SmartEvent Settings &
Policy.
The Legacy SmartEvent client opens.
5 In the top left corner, click Menu > Actions > Install Event Policy.
6 Confirm.
Step Description
7 Wait for these messages to appear:
SmartEvent Policy Installer installation complete
SmartEvent Policy Installer installation succeeded
8 Click Close.
2 Make sure the management database and configuration were upgraded correctly.
Workflow:
1. Back up the current R80.30 Security Management Server
2. On the current R80.30 Security Management Server, export the entire management database
3. Install a new R80.30 Security Management Server
4. On the new R80.30 Security Management Server, import the database
5. Test the functionality
6. Disconnect the old Security Management Server from the network
Step 2 of 7: On the current R80.30 Security Management Server, export the entire
management database
Step Description
1 Connect to the command line on the current R80.30 Security Management Server.
Step Description
6 Export the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server export -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the Management Server Migration Tool.
• -l - Exports the Check Point logs without log indexes in the $FWDIR/log/ directory.
Note - The command can export only closed logs (to which the information is not
currently written).
• -x - Exports the Check Point logs with their log indexes in the $FWDIR/log/
directory. Note - The command can export only closed logs (to which the information is
not currently written).
• --exclude-uepm-postgres-db - Does not back up the PostgreSQL database
during the export operation.
• --include-uepm-msi-files - Backs up the MSI files from the Endpoint Security
Management Server during the export operation.
7 This step applies only to R7x and R80 versions.
If SmartEvent Software Blade is enabled, then export the Events database.
See sk110173 http://supportcontent.checkpoint.com/solutions?id=sk110173.
Step Description
8 Calculate the MD5 for the exported database files:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
9 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Note - Make sure to transfer the file in the binary mode.
2 Perform a clean install of the R80.30 Security Management Server (on page 45) on another
computer.
Important:
The IP addresses of the source and target R80.30 Security Management Servers must be the
same. If you need to have a different IP address on the R80.30 Security Management Server, you
can change it only after the upgrade procedure. Note that you have to issue licenses for the new IP
address. For applicable procedures, see sk40993
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetail
s=&solutionid=sk40993&js_peid=P-114a7bc3b09-10006&partition=General&product=Security and
sk65451 http://supportcontent.checkpoint.com/solutions?id=sk65451.
Step 4 of 7: On the new R80.30 Security Management Server, import the database
Step Description
1 Connect to the command line on the R80.30 Security Management Server.
3 Transfer the exported databases from an external storage to the R80.30 Security
Management Server, to some directory.
Note - Make sure to transfer the files in the binary mode.
4 Make sure the transferred files are not corrupted. Calculate the MD5 for the transferred
files and compare them to the MD5 that you calculated on the original Security
Management Server:
[Expert@MGMT:0]# md5sum /<Full Path>/<Name of Database File>.tgz
Step Description
6 Import the management database:
• If Endpoint Policy Management blade is disabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
/<Full Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x] /<Full Path>/<Name of Exported
File>.tgz
• If Endpoint Policy Management blade is enabled on this Security Management Server
and:
• This Security Management Server is connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30 [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
• This Security Management Server is not connected to the Internet, run:
[Expert@MGMT:0]# ./migrate_server import -v R80.30
-skip_upgrade_tools_check [-l | -x]
[--exclude-uepm-postgres-db] [--include-uepm-msi-files] /<Full
Path>/<Name of Exported File>.tgz
Note - The migrate_server import command automatically restarts Check Point
services (performs cpstop and cpstart).
Syntax options:
• -v R80.30 - Specifies the version, to which you plan to upgrade.
• -skip_upgrade_tools_check - Does not try to connect to Check Point Cloud to
check for a more recent version of the upgrade tools.
• -l - Imports the Check Point logs without log indexes in the $FWDIR/log/ directory.
• -x - Imports the Check Point logs with their log indexes in the $FWDIR/log/
directory.
• --exclude-uepm-postgres-db - Does not restore the PostgreSQL database during
the import operation.
• --include-uepm-msi-files - Restores the MSI files from the Endpoint Security
Management Server during the import operation.
2 Make sure the management database and configuration were imported correctly.
Step 6 of 7: Disconnect the old Security Management Server from the network
2 Make sure that you are migrating the database only on one Domain Management Server.
If you migrate a database to more than one Domain Management Server, the import fails
and shows an error message.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. Export the entire management database from the R7x Security Management Server
3. On the R80.30 Security Management Server, create a new Domain Management Server
4. Transfer the exported R7x Security Management Server management database to the R80.30
Multi-Domain Server
5. On the R80.30 Multi-Domain Server, import R7x Security Management Server management
database to the new Domain Management Server
6. Reset SIC, create a new ICA, and establish SIC Trust with managed Security Gateways
7. Configure the VPN keys
2 Transfer the R80.30 upgrade tools package to the R7x Standalone to some directory (for
example, /var/log/path_to_Management Server Migration Tool/).
Note - Make sure to transfer the file in the binary mode.
Step 2 of 7: Export the entire management database from the R7x Security Management
Server
Step Description
1 Connect to the command line on the R7x Security Management Server.
3 Go to the directory, where you put the R80.30 Management Server Migration Tool package:
[Expert@R7x_MGMT:0]# cd /var/log/Management Server Migration Tool/
7 Transfer the exported database from the R7x Security Management Server to an external
storage:
/<Full Path>/<Name of R7x MGMT Exported File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step Description
3 Create a new Domain Management Server:
Note - This is one long command will multiple parameters.
[[email protected]_MDS:0]# mgmt_cli --root true add domain name <Name of
New Domain> comments "<Desired Comment Text>" servers.ip-address <IPv4
Address of New Domain> servers.name <Name of New Domain Management Server>
servers.multi-domain-server <Name of R80.30 Multi-Domain Server>
servers.skip-start-domain-server true
For more information, see the Management API Reference
https://sc1.checkpoint.com/documents/latest/APIs/index.html - mgmt_cli tool - Chapter
Multi-Domain - Section Domain - Subsection add domain.
Important! After you create the new Domain with this command, do not change the
Domain IPv4 address until you run the cma_migrate command.
Step Description
2 Import the R7x Security Management Server management database:
[[email protected]_MDS:0]# cma_migrate /<Full Path>/<Name of R7x MGMT
Exported File>.tgz /<Full Path>/<$FWDIR Directory of the New Domain Management
Server>/
Example:
[[email protected]_MGMT:0]# cma_migrate
/var/log/orig_R7x_database.tgz
/opt/CPmds-R80.30/customers/MyDomain3/CPsuite-R80.30/fw1/
Note - This command updates the database schema before it imports. First, the command
runs pre-upgrade verification. If no errors are found, migration continues. If there are
errors, you must fix them on the source R7x Security Management Server according to
instructions in the error messages. Then do this procedure again.
Step 6 of 7: Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Note - This step applies if the new R80.30 Domain Management Server has a different IPv4
address than the R7x Security Management Server.
Step Description
1 Connect to the command on the R80.30 Multi-Domain Server.
3 Stop the new Domain Management Server, into which you migrated the management
database from an R7x Domain Management Server:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
Step Description
8 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[[email protected]_MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstat
9 Establish the Secure Internal Communication (SIC) between the Management Server and
the managed Security Gateways:
a) Reset SIC on each Security Gateway that was managed by the original R7x Security
Management Server.
For detailed procedure, see sk65764: How to reset SIC
http://supportcontent.checkpoint.com/solutions?id=sk65764.
b) Connect with SmartConsole to the new Domain Management Server.
c) Open the object of each Security Gateway.
d) Establish SIC Trust with of each Security Gateway.
e) Install the Access Control Policy on each Security Gateway.
Workflow:
1. Perform a Clean Install of a target R80.30 Multi-Domain Server
2. Get the R80.30 Management Server Migration Tool on the R7x Multi-Domain Server
3. Export the global management database from the R7x Global Domain
4. On the Primary R80.30 Multi-Domain Server, set the Global Domain to the Active state
5. On the R80.30 Multi-Domain Server, remove all the global objects from the Global Domain
6. On the R80.30 Multi-Domain Server, import the R7x global management database to the
Global Domain
7. In R80.30 Multi-Domain Server High Availability, synchronize the global databases
Step 2 of 7: Get the R80.30 Management Server Migration Tool on the R7x <tp_mds
Step Description
1 Download the R80.30 Management Server Migration Tool (on page 136) from the R80.30
Home Page SK.
2 Transfer the R80.30 Management Server Migration Tool package to the R7x Multi-Domain
Server to some directory (for example, /var/log/path_to_Management Server
Migration Tool/).
Note - Make sure to transfer the file in the binary mode.
Step 3 of 7: Export the global management database from the R7x Global Domain
Step Description
1 Close all GUI clients (SmartConsole applications) connected to the R7x Multi-Domain
Server.
Step Description
3 Log in with the superuser credentials.
5 Go to the directory, where you put the R80.30 Management Server Migration Tool package:
[Expert@R7x_MDS:0]# cd /var/log/path_to_upgrade_tools/
10 Transfer the exported database from the R7x Multi-Domain Server to an external storage:
/<Full Path>/R7x_global_policies.tgz
Note - Make sure to transfer the file in the binary mode.
Step 4 of 7: On the Primary R80.30 Multi-Domain Server, set the Global Domain to the
Active state
In Management High Availability environment, make sure Global Domain is in the Active state on
the Primary Multi-Domain Server.
Step Description
1 Connect with SmartConsole to the IP address of the Primary R80.30 Multi-Domain Server.
Select the MDS context.
3 If the Global Domain on the Primary Multi-Domain Server is in the Standby state, then
proceed to the next Step 4.
If the Global Domain on the Primary Multi-Domain Server is already in the Active state,
then skip to the next procedure Step 5 of 7.
Step Description
4 Right-click the cell of the Global Domain, and select Connect to Domain Server.
5 In the Domain SmartConsole instance, in the top left corner, click Menu > Management
High Availability.
6 In the High Availability Status window, in the Connected To section, click Actions > Set
Active.
Step 5 of 7: On the R80.30 Multi-Domain Server, remove all the global objects from the
Global Domain
Note - This step applies only if you already configured global objects on the R80.30 Multi-Domain
Server.
Step Description
1 Connect with SmartConsole to the IP address of the Multi-Domain Server.
Select the MDS context.
Note - In Multi-Domain Server High Availability environment, connect to the Primary
Multi-Domain Server.
3 Right-click the cell of the Global Domain, and select Connect to Domain Server.
4 In the Domain SmartConsole instance, click Objects menu > Object Explorer.
Step 6 of 7: On the R80.30 Multi-Domain Server, import the R7x global management
database to the Global Domain
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Note - In Multi-Domain Server High Availability environment, connect to the Primary
Multi-Domain Server.
Step Description
4 Transfer the exported database from an external storage to the R80.30 (Primary)
Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
9 Make sure that on all Domain Management Servers, all the required daemons (FWM, FWD,
CPD, and CPCA) are in the state "up" and show their PID:
[Expert@R8x_MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[Expert@R8x_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[Expert@R8x_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[Expert@R8x_MDS:0]# mdsstat
Step Description
3 Right-click the cell of the Global Domain Server in the Active state, and select Connect to
Domain Server.
4 In the Domain SmartConsole instance, in the top left corner, click Menu > Management
High Availability.
5 In the High Availability Status window, in the Peers section, click Sync Peer.
Note - The synchronization operation can take many minutes to complete.
2 Make sure in R7x SmartDomain Manager that there is one Domain Management Server in
the Active state in each Domain to be migrated.
3 Make sure that you are migrating the database only on one Domain Management Server.
If you migrate a database to more than one Domain Management Server, the import fails
and shows an error message.
Workflow:
1. Get the R80.30 Management Server Migration Tool
2. On the R7x Multi-Domain Server, export the Domain Management Server management
database
3. On the R80.30 Multi-Domain Server, create a new Domain Management Server
4. Transfer the exported R7x Domain Management Server management database to the R80.30
Multi-Domain Server
5. On the R80.30 Multi-Domain Server, import the R7x Domain Management Server management
database to the new Domain Management Server
6. Reset SIC, create a new ICA, and establish SIC Trust with managed Security Gateways
7. Configure the VPN keys
2 Transfer the R80.30 Management Server Migration Tool package to the R7x Multi-Domain
Server to some directory (for example, /var/log/path_to_Management Server
Migration Tool/).
Note - Make sure to transfer the file in the binary mode.
Installation and Upgrade Guide R80.30 | 510
Step 2 of 7: On the R7x Multi-Domain Server, export the Domain Management Server
management database
Step Description
1 Connect to the command line on the R7x Multi-Domain Server.
4 Go to the directory, where you put the R80.30 Management Server Migration Tool package:
[Expert@R7x_MDS:0]# cd /var/log/path_to_upgrade_tools/
7 Export the entire management database from the Domain Management Server:
[Expert@R7x_MDS:0]# yes | nohup ./migrate export [-l | -x] /<Full
Path>/<Name of R7x Domain Exported File>
For details, see the R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_Ref
erenceGuide/html_frameset.htm - Chapter Security Management Server Commands -
Section migrate.
9 Transfer the exported Domain Management Server database from the current
Multi-Domain Server to an external storage:
/<Full Path>/<Name of R7x Domain Exported File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step Description
4 Create a new Domain Management Server:
Note - This is one long command will multiple parameters.
[[email protected]_MDS:0]# mgmt_cli --root true add domain name <Name of
New Domain> comments "<Desired Comment Text>" servers.ip-address <IPv4
Address of New Domain> servers.name <Name of New Domain Management Server>
servers.multi-domain-server <Name of R80.30 Multi-Domain Server>
servers.skip-start-domain-server true
For more information, see the Management API Reference
https://sc1.checkpoint.com/documents/latest/APIs/index.html - mgmt_cli tool - Chapter
Multi-Domain - Section Domain - Subsection add domain.
Important! After you create the new Domain with this command, do not change the
Domain IPv4 address until you run the cma_migrate command.
Step 5 of 7: On the R80.30 Multi-Domain Server, import the R7x Domain Management
Server management database to the new Domain Management Server
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step Description
5 Import the R7x Domain Management Server management database:
[[email protected]_MDS:0]# cma_migrate /<Full Path>/<Name of R7x Domain
Exported File>.tgz /<Full Path>/<$FWDIR Directory of the New Domain Management
Server>/
Example:
[[email protected]_MDS:0]# cma_migrate /var/log/orig_R7x_database.tgz
/opt/CPmds-R80.30/customers/MyDomain3/CPsuite-R80.30>/fw1/
Note - This command updates the database schema before it imports. First, the command
runs pre-upgrade verification. If no errors are found, migration continues. If there are
errors, you must fix them on the source R7x Domain Management Server according to
instructions in the error messages. Then do this procedure again.
6 Start the new Domain Management Server with the imported R7x management database:
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
7 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[[email protected]_MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstat
Step 6 of 7: Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Note - This step applies if the new R80.30 Domain Management Server has a different IPv4
address than the R7x Domain Management Server.
Step Description
1 Connect to the command on the R80.30 Multi-Domain Server.
4 Stop the new Domain Management Server, into which you migrated the management
database from an R7x Domain Management Server:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
Installation and Upgrade Guide R80.30 | 513
Step Description
5 Go to the context of the new Domain Management Server:
[[email protected]_MDS:0]# mdsenv <IP Address or Name of Domain Management
Server>
9 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[[email protected]_MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstat
10 Establish the Secure Internal Communication (SIC) between the Management Server and
the managed Security Gateways:
a) Reset SIC on each Security Gateway that was managed by the original R7x Domain
Management Server.
For detailed procedure, see sk65764: How to reset SIC
http://supportcontent.checkpoint.com/solutions?id=sk65764.
b) Connect with SmartConsole to the new Domain Management Server.
c) Open the object of each Security Gateway.
d) Establish SIC Trust with of each Security Gateway.
e) Install the Access Control Policy on each Security Gateway.
There can be an issue with the IKE certificates after you migrate the management database, if a
VPN tunnel is established between a Check Point Security Gateway and an externally managed,
third-party gateway.
The VPN Security Gateway presents its IKE certificate to its peer. The third-party gateway uses the
FQDN of the certificate to retrieve the host name and IP address of the Certificate Authority. If the
IKE certificate was issued by a Check Point Internal CA, the FQDN contains the host name of the
original Management Server. The peer gateway will fail to contact the original server and will not
accept the certificate.
To fix:
• Update the external DNS server to resolve the host name to the IP address of the applicable
Domain Management Server.
• Revoke the IKE certificate for the gateway and create a new one.
5 From the left navigation panel, click Multi Domain > Domains.
6 Right-click the Global Domain of the Secondary Multi-Domain Server and click Connect to
Domain.
7 In the top left corner, click Menu > Management High Availability.
8 In the High Availability Status window, in the Connected To section, click Actions > Set
Active.
Workflow:
1. Configure the required policies to allow communication with R80.30 Domain Management
Server
2. Configure the R7x Standalone object
3. Get the R80.30 Management Server Migration Tool
4. Export the entire management database from the R7x Standalone
5. On the R80.30 Multi-Domain Server, create a new Domain Management Server
6. Transfer the exported R7x Standalone management database to the R80.30 Multi-Domain
Server
7. On the R80.30 Multi-Domain Server, import R7x Standalone management database to the new
Domain Management Server
8. Reset SIC, create a new ICA, and establish SIC Trust with managed Security Gateways
9. Configure the VPN keys
10. Configure the Domain Management Server object in SmartConsole
11. Create the new Security Gateway object in SmartConsole
12. Install the R80.30 Security Gateway
13. Configure the new Security Gateway object in SmartConsole
14. Replace the R7x Standalone object in all policies in SmartConsole
Step 1 of 14: Configure the required policies to allow communication with R80.30
Domain Management Server
Step Description
1 Connect with R7x SmartDashboard to the R7x Standalone.
Step Description
2 Create a new Check Point Host object to represent the R80.30 Domain Management
Server and define it as a Secondary Security Management Server.
a) Create the object in one of these ways:
From the top toolbar, click the New ( ) > More > Check Point Host.
In the top left corner, click Objects menu > More object types > Network Object
> Gateways & Servers > New Check Point Host.
In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Check Point Host.
b) In the Name field, enter the desired name.
c) In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses of
the R80.30 Domain Management Server.
d) In the Platform section:
In the Hardware field, select the applicable option
In the Version field, select the highest version.
In the OS field, select Gaia
e) Do not initialize the SIC communication.
f) On the General Properties page, click the Management tab. Make sure the
Secondary Server is selected and greyed out.
g) Click OK.
3 Create the applicable Firewall rules in all applicable policies to allow the new Check Point
Host object (that represents the R80.30 Domain Management Server) to communicate with
all managed Security Gateways.
5 Delete the new Check Point Host object (that represents the R80.30 Domain Management
Server) and the Firewall rules created in Steps 2-4.
2 If the R7x Standalone object participates in a VPN community, remove it from the VPN
community and delete its certificate.
Note these settings, to configure them again after the migration.
3 Remove the R7x Standalone object from the Install On column in all policies.
Step Description
5 Click General Properties page > Network Security tab.
7 Click OK.
9 Do not install the Network Security policy on the R7x Standalone object.
2 Transfer the R80.30 Management Server Migration Tool package to the R7x Standalone to
some directory (for example, /var/log/path_to_Management Server Migration
Tool/).
Note - Make sure to transfer the file in the binary mode.
Step 4 of 14: Export the entire management database from the R7x Standalone
Step Description
1 Connect to the command line on the R7x Standalone.
3 Go to the directory, where you put the R80.30 Management Server Migration Tool package:
[Expert@R7x_SA:0]# cd /var/log/path_to_Management Server Migration
Tool/
Step Description
6 Calculate the MD5 for the exported database file:
[Expert@R7x_SA:0]# md5sum /<Full Path>/<Name of R7x StandAlone Exported
File>.tgz
7 Transfer the exported database from the R7x Standalone to an external storage:
/<Full Path>/<Name of R7x StandAlone Exported File>.tgz
Note - Make sure to transfer the file in the binary mode.
Step 5 of 14: On the R80.30 Multi-Domain Server, create a new Domain Management
Server
Step Description
1 Connect to the command line on the R80.30 Multi-Domain Server.
Step 6 of 14: Transfer the exported R7x Standalone management database to the R80.30
Multi-Domain Server
Step Description
1 Transfer the exported R7x Standalone management database from an external storage to
the R80.30 Multi-Domain Server, to some directory.
Note - Make sure to transfer the file in the binary mode.
Step 7 of 14: On the R80.30 Multi-Domain Server, import R7x Standalone management
database to the new Domain Management Server
Step Description
1 Unset the shell idle environment variable:
[[email protected]_MDS:0]# unset TMOUT
Step 8 of 14: Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Note - This step applies if the new R80.30 Domain Management Server has a different IPv4
address than the R7x Security Management Server.
Step Description
1 Connect to the command on the R80.30 Multi-Domain Server.
3 Stop the new Domain Management Server, into which you migrated the management
database from an R7x Domain Management Server:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
Step Description
7 Start the new Domain Management Server:
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
8 Make sure all the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server are in the state "up" and show their PID:
[[email protected]_MDS:0]# mdsstat
If some of the required daemons on a Domain Management Server are in the state "down"
or "N/A", wait for 5-10 minutes, restart that Domain Management Server and check again.
Run these three commands:
[[email protected]_MDS:0]# mdsstop_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstart_customer <IP Address or Name of Domain
Management Server>
[[email protected]_MDS:0]# mdsstat
9 Establish the Secure Internal Communication (SIC) between the Management Server and
the managed Security Gateways:
a) Reset SIC on each Security Gateway that was managed by the original R7x Security
Management Server.
For detailed procedure, see sk65764: How to reset SIC
http://supportcontent.checkpoint.com/solutions?id=sk65764.
b) Connect with SmartConsole to the new Domain Management Server.
c) Open the object of each Security Gateway.
d) Establish SIC Trust with of each Security Gateway.
e) Install the Access Control Policy on each Security Gateway.
Step Description
1 Connect with SmartConsole to the R80.30 Domain Management Server.
7 Click OK.
Step Description
1 Connect with SmartConsole to the R80.30 Domain Management Server.
3 Create a new Security Gateway object (that represents the Gateway component of the R7x
Standalone) in one of these ways:
Step Description
5 In the Name field, enter the desired name for this Security Gateway object.
6 In the IPv4 address (and IPv6 address) field, enter some dummy IP address.
You change this IP address later to the real IP address.
10 Click OK.
Step Description
1 Install the Gaia Operating System:
• Installing the Gaia Operating System on a Check Point Appliance (on page 18)
• Installing the Gaia Operating System on an Open Server (on page 20)
2 Run the Gaia First Time Configuration Wizard (on page 25).
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select the No.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
Step Description
1 Connect with SmartConsole to the new R80.30 Domain Management Server.
3 Open the Security Gateway object that represents the Gateway component of the R7x
Standalone.
4 In the IPv4 address and IPv6 address fields, configure the same IPv4 and IPv6 addresses
that you configured on the Management Connection page of the Security Gateway's First
Time Configuration Wizard. Make sure the Security Management Server or Multi-Domain
Server can connect to these IP addresses.
5 Establish the Secure Internal Communication (SIC) between the Management Server and
this Security Gateway:
a) Near the Secure Internal Communication field, click Communication.
b) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
c) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
d) Click Initialize.
e) Click OK.
Step Description
If the Certificate state field does not show Established, perform these steps:
a) Connect to the command line on the Security Gateway.
b) Make sure there is a physical connectivity between the Security Gateway and the
Multi-Domain Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
6 Click OK.
Step 14 of 14: Replace the R7x Standalone object in all policies in SmartConsole
You must create a new Security Gateway object to represent the Gateway component of the R7x
Standalone.
This new Security Gateway object represents the separate Security Gateway.
Step Description
1 Connect with SmartConsole to the new R80.30 Domain Management Server.
3 In all existing policies, replace the R7x Standalone object with the new Security Gateway
object that represents the Gateway component of the R7x Standalone.
Workflow:
1. Back up the current R80.30 Multi-Domain Server
2. Connect to the command line on the Multi-Domain Server
3. Log in to the Expert mode
4. Stop the Multi-Domain Server
5. Modify the $MDSDIR/conf/LeadingIP file
6. Modify the $MDSDIR/conf/mdsdb/mdss.C file
7. Install a new license on the target Multi-Domain Server issued for the new Multi-Domain
Server IP address
8. Modify the $MDSDIR/conf/external.if file
9. Start the Multi-Domain Server
Step Description
2 Edit the current file:
[Expert@MDS:0]# vi $MDSDIR/conf/LeadingIP
Step Description
1 Back up the current file:
[Expert@MDS:0]# cp -v $MDSDIR/conf/mdsdb/mdss.C{,_BKP}
3 Find the object of your Multi-Domain Server or Multi-Domain Log Server that has the
current IP address.
Step 7 of 9: Install a new license on the target Multi-Domain Server issued for the new
Multi-Domain Server IP address
Step Description
1 Connect to your User Center https://usercenter.checkpoint.com account.
2 Issue a new license for your Multi-Domain Server or Multi-Domain Log Server for the new
Multi-Domain Server IP address.
4 Install the new license and Support Contract (on page 613) on your Multi-Domain Server or
Multi-Domain Log Server.
Step Description
1 Back up the current $MDSDIR/conf/external.if file:
[Expert@MDS:0]# cp -v $MDSDIR/conf/external.if{,_BKP}
3 Change the current interface name to the name of the applicable main interface.
This is the interface, on which you configured the main IPv4 address of your Multi-Domain
Server or Multi-Domain Log Server.
8 Change the current interface name to the name of the applicable main interface.
This is the interface, on which you configured the main IPv4 address of your Multi-Domain
Server or Multi-Domain Log Server.
If you cannot divide the existing network into several networks with different IP addresses, you can
install a Check Point Security Gateway (or a ClusterXL) in the Bridge Mode. A Security Gateway (or
ClusterXL) in Bridge Mode is invisible to Layer 3 traffic. When traffic arrives at one of the bridge
slave interfaces, the Security Gateway (or Cluster Members) inspects it and passes it to the
second bridge slave interface.
IPsec VPN No No No
Mobile Access No No No
Notes:
1. Does not support the Anti-Virus in Traditional Mode.
Item Description
1 Network, which an administrator needs to divide into two Layer 2 segments.
The Security Gateway in Bridge Mode connects between these segments.
3 Switch that connects the first network segment to one bridged slave interface (4) on the
Security Gateway in Bridge Mode.
4 One bridged slave interface (for example, eth1) on the Security Gateway in Bridge Mode.
6 Another bridged slave interface (for example, eth2) on the Security Gateway in Bridge
Mode.
7 Dedicated Gaia Management Interface (for example, eth0) on the Security Gateway.
8 Switch that connects the second network segment to the other bridged slave interface (6)
on the Security Gateway in Bridge Mode.
Workflow:
1. Install the Security Gateway.
2. Configure the Bridge interface - in Gaia Portal, or Gaia Clish.
3. Configure the Security Gateway in SmartConsole - in Wizard Mode, or Classic Mode.
4. Configure the applicable policy for the Security Gateway in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Management Connection window, select the interface, through which you
connect to Gaia operating system.
• In the Internet Connection window, do not configure IP addresses.
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select No.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 In the left navigation tree, click Network Management > Network Interfaces.
3 Make sure that the interfaces, which you wish to add as slaves of the Bridge interface, do
not have IP addresses assigned to them.
5 On the Bridge tab, enter or select a Bridge Group ID (unique integer between 1 and 1024).
6 Select the interfaces from the Available Interfaces list and then click Add.
Notes:
• A Bridge interface in Gaia can contain only two slave interfaces.
• Do not select the interface that you configured as Gaia Management Interface.
7 On the IPv4 tab, enter the IPv4 address and subnet mask.
8 On the IPv6 tab (optional), enter the IPv6 address and mask length.
Important - First, you must enable the IPv6 Support in Gaia and reboot.
Step Description
9 Click OK.
3 Make sure that the interfaces, which you wish to add as slaves of the Bridge interface, do
not have IP addresses assigned to them. Run:
show interface <Name of Interface> ipv4-address
show interface <Name of Interface> ipv6-address
Step Description
3 Create a new Security Gateway object in one of these ways:
Step Description
8 If during the Wizard Mode, you selected Skip and initiate trusted communication later:
a) The Secure Internal Communication field shows Uninitialized.
b) Click Communication.
c) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
d) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
e) Click Initialize.
Make sure the Certificate state field shows Established.
f) Click OK.
9 On the Network Security tab, enable the additional desired Software Blades.
Important:
• See the Supported Software Blades in Bridge Mode (on page 531) and Limitations in
Bridge Mode (on page 533).
• Do not select anything on the Management tab.
10 On the Network Management page, configure the Topology of the Bridge interface.
Notes:
• If a Bridge interface connects to the Internet, set the Topology to External.
• If you use this Bridge Security Gateway object in Access Control Policy rules with
Internet objects, set the Topology to External.
11 Click OK.
Step Description
4 In the Check Point Security Gateway Creation window, click Classic Mode.
Check Point Gateway properties window opens on the General Properties page.
5 In the Name field, enter the desired name for this Security Gateway object.
6 In the IPv4 address and IPv6 address fields, configure the same IPv4 and IPv6 addresses
that you configured on the Management Connection page of the Security Gateway's First
Time Configuration Wizard. Make sure the Security Management Server or Multi-Domain
Server can connect to these IP addresses.
7 Establish the Secure Internal Communication (SIC) between the Management Server and
this Security Gateway:
a) Near the Secure Internal Communication field, click Communication.
b) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
c) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
d) Click Initialize.
e) Click OK.
If the Certificate state field does not show Established, perform these steps:
a) Connect to the command line on the Security Gateway.
b) Make sure there is a physical connectivity between the Security Gateway and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
9 On the Network Security tab, enable the additional desired Software Blades.
Important:
• See the Supported Software Blades in Bridge Mode (on page 531) and Limitations in
Bridge Mode (on page 533).
• Do not select anything on the Management tab.
10 On the Network Management page, configure the Topology of the Bridge interface.
Notes:
• If a Bridge interface connects to the Internet, set the Topology to External.
• If you configure this Bridge Security Gateway object is in Access Control Policy rules
with Internet objects, set the Topology to External.
11 Click OK.
Step 4 of 4: Configure the applicable policy for the Security Gateway in SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
Item Description
1 Network, which an administrator needs to divide into two Layer 2 segments.
The ClusterXL in Bridge Mode connects between these segments.
3 Switch that connects the first network segment to one bridged slave interface (4) on the
ClusterXL in Bridge Mode.
4 One bridged slave interface (for example, eth1) on the Cluster Members in Bridge Mode.
5 Dedicated Gaia Management Interface (for example, eth0) on the Cluster Members.
6 First Cluster Member in Bridge Mode (for example, in the Active cluster state).
Item Description
7 Network that connects dedicated synchronization interfaces (for example, eth3) on the
ClusterXL in Bridge Mode.
8 Second Cluster Member in Bridge Mode (for example, in the Standby cluster state).
9 Another bridged slave interface (for example, eth2) on the Cluster Members in Bridge
Mode.
10 Switch that connects the second network segment to the other bridged slave interface (9)
on the ClusterXL in Bridge Mode.
Workflow:
1. Install the two Cluster Members.
2. Configure the ClusterXL in High Availability mode in SmartConsole - in Wizard Mode, or
Classic Mode.
3. Configure the applicable policy for the ClusterXL Cluster in SmartConsole.
4. Enable the Bridge Active/Standby mode on both Cluster Members.
Best practice - If you configure Bridge Active/Standby mode, disable STP, RSTP, and MSTP on the
adjacent switches. See the applicable documentation for your switches.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, select these two options:
Unit is a part of a cluster
ClusterXL
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
6 On the Cluster members' properties page, add the objects for the Cluster Members.
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this Cluster Member object.
c) Configure the main physical IP address(es) for this Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
d) In the Activation Key and Confirm Activation Key fields, enter the same Activation
Key you entered during the Cluster Member's First Time Configuration Wizard.
e) Click Initialize.
f) Click OK.
g) Repeat Steps a-f to add the second Cluster Member, and so on.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
7 On the Cluster Topology pages, configure the roles of the cluster interfaces:
a) Examine the IPv4 Network Address at the top of the page.
b) Select the applicable role:
For cluster traffic interfaces, select Representing a cluster interface and
configure the Cluster Virtual IPv4 address and its Net Mask.
For cluster synchronization interfaces, select Cluster Synchronization and
select Primary only. Check Point cluster supports only one synchronization
network.
For interfaces that do not pass the traffic between the connected networks,
select Private use of each member (don't monitor members interfaces).
c) Click Next.
Step Description
10 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
14 On the Network Management page:
a) Select each interface and click Edit. The Network: <Name of Interface> window
opens.
b) From the left navigation tree, click the General page.
c) In the General section, in the Network Type field, select the applicable type:
For cluster traffic interfaces, select Cluster. Make sure the Cluster Virtual IPv4
address and its Net Mask are correct.
For cluster synchronization interfaces, select Sync or Cluster+Sync (we do not
recommend this configuration). Check Point cluster supports only one
synchronization network.
For interfaces that do not pass the traffic between the connected networks,
select Private.
d) In the Member IPs section, make sure the IPv4 address and its Net Mask are
correct on each Cluster Member.
Note - For cluster traffic interfaces, you can configure the Cluster Virtual IP
address to be on a different network than the physical IP addresses of the Cluster
Members. In this case, you must configure the required static routes on the Cluster
Members.
e) In the Topology section:
Make sure the settings are correct in the Leads To and Security Zone fields.
Make sure to enable the Anti-Spoofing.
Important:
• Make sure the Bridge interface and Bridge slave interfaces are not in the Topology.
• You cannot define the Topology of the Bridge interface. It is External by default.
15 Click OK.
Step Description
3 Create a new Cluster object in one of these ways:
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Creation window, click Classic Mode.
The Gateway Cluster Properties window opens.
6 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
8 On the Cluster Members page:
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this Cluster Member object.
c) Configure the main physical IP address(es) for this Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
d) Click Communication.
e) In the One-time password and Confirm one-time password fields, enter the same
Activation Key you entered during the Cluster Member's First Time Configuration
Wizard.
f) Click Initialize.
g) Click Close.
h) Click OK.
i) Repeat Steps a-h to add the second Cluster Member, and so on.
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
9 On the ClusterXL and VRRP page:
a) In the Select the cluster mode and configuration section, select High Availability
and ClusterXL.
b) In the Tracking section, select the desired option.
c) In the Advanced Settings section:
Optional: Select Use State Synchronization. We recommend to select this
option.
Optional: Select Use Virtual MAC (for more information, see sk50840
http://supportcontent.checkpoint.com/solutions?id=sk50840).
Select the High Availability recovery - Maintain current active Cluster Member,
or Switch to higher priority Cluster Member.
2 Run: cpconfig
4 Enter y to confirm.
Item Description
8 Examine the cluster configuration on each Cluster Member.
• In Gaia Clish, run:
show cluster state
• In Expert mode, run:
cphaprob state
Example output:
Cluster Mode: High Availability (Active Up, Bridge Mode) with IGMP Membership
Number Unique Address Firewall State (*)
1 (local) 2.2.2.3 Active
2 2.2.2.2 Standby
Item Description
1 Network, which an administrator needs to divide into two Layer 2 segments.
The ClusterXL in Bridge Mode connects between these segments.
3 Switch that connects the first network segment to one bridged slave interface (4) on the
ClusterXL in Bridge Mode.
4 One bridged slave interface (for example, eth1) on the Cluster Members in Bridge Mode.
5 Dedicated Gaia Management Interface (for example, eth0) on the Cluster Members.
6 First Cluster Member in Bridge Mode (in the Active cluster state).
7 Network that connects dedicated synchronization interfaces (for example, eth3) on the
ClusterXL in Bridge Mode.
Item Description
8 Second Cluster Member in Bridge Mode (in the Active cluster state).
9 Another bridged slave interface (for example, eth2) on the Cluster Members in Bridge
Mode.
10 Switch that connects the second network segment to the other bridged slave interface (9)
on the ClusterXL in Bridge Mode.
Workflow:
1. Install the two Cluster Members.
2. Configure the Bridge interface on both Cluster Members - in Gaia Portal, or Gaia Clish.
3. Configure the ClusterXL in High Availability mode in SmartConsole - in Wizard Mode, or
Classic Mode.
4. Configure the applicable policy for the ClusterXL Cluster in SmartConsole.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, select these two options:
Unit is a part of a cluster
ClusterXL
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 In the left navigation tree, click Network Management > Network Interfaces.
Step Description
3 Make sure that the slave interfaces, which you wish to add to the Bridge interface, do not
have IP addresses.
5 On the Bridge tab, enter or select a Bridge Group ID (unique integer between 1 and 1024).
6 Select the interfaces from the Available Interfaces list and then click Add.
Notes:
• A Bridge interface in Gaia can contain only two slave interfaces.
• Do not select the interface that you configured as Gaia Management Interface.
7 On the IPv4 tab, do not enter the IPv4 address.
9 Click OK.
3 Make sure that the slave interfaces, which you wish to add to the Bridge interface, do not
have IP addresses. Run:
show interface <Name of Interface> ipv4-address
show interface <Name of Interface> ipv6-address
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
6 On the Cluster members' properties page, add the objects for the Cluster Members.
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this Cluster Member object.
c) Configure the main physical IP address(es) for this Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
d) In the Activation Key and Confirm Activation Key fields, enter the same Activation
Key you entered during the Cluster Member's First Time Configuration Wizard.
e) Click Initialize.
f) Click OK.
g) Repeat Steps a-f to add the second Cluster Member, and so on.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
7 On the Cluster Topology page, configure the roles of the cluster interfaces:
a) Examine the IPv4 Network Address at the top of the page.
b) Select the applicable role:
For cluster traffic interfaces, select Representing a cluster interface and
configure the Cluster Virtual IPv4 address and its Net Mask.
For cluster synchronization interfaces, select Cluster Synchronization and
select Primary only. Check Point cluster supports only one synchronization
network.
For interfaces that do not pass the traffic between the connected networks,
select Private use of each member (don't monitor members interfaces).
c) Click Next.
Step Description
10 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
14 On the Network Management page:
a) Select each interface and click Edit. The Network: <Name of Interface> window
opens.
b) From the left navigation tree, click the General page.
c) In the General section, in the Network Type field, select the applicable type:
For cluster traffic interfaces, select Cluster. Make sure the Cluster Virtual IPv4
address and its Net Mask are correct.
For cluster synchronization interfaces, select Sync or Cluster+Sync (we do not
recommend this configuration). Check Point cluster supports only one
synchronization network.
For interfaces that do not pass the traffic between the connected networks,
select Private.
d) In the Member IPs section, make sure the IPv4 address and its Net Mask are
correct on each Cluster Member.
Note - For cluster traffic interfaces, you can configure the Cluster Virtual IP
address to be on a different network than the physical IP addresses of the Cluster
Members. In this case, you must configure the required static routes on the Cluster
Members.
e) In the Topology section:
Make sure the settings are correct in the Leads To and Security Zone fields.
Make sure to enable the Anti-Spoofing.
Important:
• Make sure the Bridge interface and Bridge slave interfaces are not in the Topology.
• You cannot define the Topology of the Bridge interface. It is External by default.
15 Click OK.
Step Description
3 Create a new Cluster object in one of these ways:
• From the top toolbar, click the New ( ) > Cluster > Cluster.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > Cluster > New Cluster.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > Cluster > Cluster.
4 In the Check Point Security Gateway Creation window, click Classic Mode.
The Gateway Cluster Properties window opens.
6 On the General Properties page > Platform section, select the correct options:
a) In the Hardware field:
If you install the Cluster Members on Check Point Appliances, select the correct
appliances series.
If you install the Cluster Members on Open Servers, select Open server.
b) In the Version field, select R80.30.
c) In the OS field, select Gaia.
Step Description
8 On the Cluster Members page:
a) Click Add > New Cluster Member.
The Cluster Member Properties window opens.
b) In the Name field, enter the desired name for this Cluster Member object.
c) Configure the main physical IP address(es) for this Cluster Member object.
In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6
addresses that you configured on the Management Connection page of the Cluster
Member's First Time Configuration Wizard. Make sure the Security Management
Server or Multi-Domain Server can connect to these IP addresses.
d) Click Communication.
e) In the One-time password and Confirm one-time password fields, enter the same
Activation Key you entered during the Cluster Member's First Time Configuration
Wizard.
f) Click Initialize.
g) Click Close.
h) Click OK.
i) Repeat Steps a-h to add the second Cluster Member, and so on.
If the Trust State field does not show Established, perform these steps:
a) Connect to the command line on the Cluster Member.
b) Make sure there is a physical connectivity between the Cluster Member and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
Step Description
9 On the ClusterXL and VRRP page:
a) In the Select the cluster mode and configuration section, select High Availability
and ClusterXL.
b) In the Tracking section, select the desired option.
c) In the Advanced Settings section:
Optional: Select Use State Synchronization. We recommend to select this
option.
Optional: Select Use Virtual MAC (for more information, see sk50840
http://supportcontent.checkpoint.com/solutions?id=sk50840).
Select the High Availability recovery - Maintain current active Cluster Member,
or Switch to higher priority Cluster Member.
Item Description
1 Network, which an administrator needs to divide into two Layer 2 segments.
The ClusterXL in Bridge Mode connects between these segments.
3 Switch that connects the first network segment to one bridged slave interface (6) on the
ClusterXL in Bridge Mode.
4 Switch that connects between one switch (that directly connects to the first network
segment) and one bridged slave interface (6) on the ClusterXL in Bridge Mode.
5 Dedicated Gaia Management Interface (for example, eth0) on the Cluster Members.
Item Description
6 One bridged slave interface (for example, eth1) on the Cluster Members in Bridge Mode.
7 First Cluster Member in Bridge Mode (in the Active cluster state).
8 Network that connects dedicated synchronization interfaces (for example, eth3) on the
ClusterXL in Bridge Mode.
9 Second Cluster Member in Bridge Mode (in the Active cluster state).
10 Another bridged slave interface (for example, eth2) on the Cluster Members in Bridge
Mode.
11 Switch that connects the second network segment to the other bridged slave interface (10)
on the ClusterXL in Bridge Mode.
12 Switch that connects between one switch (that directly connects to the second network
segment) and the other bridged slave interface (10) on the ClusterXL in Bridge Mode.
Workflow:
1. Install the two Cluster Members.
2. Configure the Bridge interface on both Cluster Members - in Gaia Portal, or Gaia Clish.
3. Configure the ClusterXL in High Availability mode in SmartConsole - in Wizard Mode, or
Classic Mode.
4. Configure the applicable policy for the ClusterXL Cluster in SmartConsole.
The workflow and detailed instructions are the same as in the Configuring ClusterXL in Bridge
Mode - Active/Active with Two Switches (on page 555).
Item Description
1 Security Management Server
2 Router
3 Bridge interface on the Security Gateway
4 Security Gateway
5 Regular traffic interface on the Security Gateway
6 Regular traffic interface on the Security Gateway
Packet flow:
1. The Security Management Server sends a management packet to the Management Interface
on the Security Gateway. This Management Interface is configured as Bridge interface.
2. The Security Gateway inspects the first management packet it receives on the first slave of the
Bridge interface.
3. The Security Gateway forwards the inspected management packet to the router through the
second slave of the Bridge interface.
4. The router sends the packet to the first slave of the Bridge interface.
5. The Security Gateway concludes that this packet is a retransmission and drops it.
Procedure:
Step Description
1 Connect to the command line on the Security Gateway.
You can configure the Link State Propagation in one of these modes:
Important:
• In a cluster environment, you must configure all the Cluster Members in the same way.
• Link State Propagation does not support Bond interfaces.
Step Description
6 Save the changes in the file and exit the Vi editor.
8 Make sure the Security Gateway or Cluster Members loaded the new configuration:
# fw ctl get int fw_link_state_propagation_enabled
8 Make sure the Security Gateway or Cluster Members loaded the new configuration:
# fw ctl get int fw_link_state_propagation_enabled
# fw ctl get int fw_manual_link_state_propagation_enabled
# fw ctl get str fw_lsp_pair1
# fw ctl get str fw_lsp_pair2
# fw ctl get str fw_lsp_pair3
# fw ctl get str fw_lsp_pair4
You can configure Monitor Mode on a Check Point Security Gateway interface. This lets the Check
Point Security Gateway listen to traffic from a Mirror Port or Span Port on a connected switch. Use
the Monitor Mode to analyze network traffic without changing the production environment. The
mirror port on a switch duplicates the network traffic and sends it to the Security Gateway with an
interface in Monitor Mode to record the activity logs.
You can use the Monitor Mode:
• To monitor the use of applications as a permanent part of your deployment
• To evaluate the capabilities of the Software Blades:
• The Security Gateway neither enforces any security policy, nor performs any active
operations (prevent/drop/reject) on the interface in the Monitor Mode.
• The Security Gateway terminates and does not forward all packets that arrive at the
interface in the Monitor Mode.
• The Security Gateway does not send any traffic through the interface in the Monitor Mode.
Benefits of the Monitor Mode include:
• There is no risk to your production environment.
• It requires minimal set-up configuration.
• It does not require TAP equipment, which is expensive.
Item Description
1 Switch with a mirror or SPAN port that duplicates all incoming and outgoing packets.
The Security Gateway connects to a mirror or SPAN port on the switch.
2 Servers.
3 Clients.
4 Security Gateway with an interface in Monitor Mode.
5 Security Management Server that manages the Security Gateway.
For more information, see sk101670: Monitor Mode on Gaia OS and SecurePlatform OS
http://supportcontent.checkpoint.com/solutions?id=sk101670.
Workflow:
Note - This procedure applies to both Check Point Appliances and Open Servers.
1. Install the Security Gateway.
2. Configure the Monitor Mode interface - in Gaia Portal, or Gaia Clish.
3. Configure the Security Gateway in SmartConsole - in Wizard Mode, or Classic Mode.
4. Configure the Security Gateway to process packets that arrive in the wrong order.
5. Configure the required Global Properties for the Security Gateway in SmartConsole
6. Configure the required Access Control policy for the Security Gateway in SmartConsole.
7. Make sure the Security Gateway enabled the Monitor Mode for Software Blades.
8. Connect the Security Gateway to the switch.
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Management Connection window, select the interface, through which you
connect to Gaia operating system.
• In the Internet Connection window, do not configure IP addresses.
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select No.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 In the left navigation tree, click Network Management > Network Interfaces.
3 Select the applicable physical interface from the list and click Edit.
5 In the Comment field, enter the applicable comment text (up to 100 characters).
6 On the IPv4 tab, select Use the following IPv4 address, but do not enter an IPv4 address.
7 On the IPv6 tab, select Use the following IPv6 address, but do not enter an IPv6 address.
Important - This setting is available only after you enable the IPv6 Support in Gaia and
reboot.
4 If the applicable physical interface has an IP address assigned to it, remove it:
delete interface <Name of Physical Interface> ipv4-address
delete interface <Name of Physical Interface> ipv6-address
Step Description
5 Enable the Monitor Mode on the physical interface:
set interface <Name of Physical Interface> monitor-mode on
Step Description
6 On the Trusted Communication page:
a) Select the applicable option:
If you selected Initiate trusted communication now, enter the same Activation
Key you entered during the Security Gateway's First Time Configuration Wizard.
If you selected Skip and initiate trusted communication later, make sure to
follow Step 7.
b) Click Next.
8 If during the Wizard Mode, you selected Skip and initiate trusted communication later:
a) The Secure Internal Communication field shows Uninitialized.
b) Click Communication.
c) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
d) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
e) Click Initialize.
Make sure the Certificate state field shows Established.
f) Click OK.
9 On the Network Security tab, make sure to enable only the Firewall Software Blade.
Important - Do not select anything on the Management tab.
Step Description
10B Select the Monitor Mode interface and click Edit.
Configure these settings:
a) Click the General page.
b) In the General section, enter a random IPv4 address.
Important - This random IPv4 address must not conflict with existing IPv4
addresses on your network.
c) In the Topology section:
Click Modify.
In the Leads To section, select Not defined (Internal).
In the Security Zone section, select According to topology: Internal Zone.
Click OK to close the Topology Settings window.
d) Click OK to close the Interface window.
11 Click OK.
13 This Security Gateway object is now ready to receive the Security Policy.
5 In the Name field, enter the desired name for this Security Gateway object.
6 In the IPv4 address and IPv6 address fields, configure the same IPv4 and IPv6 addresses
that you configured on the Management Connection page of the Security Gateway's First
Time Configuration Wizard. Make sure the Security Management Server or Multi-Domain
Server can connect to these IP addresses.
Step Description
7 Establish the Secure Internal Communication (SIC) between the Management Server and
this Security Gateway:
a) Near the Secure Internal Communication field, click Communication.
b) In the Platform field:
Select Open server / Appliance for all Check Point appliances models except
1100, 1200R, and 1400.
Select Open server / Appliance for an Open Server.
c) Enter the same Activation Key you entered during the Security Gateway's First
Time Configuration Wizard.
d) Click Initialize.
e) Click OK.
If the Certificate state field does not show Established, perform these steps:
a) Connect to the command line on the Security Gateway.
b) Make sure there is a physical connectivity between the Security Gateway and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) In the SmartConsole, click Reset.
g) Enter the same Activation Key you entered in the cpconfig menu.
h) Click Initialize.
9 On the Network Security tab, make sure to enable only the Firewall Software Blade.
Important - Do not select anything on the Management tab.
Step Description
10B Select the Monitor Mode interface and click Edit.
Configure these settings:
a) Click the General page.
b) In the General section, enter a random IPv4 address.
Important - This random IPv4 address must not conflict with existing IPv4
addresses on your network.
c) In the Topology section:
Click Modify.
In the Leads To section, select Not defined (Internal).
In the Security Zone section, select According to topology: Internal Zone.
Click OK to close the Topology Settings window.
d) Click OK to close the Interface window.
11 Click OK.
Step 4 of 8: Configure the Security Gateway to process packets that arrive in the wrong
order
Step Description
1 Connect to the command line on the Security Gateway.
3C Add this line to enable the Passive Streaming Layer (PSL) Tap Mode:
psl_tap_enable=1
Step Description
4 Modify the $PPKDIR/conf/simkern.conf file.
Notes:
• This configuration helps the Security Gateway process packets that arrive in the wrong or
abnormal order (for example, TCP [SYN-ACK] arrives before TCP [SYN]).
• This configuration helps the Security Gateway work better for the first 10-30 minutes when it
processes connections, in which the TCP [SYN] packets did not arrive.
• This configuration is also required when you use a TAP device or Mirror / Span ports with
separated TX/RX queues.
• This configuration will make the Mirror Port on Security Gateway work better for the first
10-30 minutes when processing connections, in which the TCP "SYN" packet did not arrive.
• It is not possible to set the value of the kernel parameters psl_tap_enable and
fw_tap_enable on-the-fly with the fw ctl set int <parameter> command (Issue ID
02386641).
Step 5 of 8: Configure the required Global Properties for the Security Gateway in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
Step Description
3B In the Default Session Timeouts section:
1. Change the value of the TCP session timeout from the default 3600 to 60 seconds.
2. Change the value of the TCP end timeout from the default 20 to 5 seconds.
3C In the Out of state packets section, you must clear all the boxes.
Otherwise, the Security Gateway drops the traffic as out of state (because the traffic does
not pass through the Security Gateway, it does not record the state information for the
traffic).
4C Clear reject_x11_in_any.
Step 6 of 8: Configure the required Access Control policy for the Security Gateway in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
Step Description
4 Create the Access Control rule that accepts all traffic:
• Source - *Any
• Destination - *Any
• VPN - *Any
• Services & Applications - *Any
• Action - Accept
• Install On - Object of Security Gateway in Monitor Mode
5 We recommend these Aggressive Aging settings for the most common TCP connections:
a) In the SmartConsole, click Objects menu > Object Explorer.
b) Open Services and select TCP.
c) Search for the most common TCP connections in this network.
d) Double-click the applicable TCP service.
e) From the left tree, click Advanced.
f) At the top, select Override default settings (on Domain Management Server, select
Override global domain settings).
g) Select Match for 'Any'.
h) In the Aggressive aging section:
Select Enable aggressive aging.
Select Specific and enter 60.
i) Click OK.
j) Close the Object Explorer.
Step 7 of 8: Make sure the Security Gateway enabled the Monitor Mode for Software
Blades
Step Description
1 Connect to the command line on the Security Gateway.
Workflow:
Note - This procedure applies to both Check Point Appliances and Open Servers.
1. Install the VSX Gateway.
2. Configure the Monitor Mode interface - in Gaia Portal, or Gaia Clish.
3. Configure the VSX Gateway to process packets that arrive in the wrong order.
4. Configure the VSX Gateway object in SmartConsole.
5. Configure the Virtual System (and other Virtual Devices) in SmartConsole.
6. Configure the required Global Properties for the Virtual System in SmartConsole.
7. Configure the required Access Control policy for the Virtual System in SmartConsole.
8. Make sure the VSX Gateway enabled the Monitor Mode for Software Blades.
9. Connect the VSX Gateway to the switch.
Step Description
1 Install the Gaia Operating System:
• Installing the Gaia Operating System on a Check Point Appliance (on page 18)
• Installing the Gaia Operating System on an Open Server (on page 20)
2 Run the Gaia First Time Configuration Wizard (on page 25).
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
• In the Management Connection window, select the interface, through which you
connect to Gaia operating system.
• In the Internet Connection window, do not configure IP addresses.
• In the Installation Type window, select Security Gateway and/or Security
Management.
• In the Products window:
a) In the Products section, select Security Gateway only.
b) In the Clustering section, clear Unit is a part of a cluster, type.
• In the Dynamically Assigned IP window, select No.
• In the Secure Internal Communication window, enter the desired Activation Key
(between 4 and 127 characters long).
2 In the left navigation tree, click Network Management > Network Interfaces.
3 Select the applicable physical interface from the list and click Edit.
5 In the Comment field, enter the applicable comment text (up to 100 characters).
6 On the IPv4 tab, select Use the following IPv4 address, but do not enter an IPv4 address.
7 On the IPv6 tab, select Use the following IPv6 address, but do not enter an IPv6 address.
Important - This setting is available only after you enable the IPv6 Support in Gaia and
reboot.
4 If the applicable physical interface has an IP address assigned to it, remove it:
delete interface <Name of Physical Interface> ipv4-address
delete interface <Name of Physical Interface> ipv6-address
Step 3 of 9: Configure the VSX Gateway to process packets that arrive in the wrong
order
Step Description
1 Connect to the command line on the Security Gateway.
Step Description
3B Edit the current $FWDIR/boot/modules/fwkern.conf file:
vi $FWDIR/boot/modules/fwkern.conf
Important - This configuration file does not support spaces or comments.
3C Add this line to enable the Passive Streaming Layer (PSL) Tap Mode:
psl_tap_enable=1
Notes:
• This configuration helps the VSX Gateway process packets that arrive in the wrong or
abnormal order (for example, TCP [SYN-ACK] arrives before TCP [SYN]).
• This configuration helps the VSX Gateway work better for the first 10-30 minutes when it
processes connections, in which the TCP [SYN] packets did not arrive.
• This configuration is also required when you use a TAP device or Mirror / Span ports with
separated TX/RX queues.
• This configuration will make the Mirror Port on Security Gateway work better for the first
10-30 minutes when processing connections, in which the TCP "SYN" packet did not arrive.
• It is not possible to set the value of the kernel parameters psl_tap_enable and
fw_tap_enable on-the-fly with the fw ctl set int <parameter> command (Issue ID
02386641).
• From the top toolbar, click the New ( ) > VSX > Gateway.
• In the top left corner, click Objects menu > More object types > Network Object >
Gateways and Servers > VSX > New Gateway.
• In the top right corner, click Objects Pane > New > More > Network Object > Gateways
and Servers > VSX > Gateway.
The VSX Gateway Wizard opens.
4 On the VSX Gateway General Properties (Specify the object's basic settings) page:
a) In the Enter the VSX Gateway Name field, enter the desired name for this VSX
Gateway object.
b) In the Enter the VSX Gateway IPv4 field, enter the same IPv4 address that you
configured on the Management Connection page of the VSX Gateway's First Time
Configuration Wizard.
c) In the Enter the VSX Gateway IPv6 field, enter the same IPv6 address that you
configured on the Management Connection page of the VSX Gateway's First Time
Configuration Wizard.
d) In the Select the VSX Gateway Version field, select R80.30.
e) Click Next.
5 On the Virtual Systems Creation Templates (Select the Creation Template most suitable
for your VSX deployment) page:
a) Select the applicable template.
b) Click Next.
Step Description
6B If the Trust State field does not show Trust established, perform these steps:
a) Connect to the command line on the VSX Gateway.
b) Make sure there is a physical connectivity between the VSX Gateway and the
Management Server (for example, pings can pass).
c) Run: cpconfig
d) Enter the number of this option: Secure Internal Communication.
e) Follow the instructions on the screen to change the Activation Key.
f) On the VSX Gateway General Properties page, click Reset.
g) Click Initialize.
8 On the Virtual Network Device Configuration (Specify the object's basic settings) page:
a) You can select Create a Virtual Network Device and configure the first desired
Virtual Network Device at this time (we recommend to do this later) - Virtual Switch
or Virtual Router.
b) Click Next.
9 On the VSX Gateway Management (Specify the management access rules) page:
a) Examine the default access rules.
b) Select the applicable default access rules.
c) Configure the applicable source objects, if needed.
d) Click Next.
Important - These access rules apply only to the VSX Gateway (context of VS0), which is
not intended to pass any "production" traffic.
Step Description
11 Examine the VSX configuration:
a) Connect to the command line on the VSX Gateway.
b) Log in to the Expert mode.
c) Run: vsx stat -v
Step 5 of 9: Configure the Virtual System (and other Virtual Devices) in SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server, or each Target Domain
Management Server that should manage each Virtual Device.
2 Configure the desired Virtual System (and other Virtual Devices) on this VSX Gateway.
When you configure this Virtual System, for the Monitor Mode interface, add a regular
interface. In the IPv4 Configuration section, enter a random IPv4 address.
Important - This random IPv4 address must not conflict with existing IPv4 addresses on
your network.
Step Description
4 Disable the Anti-Spoofing on the Monitor Mode interface:
a) In the SmartConsole, open the Virtual System object.
b) Click the Topology page.
c) Select the Monitor Mode interface and click Edit.
The Interface Properties window opens.
d) Click the General tab.
e) In the Security Zone field, select None.
f) Click the Topology tab.
g) In the Topology section, make sure the settings are Internal (leads to the local
network) and Not Defined.
h) In the Anti-Spoofing section, clear Perform Anti-Spoofing based on interface
topology.
i) Click OK to close the Interface Properties window.
j) Click OK to close the Virtual System Properties window.
k) The Management Server pushes the VSX Configuration.
Step 6 of 9: Configure the required Global Properties for the Virtual System in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Target Domain
Management Server that manages this Virtual System.
3C In the Out of state packets section, you must clear all the boxes.
Otherwise, the Virtual System drops the traffic as out of state (because the traffic does not
pass through the Virtual System, it does not record the state information for the traffic).
4C Clear reject_x11_in_any.
Step Description
5 Click OK to close the Global Properties window.
Step 7 of 9: Configure the required Access Control policy for the Virtual System in
SmartConsole
Step Description
1 Connect with SmartConsole to the Security Management Server or Target Domain
Management Server that manages this Virtual System.
Step Description
5 We recommend these Aggressive Aging settings for the most common TCP connections:
a) In the SmartConsole, click Objects menu > Object Explorer.
b) Open Services and select TCP.
c) Search for the most common TCP connections in this network.
d) Double-click the applicable TCP service.
e) From the left tree, click Advanced.
f) At the top, select Override default settings (on Domain Management Server, select
Override global domain settings).
g) Select Match for 'Any'.
h) In the Aggressive aging section:
Select Enable aggressive aging.
Select Specific and enter 60.
i) Click OK.
j) Close the Object Explorer.
Step 8 of 9: Make sure the VSX Gateway enabled the Monitor Mode for Software Blades
Step Description
1 Connect to the command line on the VSX Gateway.
This section shows how to configure specific Software Blades for Monitor Mode.
Note - For VSX, see:
• sk79700: VSX supported features on R75.40VS and above
http://supportcontent.checkpoint.com/solutions?id=sk79700
• sk106496: Software Blades updates on VSX R75.40VS and above - FAQ
http://supportcontent.checkpoint.com/solutions?id=sk106496
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
2 From the left navigation panel, click Security Policies > Threat Prevention.
Step Description
6B In the Protected Scope section, select Inspect incoming and outgoing files.
7B In the Protected Scope section, select Inspect incoming files from the following
interfaces and in the field, select All.
9 Click OK.
Configuring the Application Control and URL Filtering Software Blades for
Monitor Mode
Configure the settings below, if you enabled Application Control or URL Filtering Software Blade
on the Security Gateway in Monitor Mode:
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
2 From the left navigation panel, click Manage & Settings > Blades.
3 In the Application Control & URL Filtering section, click Advanced Settings.
The Application Control & URL Filtering Settings window opens.
Step Description
6 Click OK to close the Application Control & URL Filtering Settings window.
Configuring the Data Loss Prevention Software Blade for Monitor Mode
Configure the settings below, if you enabled the Data Loss Prevention Software Blade on the
Security Gateway in Monitor Mode:
Step Description
1 Connect with SmartConsole to the Security Management Server or Domain Management
Server that manages this Security Gateway.
2 From the left navigation panel, click Manage & Settings > Blades.
4B In the Email Addresses or Domains section, configure with full list of company's domains.
There is no need to include subdomains (for example, mydomain.com, mydomain.uk).
4C In the Networks section, select Anything behind the internal interfaces of my DLP
gateways.
Step Description
5 Click the Policy page.
Configure the applicable rules:
• In the Data column, right-click the pre-defined data types and select Edit.
• On the General Properties page, in the Flag field, select Improve Accuracy.
• In the Customer Names data type, we recommend to add the company's real
customer names.
• In the Action column, you must select Detect.
• In the Severity column, select Critical or High in all applicable rules.
• You may choose to disable/delete rules that are not applicable to the company or
reduce the Severity of these rules.
Note - Before you can configure the DLP rules, you must configure the applicable objects
in SmartConsole.
10 Make sure the Security Gateway enabled the SMTP Mirror Port Mode:
a) Connect to the command line on the Security Gateway.
b) Log in to the Expert mode.
c) Run this command:
# dlp_smtp_mirror_port status
d) Make sure the value of the kernel parameter
dlp_force_smtp_kernel_inspection is set to 1 (one).
Run these two commands:
# fw ctl get int dlp_force_smtp_kernel_inspection
# grep dlp_force_smtp_kernel_inspection
$FWDIR/boot/modules/fwkern.conf
Step Description
1 On the Proxy Server, configure the "X Forward-For header".
See the applicable documentation for your Proxy Server.
2 On the Security Gateway in Monitor Mode, enable the stripping of the X-Forward-For (XFF)
field.
Follow the sk100223: How to enable stripping of X-Forward-For (XFF) field
http://supportcontent.checkpoint.com/solutions?id=sk100223.
To protect the Security Gateway and network, Check Point Security Gateway has baseline security:
Important - If you disable the boot security or unload the currently installed policy, you leave
your Security Gateway, or a Cluster Member without protection. Before you disable the boot
security, we recommend to disconnect your Security Gateway, or a Cluster Member from the
network completely.
For additional information, see these commands in the R80.30 Command Line Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_CLI_ReferenceG
uide/html_frameset.htm:
Command Description
$CPDIR/bin/cpstat -f policy fw Shows the currently installed policy
$FWDIR/bin/control_bootsec Disables the boot security
{-r | -R}
$FWDIR/bin/control_bootsec Enables the boot security
[-g | -G]
$FWDIR/bin/comp_init_policy Deletes the local state policy
[-u | -U]
$FWDIR/bin/comp_init_policy Creates the local state Initial Policy
[-g | -G]
$FWDIR/bin/fw unloadlocal Unloads the currently installed policy
Boot Security
The Boot Security protects the Security Gateway and its networks, during the boot:
• Disables the IP Forwarding in Linux OS kernel
• Loads the Default Filter Policy
Step Description
1 Make sure to configure and install a Security Policy on the Security Gateway.
Step Description
2 Connect to the command line on the Security Gateway.
8 Copy new complied Default Filter file to the path of the Default Filter Policy file.
• For IPv4 traffic, run:
# cp -v $FWDIR/state/default.bin /etc/fw.boot/default.bin
• For IPv6 traffic, run:
# cp -v $FWDIR/state/default.bin6 /etc/fw.boot/default.bin6
Important - Make sure your customized Default Filter policy does not interfere with the Security
Gateway boot process.
Step Description
1 Make sure to configure and install a Security Policy on the Security Gateway.
6 Edit the new Default Filter Policy file to include the desired INSPECT code.
Important - Your customized Default Filter must not use these functions:
• Logging
• Authentication
• Encryption
• Content Security
7 Compile the new Default Filter file:
# fw defaultgen
• The new complied Default Filter file for IPv4 traffic is:
$FWDIR/state/default.bin
• The new complied Default Filter file for IPv6 traffic is:
$FWDIR/state/default.bin6
Step Description
9 Copy new complied Default Filter file to the path of the Default Filter Policy file.
• For IPv4 traffic, run:
# cp -v $FWDIR/state/default.bin /etc/fw.boot/default.bin
• For IPv6 traffic, run:
# cp -v $FWDIR/state/default.bin6 /etc/fw.boot/default.bin6
Command Description
cpstop -fwflag • Shuts down Check Point processes
–default
• Loads the Default Filter policy (defaultfilter)
cpstop -fwflag -proc • Shuts down Check Point processes
• Keeps the currently loaded kernel policy
• Maintains the Connections table, so that after you run the
cpstart command, you do not experience dropped packets
because they are "out of state"
Note - Only security rules that do not use user space processes
continue to work.
Step Description
1 The Security Gateway boots up.
2 The Security Gateway disables IP Forwarding and loads the Default Filter.
The Security Gateway enforces the Initial Policy until administrator installs a user-defined policy.
In subsequent boots, the Security Gateway loads the user-defined policy immediately after the
Default Filter.
There are different Initial Policies for Standalone and distributed setups:
• In a Standalone configuration, where the Security Management Server and the Security
Gateway are on the same computer, the Initial Policy allows CPMI management
communication only. This permits SmartConsole clients to connect to the Security
Management Server.
• In a distributed configuration, where the Security Management Server is on one computer and
the Security Gateway is on a different computer, the Initial Policy:
• Allows cpd and fwd daemons to communicate for SIC (to establish trust) and for Policy
installation.
• Does not allow CPMI connections through the Security Gateway. The SmartConsole will not
be able to connect to the Security Management Server, if the SmartConsole must access
the Security Management Server through a Security Gateway with the Initial Policy.
Step Description
1 Connect to the Security Gateway over serial console.
Column Description
License Status The general state of the Software Blade licenses:
• OK - All the blade licenses are valid.
• Not Activated - Blade licenses are not installed. This is only possible in
the first 15 days after the establishment of the SIC with the Security
Management Server. After the initial 15 days, the absence of licenses
will result in the blade error message.
• Error with <number> blade(s) - The specified number of blade licenses
are not installed or not valid.
• Warning with <number> blade(s) - The specified number of blade
licenses have warnings.
• N/A - No available information.
CK Unique Certificate Key of the license instance.
SKU Catalog ID from the Check Point User Center.
Account ID User's account ID.
Support Level Check Point level of support.
Installation and Upgrade Guide R80.30 | 613
Column Description
Support Expiration Date when the Check Point support contract expires.
2 In the Summary tab below, click the object's License Status (for example: OK).
The Device & License Information window opens. It shows basic object information and
License Status, license Expiration Date, and important quota information (in the
Additional Info column) for each Software Blade.
Notes:
• Quota information, quota-dependent license statuses, and blade information messages
are only supported for R80.
• The tooltip of the SKU is the product name.
The possible values for the Software Blade License Status are:
Status Description
Active The Software Blade is active and the license is valid.
Available The Software Blade is not active, but the license is valid.
No License The Software Blade is active but the license is not valid.
Expired The Software Blade is active, but the license expired.
About to Expire The Software Blade is active, but the license will expire in thirty days
(default) or less (7 days or less for an evaluation license).
Quota Exceeded The Software Blade is active, and the license is valid, but the quota of
related objects (gateways, files, virtual systems, and so on, depending on the
blade) is exceeded.
Quota Warning The Software Blade is active, and the license is valid, but the number of
objects of this blade is 90% (default) or more of the licensed quota.
N/A The license information is not available.
Option Description
License Status view To see and export license information for Software Blades on each
specific Security Management Server, gateway, or Log Server object.
License Status report To see, filter and export license status information for all configured
Security Management Server, gateway, or Log Server objects.
License Inventory To see, filter and export license information for Software Blades on all
report configured Security Management Server, gateway, or Log Server
objects.
The SmartEvent Software Blade lets you customize the License Status and License Inventory
information from the Logs & Monitor view of SmartConsole.
It is also possible to view license information from the Gateways & Servers view of SmartConsole
without enabling the SmartEvent blade on Security Management Server.
The Gateways & Servers view in SmartConsole lets you see and export the License
Inventory report.
Step Description
1 To see the License Inventory report from the Gateways & Servers view:
a) In SmartConsole, from the left navigation panel, click Gateways & Servers.
b) From the top toolbar, click Actions > License Report.
c) Wait for the SmartView to load and show this report.
By default, this report contains:
Inventory page: Blade Names, Devices Names, License Statuses
License by Device page: Devices Names, License statuses, CK, SKU, Account ID,
Support Level, Next Expiration Date
2 To export the License Inventory report from the Gateways & Servers view:
a) In the top right corner, click the Options button.
b) Select the applicable export option - Export to Excel, or Export to PDF.
The Logs & Monitor view in SmartConsole lets you see, filter and export the License
Status report.
Step Description
1 To see the License Status report from the Logs & Monitor view:
a) In SmartConsole, from the left navigation panel, click Logs & Monitor
b) At the top, open a new tab by clicking New Tab, or [+].
c) In the left section, click Views.
d) In the list of reports, double-click License Status.
e) Wait for the SmartView to load and show this report.
By default, this report contains:
Names of the configured objects, License status for each object, CK, SKU,
Account ID, Support Level, Next Expiration Date
2 To filter the License Status report in the Logs & Monitor view:
a) In the top right corner, click the Options button > View Filter.
The Edit View Filter window opens.
b) Select a Field to filter results. For example, Device Name, License Status, Account
ID.
c) Select the logical operator - Equals, Not Equals, or Contains.
d) Select or enter a filter value.
Note - Click the X icon to delete a filter.
e) Optional: Click the + icon to configure additional filters.
f) Click OK to apply the configured filters.
The report is filtered based on the configured filters.
3 To export the License Status report in the Logs & Monitor view:
a) In the top right corner, click the Options button.
b) Select the applicable export option - Export to Excel, or Export to PDF.
The Logs & Monitor view in SmartConsole lets you see, filter and export the License
Inventory report.
Step Description
1 To see the License Inventory report from the Logs & Monitor view:
a) In SmartConsole, from the left navigation panel, click Logs & Monitor
b) At the top, open a new tab by clicking New Tab, or [+].
c) In the left section, click Reports.
d) In the list of reports, double-click License Inventory.
e) Wait for the SmartView to load and show this report.
By default, this report contains:
Inventory page: Blade Names, Devices Names, License Statuses
License by Device page: Devices Names, License statuses, CK, SKU, Account ID,
Support Level, Next Expiration Date
2 To filter the License Inventory report in the Logs & Monitor view:
a) In the top right corner, click the Options button > Report Filter.
The Edit Report Filter window opens.
b) Select a Field to filter results. For example, Blade Name, Device Name, License
Overall Status, Account ID.
c) Select the logical operator - Equals, Not Equals, or Contains.
d) Select or enter a filter value.
Note - Click the X icon to delete a filter.
e) Optional: Click the + icon to configure additional filters.
f) Click OK to apply the configured filters.
The report is filtered based on the configured filters.
3 To export the License Inventory report in the Logs & Monitor view:
a) In the top right corner, click the Options button.
b) Select the applicable export option - Export to Excel, or Export to PDF.
To add a license:
Step Description
1 In the navigation tree, click Maintenance > Licenses.
2 Click New.
The Add License window opens.
Step Description
3 Enter the license data manually, or click Paste License to enter the data automatically.
The Paste License button only shows in Internet Explorer.
For other web browsers, paste the license strings into the empty text field.
4 Click OK.
To delete a license:
Step Description
1 In the navigation tree, click Maintenance > Licenses.
2 Select a license in the table.
3 Click Delete.
3 Install the new license (issued for the new IP address) on your Security Management
Server.
4 Remove the old license (issued for the old IP address) from your Security Management
Server.
6 In SmartConsole:
a) Connect with SmartConsole to the (Primary) Security Management Server.
b) Open the Security Management Server object.
c) In the left tree, click Network Management.
d) Make sure to update the IP Address and topology.
e) Click OK.
f) Publish the SmartConsole session.
g) In the top left corner, click Menu > Install database > select all objects > click
Install > click OK.
7 On your DNS Server, map the host name of your Security Management Server to the new
IP address.
Step Description
3 Install the new license (issued for the new IP address) on your Multi-Domain Server or
Multi-Domain Log Server.
4 Remove the old license (issued for the old IP address) from your Multi-Domain Server or
Multi-Domain Log Server.
6 On your DNS Server, map the host name of your Multi-Domain Server or Multi-Domain
Log Server to the new IP address.
3 Install the new license (issued for the new IP address) on your Log Server or SmartEvent
Server.
4 Remove the old license (issued for the old IP address) from your Log Server or SmartEvent
Server.
6 In SmartConsole:
a) Connect with SmartConsole to the applicable Management Server that manages
your dedicated Log Server or SmartEvent Server.
b) Open the object of your dedicated Log Server or SmartEvent Server.
c) In the left tree, click Network Management.
d) Make sure to update the IP Address and topology.
e) Click OK.
f) Publish the SmartConsole session.
g) In the top left corner, click Menu > Install database > select all objects > click
Install > click OK.
h) Install the Access Control Policy on all managed Security Gateways that send their
logs to your dedicated Log Server or SmartEvent Server.
7 On your DNS Server, map the host name of your dedicated Log Server or SmartEvent
Server to the new IP address.
Using SmartUpdate
In This Section:
Accessing SmartUpdate .................................................................................... 622
Licenses Stored in the Licenses & Contracts Repository .................................... 623
Licensing Terms for SmartUpdate ..................................................................... 624
Viewing the Licenses & Contracts Repository..................................................... 626
Adding New Licenses to the Licenses & Contracts Repository............................ 627
Deleting a License from the Licenses & Contracts Repository............................ 629
Attaching a License to a Security Gateway ......................................................... 630
Detaching a License from a Security Gateway .................................................... 631
Getting Licenses from Security Gateways .......................................................... 632
Exporting a License to a File .............................................................................. 633
Checking for Expired Licenses........................................................................... 634
SmartUpdate distributes licenses and software packages for managed Check Point and OPSEC
Certified products. It provides a centralized way to guarantee that Internet security throughout the
enterprise network is always up to date.
These features and tools are available in SmartUpdate:
• Maintaining licenses
• Upgrading packages for R77.30 and below
• Adding packages to Package Repository for R77.30 and below
Important - The SmartUpdate GUI shows two tabs - Package Management and Licenses &
Contracts. For versions R80.10 and above, the tools in the Package Management tab are no
longer supported. To install packages on Gaia OS, use CPUSE (see sk92449
http://supportcontent.checkpoint.com/solutions?id=sk92449), or Central Deployment Tool (see
sk111158 http://supportcontent.checkpoint.com/solutions?id=sk111158). For further information,
see Installing Software Packages on Gaia (on page 118).
Accessing SmartUpdate
Step Description
1 Open the SmartUpdate in one of these ways:
• In SmartConsole, in the top left corner, click Menu > Manage licenses & packages.
• On the SmartConsole client, run this executable file directly:
• On Windows OS 32-bit:
C:\Program
Files\CheckPoint\SmartConsole\<RXX>\PROGRAM\SmartDistributor.
exe
• On Windows OS 64-bit:
C:\Program Files
(x86)\CheckPoint\SmartConsole\<RXX>\PROGRAM\SmartDistributor.
exe
2 In the top left corner, click Menu > View > Menu Bar.
The menu names appear at the top of the GUI.
Attach (on page You can attach a license from the Licenses & Contracts Repository to a
630) managed Security Gateway.
Detach (on page When you detach a license from a managed Security Gateway, you have to
631) uninstall the license from that Security Gateway. If this is a Central license,
this operation makes that license in the Licenses & Contracts Repository
available to other managed Security Gateways.
Get (on page 632) You can add information from your managed Security Gateways about the
licenses you installed locally. This updates the Licenses & Contracts
Repository with all local licenses across the installation. The Get operation is
a two-way process that places all locally installed licenses in the License &
Contract Repository and removes all locally deleted licenses from the
Licenses & Contracts Repository.
Delete (on page You can delete a license from the Licenses & Contracts Repository.
629)
Export (on page You can export a license from the Licenses & Contracts Repository to a file.
633)
Term Description
State The license state depends on whether the license is associated with a
managed Security Gateway in the Licenses & Contracts Repository, and
whether the license is installed on that Security Gateway. The license state
definitions are as follows:
• Attached - Indicates that the license is associated with a managed Security
Gateway in the Licenses & Contracts Repository, and is installed on that
Security Gateway.
• Unattached - Indicates that the license is not associated with managed
Security Gateways in the Licenses & Contracts Repository, and is not
installed on managed Security Gateways.
• Assigned Indicates that the license that is associated with a managed
Security Gateway in the Licenses & Contracts Repository, but has not yet
been installed on a Security Gateway.
Upgrade Status This is a field in the Licenses & Contracts Repository that contains an error
message from the User Center when the License Upgrade process fails.
Central License Attach a Central License to the IP address of your Management Server.
Local License A Local License is tied to the IP address of the specific Security Gateway. You
can only use a local license with a Security Gateway or a Security Management
Server with the same address.
Multi-License This is a license file that contains more than one license.
File
The cplic put, and cplic add commands support these files.
Certificate Key This is a string of 12 alphanumeric characters. The number is unique to each
package.
cplic A CLI utility to manage local licenses on Check Point computers. For details,
see the R80.30 CLI Reference Guide
https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.
30_CLI_ReferenceGuide/html_frameset.htm - Chapter Security Management
Server Commands - Section cplic.
3 Click Licenses & Contracts menu at the top > Add License > From User Center.
4 Click Licenses & Contracts menu at the top > Add License > From File.
6 Click Open.
4 Click Licenses & Contracts menu at the top > Add License > Manually.
6 Click OK.
Step Description
1 Open the SmartUpdate (on page 622).
3 If you do not see the window License And Contract Repository, then click Licenses &
Contracts menu at the top > View Repository.
4 Right-click anywhere in the Licenses And Contracts Repository window and select View
Unattached Licenses.
5 Right-click the Unattached license that you want to delete, and select Delete License /
Contract.
Step Description
1 Open the SmartUpdate (on page 622).
4 In the Attach Licenses window, select the applicable Security Gateway or Cluster Member.
5 Click Next.
7 Click Finish.
9 Connect to the command line on the applicable Security Gateway or Cluster Member.
10 Run the cplic print command to make sure the license is attached.
4 In the Detach Licenses window, select the applicable Security Gateway or Cluster
Member.
5 Click Next.
7 Click Finish.
9 Connect to the command line on the applicable Security Gateway or Cluster Member.
10 Run the cplic print command to make sure the license is detached.
Step Description
1 Open the SmartUpdate (on page 622).
3 Click Licenses & Contracts menu at the top > Get all Licenses.
3 If you do not see the window License And Contract Repository, then click Licenses &
Contracts menu at the top > View Repository.
4 Right-click anywhere in the Licenses And Contracts Repository window and select View
all Licenses & Contracts.
5 Right-click the license that you want to export, and select Export License to File.
6 Select the location, enter the desired file name and click Save.
Note - If the license file with such name already exists, the new licenses are added to the existing
file.
3 If you do not see the window License And Contract Repository, then click Licenses &
Contracts menu at the top > View Repository.
4 Right-click anywhere in the Licenses And Contracts Repository window and select View
all Licenses & Contracts.
8 Right-click on one of the selected licenses and select Export License to File.
9 Select the location, enter the desired file name and click Save.
Note - If the license file with such name already exists, the new licenses are added to the existing
file.
3 Click Licenses & Contracts menu at the top > Show Expired.
4 In the License/Contract Expiration window, the expired licenses appear in the Expired
License and Contracts section.
3 Click Licenses & Contracts menu at the top > Show Expired.
4 In the License/Contract Expiration window, set the desired number of days in the Search
for licenses/contracts expiring within the next X days field.
Automatic Downloads
Check Point products connect to Check Point cloud services to download and upload information.
You can enable or disable Automatic Downloads in the Gaia First Time Configuration Wizard, on
the Products page. We recommend that you enable Automatic Downloads, so that you can use
these features:
• Blade Contracts are annual licenses for Software Blades and product features. If there is no
valid Blade contract, the applicable blades and related features will work, but with some
limitations.
• CPUSE lets you manage upgrades and installations on Gaia OS. See sk92449
http://supportcontent.checkpoint.com/solutions?id=sk92449.
• Data updates and Cloud Services are necessary for the full functionality of these Software
Blades and features:
• Application & URL Filtering
• Threat Prevention (Anti-Bot, Anti-Virus, Anti-Spam, IPS, Threat Emulation)
• HTTPS Inspection
• URL Filtering database
• Application Database
• Compliance
• SmartEndpoint
• AppWiki
• ThreatWiki
The Automatic Downloads feature is applicable to the Security Management Servers,
Multi-Domain Servers, Log Servers, and Security Gateways.
If you disabled Automatic Downloads in the Gaia First Time Configuration Wizard, you can enable it
again in SmartConsole Global properties:
Step Description
1 In the top left corner, click Menu > Global properties > Security Management Access.
3 Click OK.
Step Description
5 Connect with SmartConsole to your Management Server.
Step Description
1 In the top left corner, click Menu > Global properties > Security Management Access.
3 Click OK.