CP R80.40 Installation and Upgrade Guide
CP R80.40 Installation and Upgrade Guide
CP R80.40 Installation and Upgrade Guide
INSTALLATION AND
UPGRADE GUIDE
R80.40
[Classification: Protected]
Check Point Copyright Notice
© 2020 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed
under licensing restricting their use, copying, distribution, and decompilation. No part of this product or
related documentation may be reproduced in any form or by any means without prior written authorization
of Check Point. While every precaution has been taken in the preparation of this book, Check Point
assumes no responsibility for errors or omissions. This publication and features described herein are
subject to change without notice.
TRADEMARKS:
Refer to the Copyright page for a list of our trademarks.
Refer to the Third Party copyright notices for a list of relevant copyrights and third-party licenses.
Installation and Upgrade Guide R80.40
Important Information
Latest Software
We recommend that you install the most recent software release to stay up-to-date with the
latest functional improvements, stability fixes, security enhancements and protection
against new and evolving attacks.
Certifications
For third party independent certification of Check Point products, see the Check Point
Certifications page.
Feedback
Check Point is engaged in a continuous effort to improve its documentation.
Please help us by sending your comments.
Revision History
Date Description
24 Added:
August
2020 n "Changing the IP Address of a Multi-Domain Server or Multi-Domain Log Server" on
page 663
(replaced the procedure "Changing the Leading Interface on Multi-Domain Server
or Multi-Domain Log Server")
n "Changing the IP Address of a Domain Management Server or Domain Log Server"
on page 670
n The note in upgrade procedures - Before you can install Hotfixes on servers that
work in Management High Availability, you must upgrade all these servers.
Date Description
Updated:
n "Installing a VSX Gateway" on page 100
n "Installing a VSX Cluster" on page 118
n "Prerequisites for Upgrading and Migrating of Management Servers and Log
Servers" on page 156
n "Upgrading Security Management Servers in Management High Availability from
R80.10 and lower" on page 198
n "Upgrading Security Management Servers in Management High Availability from
R80.20 and higher" on page 259
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
n "Upgrading a Security Management Server or Log Server from R80.20 and higher"
on page 237
n "Upgrading a Multi-Domain Log Server from R80.10 and lower" on page 406
n "Upgrading a Multi-Domain Log Server from R80.20 and higher" on page 430
n "Upgrading Multi-Domain Servers in High Availability from R80.10 and lower" on
page 319
n "Upgrading Multi-Domain Servers in High Availability from R80.20 and higher" on
page 355
n "Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower" on
page 482
n "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher" on page 500
n "Migrating Database from an R80.40 Security Management Server to an R80.40
Domain Management Server" on page 624
n "Migrating Database from an R80.40 Domain Management Server to an R80.40
Security Management Server" on page 629
n "Migrating Database from an R7x Domain Management Server to an R80.40
Domain Management Server" on page 644
n "Migrating Database from an R7x Security Management Server to an R80.40
Domain Management Server" on page 638
n "Migrating Database from an R7x Standalone to an R80.40 Domain Management
Server" on page 652
n "Upgrading one R7x Multi-Domain Server with Gradual Migration of Domain
Management Servers" on page 285
n "Upgrading a Security Gateway or VSX Gateway" on page 527
n "Upgrading ClusterXL, VSX Cluster, or VRRP Cluster" on page 539
n "Multi-Version Cluster Upgrade Procedure" on page 579
n "Configuring a Single VSX Gateway in Monitor Mode" on page 693
n Corrected the command to restart the Log Exporter
Date Description
06 April Updated:
2020
n "Backing Up and Restoring a Domain" on page 616
n "Upgrade Methods" on page 167 - added the description of the detailed upgrade
report
n "Migrating Database from an R80.40 Security Management Server to an R80.40
Domain Management Server" on page 624
n "Migrating Database from an R80.40 Domain Management Server to an R80.40
Security Management Server" on page 629
10 Updated:
February
2020 n "Contract Verification" on page 173
n "Working with Licenses" on page 771
n "Using SmartUpdate" on page 781
04 Updated:
February
2020 n "Migrating Database from an R80.40 Security Management Server to an R80.40
Domain Management Server" on page 624
n "Migrating Database from an R80.40 Domain Management Server to an R80.40
Security Management Server" on page 629
03 Updated:
February
2020 n "Installing Software Packages on Gaia" on page 153 - added the description of the
detailed upgrade report in Gaia Portal
30 Added:
January
2020 n "Migrating Database from an R80.40 Security Management Server to an R80.40
Domain Management Server" on page 624
n "Migrating Database from an R80.40 Domain Management Server to an R80.40
Security Management Server" on page 629
Updated:
n "Multi-Version Cluster Limitations" on page 577 - added the limitation "In a VSX
Cluster, it is possible to install policy only on the upgraded VSX Cluster Members that
run R80.40"
Table of Contents
Glossary 14
Getting Started 24
Welcome 24
R80.40 Documentation 24
R80.40 Software Images 24
For New Check Point Customers 24
Disk Space 25
Product Deployment Scenarios 25
Backing Up and Restoring 27
The Gaia Operating System 30
Installing the Gaia Operating System on Check Point Appliances 31
Installing the Gaia Operating System on Open Servers 33
Installing a Blink Image to Configure a Check Point Gateway Appliance 35
Changing Disk Partition Sizes During the Installation of Gaia Operating System 36
Running an Unattended USB Installation of Gaia on Check Point Appliances 37
Configuring Gaia for the First Time 38
Running the First Time Configuration Wizard in Gaia Portal 39
Running the First Time Configuration Wizard in CLI Expert mode 49
Configuring the IP Address of the Gaia Management Interface 57
Changing the Disk Partition Sizes on an Installed Gaia 59
Enabling IPv6 on Gaia 60
Installing a Security Management Server 62
Installing One Security Management Server only, or Primary Security Management Server in
Management High Availability 63
Installing a Secondary Security Management Server in Management High Availability 65
Installing a Dedicated Log Server or SmartEvent Server 68
Installing a Multi-Domain Server 71
Installing One Multi-Domain Server Only, or Primary Multi-Domain Server in Management High
Availability 72
Installing a Secondary Multi-Domain Server in Management High Availability 73
Installing a Multi-Domain Log Server 75
Upgrading a Security Management Server or Log Server from R80.20 and higher with
Advanced Upgrade 242
Upgrading a Security Management Server or Log Server from R80.20 and higher with
Migration 250
Upgrading Security Management Servers in Management High Availability from R80.20 and
higher 259
Upgrade of Multi-Domain Servers and Multi-Domain Log Servers 262
Upgrading one Multi-Domain Server from R80.10 and lower 263
Upgrading one Multi-Domain Server from R80.10 and lower with CPUSE 264
Upgrading one Multi-Domain Server from R80.10 and lower with Advanced Upgrade 268
Upgrading one Multi-Domain Server from R80.10 and lower with Migration 276
Upgrading one R7x Multi-Domain Server with Gradual Migration of Domain Management
Servers 285
Upgrading one Multi-Domain Server from R80.20 and higher 297
Upgrading one Multi-Domain Server from R80.20 and higher with CPUSE 298
Upgrading one Multi-Domain Server from R80.20 and higher with Advanced Upgrade 303
Upgrading one Multi-Domain Server from R80.20 and higher with Migration 311
Upgrading Multi-Domain Servers in High Availability from R80.10 and lower 319
Upgrading Multi-Domain Servers in High Availability from R80.10 and lower with CPUSE 320
Upgrading Multi-Domain Servers in High Availability from R80.10 and lower with Advanced
Upgrade 325
Upgrading Multi-Domain Servers in High Availability from R80.10 and lower with Migration 340
Managing Domain Management Servers During the Upgrade Process 354
Upgrading Multi-Domain Servers in High Availability from R80.20 and higher 355
Upgrading Multi-Domain Servers in High Availability from R80.20 and higher with CPUSE 356
Upgrading Multi-Domain Servers in High Availability from R80.20 and higher with Advanced
Upgrade 363
Upgrading Multi-Domain Servers in High Availability from R80.20 and higher with Migration 384
Managing Domain Management Servers During the Upgrade Process 405
Upgrading a Multi-Domain Log Server from R80.10 and lower 406
Upgrading a Multi-Domain Log Server from R80.10 and lower with CPUSE 407
Upgrading a Multi-Domain Log Server from R80.10 and lower with Advanced Upgrade 412
Upgrading a Multi-Domain Log Server from R80.10 and lower with Migration 421
Upgrading a Multi-Domain Log Server from R80.20 and higher 430
Upgrading a Multi-Domain Log Server from R80.20 and higher with CPUSE 431
Upgrading a Multi-Domain Log Server from R80.20 and higher with Advanced upgrade 437
Upgrading a Multi-Domain Log Server from R80.20 and higher with Migration 446
Upgrade of Endpoint Security Management Servers and Endpoint Policy Servers 455
Upgrading an Endpoint Security Management Server from R80.10 and lower 456
Upgrading an Endpoint Security Management Server from R80.10 and lower with CPUSE 457
Upgrading an Endpoint Security Management Server from R80.10 and lower with Advanced
Upgrade 460
Upgrading an Endpoint Security Management Server from R80.10 and lower with Migration 470
Upgrading Endpoint Security Management Servers in Management High Availability from
R80.10 and lower 477
Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower 482
Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with CPUSE 483
Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with Advanced Upgrade 487
Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with Migration 494
Upgrading an Endpoint Security Management Server or Endpoint Policy Server from R80.20 and
higher 500
Upgrading an Endpoint Security Management Server or Endpoint Policy Server from R80.20
and higher with CPUSE 501
Upgrading an Endpoint Security Management Server or Endpoint Policy Server from R80.20
and higher with Advanced Upgrade 506
Upgrading an Endpoint Security Management Server or Endpoint Policy Server from R80.20
and higher with Migration 514
Upgrading Endpoint Security Management Servers in Management High Availability from
R80.20 and higher 523
Upgrade of Security Gateways and Clusters 526
Upgrading a Security Gateway or VSX Gateway 527
Upgrading a Security Gateway with CPUSE 528
Upgrading a VSX Gateway with CPUSE 532
Upgrading ClusterXL, VSX Cluster, or VRRP Cluster 539
Planning a Cluster Upgrade 540
Minimal Effort Upgrade 545
Minimal Effort Upgrade of a Security Gateway Cluster 546
Minimal Effort Upgrade of a VSX Cluster 550
Zero Downtime Upgrade 555
Zero Downtime Upgrade of a Security Gateway Cluster 556
Zero Downtime Upgrade of a VSX Cluster 565
Multi-Version Cluster (MVC) Upgrade 575
Multi-Version Cluster Upgrade Prerequisites 575
Supported Versions in Multi-Version Cluster 576
Multi-Version Cluster Limitations 577
General limitations in Multi-Version Cluster configuration 577
Limitations during failover in Multi-Version Cluster 579
Multi-Version Cluster Upgrade Procedure 579
Troubleshooting the Multi-Version Cluster 595
Upgrading a Full High Availability Cluster 597
Upgrading a Standalone from R80.10, R77.30 and lower 598
Upgrading a Standalone from R80.10 and lower with CPUSE 599
Upgrading a Standalone from R80.10 and lower with Advanced Upgrade 602
Upgrading a Standalone from R80.10 and lower with Migration 609
Special Scenarios for Management Servers 615
Backing Up and Restoring a Domain 616
Configuring ClusterXL in Bridge Mode - Active / Active with Two or Four Switches 737
Accept, or Drop Ethernet Frames with Specific Protocols 752
Routing and Bridge Interfaces 753
Managing a Security Gateway through the Bridge Interface 754
IPv6 Neighbor Discovery 756
Managing Ethernet Protocols 756
Configuring Link State Propagation (LSP) 759
Security Before Firewall Activation 763
Boot Security 764
The Initial Policy 769
Troubleshooting: Cannot Complete Reboot 770
Working with Licenses 771
Viewing Licenses in SmartConsole 772
Monitoring Licenses in SmartConsole 774
Managing Licenses in the Gaia Portal 778
Migrating a License to a New IP Address 779
Using SmartUpdate 781
Accessing SmartUpdate 782
Licenses Stored in the Licenses & Contracts Repository 783
Licensing Terms for SmartUpdate 784
Viewing the Licenses & Contracts Repository 786
Adding New Licenses to the Licenses & Contracts Repository 787
Deleting a License from the Licenses & Contracts Repository 790
Attaching a License to a Security Gateway 791
Detaching a License from a Security Gateway 792
Getting Licenses from Security Gateways 793
Exporting a License to a File 794
Checking for Expired Licenses 796
Check Point Cloud Services 797
Automatic Downloads 797
Sending Data to Check Point 799
Glossary
A
Administrator
A user with permissions to manage Check Point security products and the network
environment.
API
In computer programming, an application programming interface (API) is a set of
subroutine definitions, protocols, and tools for building application software. In general
terms, it is a set of clearly defined methods of communication between various software
components.
Appliance
A physical computer manufactured and distributed by Check Point.
Bond
A virtual interface that contains (enslaves) two or more physical interfaces for
redundancy and load sharing. The physical interfaces share one IP address and one
MAC address. See "Link Aggregation".
Bonding
See "Link Aggregation".
Bridge Mode
A Security Gateway or Virtual System that works as a Layer 2 bridge device for easy
deployment in an existing topology.
CA
Certificate Authority. Issues certificates to gateways, users, or computers, to identify
itself to connecting entities with Distinguished Name, public key, and sometimes IP
address. After certificate validation, entities can send encrypted data using the public
keys in the certificates.
Certificate
An electronic document that uses a digital signature to bind a cryptographic public key
to a specific identity. The identity can be an individual, organization, or software entity.
The certificate is used to authenticate one identity to another.
Clean Install
Installation of a Check Point Operating System from scratch on a computer.
Cluster
Two or more Security Gateways that work together in a redundant configuration - High
Availability, or Load Sharing.
Cluster Member
A Security Gateway that is part of a cluster.
CoreXL
A performance-enhancing technology for Security Gateways on multi-core processing
platforms. Multiple Check Point Firewall instances are running in parallel on multiple
CPU cores.
CoreXL SND
Secure Network Distributer. Part of CoreXL that is responsible for: Processing incoming
traffic from the network interfaces; Securely accelerating authorized packets (if
SecureXL is enabled); Distributing non-accelerated packets between Firewall kernel
instances (SND maintains global dispatching table, which maps connections that were
assigned to CoreXL Firewall instances). Traffic distribution between CoreXL Firewall
instances is statically based on Source IP addresses, Destination IP addresses, and the
IP 'Protocol' type. The CoreXL SND does not really "touch" packets. The decision to
stick to a particular FWK daemon is done at the first packet of connection on a very high
level, before anything else. Depending on the SecureXL settings, and in most of the
cases, the SecureXL can be offloading decryption calculations. However, in some other
cases, such as with Route-Based VPN, it is done by FWK daemon.
CPUSE
Check Point Upgrade Service Engine for Gaia Operating System. With CPUSE, you
can automatically update Check Point products for the Gaia OS, and the Gaia OS itself.
For details, see sk92449.
DAIP Gateway
A Dynamically Assigned IP (DAIP) Security Gateway is a Security Gateway where the
IP address of the external interface is assigned dynamically by the ISP.
Data Type
A classification of data. The Firewall classifies incoming and outgoing traffic according
to Data Types, and enforces the Policy accordingly.
Database
The Check Point database includes all objects, including network objects, users,
services, servers, and protection profiles.
Database Migration
Process of: (1) Installing the latest Security Management Server or Multi-Domain Server
version from the distribution media on a separate computer from the existing Security
Management Server or Multi-Domain Server (2) Exporting the management database
from the existing Security Management Server or Multi-Domain Server (3) Importing the
management database to the new Security Management Server or Multi-Domain Server
This upgrade method minimizes upgrade risks for an existing deployment.
Distributed Deployment
The Check Point Security Gateway and Security Management Server products are
deployed on different computers.
Domain
A network or a collection of networks related to an entity, such as a company, business
unit or geographical location.
Expert Mode
The name of the full command line shell that gives full system root permissions in the
Check Point Gaia operating system.
External Network
Computers and networks that are outside of the protected network.
External Users
Users defined on external servers. External users are not defined in the Security
Management Server database or on an LDAP server. External user profiles tell the
system how to identify and authenticate externally defined users.
Firewall
The software and hardware that protects a computer network by analyzing the incoming
and outgoing network traffic (packets).
Gaia
Check Point security operating system that combines the strengths of both
SecurePlatform and IPSO operating systems.
Gaia Clish
The name of the default command line shell in Check Point Gaia operating system. This
is a restrictive shell (role-based administration controls the number of commands
available in the shell).
Gaia Portal
Web interface for Check Point Gaia operating system.
Hotfix
A piece of software installed on top of the current software in order to fix some wrong or
undesired behavior.
ICA
Internal Certificate Authority. A component on Check Point Management Server that
issues certificates for authentication.
Internal Network
Computers and resources protected by the Firewall and accessed by authenticated
users.
IPv4
Internet Protocol Version 4 (see RFC 791). A 32-bit number - 4 sets of numbers, each
set can be from 0 - 255. For example, 192.168.2.1.
IPv6
Internet Protocol Version 6 (see RFC 2460 and RFC 3513). 128-bit number - 8 sets of
hexadecimal numbers, each set can be from 0 - ffff. For example,
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.
Link Aggregation
Technology that joins (aggregates) multiple physical interfaces together into one virtual
interface, known as a bond interface. Also known as Interface Bonding, or Interface
Teaming. This increases throughput beyond what a single connection could sustain,
and to provides redundancy in case one of the links should fail.
Log
A record of an action that is done by a Software Blade.
Log Server
A dedicated Check Point computer that runs Check Point software to store and process
logs in Security Management Server or Multi-Domain Security Management
environment.
Management Interface
Interface on Gaia computer, through which users connect to Portal or CLI. Interface on a
Gaia Security Gateway or Cluster member, through which Management Server
connects to the Security Gateway or Cluster member.
Management Server
A Check Point Security Management Server or a Multi-Domain Server.
Migration
Exporting the Check Point configuration database from one Check Point computer and
importing it on another Check Point computer.
Multi-Domain Server
A computer that runs Check Point software to host virtual Security Management Servers
called Domain Management Servers. Acronym: MDS.
Network Object
Logical representation of every part of corporate topology (physical machine, software
component, IP Address range, service, and so on).
Open Server
A physical computer manufactured and distributed by a company, other than Check
Point.
Package Repository
A SmartUpdate repository on the Security Management Server that stores uploaded
packages. These packages are then used by SmartUpdate to perform upgrades of
Check Point Small Office Appliances.
Rule
A set of traffic parameters and other conditions in a Rule Base that cause specified
actions to be taken for a communication session.
Rule Base
Also Rulebase. All rules configured in a given Security Policy.
SecureXL
Check Point product that accelerates IPv4 and IPv6 traffic. Installed on Security
Gateways for significant performance improvements.
Security Gateway
A computer that runs Check Point software to inspect traffic and enforces Security
Policies for connected network resources.
Security Policy
A collection of rules that control network traffic and enforce organization guidelines for
data protection and access to resources with packet inspection.
SIC
Secure Internal Communication. The Check Point proprietary mechanism with which
Check Point computers that run Check Point software authenticate each other over
SSL, for secure communication. This authentication is based on the certificates issued
by the ICA on a Check Point Management Server.
Single Sign-On
A property of access control of multiple related, yet independent, software systems. With
this property, a user logs in with a single ID and password to gain access to a
connected system or systems without using different usernames or passwords, or in
some configurations seamlessly sign on at each system. This is typically accomplished
using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases
on (directory) servers. Acronym: SSO.
SmartConsole
A Check Point GUI application used to manage Security Policies, monitor products and
events, install updates, provision new devices and appliances, and manage a multi-
domain environment and each domain.
SmartDashboard
A legacy Check Point GUI client used to create and manage the security settings in
R77.30 and lower versions.
Software Blade
A software blade is a security solution based on specific business needs. Each blade is
independent, modular and centrally managed. To extend security, additional blades can
be quickly added.
SSO
See "Single Sign-On".
Standalone
A Check Point computer, on which both the Security Gateway and Security
Management Server products are installed and configured.
Traffic
Flow of data between network devices.
Upgrade
Replacing a Check Point product with a newer version of the same Check Point
product.
Users
Personnel authorized to use network resources and applications.
VLAN
Virtual Local Area Network. Open servers or appliances connected to a virtual network,
which are not physically connected to the same network.
VLAN Trunk
A connection between two switches that contains multiple VLANs.
VSX
Virtual System Extension. Check Point virtual networking solution, hosted on a
computer or cluster with virtual abstractions of Check Point Security Gateways and
other network devices. These Virtual Devices provide the same functionality as their
physical counterparts.
VSX Gateway
Physical server that hosts VSX virtual networks, including all Virtual Devices that
provide the functionality of physical network devices. It holds at least one Virtual
System, which is called VS0.
Getting Started
Important - Before you install or upgrade to R80.40:
1. Read the R80.40 Release Notes.
2. Back up the current system. See "Backing Up and Restoring" on page 27.
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 or call Check Point at 1(800) 429-4391.
For additional technical information, visit the Check Point Support Center.
Welcome to the Check Point family. We look forward to meeting all of your current and future network,
application, and management security needs.
R80.40 Documentation
This guide is for administrators responsible for installing R80.40 on appliances and open servers that run
the Gaia Operating System.
To learn what is new in R80.40, see the R80.40 Release Notes.
See the R80.40 Home Page SK for information about the R80.40 release.
Disk Space
When you install or upgrade R80.40, 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:
n The amount of disk space necessary to install the product.
n The directory where the product is installed.
n The amount of free disk space that is available in the directory.
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).
A Primary Security Management Server (1) has a direct or indirect connection (2) to a Secondary
Security Management Server (3).
The databases of the Security Management Servers are synchronized, manually or on a schedule, to
back up one another.
The administrator makes one Security Management Server Active and the others Standby.
If the Active Security Management Server is down, the administrator can promote the Standby server to
be Active.
In a Full High Availability Cluster on two Check Point Appliances, each appliance runs both as a
ClusterXL Cluster Member and as a Security Management Server, in High Availability mode.
Important - You can deploy and configure a Full High Availability Cluster only on
Check Point Appliances that support Standalone configuration. See the R80.40
Release Notes and "Installing a Standalone" on page 143.
This deployment lets you reduce the maintenance required for your systems.
In the image below, the appliances are denoted as (1) and (3).
The two appliances are connected with a direct synchronization connection (2) and work in High
Availability mode:
n The Security Management Server on one appliance (for example, 1) runs as Primary, and the
Security Management Server on the other appliance (3) runs as Secondary.
n The ClusterXL on one appliance (for example, 1) runs as Active, and the ClusterXL on the other
appliance (3), runs as Standby.
n The ClusterXL Cluster Members synchronize the information about the traffic over the
synchronization connection (2).
Step Description
2 Immediately after the Pre-Upgrade Verifier (PUV) finishes successfully and does not show you
further suggestions:
n Save a second snapshot of your source system.
n Save a second backup of your source system.
n 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 - This operation reverts the appliance to the last Gaia version that was
installed using the Clean Install method.
Step Description
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]
Step Description
1 Download the Gaia Operating System Clean Install ISO file from the R80.40 Home Page SK.
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. See "Configuring Gaia for the First Time" on
page 38.
Step Description
1 Download the Gaia Operating System Clean Install ISO file from the R80.40 Home Page SK.
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.
Step Description
1 Download the Gaia Operating System ISO file from R80.40 Home Page SK.
Note - If you add the Blink image to a USB and insert the USB into the appliance before
the First Time Configuration Wizard shows, the process begins automatically.
After the installation is complete, connect with your web browser to the Check Point appliance to complete
the simplified Blink configuration.
In addition, the Blink utility lets you use a special XML file to run an unattended installation with predefined
parameters for an appliance:
n Host name
n Gaia administrator password
n Network options - IP address, Subnet, Default Gateway
n Secure Internal Communication (SIC) key
n Cluster membership
n Upload to Check Point approval
n Download from Check Point approval
For complete information, see sk120193.
Important - Always use the latest available build of the ISOmorphic Tool. If you use an
outdated build, the installation can fail.
On Check Point appliances, the ISOmorphic tool lets an administrator run an unattended installation.
In an unattended installation, an experienced Check Point system administrator:
Step Description
1 Prepares the USB with these pre-configured settings for a specified network interface:
n IP address
n Network mask
n Default Gateway
2 Sends the USB drive to an administrator, who inserts the drive into the appliance and reboots it.
The tool installs the Check Point Gaia OS and configures the appliance with the predefined
settings.
The LCD indicates a successful installation and interfaces blink in round-robin fashion.
n Connects to the Gaia Portal and runs the First Time Configuration Wizard, or
n Opens a command line to the appliance for further operating system level configuration
Note - The ISOmorphic tool does not support unattended installation on Open Servers.
Step Instructions
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://<IP address of Gaia Management Interface>
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.
Setup Continue with R80.40 Use this option to configure the installed Gaia and
configuration Check Point products.
Install Install from Check Point Use these options to install a Gaia version.
Cloud
Install from USB device
Recovery Import existing snapshot Use this option to import an existing Gaia snapshot.
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):
n Install major version - This option let you choose and install major versions available on Check
Point Cloud. The Gaia CPUSE performs the installation.
n 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.
In this window, you select and configure the main Gaia Management Interface. You connect to this IP
address to open the Gaia Portal or CLI session.
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 Select how the Gaia Management Interface gets its IPv4 address:
IPv4
n Manually - You configure the IPv4 settings in the next fields.
n Off - None.
Configure Select how the Gaia Management Interface gets its IPv6 address:
IPv6
n Manually - You configure the IPv6 settings in the next fields.
n Off - None.
Optional: In this window, you configure the interface that connects the Gaia computer to the Internet.
Configure IPv4 Select how the applicable interface gets its IPv4 address:
n Manually - You configure the IPv4 settings in the next fields.
n Off - None.
Configure IPv6 Optional. Select how the applicable interface gets its IPv6 address:
n Manually - You configure the IPv6 settings in the next fields.
n Off - None.
In this window, you configure the Host name, the DNS servers and the Proxy server on the Gaia
computer.
Field Description
Primary DNS Server Enter the applicable IPv4 address of the primary DNS server.
Secondary DNS Optional: Enter the applicable IPv4 address of the secondary DNS server.
Server
Tertiary DNS Server Optional: Enter the applicable IPv4 address of the tertiary DNS server.
Use a Proxy server Optional: Select this option to configure the applicable Proxy server.
Address Enter the applicable IPv4 address or resolvable hostname of the Proxy
server.
In this window, you configure the date and time settings on the Gaia computer.
Field Description
Set the time manually Select this option to configure the date and time settings manually.
Use Network Time Select this option to configure the date and time settings automatically
Protocol (NTP) with NTP.
Primary NTP server Enter the applicable IPv4 address or resolvable hostname of the
primary NTP server.
Version Select the version of the NTP for the primary NTP server.
Secondary NTP server Optional: Enter the applicable IPv4 address or resolvable hostname of
the secondary NTP server.
Version Select the version of the NTP for the secondary NTP server.
In this window, you select which type of Check Point products you wish to install on the Gaia computer.
Field Description
Products window
In this window, you continue to select which type of Check Point products you wish to install on the Gaia
computer.
n If in the Installation Type window, you selected Security Gateway and/or Security
Management, these options appear:
Field Description
l A Cluster Member.
l A Standalone.
Availability.
l An Endpoint Security Management Server.
l CloudGuard Controller.
l 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:
l ClusterXL - For a cluster of dedicated Security Gateways, or
l CloudGuard Controller.
Availability.
Select Log Server / SmartEvent only to install:
l A dedicated single Log Server.
n If in the Installation Type window, you selected Multi-Domain Server, these options appear:
Field Description
Field Description
Multi-Domain Log Select this option to install a dedicated single Multi-Domain Log
Server Server.
In this window, you select if this Security Gateway gets its IP address dynamically (DAIP gateway).
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.
In this window, you configure a one-time Activation Key. You must enter this key later in SmartConsole
when you create the corresponding object and initialize SIC.
Field Description
Activation Key Enter one-time activation key (between 4 and 127 characters long).
Confirm Activation Key Enter the same one-time activation key again.
In this window, you configure the main administrator for this Security Management Server.
Use Gaia Select this option, if you wish to use the default Gaia administrator
administrator: admin (admin).
Define a new Select this option, if you wish to configure an administrator username
administrator and password manually.
In this window, you configure which computers are allowed to connect with SmartConsole to this
Security Management Server.
Field Description
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.
In this window, you select the main Leading VIP Interface on this Multi-Domain Server.
Field Description
In this window, you configure which computers are allowed to connect with SmartConsole to this Multi-
Domain Server.
Field Description
In this window, you can see the installation options you selected.
The Improve product experience section:
n By default, the option Send data to Check Point is enabled. For information about this option,
see sk111080.
n By default, the option Send crash data to Check Point that might contain personal data is
disabled.
If you enable this option, Gaia operating system uploads the detected core dump files to Check
Point Cloud.
This lets Check Point R&D analyze the crashes and issue fixes for them.
Notes:
n 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.
n 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.
n To make sure the configuration is finished:
1. Connect to the command line on the Gaia computer.
2. Log in to the Expert mode.
3. Check that the bottom section of the /var/log/ftw_install.log file contains one of
these sentences:
l installation succeeded
l FTW: Complete
Run:
Example outputs:
l From a Security Gateway or Cluster Member:
Notes:
n The config_system utility is not an interactive configuration tool. It helps
automate the first time configuration process.
n The config_system utility is only for the first time configuration, and not for
ongoing system configurations.
Syntax
n To list the command options, run one of these:
Form Command
n To run the First Time Configuration Wizard from a specified configuration file, run one of these:
Form Command
n To run the First Time Configuration Wizard from a specified configuration string, run one of these:
Form Command
n To create a First Time Configuration Wizard Configuration file template in a specified path, run one
of these:
Form Command
config_system --dry-run
Form Command
St
Description
ep
Step Description
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.
Step Description
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 the "config_system --help" command to see the available
parameters.
Table: The 'config_system' parameters
Parameter Description Valid values
upload_ Uploads data that helps Check Point provide you n true
info with optimal services, if its value is set to "true". n false
For more information, see sk94509.
mgmt_gui_ Specifies the first address of the range, if the value Single IPv4 address of a host.
clients_ of the "mgmt_gui_clients_radio" parameter Example:
first_ip_ is set to "range". 192.168.0.10
field
mgmt_gui_ Specifies the last address of the range, if the value Single IPv4 address of a host.
clients_ of the "mgmt_gui_clients_radio" parameter Example:
last_ip_ is set to "range". 192.168.0.20
field
mgmt_gui_ Specifies the network address, if the value of the IPv4 address of a network.
clients_ "mgmt_gui_clients_radio" parameter is set Example:
ip_field to "network". 192.168.0.0
mgmt_gui_ Specifies the netmask, if the value of the "mgmt_ A number from 1 to 32.
clients_ gui_clients_radio" parameter is set to
subnet_ "network".
field
mgmt_gui_ Specifies the netmask, if value of the "mgmt_gui_ Single IPv4 address of a host.
clients_ clients_radio" parameter is set to "this". Example:
hostname 192.168.0.15
ipaddr_v4 Configures the IPv4 address of the management Single IPv4 address.
interface.
masklen_v4 Configures the IPv4 mask length for the A number from 0 to 32.
management interface.
default_ Specifies IPv4 address of the default gateway. Single IPv4 address.
gw_v4
ipstat_v6 Turns static IPv6 configuration on, if its value is set n manually
to "manually". n off
ipaddr_v6 Configures the IPv6 address of the management Single IPv6 address.
interface.
masklen_v6 Configures the IPv6 mask length for the A number from 0 to 128.
management interface.
default_ Specifies IPv6 address of the default gateway. Single IPv6 address.
gw_v6
hostname Configures the name of the local host (optional). A string of alphanumeric
characters.
domainname Configures the domain name (optional). Fully qualified domain name.
Example:
somedomain.com
proxy_ Configures the IP address of the proxy server IPv4 address, or Hostname.
address (optional).
proxy_port Configures the port number of the proxy server A number from 1 to 65535.
(optional).
You can change the IP address of the Gaia Management Interface after you run the Gaia First Time
Configuration Wizard.
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.
Step Description
To see the size of the system-root and log partitions on an installed system:
Step Description
3 Run:
df -h
Note - Most of the remaining space on the disk is reserved for backup images and upgrades.
Step Description
Step Instructions
2 From the navigation tree, click System Management > System Configuration.
4 Click Apply .
Step Instructions
5 Reboot:
reboot
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
1. In the Products section, select Security Management only.
2. In the Clustering section, in the Define Security Management as field, select
Primary .
n In the Security Management GUI Clients window, configure the applicable allowed
computers:
l Any IP Address - Allows all computers to connect.
connect.
Step Description
Step Description
6 Click OK.
Step Description
3 Select When disk space is below < number> Mbytes, start deleting old files .
5 Click OK.
Step Description
Important - You must use the same Gaia installation version as you used for
the Primary Security Management Server.
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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 .
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
3 Create a new Check Point Host object that represents the Secondary Security
Management Server in one of these ways:
n From the top toolbar, click the New ( > More > Check Point Host.
n In the top left corner, click Objects menu > More object types > Network
Object > Gateways & Servers > New Check Point Host.
n In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Check Point Host.
Step Description
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
3 Select When disk space is below < number> Mbytes, start deleting old files .
5 Click OK.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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 .
n In the Security Management Administrator window, select one of these
options:
l Use Gaia administrator
connect.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
1 Connect with SmartConsole to the Security Management Server that works with this
Log Server or SmartEvent Server.
3 Create a new Check Point Host object that represents the dedicated Log Server or
SmartEvent Server in one of these ways:
n From the top toolbar, click the New ( ) > More > Check Point Host.
n In the top left corner, click Objects menu > More object types > Network
Object > Gateways & Servers > New Check Point Host.
n In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Check Point Host.
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.
11 Click OK.
12 In the SmartConsole top left corner, click Menu > Install database.
Step Description
14 Click Install .
15 Click OK.
Step Description
3 Select When disk space is below < number> Mbytes, start deleting old files .
5 Click OK.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Multi-Domain Server.
n In the Installation Type window, select Primary Multi-Domain Server.
n In the Leading VIP Interfaces Configuration window, select the applicable
interface.
n In the Multi-Domain Server GUI Clients window, select one of these options:
l Any host to allow all computers to connect
computer
n In the Security Management Administrator window, select one of these
options:
l Use Gaia administrator
Step Description
Step Description
Important - You must use the same Gaia installation version as you used for
the Primary Multi-Domain Server.
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Multi-Domain Server.
n In the Installation Type window, select Secondary Multi-Domain Server.
n In the Leading VIP Interfaces Configuration window, select the applicable
interface.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
1 Connect with SmartConsole to the Primary Multi-Domain Server - the MDS context.
2 From the left navigation panel, click Multi Domain > Domains .
Step Description
7 Enter the same Activation Key you entered during the setup of First Time
Configuration Wizard of the Secondary Multi-Domain Server.
8 Click OK.
14 Click OK.
Notes:
n 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.
n 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).
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Multi-Domain Server.
n In the Installation Type window, select Multi-Domain Log Server.
n In the Leading VIP Interfaces Configuration window, select the applicable
interface.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
1 Connect with SmartConsole to the Primary Multi-Domain Server - the MDS context.
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
16 Click OK.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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 .
n In the Security Management GUI Clients window, configure the applicable
allowed computers:
l Any IP Address - Allows all computers to connect.
connect.
Step Description
Step Description
6 Click OK.
7 In the SmartConsole top left corner, click Menu > Install database.
9 Click Install .
10 Click OK.
Step Description
Important - You must use the same Gaia installation version as you used for
the Primary Endpoint Security Management Server.
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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 .
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
Step Description
3 Create a new Check Point Host object that represents the Secondary Endpoint
Security Management Server in one of these ways:
n From the top toolbar, click the New ( > More > Check Point Host.
n In the top left corner, click Objects menu > More object types > Network
Object > Gateways & Servers > New Check Point Host.
n In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Check Point Host.
6 In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses.
10 Establish the Secure Internal Communication (SIC) between the Primary Endpoint
Security Management Server and the Secondary Endpoint 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 Endpoint 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 .
17 Make sure the Endpoint Security Management Servers are able to synchronize.
Follow the installation step instructions in "Installing a Dedicated Log Server or SmartEvent
Server" on page 68.
Step Description
3 Create a new Check Point Host object that represents the Endpoint Policy Server in
one of these ways:
n From the top toolbar, click the New ( ) > More > Check Point Host.
n In the top left corner, click Objects menu > More object types > Network
Object > Gateways & Servers > New Check Point Host.
n In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Check Point Host.
6 In the IPv4 Address and IPv6 Address fields, enter the applicable IP addresses.
8 On the Management tab, select both the Endpoint Policy Management and Logging
& Status Software Blades.
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.
l Management API Web Services (see Check Point Management API Reference)
n When you disable the Endpoint Policy Management Software Blade on a Security Management
Server, the SSL connection port automatically changes back to the default TCP port 443.
2 GB or more Client files (each additional version of client packages requires 1 GB of disk space).
1 GB Logs.
Note - To make future upgrades easier, we recommend that you use a larger disk size
than necessary in this deployment.
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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 .
n In the Security Management GUI Clients window, configure the applicable
allowed computers:
l Any IP Address - Allows all computers to connect.
connect.
Step Description
3 Run:
cloudguard on
Enable the Identity Awareness Software Blade on the applicable Security Gateways.
Installing SmartConsole
SmartConsole is a GUI client you use to manage the Check Point environment.
For SmartConsole requirements, see the R80.40 Release Notes.
Downloading SmartConsole
You can download the SmartConsole installation package in several ways:
Step Description
Step Description
2 Search for:
"R80.40 SmartConsole"
You can download the SmartConsole package from the Gaia Portal of your Security Management
Server or Multi-Domain Server.
Step Description
Installing SmartConsole
To install the SmartConsole client on Windows platforms:
Step Description
1 Transfer the SmartConsole installation file to a Windows-based computer you wish to use as a
SmartConsole Client.
Logging in to SmartConsole
Step Description
2 Enter the IP address or resolvable hostname of the Security Management Server, Multi-Domain
Server, or Domain Management Server.
The Management Server authenticates the connection when you log in for the first time.
Multiple administrators can log in at the same time.
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:
n 18190
n 18264
n 19009
For more information, see:
n sk52421: Ports used by Check Point software
n sk43401: How to completely disable FireWall Implied Rules
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select the applicable option.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
Step Description
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:
l Select Open server / Appliance for all Check Point appliance
10 Click OK.
Step Description
5 In the Name field, enter the applicable 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.
If this Security Gateway receives its IP addresses from a DHCP server, select
Dynamic Address .
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 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Open server.
b. In the Version field, select R80.40.
c. In the OS field, select Gaia.
10 Click OK.
3. Configure the applicable Security Policy for the Security Gateway in SmartConsole
Step Description
Step Description
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select the applicable option.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
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 applicable 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.40.
e. Click Next.
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. In SmartConsole, on the VSX Gateway General Properties page, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
7 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
applicable Virtual Network Device at this time (we recommend to do this later) -
Virtual Switch or Virtual Router.
b. Click Next.
Step Description
8 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.
13 Enable the applicable Software Blades for the VSX Gateway object itself (context of
VS0).
Refer to:
n sk79700: VSX supported features on R75.40VS and above
n sk106496: Software Blades updates on VSX R75.40VS and above - FAQ
n Applicable Administration Guides on the R80.40 Home Page.
Step Description
18 Configure the applicable Threat Prevention Policy for this VSX Gateway.
19 Install the applicable Threat Prevention Policy on the VSX Gateway object:
a. Click Install Policy .
b. In the Policy field, select the applicable Threat Prevention Policy for this VSX
Gateway object.
c. Click Install .
Step Description
3 Configure the applicable Access Control Policies for these Virtual Devices.
Step Description
6 Configure the applicable Threat Prevention Policies for these Virtual Devices.
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select Security Gateway only.
b. In the Clustering section, select these two options:
l Unit is a part of a cluster
l ClusterXL
You can configure the ClusterXL object in either Wizard Mode, or Classic Mode.
Step Description
Network Object > Gateways and Servers > Cluster > New Cluster.
l In the top right corner, click Objects Pane > New > More > Network
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 applicable 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.
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
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:
l 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.
l For cluster synchronization interfaces, select Cluster
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
For more information, click the (?) button in the top right
corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right
corner.
Step Description
Cluster Virtual IPv4 address and its Net Mask are correct.
l For cluster synchronization interfaces, select Sync or
Zone fields.
l Make sure to enable the Anti-Spoofing.
15 Click OK.
Step Description
Network Object > Gateways and Servers > Cluster > New Cluster.
l In the top right corner, click Objects Pane > New > More > Network
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
For more information, click the (?) button in the top right
corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right
corner.
Step Description
Cluster Virtual IPv4 address and its Net Mask are correct.
l For cluster synchronization interfaces, select Sync or
Zone fields.
l Make sure to enable the Anti-Spoofing.
11 Click OK.
3. Configure the applicable Access Control policy for the ClusterXL in SmartConsole
Step Description
4 Configure and install the applicable Access Control Policy on the ClusterXL object.
5 Configure and install the applicable Threat Prevention Policy on the ClusterXL object.
Step Description
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select Security Gateway only.
b. In the Clustering section, select these two options:
l Unit is a part of a cluster
l ClusterXL
Note - The steps below are for the Dedicated Management Interfaces (DMI)
configuration. For the non-DMI configuration, see the R80.40 VSX
Administration Guide.
Step Description
Step Description
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 applicable 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.40.
e. In the Select the VSX Cluster Platform field, select the applicable VSX Cluster
mode:
n ClusterXL (for High Availability)
n ClusterXL Virtual System Load Sharing
f. Click Next.
5 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 applicable 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
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. In SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, 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
applicable 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
Step Description
set virtual-system 0
show cluster state
n In the Expert mode, run:
vsenv 0
cphaprob state
Important:
n All VSX Cluster Members must show the same information
about the states of all VSX Cluster Members.
n One VSX Cluster Member must be in the Active state, and all
other VSX Cluster Members must be in Standby state.
n All Virtual Systems must show the same information about the
states of all Virtual Systems.
d. Examine the cluster interfaces in one of these ways:
n In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
n In the Expert mode, run:
vsenv 0
cphaprob -a if
Step Description
3 Configure the applicable Access Control and Threat Prevention Policies for these
Virtual Devices.
Step Description
set virtual-system 0
show cluster state
n In the Expert mode, run:
vsenv 0
cphaprob state
Important:
n All VSX Cluster Members must show the same information
about the states of all VSX Cluster Members.
n One VSX Cluster Member must be in the Active state, and all
other VSX Cluster Members must be in Standby state.
n All Virtual Systems must show the same information about the
states of all Virtual Systems.
d. Examine the cluster interfaces in one of these ways:
n In Gaia Clish, run:
set virtual-system 0
show cluster members interfaces all
n In the Expert mode, run:
vsenv 0
cphaprob -a if
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select Security Gateway only.
b. In the Clustering section, select these two options:
l Unit is a part of a cluster
l VRRP Cluster
5 On Gaia, VRRP can be used with ClusterXL enabled or with ClusterXL disabled.
See the R80.40 Gaia Administration Guide - Chapter High Availability for more
information.
If it is necessary to configure VRRP with ClusterXL enabled, then:
a. When prompted to reboot, click Cancel .
b. Connect to the command line.
c. Run:
cpconfig
d. Select Enable cluster membership for this gateway to enable State
synchronization.
Enter y when prompted.
e. Exist from the cpconfig menu.
6 Reboot.
2. Perform the initial VRRP configuration in Gaia on the VRRP Cluster Members
Step Description
Network Object > Gateways and Servers > Cluster > New Cluster.
l In the top right corner, click Objects Pane > New > More > Network
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 applicable 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 Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
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:
l 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.
l For cluster synchronization interfaces, select Cluster
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
Members IP Addresses
For more information, click the (?) button in the top right corner.
Cluster Virtual IPv4 address and its Net Mask are correct.
l For cluster synchronization interfaces, select Sync or
Zone fields.
l Make sure to enable the Anti-Spoofing.
15 Click OK.
Step Description
Network Object > Gateways and Servers > Cluster > New Cluster.
l In the top right corner, click Objects Pane > New > More > Network
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
Members IP Addresses
For more information, click the (?) button in the top right corner.
Cluster Virtual IPv4 address and its Net Mask are correct.
l For cluster synchronization interfaces, select Sync or
Zone fields.
l Make sure to enable the Anti-Spoofing.
11 Click OK.
Ste
Description
p
If the VRRP Cluster Members use dynamic routing protocols (such as OSPF or RIP),
create new rules for each multicast destination IP address.
Alternatively, you can create a Network object to represent all multicast network IP
destinations:
n Name: MCAST.NET (this is an example name)
n IP Address: 224.0.0.0
n Net mask: 240.0.0.0
You can use one rule for all multicast protocols you agree to accept, as shown in this
example:
Services &
N Nam Sourc Destinatio VP Actio Trac Instal
Application
o e e n N n k l On
s
Ste
Description
p
7 Configure and install the applicable Threat Prevention Policy on the VRRP Cluster
object.
Step Description
show vrrp
n In the Expert mode, run:
clish -c "show vrrp"
Important - You can deploy and configure a Full High Availability Cluster only on Check
Point Appliances that support Standalone configuration. See the R80.40 Release
Notes and "Installing a Standalone" on page 143.
This deployment lets you reduce the maintenance required for your systems.
In the image below, the appliances are denoted as (1) and (3).
The two appliances are connected with a direct synchronization connection (2) and work in High
Availability mode:
n The Security Management Server on one appliance (for example, 1) runs as Primary, and the
Security Management Server on the other appliance (3) runs as Secondary.
n The ClusterXL on one appliance (for example, 1) runs as Active, and the ClusterXL on the other
appliance (3), runs as Standby.
n The ClusterXL Cluster Members synchronize the information about the traffic over the
synchronization connection (2).
For information on ClusterXL functionality, see the R80.40 ClusterXL Administration Guide.
For information on Security Management Servers, see the R80.40 Security Management Administration
Guide.
Important - SmartEvent Server is not supported in Management High Availability and
Full High Availability Cluster environments (sk25164). For these environments, install a
Dedicated SmartEvent Server (see "Installing a Dedicated Log Server or SmartEvent
Server" on page 68).
1. Install the first Cluster Member of the Full High Availability Cluster that runs the
Primary Security Management Server
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select both Security Gateway and Security
Management.
b. In the Clustering section:
l Clear Unit is a part of a cluster, type.
connect
6 In the left navigation tree, click Network Management > Network Interfaces .
Configure all required interfaces with applicable unique IP addresses.
2. Install the second Cluster Member of the Full High Availability Cluster that runs the
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select both Security Gateway and Security
Management.
b. In the Clustering section:
l Clear Unit is a part of a cluster, type.
6 In the left navigation tree, click Network Management > Network Interfaces .
Configure all required interfaces with applicable unique IP addresses.
Step Description
3 In the left navigation tree, click Network Management > Network Interfaces .
Step Description
Step Description
1 Connect with SmartConsole to the Cluster Member that runs the Primary Security
Management Server.
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.
8 Click Next.
10 Click Finish.
Step Description
Note - You can also control the Full High Availability Cluster Members in Gaia Portal >
High Availability > Cluster page.
Best Practice - We recommend that you install a dedicated Log Server and configure
the Cluster Members to forward their logs to that dedicated Log Server.
Step Description
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.
Installing a Standalone
In a Standalone deployment, a Check Point computer runs both the Security Gateway and Security
Management Server products.
Important:
n These instructions apply only to Check Point Appliances that support a Standalone
deployment.
n These instructions apply to all Open Servers.
n These instructions apply to Virtual Machines.
See the R80.40 Release Notes for the requirements for a Standalone deployment.
These methods are available to configure a Standalone deployment:
This method is supported on Check Point appliances (that support a Standalone deployment), Open
Servers, and Virtual Machines that meet the requirements listed in the R80.40 Release Notes.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select both Security Gateway and Security
Management.
b. In the Clustering section:
l Clear Unit is a part of a cluster, type.
range to connect
Step Description
Step Description
7 Click OK.
3. Configure the applicable Access Control policy for the Standalone in SmartConsole
Step Description
This method is supported only on Check Point appliances that support a Standalone deployment.
This method 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.
Post-Installation Configuration
After the installation is complete, and you rebooted the Check Point computer:
n Configure the applicable settings in the Check Point Configuration Tool.
n Check the recommended and available software packages in CPUSE (see "Installing Software
Packages on Gaia" on page 153).
The Check Point Configuration Tool lets you configure these settings:
Check Point
Commands Available Configuration Options
computer
(9) Exit
(13) Exit
Check Point
Commands Available Configuration Options
computer
(11) Exit
For more information, see the R80.40 Security Management Administration Guide.
Note - The options shown depend on the configuration and installed products.
Licenses and Manages Check Point licenses and contracts on this server.
contracts
GUI Clients Configures the GUI clients that can use SmartConsole to connect to this
server.
Random Pool Configures the RSA keys, to be used by Gaia Operating System.
Certificate Authority Initializes the Internal Certificate Authority (ICA) and configures the
Certificate Authority's (CA) Fully Qualified Domain Name (FQDN).
Automatic start of Shows and controls which of the installed Check Point products start
Check Point automatically during boot.
Products
For more information, see the R80.40 Multi-Domain Security Management Administration Guide.
Leading VIP Interfaces The Leading VIP Interfaces are real interfaces connected to an
external network.
These interfaces are used when you configure virtual IP
addresses for Domain Management Servers.
Random Pool Configures the RSA keys, to be used by Gaia Operating System.
GUI Clients Configures the GUI clients that can use SmartConsole to
connect to this server.
Automatic Start of Multi- Shows and controls if Multi-Domain Server starts automatically
Domain Server during boot.
Start Multi-Domain Server Configures a password to control the start of the Multi-Domain
Password Server.
IPv6 Support for Multi-Domain Enables or disables the IPv6 Support on the Multi-Domain
Server Server.
IPv6 Support for Existing Enables or disables the IPv6 Support on the Domain
Domain Management Servers Management Servers.
Note - The options shown depend on the configuration and installed products.
Licenses and contracts Manages Check Point licenses and contracts on this Security
Gateway or Cluster Member.
Secure Internal Communication Manages SIC on the Security Gateway or Cluster Member.
This change requires a restart of Check Point services on the
Security Gateway or Cluster Member.
For more information, see:
n The R80.40 Security Management Administration
Guide.
n sk65764: How to reset SIC.
Enable cluster membership for Enables the cluster membership on the Security Gateway.
this gateway This change requires a reboot of the Security Gateway.
For more information, see the R80.40 ClusterXL
Administration Guide.
Disable cluster membership for Disables the cluster membership on the Security Gateway.
this gateway This change requires a reboot of the Security Gateway.
For more information, see the R80.40 ClusterXL
Administration Guide.
Enable Check Point Per Virtual Enables Virtual System Load Sharing on the VSX Cluster
System State Member.
For more information, see the R80.40 VSX Administration
Guide.
Disable Check Point Per Disables Virtual System Load Sharing on the VSX Cluster
Virtual System State Member.
For more information, see the R80.40 VSX Administration
Guide.
Enable Check Point ClusterXL Enables Check Point ClusterXL for Bridge mode.
for Bridge Active/Standby This change requires a reboot of the Cluster Member.
For more information, see the R80.40 ClusterXL
Administration Guide.
Disable Check Point ClusterXL Disables Check Point ClusterXL for Bridge mode.
for Bridge Active/Standby This change requires a reboot of the Cluster Member.
For more information, see the R80.40 ClusterXL
Administration Guide.
Check Point CoreXL Manages CoreXL on the Security Gateway or Cluster Member.
After all changes in CoreXL configuration, you must reboot the
Security Gateway or Cluster Member.
For more information, see the R80.40 Performance Tuning
Administration Guide.
Automatic start of Check Point Shows and controls which of the installed Check Point products
Products start automatically during boot.
You use the CPUSE on each Gaia computer to install the applicable packages.
For more information, see sk92449.
n If a Gaia computer is connected to the Internet
Installation
Action Plan
Method
Online 1. Connect to the Gaia Portal or Gaia Clish on your Gaia computer.
2. Verify the applicable CPUSE Software Packages.
3. Download the applicable CPUSE Software Packages.
4. Install the applicable CPUSE Software Packages.
Offline See the instructions for a Gaia computer that is not connected to the
Internet.
l Upgrade Wizard
l Upgrade Wizard
Important:
When you perform an upgrade to R80.40 with CPUSE from R80.20.M1, R80.20,
R80.20.M2, or R80.30, you can see the upgrade report in Gaia Portal:
1. From the left navigation tree, click Upgrades (CPUSE) > Status and
Actions .
2. In the Major Versions section, select the R80.40 Upgrade package.
3. In the right pane Package Details , click the link To see a detailed upgrade
report.
4. A pop up opens and shows the upgrade progress in real time.
The report supports only these configurations:
n Security Management Servers
n Endpoint Security Management Servers
n CloudGuard Controllers
n Multi-Domain Servers
n Log Servers
n Endpoint Policy Servers
n Multi-Domain Log Servers
n Standalone Servers
You use the Central Deployment Tool on the Management Server to deploy the applicable packages
to the applicable managed Security Gateways and Clusters.
For more information, see sk111158.
Note - You can use the Upgrade/Download Wizard to download the applicable
installation and upgrade images.
Procedure
1. Connect to the Management Server that manages the R7x Security Gateway or Cluster
2. Add a new explicit Firewall rule:
3. Install the modified Firewall Policy on the R7x Security Gateway or Cluster.
4. If later you upgrade this R7x Security Gateway or Cluster to R80.10 or higher, delete this
explicit rule.
l $FWDIR/lib/
l $FWDIR/conf/
l $CVPNDIR/conf/
l /opt/CP*/lib/
l /opt/CP*/conf/
l $MDSDIR/conf/
l $MDSDIR/customers/<Name_of_Domain>/CP*/lib/
l $MDSDIR/customers/<Name_of_Domain>/CP*/conf/
n For your Management Servers in High Availability configuration, plan the upgrade.
Upgrade to
Action Plan
R80.40
From R80.20, 1. Make sure to run Pre-Upgrade Verifier on all source servers and
R80.20.M2, to fix all detected issues before you start the upgrade.
and higher 2. Make sure the Global Domain is Active on the Primary Multi-Domain
versions Server.
3. Upgrade the Primary Multi-Domain Server.
4. Upgrade the Secondary Multi-Domain Server.
Important - 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.
From 1. Make sure to run Pre-Upgrade Verifier on all source servers and
R80.20.M1 to fix all detected issues before you start the upgrade.
version 2. Make sure the Global Domain is Active on the Primary Multi-Domain
Server.
3. Upgrade the Primary Multi-Domain Server.
4. Perform a clean install of the Secondary Security Management
Server.
Important - 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.
5. Connect the Secondary Multi-Domain Server to the Primary Multi-
Domain Server.
From R7X or l If the Primary Multi-Domain Server is not available at this time, you
R80.10 must first promote the Secondary Multi-Domain Server to be the
versions Primary.
n If your Security Management Server or Multi-Domain Server manages dedicated Log Servers or
dedicated SmartEvent Servers, you must upgrade these dedicated servers to the same version as
the Management Server.
Important - You must upgrade your Management Servers before you can
upgrade these dedicated servers.
Note - SmartEvent Server can run the same version or higher than the Log Server.
n If your Multi-Domain Server manages Multi-Domain Log Servers, you must upgrade the Multi-
Domain Log Servers to the same version as the Multi-Domain Server.
Important - You must upgrade your Multi-Domain Servers before you can
upgrade the Multi-Domain Log Servers.
n Before you upgrade a Multi-Domain Server, we recommend the steps below to optimize the
upgrade process.
Procedure
Step Description
n 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.
n Before you start an upgrade of your Security Gateway and Cluster Members, you must upgrade the
Management Server.
n 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.
Note - On VSX Gateway and VSX Cluster Member, some of these directories
exist in the context of each Virtual Device.
l $FWDIR/boot/modules/
l $FWDIR/conf/
l $FWDIR/lib/
l $FWDIR/database/
l $CVPNDIR/conf/
l $PPKDIR/boot/modules/
l /var/ace/
l $FWDIR/boot/modules/fwkern.conf
l $FWDIR/boot/modules/vpnkern.conf
l $FWDIR/conf/fwaffinity.conf
l $FWDIR/conf/fwauthd.conf
l $FWDIR/conf/local.arp
l $FWDIR/conf/discntd.if
l $FWDIR/conf/cpha_bond_ls_config.conf
l $FWDIR/conf/resctrl
l $FWDIR/conf/vsaffinity_exception.conf
l $FWDIR/database/qos_policy.C
l simkern.conf:
o In R80.20 and higher: $PPKDIR/conf/simkern.conf
o In R80.10 and lower: $PPKDIR/boot/modules/simkern.conf
l sim_aff.conf:
o In R80.20 and higher: $PPKDIR/conf/sim_aff.conf
o In R80.10 and lower: $PPKDIR/boot/modules/sim_aff.conf
l $CPDIR/tmp/.CPprofile.sh
l $CPDIR/tmp/.CPprofile.csh
l /var/ace/sdconf.rec
l /var/ace/sdopts.rec
l /var/ace/sdstatus.12
l /var/ace/securid
l $FWDIR/boot/modules/fwkern.conf
l $FWDIR/boot/modules/vpnkern.conf
l $FWDIR/conf/fwaffinity.conf
l $FWDIR/conf/fwauthd.conf
l $FWDIR/conf/local.arp
l $FWDIR/conf/discntd.if
l $FWDIR/conf/cpha_bond_ls_config.conf
l $FWDIR/conf/resctrl
l $FWDIR/conf/vsaffinity_exception.conf
l $FWDIR/database/qos_policy.C
l simkern.conf:
o In R80.20 and higher: $PPKDIR/conf/simkern.conf
o In R80.10 and lower: $PPKDIR/boot/modules/simkern.conf
l sim_aff.conf:
o In R80.20 and higher: $PPKDIR/conf/sim_aff.conf
o In R80.10 and lower: $PPKDIR/boot/modules/sim_aff.conf
l /var/ace/sdconf.rec
l /var/ace/sdopts.rec
l /var/ace/sdstatus.12
l /var/ace/securid
Prerequisites:
n Make sure you use the latest version of this document (see the "Important Information" on page 3
page for links).
n See the R80.40 Release Notes for:
l Supported upgrade paths
l Minimum hardware and operating system requirements
l Supported Security Gateways
n Make sure to read all applicable known limitations in the R80.40 Known Limitations SK.
n Before starting an upgrade of your Security Gateway and Cluster Members, you must upgrade the
Management Server.
n Licenses and Service Contracts:
l Make sure you have valid licenses installed on all applicable Check Point computers - source
and target.
l Make sure you have a valid Service Contract that includes software upgrades and major
releases registered to your Check Point User Center account.
The contract file is stored on the Management Server and downloaded to Check Point
Security Gateways during the upgrade process.
For more information about Service Contracts, see sk33089.
Procedure:
Step Description
1 Open these files on the Management Server and write down all custom changes in the
applicable files:
n Apache configuration:
$CVPNDIR/conf/httpd.conf
$CVPNDIR/conf/includes/*
Step Description
n Local certificates:
$CVPNDIR/var/ssl/ca-bundle/*
n RSA configuration:
/var/ace/sdconf.rec
n Mobile Access Gaia Portal configuration (run these commands in the 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.40 using one of the supported methods (see
"Upgrade Methods" on page 167).
4 Manually edit the default files on the upgraded the Management Server to include your custom
changes.
Step Description
2 See the R80.40 CloudGuard Controller Administration Guide for a list of supported Security
Gateways.
3 When you upgrade a vSEC Controller R80.10 and lower to CloudGuard Controller R80.40,
these files are overwritten with default values:
n $MDS_FWDIR/conf/vsec.conf
n $MDS_FWDIR/conf/tagger_db.C
n $MDS_FWDIR/conf/AWS_regions.conf
Before you begin the upgrade, back up all files you changed in the past.
4 Before you begin the upgrade on a vSEC Controller R80.10 and lower, if you have a Cisco APIC
server, keep only one URL.
After the upgrade, add the other URLs.
Note - During the upgrade, vSEC Controller R80.10 and lower does not communicate
with the Data Centers. Therefore, Data Center objects are not updated on the vSEC
Controller or the Security Gateways.
Upgrade Methods
You can use this method to upgrade your Security Gateways and Cluster Members:
Gateway CPUSE
You can use these methods to upgrade your Management Servers and Log Servers:
Important:
n Upgrade with CPUSE is supported only on Check Point computers that currently
run Gaia Operating System.
n Before you upgrade your Security Gateways and Cluster Members, you must
upgrade your Management Servers that manage them.
n 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.
n You must upgrade your Multi-Domain Log Servers to the same version as the
Multi-Domain Servers that manage them.
n Gradual Upgrade is supported only from R7x versions.
n During the upgrade process in a Management High Availability environment, we
recommend that you do not use any of the Security Management Servers or
Multi-Domain Servers to make changes in the management databases.
This can cause inconsistent synchronization between these servers.
With CPUSE, you can install software packages to upgrade or to perform a clean install on Check Point
computers that run on the Gaia Operating System.
For more about CPUSE, see sk92449.
For detailed CPUSE upgrade instructions, see:
Upgrade
Section in this Guide
From
R80.30, n "Upgrading a Security Management Server or Log Server from R80.20 and
R80.20.M2, higher with CPUSE" on page 238
R80.20, n "Upgrading one Multi-Domain Server from R80.20 and higher" on page 297
R80.20.M1 n "Upgrading Multi-Domain Servers in High Availability from R80.20 and higher"
on page 355
n "Upgrading a Multi-Domain Log Server from R80.20 and higher with CPUSE"
on page 431
n "Upgrading an Endpoint Security Management Server or Endpoint Policy
Server from R80.20 and higher with CPUSE" on page 501
Upgrade
Section in this Guide
From
R80.10 n "Upgrading a Security Management Server from R80.10 and lower with
and lower CPUSE" on page 178
n "Upgrading an Endpoint Security Management Server from R80.10 and lower
with CPUSE" on page 457
n "Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with
CPUSE" on page 483
n "Upgrading a Dedicated Log Server from R80.10 and lower with CPUSE" on
page 204
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower with
CPUSE" on page 221
n "Upgrading one Multi-Domain Server from R80.10 and lower" on page 263
n "Upgrading Multi-Domain Servers in High Availability from R80.10 and lower
with CPUSE" on page 320
n "Upgrading a Multi-Domain Log Server from R80.10 and lower with CPUSE"
on page 407
n "Upgrading a Security Gateway with CPUSE" on page 528
n "Upgrading a VSX Gateway with CPUSE" on page 532
Note - When you perform an upgrade to R80.40 with CPUSE from R80.20.M1,
R80.20, R80.20.M2, or R80.30, you can see the upgrade report in Gaia Portal. See
"Installing Software Packages on Gaia" on page 153.
In an advanced upgrade scenario, perform these steps on the same Check Point computer:
Step Description
1 Take a full backup and snapshot of the current Check Point computer.
2 Export the entire management database with the R80.40 Management Server Migration
Tool.
Upgrade
Section in this Guide
From
R80.30, n "Upgrading a Security Management Server or Log Server from R80.20 and
R80.20.M2, higher with Advanced Upgrade" on page 242
R80.20, n "Upgrading one Multi-Domain Server from R80.20 and higher with Advanced
R80.20.M1 Upgrade" on page 303
n "Upgrading Multi-Domain Servers in High Availability from R80.20 and higher
with Advanced Upgrade" on page 363
n "Upgrading a Multi-Domain Log Server from R80.20 and higher with
Advanced upgrade" on page 437
n "Upgrading an Endpoint Security Management Server or Endpoint Policy
Server from R80.20 and higher with Advanced Upgrade" on page 506
R80.10 n "Upgrading a Security Management Server from R80.10 and lower with
and lower Advanced Upgrade" on page 181
n "Upgrading an Endpoint Security Management Server from R80.10 and lower
with Advanced Upgrade" on page 460
n "Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with
Advanced Upgrade" on page 487
n "Upgrading a Dedicated Log Server from R80.10 and lower with Advanced
Upgrade" on page 208
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower with
Advanced Upgrade" on page 225
n "Upgrading one Multi-Domain Server from R80.10 and lower with Advanced
Upgrade" on page 268
n "Upgrading Multi-Domain Servers in High Availability from R80.10 and lower
with Advanced Upgrade" on page 325
n "Upgrading a Multi-Domain Log Server from R80.10 and lower with Advanced
Upgrade" on page 412
In a migration and upgrade scenario, perform these steps on the source Check Point computer and the
different target Check Point computer:
Step Description
1 Export the entire management database from the source Check Point computer with the
R80.40 Management Server Migration Tool.
3 Import the entire management database on the new target R80.40 Check Point computer.
Upgrade
Section
From
R80.30, n "Upgrading a Security Management Server or Log Server from R80.20 and
R80.20.M2, higher with Migration" on page 250
R80.20, n "Upgrading one Multi-Domain Server from R80.20 and higher with Migration"
R80.20.M1 on page 311
n "Upgrading Multi-Domain Servers in High Availability from R80.20 and higher
with Migration" on page 384
n "Upgrading a Multi-Domain Log Server from R80.20 and higher with
Migration" on page 446
n "Upgrading an Endpoint Security Management Server or Endpoint Policy
Server from R80.20 and higher with Migration" on page 514
R80.10 n "Upgrading a Security Management Server from R80.10 and lower with
and lower Migration" on page 191
n "Upgrading an Endpoint Security Management Server from R80.10 and lower
with Migration" on page 470
n "Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower with
Migration" on page 494
n "Upgrading a Dedicated Log Server from R80.10 and lower with Migration" on
page 214
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower with
Migration" on page 231
n "Upgrading one Multi-Domain Server from R80.10 and lower with Migration"
on page 276
n "Upgrading Multi-Domain Servers in High Availability from R80.10 and lower
with Migration" on page 340
n "Upgrading a Multi-Domain Log Server from R80.10 and lower with Migration"
on page 421
In a gradual scenario, perform these steps on the source R7x Multi-Domain Server and the target
R80.40 Multi-Domain Server:
Step Description
2 Create the corresponding Domain Management Servers, into which you import the entire
management databases from the source R7x Domain Management Servers.
3 Migrate the Global Policy from the current R7x Multi-Domain Server to the R80.40 Multi-
Domain Server.
Step Description
4 On the current R7x Multi-Domain Server, export the entire management databases from the
applicable source R7x Domain Management Servers one by one with the R80.40
Management Server Migration Tool.
5 On the target R80.40 Multi-Domain Server, import the entire management databases to the
applicable target R80.40 Domain Management Servers one by one.
Best Practice - We recommend you upgrade the entire Multi-Domain Server at once.
For detailed gradual upgrade instructions, see "Upgrading one R7x Multi-Domain Server with Gradual
Migration of Domain Management Servers" on page 285.
Contract Verification
Before you upgrade your Management Server to R80.40, 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 a Contract File is not present, later you can download a Contract File manually from the Check Point User
Center and import it.
If a Contract File does not cover the Management Server, a message informs you that the Management
Server is not eligible for upgrade.
Important - The absence of a valid Contract File does not prevent upgrade.
Note - In most cases, you do not need to worry about your Service Contract File. Your
Management Server is configured to communicate with the User Center automatically,
and download the most current file. This allows the Management Server to enable the
purchased services properly.
You can download a valid Contract File later.
Option Description
Download a contract file If you have Internet access and a valid User Center account, download a
from the User Center Contract File directly from your User Center account:
Import a local contract file If the Management Server does not have Internet access:
Continue without contract Select this option, if you intend to get and install a valid Contract File later.
information Note that at this point your managed Security Gateways are not strictly
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.
Action items before Errors you must repair before the upgrade.
the upgrade Warnings of issues for you to decide whether to fix before upgrade.
An example of an error you must fix before the upgrade is an invalid policy name.
Action items after Errors and warnings that you must fix after the upgrade.
the upgrade
The most important files in the Management Server Migration Tool and Upgrade Tools packages:
Package Description
migrate Exports and imports the management database and applicable Check Point
migrate_server configuration.
For details, see the R80.40 CLI Reference Guide - Chapter Security
Management Server Commands:
n Section migrate.
n Section migrate_server.
Package Description
pre_upgrade_ Analyzes compatibility of the currently installed configuration with the version,
verifier to which you upgrade.
It gives a report on the actions to take before and after the upgrade.
Note - This tool is required only when you upgrade from R77.30 (and
lower) version to R80.40.
puv_report_ Runs at the end of pre_upgrade_verifier and converts the text report
generator file to an HTML file.
Note - This tool is required only when you upgrade from R77.30 (and
lower) version to R80.40.
Best Practice - Always run the Pre-Upgrade Verifier (PUV) on the source server
before the upgrade.
The 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.
The Pre-Upgrade Verifier can only verify a management database that is intended for upgrade to a
different major version (for example, from R77.xx to R80.40).
The Pre-Upgrade Verifier runs automatically during the upgrade process. You can also run it manually.
Run this command and use the applicable syntax based on the instructions on the screen:
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with CPUSE" on page 238.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
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:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
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 .
Step Description
6 Confirm.
8 Click Close.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export
the entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
9 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Important:
n If you upgrade from R80 (or higher) version to R80.40, then these
options are available:
l The IP addresses of the source and target Security
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Security
Management Server, to some directory.
Step Description
Notes:
n 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.40 Security Management
Server.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Security Management Servers
must be the same.
l If it is necessary to have a different IP address on the R80.40
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
6. Install the licenses and change the IP address of the R80.40 Security Management
Server
Scenario Instructions
You upgraded from R80 (or higher) version to Follow these steps:
R80.40, and the IP addresses of the source and a. Issue licenses for the new IP
target Security Management Servers are address in your Check Point User
different Center account.
b. Install the new licenses on the
R80.40 Security Management
Server.
Scenario Instructions
You upgraded from R77.30 (and lower) version Follow these steps (based on sk40993):
to R80.40 and need to have a different IP a. Issue licenses for the new IP
address on the R80.40 Security Management address in your Check Point User
Server Center account.
b. Perform the required changes in
the SmartConsole:
i. Connect with SmartConsole
to the Security Management
Server.
ii. From the left navigation
panel, click Gateways &
Servers .
iii. Open the Security
Management Server object.
iv. On the General Properties
page, change the current IP
address to the new IP
address.
v. On the Network
Management page, edit the
applicable interface and
change the current IP
address to the new IP
address.
vi. Click OK.
vii. Publish the SmartConsole
session.
viii. Close the SmartConsole.
c. Stop the Check Point services:
i. Connect to the command
line.
ii. Log in to either Gaia Clish, or
Expert mode.
iii. Run: cpstop
d. Perform the required changes in
Gaia OS:
i. Connect to either Gaia
Portal, or Gaia Clish.
ii. 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.40 Gaia
Administration Guide.
Scenario Instructions
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:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
Step Description
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Migration" on page 250.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export
the entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
9 Transfer the exported databases from the current Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Perform a clean install of the R80.40 Security Management Server on another computer.
Do not perform initial configuration in SmartConsole.
See "Installing a Security Management Server" on page 62.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 Security Management Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Security
Management Server, to some directory.
Notes:
n 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.40 Security Management
Server.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Security Management Servers
must be the same.
l If it is necessary to have a different IP address on the R80.40
Step Description
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
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:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
11. Disconnect the old Security Management Server from the network
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Step Description
1 Upgrade the Primary Security Management Server with one of the supported methods.
See "Upgrade Methods" on page 167.
2 Upgrade the Secondary Security Management Server with one of the supported methods.
See "Upgrade Methods" on page 167.
4 Connect with R80.40 SmartConsole to the R80.40 Primary Security Management Server.
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary
Security Management Server:
Step Description
Important - This step applies only if the SmartEvent Correlation Unit Software
Blade is enabled on the R80.40 Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide >
Chapter Log Exporter
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
Step Description
1 Upgrade the Primary Security Management Server with one of the supported methods.
See "Upgrade Methods" on page 167.
2 Perform a clean install of the R80.40 on the Secondary Security Management Server.
See "Installing a Secondary Security Management Server in Management High Availability"
on page 65.
4 Connect with R80.40 SmartConsole to the R80.40 Primary Security Management Server.
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary
Security Management Server:
Step Description
Important - This step applies only if the SmartEvent Correlation Unit Software
Blade is enabled on the R80.40 Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide >
Chapter Log Exporter
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with CPUSE" on page 238.
n To upgrade a dedicated SmartEvent Server, see "Upgrading a Dedicated
SmartEvent Server from R80.10 and lower with CPUSE" on page 221.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
3 Before you upgrade a dedicated Log Server, you must upgrade the applicable
Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Log
Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n To upgrade a dedicated SmartEvent Server, see "Upgrading a Dedicated
SmartEvent Server from R80.10 and lower with Advanced Upgrade" on
page 225.
3 Before you upgrade a dedicated Log Server, you must upgrade the applicable
Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Log
Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 Log Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Log Server,
to some directory.
Step Description
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n To upgrade a dedicated SmartEvent Server, see "Upgrading a Dedicated
SmartEvent Server from R80.10 and lower with Migration" on page 231.
3 Before you upgrade a dedicated Log Server, you must upgrade the applicable
Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Log
Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 Log Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Log Server,
to some directory.
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with CPUSE" on page 238.
n To upgrade a dedicated Log Server or Endpoint Policy Server, see "Upgrading a
Dedicated Log Server from R80.10 and lower with CPUSE" on page 204.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the
applicable Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the
SmartEvent Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n To upgrade a dedicated Log Server or Endpoint Policy Server, see "Upgrading a
Dedicated Log Server from R80.10 and lower with Advanced Upgrade" on
page 208.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the
applicable Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the
SmartEvent Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated SmartEvent Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 SmartEvent Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
4 Transfer the exported databases from an external storage to the R80.40 SmartEvent
Server, to some directory.
Step Description
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Migration" on page 250.
n To upgrade a dedicated Log Server or Endpoint Policy Server, see "Upgrading a
Dedicated Log Server from R80.10 and lower with Migration" on page 214.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
3 Before you upgrade a dedicated SmartEvent Server, you must upgrade the
applicable Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the
SmartEvent Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated SmartEvent Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 SmartEvent Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 SmartEvent
Server, to some directory.
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Security Management Server
l CloudGuard Controller
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
5. Update the object version of the dedicated Log Servers and SmartEvent Servers
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Security Management Server
l CloudGuard Controller
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export
Step Description
8 Transfer the exported databases from the source Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Security Management Server only, or Primary Security
Management Server in Management High Availability" on page 63.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Security
Management Server, to some directory.
Step Description
Important - This step applies only if the target R80.40 Security Management
Server has a different IP address than the source Security Management
Server.
Step Description
1 Issue licenses for the new IP address in your Check Point User Center account.
3 Wait for a couple of minutes for the Security Management Server to detect the new
licenses.
Alternatively, restart Check Point services:
cpstop
cpstart
9. Update the object version of the dedicated Log Servers and SmartEvent Servers
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Security Management Server, run the Pre-Upgrade Verifier and export
Step Description
8 Transfer the exported databases from the source Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Security Management Server only, or Primary Security
Management Server in Management High Availability" on page 63.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Security
Management Server, to some directory.
Step Description
Important - This step applies only if the target R80.40 Security Management
Server has a different IP address than the source Security Management
Server.
Step Description
1 Issue licenses for the new IP address in your Check Point User Center account.
3 Wait for a couple of minutes for the Security Management Server to detect the new
licenses.
Alternatively, restart Check Point services:
cpstop
cpstart
9. Update the object version of the dedicated Log Servers and SmartEvent Servers
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
14. Disconnect the old Security Management Server from the network
l CloudGuard Controllers
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
Step Description
1 Upgrade the Primary Security Management Server with one of the supported methods.
n CPUSE
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with CPUSE" on page 238
n Advanced Upgrade
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with Advanced Upgrade" on page 242
n Migration
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with Migration" on page 250
2 Upgrade the Secondary Security Management Server with one of the supported methods.
n CPUSE
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with CPUSE" on page 238
n Advanced Upgrade
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with Advanced Upgrade" on page 242
n Migration
See "Upgrading a Security Management Server or Log Server from R80.20 and higher
with Migration" on page 250
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary Security
Management Server:
Step Description
Important - This step applies only if the SmartEvent Correlation Unit Software Blade
is enabled on the R80.40 Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
Important - You must upgrade the Multi-Domain Server before you can upgrade the
Multi-Domain Log Server, dedicated Log Servers, and dedicated SmartEvent Servers.
Note - To upgrade from R80.20 and higher, see "Upgrading one Multi-Domain Server
from R80.20 and higher" on page 297.
For configuration information, see the R80.40 Multi-Domain Security Management Administration Guide.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading one Multi-Domain Server
from R80.20 and higher with CPUSE" on page 298.
n This upgrade method is supported only for servers that already run Gaia
Operating System.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
4 Click Install .
5 Click OK.
4. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
5. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading one Multi-Domain Server
from R80.20 and higher with Advanced Upgrade" on page 303.
n This upgrade method is supported only for servers that already run Gaia
Operating System.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
Note - If you enter no in the question "Do you wish to export the
log database", the configuration is still exported.
15 Transfer the exported database from the current Multi-Domain Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. On the R80.40 Multi-Domain Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
4 Click Install .
5 Click OK.
7. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
8. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading one Multi-Domain Server
from R80.20 and higher with Migration" on page 311.
n This upgrade method is supported only for servers that already run Gaia
Operating System.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
Note - If you enter no in the question "Do you wish to export the
log database", the configuration is still exported.
15 Transfer the exported database from the current Multi-Domain Server to an external
storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Multi-Domain Server Only, or Primary Multi-Domain
Server in Management High Availability" on page 72.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
4 Click Install .
5 Click OK.
7. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
8. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
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:
n "Upgrading one Multi-Domain Server from R80.10 and lower with CPUSE" on page 264
n "Upgrading one Multi-Domain Server from R80.10 and lower with Advanced Upgrade" on
page 268
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:
n The entire Multi-Domain Server cannot be upgraded at once because of a business impact.
n During the upgrade, it is necessary to rename some or all of the Domain Management Servers.
n In Multi-Domain Server High Availability deployment, it is necessary to change the number of
Domain Management Servers on Multi-Domain Servers.
n You must migrate the Global Policies before you migrate the databases from other Domains.
n You can migrate the Global Policies only one time from the R7x Multi-Domain Server.
n Until the entire migration procedure is completed, you cannot make changes in the Global Policies
on the source Multi-Domain Servers.
If it is necessary to make changes on the source Multi-Domain Servers, follow these guidelines:
l If you deleted or modified a global object in the source R7x Multi-Domain Server database,
you must make the same changes in the migrated Global Policies on the target R80.40
Multi-Domain Server.
l If you added a global object in the source R7x Multi-Domain Server database, you must
delete that global object before you export the databases from other Domains.
Procedure:
Create the Domain Management Servers, into which you import the entire management
database from the source Domain Management Servers.
Important:
n Do not start the new Domain Management Servers.
n Do not configure anything in the new Domain Management
Servers.
You can create the Domain Management Servers in one these ways:
n In SmartConsole.
See the R80.40 Multi-Domain Security Management Administration Guide - Chapter
Managing Domains - Section Creating a New Domain.
n With the "mgmt_cli add domain" command.
See the Check Point Management API Reference - mgmt_cli tool - Chapter Multi-Domain
- Section Domain - Subsection add domain.
4. 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
5 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
10 Transfer the exported database from the R7x Multi-Domain Server to an external
storage:
/<Full Path>/R7x_global_policies.tgz
5. On the R80.40 Multi-Domain Server, import the R7x global management database to
the Global Domain
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Primary Multi-
Domain Server, to some directory.
Step Description
10 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6. On the R7x Multi-Domain Server, export the entire management databases from the
applicable source Domain Management Servers one by one
Step Description
4 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
7 Export the entire management database from each applicable Domain Management
Server:
yes | nohup ./migrate export [-l | -x] /<Full
Path>/<Name of R7x Domain Exported File>
For details, see the R80.40 CLI Reference Guide - Chapter Multi-Domain Security
Management Commands - Section migrate.
Step Description
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
Step Description
8. On the target R80.40 Multi-Domain Server, import the entire management database
to the applicable target Domain Management Servers one by one
Step Description
Step Description
5 Import the R7x Domain Management Server management databases one by one:
cma_migrate /<Full Path>/<Name of R7x Domain Exported
File>.tgz /<Full Path>/<$FWDIR Directory of the New
Domain Management Server>/
Example:
cma_migrate /var/log/orig_R7x_database.tgz /opt/CPmds-
R80.40/customers/MyDomain3/CPsuite-R80.40/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:
mdsstart_customer <IP Address or Name of Domain
Management Server>
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
9. On the target R80.40 Multi-Domain Server, upgrade the attributes of all managed
objects in each target Domain Management Server
Step Description
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in each new target Domain
Management Server (one at a time):
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n
<Name of Domain Management Server>
Note - Because the command prompts you for a 'yes/no' for the Domain
and each object in the Domain, you can explicitly provide the 'yes' answer to
all questions with this command:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_version -
c ALL -n <Name of Domain Management Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
1 Run the mdsconfig command and configure the options Administrators and GUI
clients .
See "Post-Installation Configuration" on page 147.
11. Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Important:
n This step applies only if the target R80.40 Domain Management Server
has a different IPv4 address than the source R7x Domain
Management Server.
n In a Cluster, you must configure all the Cluster Members in the same
way.
When a Management Server and a managed Security Gateway establish SIC Trust, the Security
Gateway saves the IP address of the Internal Certificate Authority (ICA) of its Management
Server. The Security Gateway uses this IP address for Automatic Certificate Renewal process
when the certificate on the Security Gateway expires.
To force the Security Gateway to update the saved IP address of the Management Server's ICA,
follow one of these procedures:
cpconfig
c. Choose the option Secure Internal Communication from the menu - enter 5 press the
Enter key.
Follow the instructions on the screen to re-initialize the communication and to enter the
Activation Key.
d. Exit the Check Point Configuration Tool.
e. Wait for Check Point processes to restart.
f. Connect with SmartConsole to the Management Server that manages the Security
Gateway (Cluster) object.
g. From the left navigation panel, click Gateways & Servers .
h. Double-click the Security Gateway (Cluster) object.
i. From the left tree, click General Properties .
In a Cluster object, click Cluster Members and edit every Cluster Member object.
j. Click Communication.
k. Click Reset.
l. Enter the same Activation Key you entered on the Security Gateway (Cluster Member).
m. Click Initialize.
n. The Trust State field must show Trust established.
o. Click Close.
p. Click OK.
q. Publish the SmartConsole session.
r. Install the Access Control Policy on the Security Gateway (Cluster) object.
For more information, see sk103356: How to renew SIC after changing IP Address of
Security Management Server.
a. Connect to the command line on the Security Gateway (every Cluster Member).
b. Log in to the Expert mode.
c. Back up the current $CPDIR/registry/HKLM_registry.data file:
cp -v $CPDIR/registry/HKLM_registry.data{,_BKP}
vi $CPDIR/registry/HKLM_registry.data
e. Search for:
:ICAip
: (SIC
:ICAdn ("O=R80.40-Manager..ntk6rk")
:MySICname ("CN=R80.40-MyGW,O=R80.40-
Manager..ntk6rk")
:HasCertificate ("[4]1")
:CertPath ("/opt/CPshrd-R80.40/conf/sic_cert.p12")
:ICAip (192.168.41.80)
12. Rebuild the status of Global VPN communities after the gradual upgrade
Step Description
Important - This step applies if the original R7x Domain Management Server
managed VPN gateways.
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, then 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:
n Update the external DNS server to resolve the host name to the IP address of the
applicable Domain Management Server.
n Revoke the IKE certificate for the Security Gateway and create a new one.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly on
each Domain Management Server.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
4 Click Install .
5 Click OK.
5. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
6. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the
Step Description
Step Description
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Multi-Domain Server Only, or Primary Multi-Domain
Server in Management High Availability" on page 72.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. Get the required Upgrade Tools on the R80.40 server
Step Description
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
4 Click Install .
5 Click OK.
8. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
9. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
Step Description
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Multi-Domain Server, run the Pre-Upgrade Verifier and export the
Step Description
Step Description
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Multi-Domain Server Only, or Primary Multi-Domain
Server in Management High Availability" on page 72.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. Get the required Upgrade Tools on the R80.40 server
Step Description
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
4 Click Install .
5 Click OK.
8. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
9. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Management Server at a
time with this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Management Server>
Step Description
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Important - You must upgrade the Multi-Domain Servers before you can upgrade the
Multi-Domain Log Servers, dedicated Log Servers, and dedicated SmartEvent
Servers.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Note - To upgrade from R80.20 and higher, see "Upgrading Multi-Domain Servers in
High Availability from R80.20 and higher" on page 355.
For configuration information, see the R80.40 Multi-Domain Security Management Administration Guide.
Notes:
n Note - To upgrade from R80.20 and higher, see "Upgrading Multi-Domain
Servers in High Availability from R80.20 and higher with CPUSE" on page 356.
n This upgrade method is supported only for servers that already run Gaia
Operating System.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
4 Click Install .
5 Click OK.
8. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
9. Upgrade the attributes of all managed objects in all Domain Management Servers
Important - Perform this steps on every Multi-Domain Server with Active
Domain Management Servers.
To determine which Multi-Domain Servers run Active Domain Management
Servers:
a. Connect with SmartConsole to a Multi-Domain Server and select the
MDS context.
b. From the left navigation panel, click Multi Domain > Domains .
The table shows Domains and Multi-Domain Servers:
n Every column shows a Multi-Domain Server.
n Active Domain Management Servers (for a Domain) are marked with a
solid black "barrel" icon.
n Standby Domain Management Servers (for a Domain) are marked with
an empty "barrel" icon.
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading Multi-Domain Servers in
High Availability from R80.20 and higher with Advanced Upgrade" on page 363.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
3. On the Primary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
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 Multi-Domain Server to an external
storage:
/var/log/Primary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
5. On the Primary R80.40 Multi-Domain Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
7. On the Secondary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
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 Multi-Domain Server to an external
storage:
/var/log/Secondary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
9. On the Secondary R80.40 Multi-Domain Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
The preliminary steps below 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 - The example that follows, assumes that you already upgraded the
Primary Multi-Domain Server, and upgraded one of the Secondary Multi-
Domain Servers with Active Domain Management Servers on it.
a. 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:
n The Primary Multi-Domain Server
n The first Secondary Multi-Domain Server
b. Make sure the High Availability status of 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.
b. 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:
n The Primary Multi-Domain Server
n The first Secondary Multi-Domain Server
n The second Secondary Multi-Domain Server
b. Make sure the High Availability status of 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.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
11. Install the management database on each Domain Management Server of the
Primary Multi-Domain Server
Step Description
Step Description
4 Click Install .
5 Click OK.
12. Install the management database on each Domain Management Server of the
Secondary Multi-Domain Server
Step Description
4 Click Install .
5 Click OK.
13. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
14. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading Multi-Domain Servers in
High Availability from R80.20 and higher with Migration" on page 384.
5 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
3. On the Primary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
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 Multi-Domain Server to an external
storage:
/var/log/Primary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Step Description
2 Perform the clean install on another server in one of these ways (do not perform initial
configuration in SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing One Multi-Domain Server Only, or Primary Multi-Domain
Server in Management High Availability" on page 72.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
5. On the Primary R80.40 Multi-Domain Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
7. On the Secondary Multi-Domain Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
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 Multi-Domain Server to an external
storage:
/var/log/Secondary_exported_mds.<DDMMYYYY-HHMMSS>.tgz
Step Description
2 Perform the clean install on another server in one of these ways (do not perform initial
configuration in SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing a Secondary Multi-Domain Server in Management High
Availability" on page 73.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
9. On the Secondary R80.40 Multi-Domain Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
The preliminary steps below 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 - The example that follows, assumes that you already upgraded the
Primary Multi-Domain Server, and upgraded one of the Secondary Multi-
Domain Servers with Active Domain Management Servers on it.
a. 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:
n The Primary Multi-Domain Server
n The first Secondary Multi-Domain Server
b. Make sure the High Availability status of 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.
b. 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:
n The Primary Multi-Domain Server
n The first Secondary Multi-Domain Server
n The second Secondary Multi-Domain Server
b. Make sure the High Availability status of 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.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Server, to some directory.
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
11. Install the management database on each Domain Management Server of the
Primary Multi-Domain Server
Step Description
4 Click Install .
5 Click OK.
12. Install the management database on each Domain Management Server of the
Secondary Multi-Domain Server
Step Description
4 Click Install .
5 Click OK.
13. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
14. Upgrade the attributes of all managed objects in all Domain Management Servers
Important - Perform this steps on every Multi-Domain Server with Active
Domain Management Servers.
To determine which Multi-Domain Servers run Active Domain Management
Servers:
a. Connect with SmartConsole to a Multi-Domain Server and select the
MDS context.
b. From the left navigation panel, click Multi Domain > Domains .
The table shows Domains and Multi-Domain Servers:
n Every column shows a Multi-Domain Server.
n Active Domain Management Servers (for a Domain) are marked with a
solid black "barrel" icon.
n Standby Domain Management Servers (for a Domain) are marked with
an empty "barrel" icon.
Step Description
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
Step Description
8 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
If your business model cannot support management downtime during the upgrade, you can continue to
manage Domain Management Servers during the upgrade process.
If you make changes to Domain Management Server databases during the upgrade process, this can
create a risk of inconsistent Domain Management Server database content between instances on different
Multi-Domain Servers. The synchronization process cannot resolve these database inconsistencies.
After you successfully upgrade one Multi-Domain Server, you can set its Domain Management Servers to
the Active state, while you upgrade the others. Synchronization between the Domain Management
Servers occurs after all Multi-Domain Servers are upgraded.
If, during the upgrade process, you make changes to the Domain Management Server database on
different Multi-Domain Servers, the contents of these databases will be different. Because you cannot
synchronize these databases, some of these changes will be lost. The Domain Management Server High
Availability status appears as Collision.
You must decide which database version to retain and synchronize it to the other Domain Management
Servers. Then you must re-enter the lost changes to the synchronized database - configure the same
objects and settings again.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
Step Description
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Important - If you upgrade from R80.20.M1, then you must perform a clean
install of the Secondary R80.40 Multi-Domain Server:
a. See the R80.40 Release Notes for requirements.
b. Follow "Installing a Secondary Multi-Domain Server in Management
High Availability" on page 73.
Do not perform initial configuration in SmartConsole.
The IP addresses of the source and target R80.40 servers must be the
same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that
you have to issue licenses for the new IP address. See "Changing the
IP Address of a Multi-Domain Server or Multi-Domain Log Server" on
page 663.
6. Get the required Upgrade Tools on the Secondary 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
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
Step Description
4 Click Install .
5 Click OK.
10. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
11. Upgrade the attributes of all managed objects in all Domain Management Servers
Important - Perform this steps on every Multi-Domain Server with Active
Domain Management Servers.
To determine which Multi-Domain Servers run Active Domain Management
Servers:
a. Connect with SmartConsole to a Multi-Domain Server and select the
MDS context.
b. From the left navigation panel, click Multi Domain > Domains .
The table shows Domains and Multi-Domain Servers:
n Every column shows a Multi-Domain Server.
n Active Domain Management Servers (for a Domain) are marked with a
solid black "barrel" icon.
n Standby Domain Management Servers (for a Domain) are marked with
an empty "barrel" icon.
Step Description
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
2. Make sure the Global Domain is Active on the Primary Multi-Domain Server
Step Description
2 From the left navigation panel, click Multi Domain > Domains .
The table shows Domains and Multi-Domain Servers:
n Every column shows a Multi-Domain Server.
n Active Domain Management Servers (for a Domain) are marked with a solid
black "barrel" icon.
n Standby Domain Management Servers (for a Domain) 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.
The 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.
3. Get the required Upgrade Tools on the Primary and on the Secondary Multi-Domain
Servers
Step Description
Step Description
Step Description
Step Description
Step Description
Step Description
4 Transfer the exported databases from the source Multi-Domain Server to an external
storage:
/<Full Path>/Primary_<Name of Database File>.tgz
Step Description
Step Description
4 Transfer the exported databases from the source Multi-Domain Server to an external
storage:
/<Full Path>/Secondary_<Name of Database File>.tgz
Step Description
2 n If you upgrade from R80.20, R80.20.M2, and higher versions, you can follow
one of these procedures:
l "Installing Software Packages on Gaia" on page 153.
Select the R80.40 package and perform Upgrade. See sk92449 for
detailed steps.
l "Installing One Multi-Domain Server Only, or Primary Multi-Domain
Server in Management High Availability" on page 72.
Do not perform initial configuration in SmartConsole.
n If you upgrade from R80.20.M1 version, you must follow this procedure:
l "Installing a Secondary Multi-Domain Server in Management High
Availability" on page 73.
Do not perform initial configuration in SmartConsole.
Step Description
Step Description
If you installed the target R80.40 Multi-Domain Server with a different IP address than the
source Multi-Domain Server, you must create a special JSON configuration file before you
import the management database from the source Multi-Domain Server. Note that you have
to issue licenses for the new IP address.
Important:
n If none of the servers in the same Multi-Domain Security
Management environment changed their original IP addresses,
then you do not need to create the special JSON configuration file.
n Even if only one of the servers migrates to a new IP address, all the
other servers must get this configuration file for the import process.
You must use the same JSON configuration file on all servers in the
same Multi-Domain Security Management environment.
Ste
Description
p
Format for migrating both the Primary and the Secondary Multi-Domain
Servers to new IP addresses
[{"name":"<Name of Primary Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 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 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 Multi-Domain Server>"},{"name":"<Name
of Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
R80.40 Multi-Domain Log Server"}]
Ste
Description
p
Example
There are 3 servers in the R80.30 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.30 Multi-Domain
Server is:
192.168.10.21
b. The current IPv4 address of the source Secondary R80.30 Multi-Domain
Server is:
192.168.10.22
c. The name of the source Primary R80.30 Multi-Domain Server object in
SmartConsole is:
MyPrimaryMDS
d. The name of the source Secondary R80.30 Multi-Domain Server object in
SmartConsole is:
MySecondaryMDS
e. The new IPv4 address of the target Primary R80.40 Multi-Domain Server
is:
172.30.40.51
f. The new IPv4 address of the target Secondary R80.40 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":"MyPrimaryMDS","newIpAddress4":"172.30.40.
51"},
{"name":"MySecondaryMDS","newIpAddress4":"172.30.40
.52"}]
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-
Domain Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
Step Description
2 n If you upgrade from R80.20, R80.20.M2, and higher versions, you can follow
one of these procedures:
l "Installing Software Packages on Gaia" on page 153.
Select the R80.40 package and perform Upgrade. See sk92449 for
detailed steps.
l "Installing a Secondary Multi-Domain Server in Management High
Availability" on page 73.
Do not perform initial configuration in SmartConsole.
n If you upgrade from R80.20.M1 version, you must follow this procedure:
l "Installing a Secondary Multi-Domain Server in Management High
Availability" on page 73.
Do not perform initial configuration in SmartConsole.
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
Step Description
If you installed the target R80.40 Multi-Domain Server with a different IP address than the
source Multi-Domain Server, you must create a special JSON configuration file before you
import the management database from the source Multi-Domain Server. Note that you have
to issue licenses for the new IP address.
Important:
n If none of the servers in the same Multi-Domain Security
Management environment changed their original IP addresses,
then you do not need to create the special JSON configuration file.
n Even if only one of the servers migrates to a new IP address, all the
other servers must get this configuration file for the import process.
You must use the same JSON configuration file on all servers in the
same Multi-Domain Security Management environment.
Ste
Description
p
Format for migrating both the Primary and the Secondary Multi-Domain
Servers to new IP addresses
[{"name":"<Name of Primary Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 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 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 Multi-Domain Server>"},{"name":"<Name
of Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
R80.40 Multi-Domain Log Server"}]
Ste
Description
p
Example
There are 3 servers in the R80.30 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.30 Multi-Domain
Server is:
192.168.10.21
b. The current IPv4 address of the source Secondary R80.30 Multi-Domain
Server is:
192.168.10.22
c. The name of the source Primary R80.30 Multi-Domain Server object in
SmartConsole is:
MyPrimaryMDS
d. The name of the source Secondary R80.30 Multi-Domain Server object in
SmartConsole is:
MySecondaryMDS
e. The new IPv4 address of the target Primary R80.40 Multi-Domain Server
is:
172.30.40.51
f. The new IPv4 address of the target Secondary R80.40 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":"MyPrimaryMDS","newIpAddress4":"172.30.40.
51"},
{"name":"MySecondaryMDS","newIpAddress4":"172.30.40
.52"}]
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-
Domain Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
16. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
Step Description
4 Click Install .
5 Click OK.
18. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
1. If the Primary Multi-Domain Server is not available, promote the Secondary Multi-
Domain Server to be the Primary
For instructions, see the R80.40 Multi-Domain Security Management Administration Guide -
Chapter Working with High Availability - Section Failure Recovery - Subsection Promoting the
Secondary Multi-Domain Server to Primary.
2. Make sure the Global Domain is Active on the Primary Multi-Domain Server
Step Description
2 From the left navigation panel, click Multi Domain > Domains .
The table shows Domains and Multi-Domain Servers:
n Every column shows a Multi-Domain Server.
n Active Domain Management Servers (for a Domain) are marked with a solid
black "barrel" icon.
n Standby Domain Management Servers (for a Domain) 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.
The 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.
3. Get the required Upgrade Tools on the Primary and on the Secondary Multi-Domain
Servers
Step Description
Step Description
Step Description
Step Description
Step Description
Step Description
4 Transfer the exported databases from the source Multi-Domain Server to an external
storage:
/<Full Path>/Primary_<Name of Database File>.tgz
Step Description
Step Description
4 Transfer the exported databases from the source Multi-Domain Server to an external
storage:
/<Full Path>/Secondary_<Name of Database File>.tgz
Step Description
Step Description
Step Description
If you installed the target R80.40 Multi-Domain Server with a different IP address than the
source Multi-Domain Server, you must create a special JSON configuration file before you
import the management database from the source Multi-Domain Server. Note that you have
to issue licenses for the new IP address.
Important:
n If none of the servers in the same Multi-Domain Security
Management environment changed their original IP addresses,
then you do not need to create the special JSON configuration file.
n Even if only one of the servers migrates to a new IP address, all the
other servers must get this configuration file for the import process.
You must use the same JSON configuration file on all servers in the
same Multi-Domain Security Management environment.
Ste
Description
p
Format for migrating both the Primary and the Secondary Multi-Domain
Servers to new IP addresses
[{"name":"<Name of Primary Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 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 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address of
Primary R80.40 Multi-Domain Server>"},{"name":"<Name of
Secondary Multi-Domain Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
Secondary R80.40 Multi-Domain Server>"},{"name":"<Name
of Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
R80.40 Multi-Domain Log Server"}]
Ste
Description
p
Example
There are 3 servers in the R80.30 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.30 Multi-Domain
Server is:
192.168.10.21
b. The current IPv4 address of the source Secondary R80.30 Multi-Domain
Server is:
192.168.10.22
c. The name of the source Primary R80.30 Multi-Domain Server object in
SmartConsole is:
MyPrimaryMDS
d. The name of the source Secondary R80.30 Multi-Domain Server object in
SmartConsole is:
MySecondaryMDS
e. The new IPv4 address of the target Primary R80.40 Multi-Domain Server
is:
172.30.40.51
f. The new IPv4 address of the target Secondary R80.40 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":"MyPrimaryMDS","newIpAddress4":"172.30.40.
51"},
{"name":"MySecondaryMDS","newIpAddress4":"172.30.40
.52"}]
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-
Domain Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
Step Description
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
If you installed the target R80.40 Multi-Domain Server with a different IP address than the
source Multi-Domain Server, you must create a special JSON configuration file before you
import the management database from the source Multi-Domain Server. Note that you have
to issue licenses for the new IP address.
Important:
n If none of the servers in the same Multi-Domain Security
Management environment changed their original IP addresses,
then you do not need to create the special JSON configuration file.
n Even if only one of the servers migrates to a new IP address, all the
other servers must get this configuration file for the import process.
You must use the same JSON configuration file on all servers in the
same Multi-Domain Security Management environment.
Ste
Description
p
Ste
Description
p
Format for migrating both the Primary and the Secondary Multi-Domain
Servers to new IP addresses
[{"name":"<Name of Primary Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address
of Primary R80.40 Multi-Domain Server>"},
{"name":"<Name of Secondary Multi-Domain Server
Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.40 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 Multi-Domain Server Object
in SmartConsole>","newIpAddress4":"<New IPv4 Address
of Primary R80.40 Multi-Domain Server>"},
{"name":"<Name of Secondary Multi-Domain Server
Object in SmartConsole>","newIpAddress4":"<New IPv4
Address of Secondary R80.40 Multi-Domain Server>"},
{"name":"<Name of Multi-Domain Log Server Object in
SmartConsole>","newIpAddress4":"<New IPv4 Address of
R80.40 Multi-Domain Log Server"}]
Ste
Description
p
Example
There are 3 servers in the R80.30 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.30 Multi-Domain
Server is:
192.168.10.21
b. The current IPv4 address of the source Secondary R80.30 Multi-Domain
Server is:
192.168.10.22
c. The name of the source Primary R80.30 Multi-Domain Server object in
SmartConsole is:
MyPrimaryMDS
d. The name of the source Secondary R80.30 Multi-Domain Server object in
SmartConsole is:
MySecondaryMDS
e. The new IPv4 address of the target Primary R80.40 Multi-Domain Server
is:
172.30.40.51
f. The new IPv4 address of the target Secondary R80.40 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":"MyPrimaryMDS","newIpAddress4":"172.30.40.
51"},
{"name":"MySecondaryMDS","newIpAddress4":"172.30.40
.52"}]
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-
Domain Server, to some directory.
Step Description
9 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
Step Description
3 From the top toolbar, open the Secondary Multi-Domain Server object.
6 Click OK.
15. Upgrade the Multi-Domain Log Servers, dedicated Log Servers, and dedicated
SmartEvent Servers
Step Description
4 Click Install .
5 Click OK.
17. Upgrade the attributes of all managed objects in all Domain Management Servers
Step Description
4 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Management Servers at
once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Multi-Domain Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Multi-Domain Server>
7 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
If your business model cannot support management downtime during the upgrade, you can continue to
manage Domain Management Servers during the upgrade process.
If you make changes to Domain Management Server databases during the upgrade process, this can
create a risk of inconsistent Domain Management Server database content between instances on different
Multi-Domain Servers. The synchronization process cannot resolve these database inconsistencies.
After you successfully upgrade one Multi-Domain Server, you can set its Domain Management Servers to
the Active state, while you upgrade the others. Synchronization between the Domain Management
Servers occurs after all Multi-Domain Servers are upgraded.
If, during the upgrade process, you make changes to the Domain Management Server database on
different Multi-Domain Servers, the contents of these databases will be different. Because you cannot
synchronize these databases, some of these changes will be lost. The Domain Management Server High
Availability status appears as Collision.
You must decide which database version to retain and synchronize it to the other Domain Management
Servers. Then you must re-enter the lost changes to the synchronized database - configure the same
objects and settings again.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading a Multi-Domain Log
Server from R80.20 and higher with CPUSE" on page 431.
n This upgrade method is supported only for servers that already run Gaia
Operating System.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
3. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
4 Click Install .
5 Click OK.
4. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
Step Description
8 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading a Multi-Domain Log
Server from R80.20 and higher with Advanced upgrade" on page 437.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
Note - If you enter no in the question "Do you wish to export the
log database", the configuration is still exported.
15 Transfer the exported database from the current Multi-Domain Log Server to an
external storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. On the R80.40 Multi-Domain Log Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Log Server, to some directory.
Step Description
8 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
6. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
4 Click Install .
Step Description
5 Click OK.
7. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
Step Description
8 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading a Multi-Domain Log
Server from R80.20 and higher with Migration" on page 446.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
1 Download the R80.40 Clean Install ISO file from the R80.40 Home Page SK.
2 Transfer the R80.40 ISO file to the current server to some directory (for example,
/var/log/path_to_iso/).
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the
entire management database
Step Description
Step Description
Step Description
Note - If you enter no in the question "Do you wish to export the
log database", the configuration is still exported.
15 Transfer the exported database from the current Multi-Domain Log Server to an
external storage:
/var/log/exported_mds.<DDMMYYYY-HHMMSS>.tgz
Step Description
2 Perform the clean install on another server in one of these ways (do not perform initial
configuration in SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing a Multi-Domain Log Server" on page 75.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. On the R80.40 Multi-Domain Log Server, import the databases
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Log Server, to some directory.
Step Description
8 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
6. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
4 Click Install .
Step Description
5 Click OK.
7. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
Step Description
8 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
11. Disconnect the old Multi-Domain Log Server from the network
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
Step Description
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
4. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
4 Click Install .
5 Click OK.
5. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
Step Description
7 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the
Step Description
Step Description
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing a Multi-Domain Log Server" on page 75.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. Get the required Upgrade Tools on the R80.40 server
Step Description
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Log Server, to some directory.
Step Description
9 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
8. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
Step Description
4 Click Install .
5 Click OK.
9. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
7 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n For additional information related to this upgrade, see sk163814.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Multi-Domain Log Server.
5 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Multi-Domain Log Server, run the Pre-Upgrade Verifier and export the
Step Description
Step Description
Step Description
2 Perform the clean install on another server in one of these ways (do not perform initial
configuration in SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing a Multi-Domain Log Server" on page 75.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
server, you can change it only after the upgrade procedure. Note that you
have to issue licenses for the new IP address. See "Changing the IP Address
of a Multi-Domain Server or Multi-Domain Log Server" on page 663.
4. Get the required Upgrade Tools on the R80.40 server
Step Description
Step Description
5 Transfer the exported database from an external storage to the R80.40 Multi-Domain
Log Server, to some directory.
Step Description
9 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
3 From the top toolbar, open the Multi-Domain Log Server object.
6 Click OK.
8. Install the management database on each Domain Log Server on Multi-Domain Log
Server
Step Description
1 Connect with SmartConsole to each Domain Management Server that manages the
Domain Log Server.
Step Description
4 Click Install .
5 Click OK.
9. Upgrade the attributes of all managed objects in all Domain Log Servers
Step Description
4 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
6 Upgrade the attributes of all managed objects in all Domain Log Servers at once:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
Notes:
n 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:
yes | $MDSDIR/scripts/mds_fix_cmas_clms_
version -c ALL
n You can perform this action on one Domain Log Server at a time with
this command:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c
ALL -n <Name of Domain Log Server>
7 Make sure that all the required daemons have the correct state:
mdsstat
n The state of the FWM, FWD, and CPD daemons must be "up" on all levels.
These daemons must show their PID, or "pnd".
n The state of the CPCA daemon must be "N/R" on the MDS level.
n The state of the CPCA daemon must be "down" on the Domain Log Server
level.
If the state of one of the required daemons (FWM, FWD, or CPD) on a Domain Log
Server is "down", then wait for 5-10 minutes, restart that Domain Log Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain Log
Server>
mdsstart_customer <IP Address or Name of Domain Log
Server>
mdsstat
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
1 Connect with SmartConsole to the R80.40 Multi-Domain Server that manages the
Multi-Domain Log Server.
13. Disconnect the old Multi-Domain Log Server from the network
Notes:
n To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server or Endpoint Policy Server from R80.20 and higher with
CPUSE" on page 501.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
If your Endpoint Security Management Server manages dedicated Endpoint Policy Servers, you
must upgrade these dedicated servers to the same version as the Endpoint Security
Management Server:
"Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower" on page 482
If applicable, see:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.40 Endpoint 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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server from R80.10 and lower with Advanced Upgrade" above.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Endpoint 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 Endpoint Security Management Server.
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
9 Transfer the exported databases from the current Endpoint Security Management
Server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important:
n If you upgrade from R80 (or higher) version to R80.40, then these
options are available:
l The IP addresses of the source and target Endpoint Security
Step Description
1 Connect to the command line on the R80.40 Endpoint Security Management Server.
4 Transfer the exported databases from an external storage to the R80.40 Endpoint
Security Management Server, to some directory.
Step Description
Notes:
n If you upgrade from R80 (or higher) version, and the IP addresses of
the source and target Endpoint 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.40 Endpoint Security
Management Server.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Endpoint Security Management
Servers must be the same.
l If it is necessary to have a different IP address on the R80.40
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
6. Install the licenses and change the IP address of the R80.40 Endpoint Security
Management Server
Scenario Instructions
You upgraded from R80 (or higher) version to Follow these steps:
R80.40, and the IP addresses of the source and a. Issue licenses for the new IP
target Endpoint Security Management Servers are address in your Check Point User
different Center account.
b. Install the new licenses on the
R80.40 Endpoint Security
Management Server.
Scenario Instructions
You upgraded from R77.30 (and lower) version to Follow these steps (based on sk40993):
R80.40 and need to have a different IP address on a. Issue licenses for the new IP
the R80.40 Endpoint Security Management address in your Check Point User
Servers Center account.
b. Perform the required changes in
the SmartConsole:
i. Connect with
SmartConsole to the
Endpoint Security
Management Servers.
ii. From the left navigation
panel, click Gateways &
Servers .
iii. Open the Endpoint
Security Management
Servers object.
iv. On the General Properties
page, change the current
IP address to the new IP
address.
v. On the Network
Management page, edit
the applicable interface
and change the current IP
address to the new IP
address.
vi. Click OK.
vii. Publish the SmartConsole
session.
viii. Close the SmartConsole.
c. Stop the Check Point services:
i. Connect to the command
line.
ii. Log in to either Gaia Clish,
or Expert mode.
iii. Run: cpstop
d. Perform the required changes in
Gaia OS:
i. Connect to either Gaia
Portal, or Gaia Clish.
ii. 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.40 Gaia
Administration Guide.
Scenario Instructions
If your Endpoint Security Management Server manages dedicated Endpoint Policy Servers, you
must upgrade these dedicated servers to the same version as the Endpoint Security
Management Server:
"Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower" on page 482
If applicable, see:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
Step Description
4 Click Install .
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.40 Endpoint 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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
11. Test the functionality on the R80.40 Endpoint Security Management Server
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Note - To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server or Endpoint Policy Server from R80.20 and higher with
Migration" on page 514.
Important - Before you upgrade an Endpoint Security Management Server:
Step Description
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Endpoint 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 Endpoint Security Management Server.
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
9 Transfer the exported databases from the current Endpoint Security Management
Server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Perform a clean install of the R80.40 Endpoint Security Management Server on another
computer.
Do not perform initial configuration in SmartConsole.
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 Endpoint Security Management Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
1 Connect to the command line on the R80.40 Endpoint Security Management Server.
4 Transfer the exported databases from an external storage to the R80.40 Endpoint
Security Management Server, to some directory.
Step Description
Notes:
n If you upgrade from R80 (or higher) version, and the IP addresses of
the source and target Endpoint 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.40 Endpoint Security
Management Server.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Endpoint Security Management
Servers must be the same.
l If it is necessary to have a different IP address on the R80.40
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
If your Endpoint Security Management Server manages dedicated Endpoint Policy Servers, you
must upgrade these dedicated servers to the same version as the Endpoint Security
Management Server:
"Upgrading a Dedicated Endpoint Policy Server from R80.10 and lower" on page 482
If applicable, see:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
1 Connect with the SmartConsole to the R80.40 Endpoint 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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
10. Test the functionality on the R80.40 Endpoint Security Management Server
Step Description
2 Make sure the management database and configuration were upgraded correctly.
11. Disconnect the old Endpoint Security Management Server from the network
Disconnect the network cables the old Endpoint Security Management Server.
12. Connect the new Endpoint Security Management Server to the network
Connect the network cables to the new Endpoint Security Management Server.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Step Description
1 Upgrade the Primary Endpoint Security Management Server with one of the supported
methods.
See "Upgrade Methods" on page 167.
2 Upgrade the Secondary Endpoint Security Management Server with one of the supported
methods.
See "Upgrade Methods" on page 167.
4 Connect with R80.40 SmartConsole to the R80.40 Primary Endpoint Security Management
Server.
5 Update the object version of the Secondary Endpoint Security Management Server:
Step Description
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary
Endpoint Security Management Server:
Important - This step applies only if the SmartEvent Correlation Unit Software
Blade is enabled on the R80.40 Endpoint Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide >
Chapter Log Exporter
Step Description
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
Step Description
1 Upgrade the Primary Endpoint Security Management Server with one of the supported
methods.
See "Upgrade Methods" on page 167.
2 Perform a clean install of the R80.40 on the Secondary Endpoint Security Management
Server.
See "Installing a Secondary Endpoint Security Management Server in Management High
Availability" on page 80.
4 Connect with R80.40 SmartConsole to the R80.40 Primary Endpoint Security Management
Server.
5 Update the object version of the Secondary Endpoint Security Management Server:
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary
Endpoint Security Management Server:
Step Description
Important - This step applies only if the SmartEvent Correlation Unit Software
Blade is enabled on the R80.40 Endpoint Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide >
Chapter Log Exporter
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
Notes:
n To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server or Endpoint Policy Server from R80.20 and higher with
CPUSE" on page 501.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
3 Before you upgrade a dedicated Endpoint Policy Server, you must upgrade the
applicable Endpoint Security Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Endpoint
Policy Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
6 Click OK.
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
Notes - To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server or Endpoint Policy Server from R80.20 and higher with
Advanced Upgrade" on page 506.
Important - Before you upgrade a dedicated Endpoint Policy Server:
Step Description
3 Before you upgrade a dedicated Endpoint Policy Server, you must upgrade the
applicable Endpoint Security Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Endpoint
Policy Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated Endpoint Policy Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current dedicated Endpoint Policy Server.
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
Step Description
5
Important - This step applies only when you upgrade from R77.30 or lower.
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
4. On the R80.40 or Endpoint Policy Server, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
4 Transfer the exported databases from an external storage to the R80.40 or Endpoint
Policy Server, to some directory.
Step Description
Step Description
6 Click OK.
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
10. Test the functionality on the R80.40 Endpoint Security Management Server
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
Notes - To upgrade from R80.20 and higher, see "Upgrading an Endpoint Security
Management Server or Endpoint Policy Server from R80.20 and higher with
Migration" on page 514.
Important - Before you upgrade a dedicated Endpoint Policy Server:
Step Description
3 Before you upgrade a dedicated Endpoint Policy Server, you must upgrade the
applicable Endpoint Security Management Server that manages it.
4 You must close all GUI clients (SmartConsole applications) connected to the Endpoint
Policy Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current dedicated Endpoint Policy Server, run the Pre-Upgrade Verifier and
export the entire management database
Step Description
1 Connect to the command line on the current dedicated Endpoint Policy Server.
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
Step Description
5
Important - This step applies only when you upgrade from R77.30 or lower.
8 Transfer the exported databases from the current server to an external storage:
/<Full Path>/<Name of Database File>.tgz
Perform a clean install of the R80.40 Endpoint Policy Server on another computer.
Do not perform initial configuration in SmartConsole.
See "Installing an Endpoint Policy Server" on page 83
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
Step Description
4 Transfer the exported databases from an external storage to the R80.40 or Endpoint
Policy Server, to some directory.
Step Description
6 Click OK.
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
4 Click Install .
5 Click OK.
Step Description
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
8 Click Close.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
10. Test the functionality on the R80.40 Endpoint Security Management Server
Step Description
1 Connect with SmartConsole to the R80.40 Endpoint Security Management Server that
manages the dedicated Endpoint Policy Server.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Endpoint Security Management Server
Important - Before you upgrade an Endpoint Security Management Server or Endpoint Policy
Server:
Step Description
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server or Endpoint Policy Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. Upgrade the Endpoint Security Management Server or Endpoint Policy Server with
CPUSE
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Endpoint Security Management Server
Important - Before you upgrade an Endpoint Security Management Server or Endpoint Policy
Server:
Step Description
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server or Endpoint Policy Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Endpoint Security Management Server or Endpoint Policy Server, run
the Pre-Upgrade Verifier and export the entire management database
Step Description
Step Description
8 Transfer the exported databases from the source Endpoint Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing an Endpoint Security Management Server" on page 78.
n Follow "Installing an Endpoint Policy Server" on page 83.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Endpoint
Server, to some directory.
Step Description
Important - This step applies only if the target R80.40 Endpoint Server has a
different IP address than the source Endpoint Server.
Step Description
1 Issue licenses for the new IP address in your Check Point User Center account.
3 Wait for a couple of minutes for the Endpoint Server to detect the new licenses.
Alternatively, restart Check Point services:
cpstop
cpstart
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n This procedure is supported only for servers that run R80.20.M1, R80.20,
R80.20.M2, or R80.30.
n These instructions equally apply to:
l Endpoint Security Management Server
Important - Before you upgrade an Endpoint Security Management Server or Endpoint Policy
Server:
Step Description
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server or Endpoint Policy Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Procedure:
Step Description
2. On the current Endpoint Security Management Server or Endpoint Policy Server, run
the Pre-Upgrade Verifier and export the entire management database
Step Description
Step Description
8 Transfer the exported databases from the source Endpoint Server to an external
storage:
/<Full Path>/<Name of Database File>.tgz
Step Description
2 Perform the clean install in one of these ways (do not perform initial configuration in
SmartConsole):
n Follow "Installing Software Packages on Gaia" on page 153 - select the R80.40
package and perform Clean Install . See sk92449 for detailed steps.
n Follow "Installing an Endpoint Security Management Server" on page 78.
n Follow "Installing an Endpoint Policy Server" on page 83.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Endpoint
Server, to some directory.
Step Description
Important - This step applies only if the target R80.40 Endpoint Server has a
different IP address than the source Endpoint Server.
Step Description
1 Issue licenses for the new IP address in your Check Point User Center account.
3 Wait for a couple of minutes for the Endpoint Server to detect the new licenses.
Alternatively, restart Check Point services:
cpstop
cpstart
Step Description
6 Click OK.
Step Description
4 Click Install .
5 Click OK.
Step Description
Step Description
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.
Step Description
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
4 You must close all GUI clients (SmartConsole applications) connected to the source
Endpoint Security Management Server or Endpoint Policy Server.
6 Run the Pre-Upgrade Verifier on all source servers and fix all detected issues before
you start the upgrade.
Important - Before you can install Hotfixes on servers that work in Management High
Availability, you must upgrade all these servers.
Procedure:
Step Description
1 Upgrade the Primary Endpoint Security Management Server with one of the supported
methods.
n CPUSE
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with CPUSE" on page 501
n Advanced Upgrade
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with Advanced Upgrade" on page 506
n Migration
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with Migration" on page 514
2 Upgrade the Secondary Endpoint Security Management Server with one of the supported
methods.
n CPUSE
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with CPUSE" on page 501
n Advanced Upgrade
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with Advanced Upgrade" on page 506
n Migration
See "Upgrading an Endpoint Security Management Server or Endpoint Policy Server
from R80.20 and higher with Migration" on page 514
4 Connect with SmartConsole to the R80.40 Primary Endpoint Security Management Server.
5 Update the object version of the Secondary Endpoint Security Management Server:
6 Make sure Secure Internal Communication (SIC) works correctly with the Secondary Security
Management Server:
Step Description
Important - This step applies only if the SmartEvent Correlation Unit Software Blade
is enabled on the R80.40 Endpoint Security Management Server.
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.
For more information, see the R80.40 Logging and Monitoring Administration Guide > Chapter
Log Exporter
a. In the top left corner, click Menu > Management High Availability .
b. In the Peers section, click Actions > Sync Peer.
c. The status must show Successfully synced for all peers.
4 Schedule a full maintenance window to make sure you can make all the 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.
Procedure:
1. On the Security Gateway, upgrade to R80.40 with CPUSE, or perform a Clean Install
of R80.40
Important - You must reboot the Security Gateway after the upgrade or clean install.
Clean Install of Follow "Installing a Security Gateway" on page 94 - only the step
R80.40 from scratch "Install the Security Gateway".
Important - 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
Security Gateway (prior to the upgrade).
Step Description
6 Click Reset.
Step Description
7 In the One-time password field, enter the same Activation Key you entered during the
First Time Configuration Wizard of the Security Gateway.
8 In the Confirm one-time password field, enter the same Activation Key again.
9 Click Initialize.
Step Description
6 Click OK.
Step Description
Step Description
Step Description
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.
Important - Back up both the Management Server and the VSX Gateway.
Follow sk100395.
4 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
The upgrade process replaces all existing files with default files.
If you have custom configurations on the VSX Gateway, they are lost during the
upgrade.
As a result, different issues can occur in the upgraded VSX Gateway.
1. On the Management Server, upgrade the configuration of the VSX Gateway object
to R80.40
Step Description
Select R80.40.
/opt/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
n On a Multi-Domain Server:
/opt/CPmds-R80.40/customers/<Name_of_
Domain>/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_
HH_MM.log
Step Description
9 Make sure in the Platform section, the Version field shows R80.40.
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action
plan.
Step Description
Step Description
Step Description
3 From the left navigation panel, click Logs & Monitor > Logs .
4 Examine the logs from the Virtual Systems on this VSX Gateway to make sure they
inspect the traffic as expected.
1. On the Management Server, upgrade the configuration of the VSX Gateway object
to R80.40
Step Description
Select R80.40.
/opt/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
n On a Multi-Domain Server:
/opt/CPmds-R80.40/customers/<Name_of_
Domain>/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_
HH_MM.log
Step Description
9 Make sure in the Platform section, the Version field shows R80.40.
Important - You must reboot the VSX Gateway after the upgrade or clean install.
Clean Install of Follow "Installing a VSX Gateway" on page 100 - only the step
R80.40 from scratch "Install the VSX Gateway".
Important - 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 Gateway (prior to the upgrade).
Step Description
2 Connect to the command line on the R80.40 Security Management Server or Multi-
Domain Server that manages this VSX Gateway.
Step Description
Important - Enter the same Activation Key you entered during the First
Time Configuration Wizard of the VSX Gateway.
Step Description
3 From the left navigation panel, click Logs & Monitor > Logs .
4 Examine the logs from the Virtual Systems on this VSX Gateway to make sure they
inspect the traffic as expected.
5 If you upgrade a VSX Cluster, then on the Management Server you must upgrade the
configuration of the VSX Cluster object to R80.40.
6 Schedule a full maintenance window to make sure you can make all the 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
(see below).
Maintenance
Upgrade
Description Window Limitations
Method
(downtime)
"Multi- Select this method, if connectivity is of utmost This upgrade This upgrade
Version concern. method does method supports
Cluster Connection failover is guaranteed - no not require a only specific
(MVC) connections are dropped. downtime upgrade paths.
Upgrade" Connections that were initiated before the window. Many types of
on upgrade are synchronized with the upgraded Duration of connections do
page 575 Security Gateways and cluster members, so this upgrade is not survive after
that no connections are dropped. short. failover to
You can select this method, if you upgrade a upgraded Cluster
ClusterXL or a VSX Cluster. Member.
You can select this method, if you upgrade a 3rd See:
party cluster (VRRP on Gaia). n "Supported
Versions in
Multi-
Version
Cluster" on
page 576
n "Multi-
Version
Cluster
Limitations"
on
page 577.
"Minimal Select this method, if you have a period of time, This upgrade None
Effort during which network downtime is allowed. method
Upgrade" This method is the simplest, because it lets you requires a
on upgrade each Cluster Member as an independent substantial
page 545 Security Gateway. downtime
(Simple All connections that were initiated before the window.
Upgrade) upgrade, are dropped during the upgrade. Duration of
You can select this method, if you upgrade a this upgrade is
ClusterXL or a VSX Cluster. as long as it
You can select this method, if you upgrade a 3rd takes to
party cluster (VRRP on Gaia). upgrade all
Cluster
Members.
Maintenance
Upgrade
Description Window Limitations
Method
(downtime)
"Zero Select this method, if you cannot have any This upgrade This upgrade
Downtime network downtime and need to complete the method method does not
Upgrade" upgrade quickly, with a minimal number of requires a support Dynamic
on dropped connections. relatively short Routing
page 555 During this type of upgrade, there is always at downtime connections.
least one Active Cluster Member in cluster that window to drop
handles traffic. old
All connections that were initiated through a connections.
Cluster Member that runs the old version, are Duration of
dropped when you upgrade that Cluster this upgrade is
Member to a new version, because Cluster relatively
Members that run different Check Point software short.
versions, cannot synchronize connections.
Network connectivity, however, remains available
during the upgrade, and connections initiated
through an upgraded cluster member are not
dropped.
You can select this method, if you upgrade a
ClusterXL or a VSX Cluster.
You can select this method, if you upgrade a 3rd
party cluster (VRRP on Gaia).
Note - This applies only when the Multi-Version Cluster (MVC) Mechanism is disabled
(see "Multi-Version Cluster (MVC) Upgrade" on page 575).
When Cluster Members of different versions are on the same network, Cluster Members of the new
(upgraded) version remain in the state Ready , and Cluster Members of the previous version remain in
state Active Attention.
Cluster Members in the state Ready do not process traffic and do not synchronize with other Cluster
Members.
To prevent Cluster Members from being in the state "Ready":
Option Instructions
Important - You can use this upgrade method for all supported versions as described
in the R80.40 Release Notes.
5 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
Procedure:
1. On each Cluster Member, Upgrade to R80.40 with CPUSE, or perform a Clean Install
of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Description
Step Description
6 If you performed a Clean Install of R80.40 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 show Trust established.
j. Click Close to close the Communication window.
k. Click OK to close the Cluster Member Properties window.
Step Description
Step Description
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.
Important - Back up both the Management Server and the VSX Cluster
Members. Follow sk100395.
5 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
Procedure:
1. On the Management Server, upgrade the configuration of the VSX Cluster object to
R80.40
Step Description
Step Description
Select R80.40.
/opt/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
n On a Multi-Domain Server:
/opt/CPmds-R80.40/customers/<Name_of_
Domain>/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
9 Make sure in the Platform section, the Version field shows R80.40.
2. On each VSX Cluster Member, Upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Installation
Instructions
Method
Installation
Instructions
Method
Clean Install of a. Follow "Installing a VSX Cluster" on page 118 - only the section
R80.40 from "Install the VSX Cluster Members".
scratch Important - 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).
b. After you complete the Gaia First Time Configuration Wizard and
reboot, configure the required settings on the VSX Cluster
Member.
For more information, see the R80.40 CLI Reference Guide -
Chapter VSX Commands > Section vsx_util > Section vsx_util
reconfigure.
c. Run the "vsx_util reconfigure" command on the
Management Server to push the VSX configuration to the VSX
Cluster Member.
Important - You must enter the same Activation Key you
entered during the First Time Configuration Wizard of
the VSX Cluster Member.
d. Configure the required settings on the VSX Cluster Member:
n OS configuration (for example, DNS, NTP, DHCP, Dynamic
Routing, DHCP Relay, and so on).
n Settings manually defined in various configuration files.
n Applicable Check Point configuration files.
Step Description
Step Description
4. On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
set virtual-system 0
show cluster state
n In the Expert mode, run:
vsenv 0
cphaprob state
Important:
n All VSX Cluster Members must show the
same information about the states of all
VSX Cluster Members.
n One VSX Cluster Member must be in the
Active state, and all other VSX Cluster
Members must be in Standby state.
n All Virtual Systems must show the same
information about the states of all Virtual
Systems.
Step Instructions
set virtual-system 0
show cluster members interfaces
all
n In the Expert mode, run:
vsenv 0
cphaprob -a if
Step Description
2 From the left navigation panel, click Logs & Monitor > Logs .
3 Examine the logs from the Virtual Systems on this VSX Cluster to make sure they
inspect the traffic as expected.
Important - You can use this upgrade method for all supported versions as described
in the R80.40 Release Notes.
5 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
The procedure below is based on 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.
Procedure:
Important - This step does not apply to R80.30 with Linux kernel 3.10 (run the
"uname -r" command).
Best Practice - To avoid possible problems with switches around the cluster
during the upgrade, we recommend to change the Cluster Control Protocol
(CCP) (CCP) mode to Broadcast.
Step Description
2. On the Cluster Member M2, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
3. On the Cluster Member M3, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Description
Step Description
6 If you performed a Clean Install of R80.40 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 show Trust established.
j. Click Close to close the Communication window.
k. Click OK to close the Cluster Member Properties window.
Step Description
Step Description
Step Description
(!).
l In R80.10 and lower - Active
Attention.
7. On the old Cluster Member M1, stop all Check Point services
Step Description
Step Description
Step Description
9. On the old Cluster Member M1, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Description
6 Click Edit.
8 Click Reset.
Step Description
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
Step Description
Step Description
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.
Important - Back up both the Management Server and the VSX Cluster
Members. Follow sk100395.
5 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
The procedure below describes an example VSX Cluster with three VSX Cluster Members M1, M2 and M3.
However, you can use it for clusters that consist of two or more Cluster Members.
Procedure:
1. On the Management Server, upgrade the configuration of the VSX Cluster object to
R80.40
Step Description
Step Description
Select R80.40.
/opt/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
n On a Multi-Domain Server:
/opt/CPmds-R80.40/customers/<Name_of_
Domain>/CPsuite-R80.40/fw1/log/vsx_util_YYYYMMDD_HH_
MM.log
9 Make sure in the Platform section, the Version field shows R80.40.
Important - This step does not apply to R80.30 with Linux kernel 3.10 (run the
"uname -r" command).
Best Practice - To avoid possible problems with switches around the cluster
during the upgrade, we recommend to change the Cluster Control Protocol
(CCP) (CCP) mode to Broadcast.
Step Description
Step Description
3. On the VSX Cluster Member M2, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Installation
Instructions
Method
Installation
Instructions
Method
Clean Install of a. Follow "Installing a VSX Cluster" on page 118 - only the section
R80.40 from "Install the VSX Cluster Members".
scratch Important - 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).
b. After you complete the Gaia First Time Configuration Wizard and
reboot, configure the required settings on the VSX Cluster
Member.
For more information, see the R80.40 CLI Reference Guide -
Chapter VSX Commands > Section vsx_util > Section vsx_util
reconfigure.
c. Run the "vsx_util reconfigure" command on the
Management Server to push the VSX configuration to the VSX
Cluster Member.
Important - You must enter the same Activation Key you
entered during the First Time Configuration Wizard of
the VSX Cluster Member.
d. Configure the required settings on the VSX Cluster Member:
n OS configuration (for example, DNS, NTP, DHCP, Dynamic
Routing, DHCP Relay, and so on).
n Settings manually defined in various configuration files.
n Applicable Check Point configuration files.
4. On the VSX Cluster Member M3, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Installation
Instructions
Method
Installation
Instructions
Method
Clean Install of a. Follow "Installing a VSX Cluster" on page 118 - only the section
R80.40 from "Install the VSX Cluster Members".
scratch Important - 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).
b. After you complete the Gaia First Time Configuration Wizard and
reboot, configure the required settings on the VSX Cluster
Member.
For more information, see the R80.40 CLI Reference Guide -
Chapter VSX Commands > Section vsx_util > Section vsx_util
reconfigure.
c. Run the "vsx_util reconfigure" command on the
Management Server to push the VSX configuration to the VSX
Cluster Member.
Important - You must enter the same Activation Key you
entered during the First Time Configuration Wizard of
the VSX Cluster Member.
d. Configure the required settings on the VSX Cluster Member:
n OS configuration (for example, DNS, NTP, DHCP, Dynamic
Routing, DHCP Relay, and so on).
n Settings manually defined in various configuration files.
n Applicable Check Point configuration files.
Step Description
Step Description
6. On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
set virtual-system 0
show cluster state
n In the Expert mode, run:
vsenv 0
cphaprob state
Important:
n The cluster states of the upgraded VSX
Cluster Members M2 and M3 are Ready .
n The cluster state of the old VSX Cluster
Member M1 is:
l In R80.20 and higher - Active(!).
Attention.
7. On the old VSX Cluster Member M1, stop all Check Point services
Step Description
Step Description
8. On the upgraded VSX Cluster Members M2 and M3, examine the cluster state
Step Description
9. On the old VSX Cluster Member M1, upgrade to R80.40 with CPUSE, or perform a
Clean Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Installation
Instructions
Method
Installation
Instructions
Method
Clean Install of a. Follow "Installing a VSX Cluster" on page 118 - only the section
R80.40 from "Install the VSX Cluster Members".
scratch Important - 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).
b. After you complete the Gaia First Time Configuration Wizard and
reboot, configure the required settings on the VSX Cluster
Member.
For more information, see the R80.40 CLI Reference Guide -
Chapter VSX Commands > Section vsx_util > Section vsx_util
reconfigure.
c. Run the "vsx_util reconfigure" command on the
Management Server to push the VSX configuration to the VSX
Cluster Member.
Important - You must enter the same Activation Key you
entered during the First Time Configuration Wizard of
the VSX Cluster Member.
d. Configure the required settings on the VSX Cluster Member:
n OS configuration (for example, DNS, NTP, DHCP, Dynamic
Routing, DHCP Relay, and so on).
n Settings manually defined in various configuration files.
n Applicable Check Point configuration files.
Step Description
Step Description
11. On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
Step Instructions
set virtual-system 0
show cluster state
n In the Expert mode, run:
vsenv 0
cphaprob state
Important:
n All VSX Cluster Members must show the
same information about the states of all
VSX Cluster Members.
n One VSX Cluster Member must be in the
Active state, and all other VSX Cluster
Members must be in Standby state.
n All Virtual Systems must show the same
information about the states of all Virtual
Systems.
set virtual-system 0
show cluster members interfaces
all
n In the Expert mode, run:
vsenv 0
cphaprob -a if
Step Description
2 From the left navigation panel, click Logs & Monitor > Logs .
3 Examine the logs from the Virtual Systems on this VSX Cluster to make sure they
inspect the traffic as expected.
Step Description
4 See "Supported Versions in Multi-Version Cluster" on the next page to know if you must install a
Jumbo Hotfix Accumulator.
7 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
Member 1 Member 2
R80.40 Version X
n There are three, four, or five Cluster Members in the Multi-Version Cluster
Important - In this scenario, Jumbo Hotfix Accumulator is required:
l On Cluster Members R80.20, you must install R80.20 Jumbo Hotfix
n While the cluster contains Cluster Members that run different software versions (Multi-Version
Cluster), it is not supported to change specific settings of the cluster object in SmartConsole.
l You cannot change the cluster mode.
For example, from High Availability to Load Sharing.
l In the High Availability mode, you cannot change the recovery mode.
For example, from Maintain current active Cluster Member to Switch to higher priority
Cluster Member.
l You cannot change the cluster topology.
Do not add, remove, or edit settings of cluster interfaces (IP addresses, Network Objectives,
and so on).
In a VSX Cluster object, do not add, remove, or edit static routes.
Note - You can change these settings either before or after you upgrade all the
Cluster Members.
n While the cluster contains Cluster Members that run different software versions (Multi-Version
Cluster), you must install the policy two times.
Procedure
Important - In a VSX Cluster, it is possible to install policy only on the
upgraded VSX Cluster Members that run R80.40. After you change the
version of the VSX Cluster object to R80.40, the Management Server does
not let you change it to the previous version.
1. Make the required changes in the Access Control or Threat Prevention policy.
2. In SmartConsole, change the version of the cluster object to R80.40:
On the General Properties page > in the Platform section > in the Version field, select
R80.40 > click OK.
These connections do not survive failover between Cluster Members with different versions:
n VPN:
l During a cluster failover from an R80.40 Cluster Member to an R77.30 Cluster Member, all
VPN connections on an R80.40 Cluster Member that are inspected on CoreXL Firewall
instances #1 and higher, are lost.
l Mobile Access VPN connections.
l Remote Access VPN connections.
l VPN Traditional Mode connections.
n Static NAT connections are cut off during a cluster failover from an R80.40 Cluster Member to an
R80.10 or R77.30 Cluster Member, if VMAC mode is enabled in this cluster.
n Identity Awareness connections.
n Data Loss Prevention (DLP) connections.
n IPv6 connections.
n Threat Emulation connections.
n PSL connections that are open during fail-over and then fail-back.
In addition, see the R80.40 ClusterXL Administration Guide > Chapter High Availability and Load Sharing
Modes in ClusterXL > Section Cluster Failover.
5 Schedule a full maintenance window to make sure you can make all the custom
configurations again after the upgrade.
Note - MVC supports Cluster Members with different Gaia kernel editions (R80.40 64-
bit and R77.30 / R80.10 32-bit).
The procedure described below is based on an example cluster with three Cluster Members M1, M2 and
M3.
However, you can use it for clusters that consist of two or more.
Action plan:
1. On the Cluster Member M3:
a. Upgrade to R80.40
Note - If you perform a Clean Install of R80.40, then you must establish SIC in SmartConsole
with this Cluster Member
b. Enable the MVC
2. In SmartConsole, change the cluster object version to R80.40 and install policy on the Cluster
Member M3.
3. On the next Cluster Member M2:
a. Upgrade to R80.40
Note - If you perform a Clean Install of R80.40, then you must establish SIC in SmartConsole
with this Cluster Member
b. Enable the MVC
4. In SmartConsole, install policy on the Cluster Member M3 and M2.
5. On the remaining Cluster Member M1:
n Upgrade to R80.40
Note - If you perform a Clean Install of R80.40, then you must establish SIC in SmartConsole
with this Cluster Member
6. In SmartConsole, install policy on all the Cluster Members M1, M2, and M3.
Procedure:
1. On the Cluster Member M3, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Instructions
Step Description
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.
Step Description
11 Click Initialize.
Step Description
6 If you performed a Clean Install of R80.40 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 show Trust established.
j. Click Close to close the Communication window.
k. Click OK to close the Cluster Member Properties window.
5. In SmartConsole, install the Access Control Policy On the R80.40 Cluster Member
M3
Step Description
Step Description
On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
set virtual-system 0
show cluster state
l In the Expert mode, run:
vsenv 0
cphaprob state
Important:
l All VSX Cluster Members must show the
set virtual-system 0
show cluster members interfaces
all
l In the Expert mode, run:
vsenv 0
cphaprob -a if
7. On the Cluster Member M2, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Instructions
Step Instructions
Step Description
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
10. In SmartConsole, install the Access Control Policy On the R80.40 Cluster Members
M3 and M2
Step Description
Step Description
Step Description
On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
set virtual-system 0
show cluster state
l In the Expert mode, run:
vsenv 0
cphaprob state
Important:
l All VSX Cluster Members must show the
set virtual-system 0
show cluster members interfaces
all
l In the Expert mode, run:
vsenv 0
cphaprob -a if
12. On the old Cluster Member M1, upgrade to R80.40 with CPUSE, or perform a Clean
Install of R80.40
Important - You must reboot the Cluster Member after the upgrade or clean install.
Step Description
Step Description
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
Step Description
Step Description
On each VSX Cluster Member, examine the VSX configuration and cluster state
Step Instructions
set virtual-system 0
show cluster state
l In the Expert mode, run:
vsenv 0
cphaprob state
Important:
l All VSX Cluster Members must show the
set virtual-system 0
show cluster members interfaces
all
l In the Expert mode, run:
vsenv 0
cphaprob -a if
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.
Step Instructions
For more information, see the R80.40 ClusterXL Administration Guide > Chapter Monitoring
and Troubleshooting Clusters - Section ClusterXL Monitoring Commands > Section Viewing
Delta Synchronization.
3 Examine the number of concurrent connections in the Connections kernel table (ID 8158).
In the Expert mode, run:
fw tab -t connections -s
For complete debug procedure, see the R80.40 Next Generation Security Gateway Guide > Chapter
Kernel Debug on Security Gateway.
Notes:
n To upgrade from R80.20 or R80.30, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with CPUSE" on page 238.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
See "Installing Software Packages on Gaia" on page 153 and follow the applicable action plan.
If your Standalone manages dedicated Log Servers or SmartEvent Servers, you must upgrade
these dedicated servers to the same version as the Standalone:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
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 .
Step Description
6 Confirm.
8 Click Close.
Step Description
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 or R80.30, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Standalone, run the Pre-Upgrade Verifier and export the entire
management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
If SmartEvent Software Blade is enabled on this Standalone, then export the Events
database.
See sk110173.
9 Transfer the exported databases from the current Standalone to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP address of the source and target Standalone servers must
be the same. If it is necessary to have a different IP address on the R80.40
Standalone server, you can change it only after the upgrade procedure. Note
that you have to issue licenses for the new IP address.
4. On the R80.40 Standalone, import the databases
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Standalone,
to some directory.
Step Description
Notes:
n If you upgrade from R80 (or higher) version, and the IP addresses of
the source and target Standalone 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.40 Standalone.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Standalone must be the same.
l If it is necessary to have a different IP address on the R80.40
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
If SmartEvent Software Blade is enabled on this Standalone, then import the Events
database.
See sk110173.
If your Standalone manages dedicated Log Servers or SmartEvent Servers, you must upgrade
these dedicated servers to the same version as the Standalone:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
Step Description
5 Click OK.
Step Description
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.
Step Description
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Notes:
n To upgrade from R80.20 or R80.30, see "Upgrading a Security Management
Server or Log Server from R80.20 and higher with Advanced Upgrade" on
page 242.
n This upgrade method is supported only for servers that already run on Gaia
Operating System.
n These instructions equally apply to:
l Security Management Server
4 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the current Standalone, run the Pre-Upgrade Verifier and export the entire
management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
5
Important - This step applies only when you upgrade from R77.30 or lower.
Step Description
7
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
If SmartEvent Software Blade is enabled on this Standalone, then export the Events
database.
See sk110173.
9 Transfer the exported databases from the current Standalone to an external storage:
/<Full Path>/<Name of Database File>.tgz
Important - The IP address of the source and target Standalone must be the
same. If it is necessary to have a different IP address on the R80.40
Standalone, you can change it only after the upgrade procedure. Note that
you have to issue licenses for the new IP address.
4. On the R80.40 Standalone, import the databases
Important - Before you import the management database, we strongly
recommend to install the latest General Availability Take of the R80.40
Jumbo Hotfix Accumulator from sk165456. This makes sure the R80.40
server has the latest improvements for reported import issues.
Step Description
Step Description
4 Transfer the exported databases from an external storage to the R80.40 Standalone,
to some directory.
Notes:
n If you upgrade from R80 (or higher) version, and the IP addresses of
the source and target Standalone 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.40 Standalone.
n If you upgrade from R77.30 (or lower) version to R80.40, then the IP
addresses of the source and target Standalone must be the same.
l If it is necessary to have a different IP address on the R80.40
Step Description
8
Important - This step applies only when you upgrade from R80, R77.30 or
lower.
If SmartEvent Software Blade is enabled on this Standalone, then import the Events
database.
See sk110173.
If your Standalone manages dedicated Log Servers or SmartEvent Servers, you must upgrade
these dedicated servers to the same version as the Standalone:
n "Upgrading a Dedicated Log Server from R80.10 and lower" on page 203
n "Upgrading a Dedicated SmartEvent Server from R80.10 and lower" on page 220
Step Description
4 Click Install .
5 Click OK.
Step Description
Step Description
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.
Step Description
Step Description
2 Make sure the management database and configuration were upgraded correctly.
Important:
n You can restore a Domain only on the same Multi-Domain Server, on which you
backed it up.
n You can restore a Domain, to which a Global Policy is assigned, only if during the
Domain backup you did not purge the assigned Global Domain Revision.
Backing Up a Domain
backup-domain
For API documentation, see the Check Point Management API Reference - search for backup-domain.
Restoring a Domain
Before you can restore a Domain, you must delete the current Domain.
Before you delete the current Domain, make sure it is possible to restore it.
Run this API with the "verify-only" flag:
restore-domain
For API documentation, see the Check Point Management API Reference - search for
restore-domain.
Before you can restore a Domain, you must delete the current Domain.
You can perform this step in one of these ways:
n In SmartConsole connected to the MDS context
n With the API delete domain (see the Check Point Management API Reference)
restore-domain
For API documentation, see the Check Point Management API Reference - search for
restore-domain.
4. Restore the Standby Domain Management Servers and Domain Log Servers
When you restore the Standby Domain Management Servers and Domain Log Servers, they
must have the same IP addresses that were used when you collected the Domain backup.
For API documentation, see the Check Point Management API Reference - search for set
domain
For each Standby Domain Management Server, run this API:
You must again configure the Multi-Domain Server Administrators and GUI clients and assign
them to the Domains.
a. Configure the Multi-Domain Server Administrators and GUI clients:
i. Run the mdsconfig command
ii. Configure the Administrators
iii. Configure the GUI clients
b. Assign the Administrators and GUI clients to the Domains:
See the R80.40 Multi-Domain Security Management Administration Guide - Chapter
Managing Domains - Section Creating a New Domain and Section Assigning
Trusted Clients to Domains .
Procedure:
migrate-export-domain
For API documentation, see the Check Point Management API Reference - search for
migrate-export-domain.
b. Calculate the MD5 of the export file:
a. Transfer the export file from the source Multi-Domain Server to the target Multi-Domain
Server, to some directory.
migrate-import-domain
For API documentation, see the Check Point Management API Reference - search for
migrate-import-domain.
b. Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the state
"up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server and check
again. Run these three commands:
You must again configure the Multi-Domain Server Administrators and GUI clients and assign
them to the Domains.
a. Configure the Multi-Domain Server Administrators and GUI clients:
i. Run the mdsconfig command
ii. Configure the Administrators
iii. Configure the GUI clients
iv. Exit the mdsconfig menu
b. Assign the Administrators and GUI clients to the Domains:
See the R80.40 Multi-Domain Security Management Administration Guide - Chapter
Managing Domains - Section Creating a New Domain and Section Assigning Trusted
Clients to Domains .
a. Connect with SmartConsole to the Active Domain (to which this Domain Management
Server belongs).
b. Install the applicable policies on all managed Security Gateways and Clusters.
3 You must close all GUI clients (SmartConsole applications) connected to the source
Security Management Server.
Procedure:
1. On the source R80.40 Security Management Server, export the entire management
database
Step Description
1 Connect to the command line on the current R80.40 Security Management Server.
Step Description
For details, see the R80.40 CLI Reference Guide - Chapter Security Management
Server Commands - Section migrate_server.
6 Transfer the exported databases from the source Security Management Server to an
external storage:
/<Full Path>/<Name of Database File>.tgz
Step Description
Important - The IP addresses of the source and target R80.40 servers must
be the same. If it is necessary to have a different IP address on the R80.40
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 and sk65451.
3. On the R80.40 Security Management Server, import the databases
Step Description
4 Transfer the exported database from an external storage to the R80.40 Security
Management Server, to some directory.
Step Description
2 Make sure the management database and configuration were upgraded correctly.
cpwd_admin list
The "STAT" column must show "E" (executing) for all processes.
n Close the active Security log ($FWDIR/log/fw.log) and Audit log ($FWDIR/log/fw.adtlog)
files:
fw logswitch
fw logswitch -audit
n If the target Domain Management Server must have a different IP address than the source Security
Management Server, then you must prepare the source database before the export.
Instructions in SmartConsole
1. Create a new Host object with the new IP address of the target Domain Management
Server.
2. In each Security Policy, add a new Access Control rule to allow specific traffic from the Host
object with new IP address to all managed Security Gateways and Clusters.
Services &
N Sourc Destinatio VP Actio Trac Install
Name Application
o e n N n k On
s
Notes:
l You must use the pre-defined Check Point services.
Procedure:
migrate-export-domain
For API documentation, see the Check Point Management API Reference - search for
migrate-export-domain.
Example:
a. Transfer the export file from the source Security Management Server to the target Multi-
Domain Server, to some directory.
migrate-import-domain
For API documentation, see the Check Point Management API Reference - search for
migrate-import-domain.
Make sure the name of the Domain you create does not conflict with the name of an
existing Domain.
Example:
c. Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the state
"up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server and check
again. Run these three commands:
You must again configure the Multi-Domain Server Administrators and GUI clients and assign
them to the new Domain.
a. Configure the Multi-Domain Server Administrators and GUI clients:
i. Run the mdsconfig command.
ii. Configure the Administrators .
iii. Configure the GUI clients .
iv. Exit the mdsconfig menu.
b. Assign the Administrators and GUI clients to the new Domain.
See the R80.40 Multi-Domain Security Management Administration Guide - Chapter
Managing Domains - Section Creating a New Domain and Section Assigning Trusted
Clients to Domains .
cpstop
In SmartConsole, install the applicable policies on all managed Security Gateways and Clusters.
9. Delete the special Access Control rule you added before migration
Important - This step applies only if the target Domain Management Server
has a different IP address than the source Security Management Server.
n If the target Security Management Server must have a different IP address than the source Domain
Management Server, then you must prepare the source database before the export.
Instructions in SmartConsole
1. Create a new Host object with the new IP address of the target Security Management
Server.
2. In each Security Policy, add a new Access Control rule to allow specific traffic from the Host
object with new IP address to all managed Security Gateways and Clusters.
Services &
N Sourc Destinatio VP Actio Trac Install
Name Application
o e n N n k On
s
Notes:
l You must use the pre-defined Check Point services.
Procedure:
1. On the source R80.40 Multi-Domain Server, export the Domain Management Server
migrate-export-domain
For API documentation, see the Check Point Management API Reference - search for
migrate-export-domain.
Example:
2. Transfer the export file to the target R80.40 Security Management Server
a. Transfer the export file from the source Multi-Domain Server to the target Security
Management Server, to some directory.
3. On the target Security Management Server, import the Domain Management Server
database
Parameters
Parameter Description
-sn <Name of New Security Specifies a new name of the new Security
Management Server> Management Server object.
-dsi <IP Address of New Specifies a new IP Address of the new Security
Security Management Management Server object.
Server>
-o <Full Path to Exported Specifies the full path to the export file you
File>.tgz transferred from the source R80.40 Multi-Domain
Server.
-skip_logs Optional.
Specifies not to import log files
$FWDIR/log/fw.*log.
You must again configure the Security Management Server Administrators and GUI clients.
a. Run the cpconfig command.
b. Configure the Administrators .
In SmartConsole, install the applicable policies on all managed Security Gateways and Clusters.
Make sure you backed up the Multi-Domain Server. See "Backing Up and Restoring" on page 27.
a. Connect with SmartConsole to the source Multi-Domain Server to the MDS context.
b. From the left navigation panel, click Multi Domain > Domains .
c. Right-click the Domain Management Server object you migrated and select Delete.
9. Delete the special Access Control rule you added before migration
Important - This step applies only if the target Security Management Server
has a different IP address than the source Domain Management Server.
Procedure:
Step Description
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
3. 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.
5 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
10 Transfer the exported database from the R7x Multi-Domain Server to an external
storage:
/<Full Path>/R7x_global_policies.tgz
4. On the Primary R80.40 Multi-Domain Server, set the Global Domain to the Active
state
Step Description
3 If the Global Domain on the Primary Multi-Domain Server is in the Standby state, then
proceed to the next Step 4 in this procedure.
If the Global Domain on the Primary Multi-Domain Server is already in the Active
state, then skip to the next Step 5 in the main procedure.
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.
5. On the R80.40 Multi-Domain Server, remove all the global objects from the Global
Domain
Important - This step applies only if you already configured global objects on
the R80.40 Multi-Domain Server.
Step Description
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.
6. On the R80.40 Multi-Domain Server, import the R7x global management database to
Step Description
5 Transfer the exported database from an external storage to the R80.40 Primary Multi-
Domain Server, to some directory.
Step Description
10 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down", then wait for 5-10 minutes, restart that Domain Management Server, and
check again. Run these three commands:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
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 - This procedure is not supported for exporting the management database from
an R8x Security Management Server and importing it to an R80.40 Domain
Management Server.
Important - Before you migrate the database:
Step Description
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.
Important - Before you import the database on the Secondary Multi-Domain Server in
Management High Availability, you must change the state of its Global Domain to
Active.
Instructions
Step Description
2 From the left navigation panel, click Multi Domain > Domains .
6 Close SmartConsole.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
2. On the R7x Security Management Server, Export the entire management database
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
Step Description
7 Transfer the exported database from the R7x Standalone to an external storage:
/<Full Path>/<Name of R7x MgmtServer Exported File>.tgz
Step Description
Step Description
1 Transfer the exported R7x Security Management Server management database from
an external storage to the R80.40 Multi-Domain Server, to some directory.
Step Description
Step Description
6. Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Important:
n This step applies if the new R80.40 Domain Management Server has a
different IPv4 address than the R7x Security Management Server.
n In a Cluster, you must configure all the Cluster Members in the same
way.
When a Management Server and a managed Security Gateway establish SIC Trust, the Security
Gateway saves the IP address of the Internal Certificate Authority (ICA) of its Management
Server. The Security Gateway uses this IP address for Automatic Certificate Renewal process
when the certificate on the Security Gateway expires.
To force the Security Gateway to update the saved IP address of the Management Server's ICA,
follow one of these procedures:
cpconfig
c. Choose the option Secure Internal Communication from the menu - enter 5 press the
Enter key.
Follow the instructions on the screen to re-initialize the communication and to enter the
Activation Key.
d. Exit the Check Point Configuration Tool.
e. Wait for Check Point processes to restart.
f. Connect with SmartConsole to the Management Server that manages the Security
Gateway (Cluster) object.
g. From the left navigation panel, click Gateways & Servers .
h. Double-click the Security Gateway (Cluster) object.
i. From the left tree, click General Properties .
In a Cluster object, click Cluster Members and edit every Cluster Member object.
j. Click Communication.
k. Click Reset.
l. Enter the same Activation Key you entered on the Security Gateway (Cluster Member).
m. Click Initialize.
n. The Trust State field must show Trust established.
o. Click Close.
p. Click OK.
q. Publish the SmartConsole session.
r. Install the Access Control Policy on the Security Gateway (Cluster) object.
For more information, see sk103356: How to renew SIC after changing IP Address of
Security Management Server.
a. Connect to the command line on the Security Gateway (every Cluster Member).
b. Log in to the Expert mode.
c. Back up the current $CPDIR/registry/HKLM_registry.data file:
cp -v $CPDIR/registry/HKLM_registry.data{,_BKP}
vi $CPDIR/registry/HKLM_registry.data
e. Search for:
:ICAip
: (SIC
:ICAdn ("O=R80.40-Manager..ntk6rk")
:MySICname ("CN=R80.40-MyGW,O=R80.40-
Manager..ntk6rk")
:HasCertificate ("[4]1")
:CertPath ("/opt/CPshrd-R80.40/conf/sic_cert.p12")
:ICAip (192.168.41.80)
Important - This step applies if the original R7x Security Management Server
managed VPN gateways.
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, then 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:
n Update the external DNS server to resolve the host name to the IP address of the
applicable Domain Management Server.
n Revoke the IKE certificate for the Security Gateway and create a new one.
Note - This procedure is not supported for exporting the management database from a
specific Domain Management Server on an R8x Multi-Domain Server and importing it
on an R80.40 Multi-Domain Server.
Important - Before you migrate a database:
Step Description
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.
Important - Before you import the database on the Secondary Multi-Domain Server in
Management High Availability, you must change the state of its Global Domain to
Active.
Instructions
Step Description
2 From the left navigation panel, click Multi Domain > Domains .
6 Close SmartConsole.
Procedure:
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
Step Description
4 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
7 Export the entire management database from the Domain Management Server:
yes | nohup ./migrate export [-l | -x] /<Full
Path>/<Name of R7x Domain Exported File>
For details, see the R80.40 CLI Reference Guide - Chapter Security Management
Server Commands - Section migrate.
Step Description
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
Step Description
Important - xxx
Important - After you create the new Domain with this command, do not change the
Domain IPv4 address until you run the "cma_migrate" command.
4. Transfer the exported R7x Domain Management Server management database to the
R80.40 Multi-Domain Server
Step Description
1 Transfer the exported R7x Domain Management Server management database from
an external storage to the R80.40 Multi-Domain Server, to some directory.
5. On the R80.40 Multi-Domain Server, import the R7x Domain Management Server
management database to the new Domain Management Server
Step Description
6 Start the new Domain Management Server with the imported R7x management
database:
mdsstart_customer <IP Address or Name of Domain
Management Server>
Step Description
7 All the required daemons (FWM, FWD, CPD, and CPCA) on the new Domain
Management Server must be in the state "up" and show their PID:
mdsstat
If some of the required daemons on a Domain Management Server are in the state
"down" or "N/A" even after for 5-10 minutes, then restart that Domain Management
Server, and check again:
mdsstop_customer <IP Address or Name of Domain
Management Server>
mdsstart_customer <IP Address or Name of Domain
Management Server>
mdsstat
6. Reset SIC, create a new ICA, and establish SIC Trust with managed Security
Gateways
Important:
n This step applies if the new R80.40 Domain Management Server has a
different IPv4 address than the R7x Domain Management Server.
n In a Cluster, you must configure all the Cluster Members in the same
way.
When a Management Server and a managed Security Gateway establish SIC Trust, the Security
Gateway saves the IP address of the Internal Certificate Authority (ICA) of its Management
Server. The Security Gateway uses this IP address for Automatic Certificate Renewal process
when the certificate on the Security Gateway expires.
To force the Security Gateway to update the saved IP address of the Management Server's ICA,
follow one of these procedures:
cpconfig
c. Choose the option Secure Internal Communication from the menu - enter 5 press the
Enter key.
Follow the instructions on the screen to re-initialize the communication and to enter the
Activation Key.
d. Exit the Check Point Configuration Tool.
For more information, see sk103356: How to renew SIC after changing IP Address of
Security Management Server.
a. Connect to the command line on the Security Gateway (every Cluster Member).
b. Log in to the Expert mode.
c. Back up the current $CPDIR/registry/HKLM_registry.data file:
cp -v $CPDIR/registry/HKLM_registry.data{,_BKP}
vi $CPDIR/registry/HKLM_registry.data
e. Search for:
:ICAip
: (SIC
:ICAdn ("O=R80.40-Manager..ntk6rk")
:MySICname ("CN=R80.40-MyGW,O=R80.40-
Manager..ntk6rk")
:HasCertificate ("[4]1")
:CertPath ("/opt/CPshrd-R80.40/conf/sic_cert.p12")
:ICAip (192.168.41.80)
Important - This step applies if the original R7x Domain Management Server
managed VPN gateways.
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, then 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:
n Update the external DNS server to resolve the host name to the IP address of the
applicable Domain Management Server.
n Revoke the IKE certificate for the Security Gateway and create a new one.
Step Description
Step Description
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.
1 Make sure that the target Domain Management Server can communicate with all the
Security Gateways managed by the R7x Standalone.
Procedure:
Step Description
2 Create a new Check Point Host object to represent the R80.40 Domain Management
Server and define it as a Secondary Security Management Server.
a. Create the object in one of these ways:
n From the top toolbar, click the New ( ) > More > Check Point Host.
n In the top left corner, click Objects menu > More object types >
Network Object > Gateways & Servers > New Check Point Host.
n 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 applicable name.
c. In the IPv4 Address and IPv6 Address fields, enter the applicable IP
addresses of the R80.40 Domain Management Server.
d. In the Platform section:
n In the Hardware field, select the applicable option
n In the Version field, select the highest version.
n 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 grayed out.
g. Click OK.
Step Description
3 Create the applicable Firewall rules in all applicable policies to allow the new Check
Point Host object (that represents the R80.40 Domain Management Server) to
communicate with all managed Security Gateways.
5 Delete the new Check Point Host object (that represents the R80.40 Domain
Management Server) and the Firewall rules created in Steps 2 - 4.
Step Description
1 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.
2 Remove the R7x Standalone object from the Install On column in all policies.
6 Click OK.
8 Do not install the Network Security policy on the R7x Standalone object.
Step Description
1 Download the R80.40 Management Server Migration Tool from the R80.40 Home
Page SK (see "Management Server Migration Tool and Upgrade Tools" on
page 174).
2 Transfer the R80.40 Management Server Migration Tool package to the current
server to some directory (for example, /var/log/path_to_migration_
tool/).
Step Description
3 Go to the directory, where you put the R80.40 Management Server Migration Tool
package:
cd /var/log/path_to_migration_tool/
7 Transfer the exported database from the R7x Standalone to an external storage:
/<Full Path>/<Name of R7x StandAlone Exported File>.tgz
Step Description
Step Description
6. Transfer the exported R7x Standalone management database to the R80.40 Multi-
Domain Server
Step Description
Step Description
Step Description
When a Management Server and a managed Security Gateway establish SIC Trust, the Security
Gateway saves the IP address of the Internal Certificate Authority (ICA) of its Management
Server. The Security Gateway uses this IP address for Automatic Certificate Renewal process
when the certificate on the Security Gateway expires.
To force the Security Gateway to update the saved IP address of the Management Server's ICA,
follow one of these procedures:
cpconfig
c. Choose the option Secure Internal Communication from the menu - enter 5 press the
Enter key.
Follow the instructions on the screen to re-initialize the communication and to enter the
Activation Key.
d. Exit the Check Point Configuration Tool.
e. Wait for Check Point processes to restart.
f. Connect with SmartConsole to the Management Server that manages the Security
Gateway (Cluster) object.
g. From the left navigation panel, click Gateways & Servers .
h. Double-click the Security Gateway (Cluster) object.
i. From the left tree, click General Properties .
In a Cluster object, click Cluster Members and edit every Cluster Member object.
j. Click Communication.
k. Click Reset.
l. Enter the same Activation Key you entered on the Security Gateway (Cluster Member).
m. Click Initialize.
n. The Trust State field must show Trust established.
o. Click Close.
p. Click OK.
q. Publish the SmartConsole session.
r. Install the Access Control Policy on the Security Gateway (Cluster) object.
For more information, see sk103356: How to renew SIC after changing IP Address of
Security Management Server.
a. Connect to the command line on the Security Gateway (every Cluster Member).
b. Log in to the Expert mode.
c. Back up the current $CPDIR/registry/HKLM_registry.data file:
cp -v $CPDIR/registry/HKLM_registry.data{,_BKP}
vi $CPDIR/registry/HKLM_registry.data
e. Search for:
:ICAip
: (SIC
:ICAdn ("O=R80.40-Manager..ntk6rk")
:MySICname ("CN=R80.40-MyGW,O=R80.40-
Manager..ntk6rk")
:HasCertificate ("[4]1")
:CertPath ("/opt/CPshrd-R80.40/conf/sic_cert.p12")
:ICAip (192.168.41.80)
Important - This step applies if the original R7x Standalone managed VPN gateways.
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, then 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:
n Update the external DNS server to resolve the host name to the IP address of the
applicable Domain Management Server.
n Revoke the IKE certificate for the Security Gateway and create a new one.
The Domain Management Server object represents the Management Server component of the
R7x Standalone.
Step Description
Step Description
7 Click OK.
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
3 Create a new Security Gateway object (that represents the Gateway component of the
R7x Standalone) in one of these ways:
n From the top toolbar, click the New ( ) > Gateway .
n In the top left corner, click Objects menu > More object types > Network
Object > Gateways and Servers > New Gateway .
n In the top right corner, click Objects Pane > New > More > Network Object >
Gateways and Servers > Gateway .
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 applicable name for this Security Gateway object.
6 In the IPv4 address (and IPv6 address ) field, enter some dummy IP address.
Later, you change this IP address to the real IP address.
Step Description
10 Click OK.
You must install a separate Security Gateway to represent the Gateway component of the R7x
Standalone.
You can install the Security Gateway from scratch on the former R7x Standalone server.
Step Description
C During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select the No.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
Step Description
Step Description
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:
n Select Open server / Appliance for all Check Point models 3000 and
higher.
n 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
6 Click OK.
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
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.
Procedure:
Note - This step applies only if it is necessary to use the same physical
interface, but with a different IP address.
See the R80.40 Gaia Administration Guide > Chapter Network Management > Section Network
Interfaces > Section Physical Interfaces.
Step Description
2 Issue a new license for the new IP address of your Multi-Domain Server or Multi-
Domain Log Server.
4 Install the new license and Support Contract in the MDS context on your Multi-Domain
Server or Multi-Domain Log Server.
See "Working with Licenses" on page 771.
Step Description
Step Description
4 Go to the MDS context:
mdsenv
Step Instructions
Step Instructions
Step Instructions
Step Description
Step Description
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.
Step Description
Step Description
3 Find the object of your Multi-Domain Server or Multi-Domain Log Server that has the
current IP address.
Step Description
Step Description
Step Description
Step Instructions
13. Change the IP addresses of all existing Domain Management Servers and Domain
Log Servers
Follow "Changing the IP Address of a Domain Management Server or Domain Log Server" on
page 670.
Important Notes
n If you just installed the Secondary Multi-Domain Server or Multi-Domain Log Server, and it is
necessary to change the server's IP address, you only need to change the
$MDSDIR/conf/LeadingIP file.
n After you change the IP address of the Multi-Domain Server or Multi-Domain Log Server, you
have to synchronize the local log database again on these servers (see sk116335):
l Multi-Domain Server
l Secondary Multi-Domain Server (if it is installed in the environment)
l Multi-Domain Log Server
l Secondary Multi-Domain Log Server (if it is installed in the environment)
l Global SmartEvent Server (if it is installed in the environment)
Important:
n See "Changing the IP Address of a Multi-Domain Server or Multi-Domain Log
Server" on page 663.
n On Multi-Domain Servers in a Management High Availability environment, you
must perform the procedure below in this order:
1. Change the IP address on the Active Domain Management Server on the
Primary Multi-Domain Server
2. On the Primary Multi-Domain Server, change the state of the Active
Domain Management Server to Standby
3. On the Secondary Multi-Domain Server, change the state of the
applicable Domain Management Server to Active
4. Change the IP address on the Active Domain Management Server on the
Secondary Multi-Domain Server
n On Multi-Domain Log Servers in a Management High Availability environment,
you must perform the procedure below in this order:
1. Change the IP address on the Active Domain Log Server on the Primary
Multi-Domain Log Server
2. On the Primary Multi-Domain Log Server, change the state of the Active
Domain Log Server to Standby
3. On the Secondary Multi-Domain Log Server, change the state of the
applicable Domain Log Server to Active
4. Change the IP address on the Active Domain Log Server on the
Secondary Multi-Domain Log Server
Procedure:
You must close all GUI clients (SmartConsole applications) connected to the Multi-Domain
Server or Multi-Domain Log Server.
Step Description
4 Go to the MDS context:
mdsenv
Step Instructions
Step Instructions
Step Instructions
You can change the IP addresses of several Domain Management Servers or Domain
Log Servers in one command:
a. Make sure the services stopped in all applicable contexts.
b. Create a plain text file that contains pairs of server names and their new IPv4
addresses (separated with comma).
Example of a file:
MyDomainManagementServer_1, 172.30.40.51
MyDomainManagementServer_2, 172.30.40.52
MyDomainManagementServer_3, 172.30.40.53
c. Run this command:
$MDS_TEMPLATE/scripts/change_cma_ip.sh -f /<Path
To>/<File>
Step Description
Step Description
Step Description
Step Instructions
2 Make sure that all the required daemons (FWM, FWD, CPD, and CPCA) are in the
state "up" and show their PID (the "pnd" state is also acceptable):
mdsstat
If some of the required daemons on a Domain Management Server (Domain Log
Server) are in the state "down", then wait for 5-10 minutes, restart that Domain
Management Server (Domain Log Server), and check again. Run these three
commands:
mdsstop_customer <IP Address or Name or IP of Domain
Management Server or Domain Log Server>
mdsstart_customer <IP Address or Name or IP of Domain
Management Server or Domain Log Server>
mdsstat
Important Note
If SmartLog does not work for a Domain Management Server with the modified IP address:
1. Connect with SmartConsole to that Domain Management Server.
2. From the left navigation panel, click Gateways & Servers .
3. Open the Domain Management Server object.
4. Make any change in the Domain Management Server object (for example, in the Comment
field).
5. Click OK.
6. Publish the SmartConsole session.
Notes:
n If you manage IPS globally, you must reassign the Global Policies before
installing the policy on the managed Security Gateways.
n Starting in R80, the IPS subscription has changed. All Domains subscribed to
IPS, are automatically assigned to an "Exclusive" subscription. "Override" and
"Merge" subscriptions are no longer supported.
n For more on IPS in Multi-Domain Server environment, see the R80.40 Multi-
Domain Security Management Administration Guide.
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.
Important - Check Point Cluster does not support the Monitor Mode.
n Captive Portal.
n Identity Agent.
For more information, see sk101670: Monitor Mode on Gaia OS and SecurePlatform OS.
Note - This procedure applies to both Check Point Appliances and Open Servers.
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Management Connection window, select the interface, through which
you connect to Gaia operating system.
n In the Internet Connection window, do not configure IP addresses.
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select No.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
You can configure the Monitor Mode on an interface either in Gaia Portal, or Gaia Clish.
Step Description
Step Description
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.
9 Click OK.
Step Description
Step Description
4 If the applicable physical interface has an IP address assigned to it, remove that IP
address.
n To remove an IPv4 address:
You can configure the Security Gateway object in SmartConsole either in Wizard Mode, or in
Classic Mode.
Step Description
4 In the Check Point Security Gateway Creation window, click Wizard Mode.
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:
n Select Open server / Appliance for all Check Point models 3000 and
higher.
n 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.
Step Description
12 Click OK.
14 This Security Gateway object is now ready to receive the Security Policy.
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 applicable 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
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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
9 On the Network Security tab, make sure to enable only the Firewall Software
Blade.
Step Description
12 Click OK.
14 This Security Gateway object is now ready to receive the Security Policy.
4. Configure the Security Gateway to process packets that arrive in the wrong order
Step Description
Step Description
c. Add this line to enable the Passive Streaming Layer (PSL) Tap
Mode:
psl_tap_enable=1
d. Add this line to enable the Firewall Tap Mode:
fw_tap_enable=1
e. Save the changes in the file and exit the Vi editor.
Step Description
Notes:
n 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]).
n 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.
n This configuration is also required when you use a TAP device or
Mirror / Span ports with separated TX/RX queues.
n 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.
n 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 (Known Limitation 02386641).
5. Configure the required Global Properties for the Security Gateway in SmartConsole
Step Description
3 From the left tree, click the Stateful Inspection pane and configure:
a. In the Default Session Timeouts section:
i. Change the value of the TCP session timeout from the default 3600 to
60 seconds.
ii. Change the value of the TCP end timeout from the default 20 to 5
seconds.
b. 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).
Step Description
4 From the left tree, click the Advanced page > click the Configure button, and
configure:
a. Click FireWall-1 > Stateful Inspection.
b. Clear reject_x11_in_any .
c. Click OK to close the Advanced Configuration window.
6. Configure the required Access Control Policy for the Security Gateway in
SmartConsole
Ste
Description
p
Ste
Description
p
5
Best Practice
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.
7. Make sure the Security Gateway enabled the Monitor Mode for Software Blades
Step Description
On the Security Gateway, connect the interface in the Monitor Mode to the mirror or SPAN port on
the switch.
Note - This procedure applies to both Check Point Appliances and Open Servers.
Procedure:
Important - Make sure the VSX Gateway has enough physical interfaces.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Management Connection window, select the interface, through which
you connect to Gaia operating system.
n In the Internet Connection window, do not configure IP addresses.
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select No.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
You can configure the Monitor Mode on an interface either in Gaia Portal, or Gaia Clish.
Step Description
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.
9 Click OK.
Step Description
Step Description
4 If the applicable physical interface has an IP address assigned to it, remove that IP
address.
n To remove an IPv4 address:
3. Configure the VSX Gateway to process packets that arrive in the wrong order
Step Description
Step Description
c. Add this line to enable the Passive Streaming Layer (PSL) Tap
Mode:
psl_tap_enable=1
d. Add this line to enable the Firewall Tap Mode:
fw_tap_enable=1
e. Save the changes in the file and exit the Vi editor.
Step Description
Notes:
n 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]).
n 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.
n This configuration is also required when you use a TAP device or
Mirror / Span ports with separated TX/RX queues.
n This configuration will make the Mirror Port on VSX Gateway work
better for the first 10-30 minutes when processing connections, in
which the TCP-SYN packet did not arrive.
n 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 (Known Limitation 02386641).
4. Configure the VSX Gateway object in SmartConsole
Step Description
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 applicable 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.40.
e. Click Next.
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. In SmartConsole, on the VSX Gateway General Properties page, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
7 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
applicable Virtual Network Device at this time (we recommend to do this later) -
Virtual Switch or Virtual Router.
b. Click Next.
Step Description
8 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.
5. Configure the Virtual System object (and other Virtual Devices) in SmartConsole
Step Description
Step Description
2 Configure the applicable 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.
4 Disable the Anti-Spoofing on the interface that is configured in the Monitor Mode:
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.
6. Configure the required Global Properties for the Virtual System in SmartConsole
Step Description
Step Description
3 From the left tree, click the Stateful Inspection pane and configure:
a. In the Default Session Timeouts section:
i. Change the value of the TCP session timeout from the default 3600 to
60 seconds.
ii. Change the value of the TCP end timeout from the default 20 to 5
seconds.
b. 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).
4 From the left tree, click the Advanced page > click the Configure button, and
configure:
a. Click FireWall-1 > Stateful Inspection.
b. Clear reject_x11_in_any .
c. Click OK to close the Advanced Configuration window.
7. Configure the required Access Control policy for the Virtual System in SmartConsole
Ste
Description
p
Ste
Description
p
5
Best Practice
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:
n Select Enable aggressive aging.
n Select Specific and enter 60.
i. Click OK.
j. Close the Object Explorer.
8. Make sure the VSX Gateway enabled the Monitor Mode for Software Blades
Step Description
Step Description
On the VSX Gateway, connect the interface in the Monitor Mode to the mirror or SPAN port on the
switch.
Step Description
2 From the left navigation panel, click Security Policies > Threat Prevention.
Notes:
n We recommend the Optimized profile.
n The Track setting Packet Capture is optional.
5 From the left tree, click the General Policy page and configure:
6 From the left tree, click the Anti-Virus page and configure:
a. In the Protected Scope section, select Inspect incoming and outgoing files .
b. In the File Types section:
n Select Process all file types .
n Optional: Select Enable deep inspection scanning (impacts performance).
c. Optional: In the Archives section, select Enable Archive scanning (impacts
performance).
7 From the left tree, click the Threat Emulation page > click General and configure:
n In the Protected Scope section, select Inspect incoming files from the following
interfaces and from the menu, select All .
9 Click OK.
Step Description
Step Description
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.
6 Click OK to close the Application Control & URL Filtering Settings window.
Step Description
2 From the left navigation panel, click Manage & Settings > Blades .
4 In SmartDashboard:
n In the Data column, right-click the pre-defined data types and select Edit.
l On the General Properties page, in the Flag field, select Improve Accuracy .
l In the Customer Names data type, we recommend to add the company's real
customer names.
n In the Action column, you must select Detect.
n In the Severity column, select Critical or High in all applicable rules.
n You may choose to disable or 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.
7 Click Launch Menu > File > Update (or press the CTRL S keys).
Step Description
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
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.
Support
Support
of a
of a Support of VSX
Security
Software Blade ClusterXL Virtual Systems
Gateway
in Bridge in Bridge Mode
in Bridge
Mode
Mode
Support
Support
of a
of a Support of VSX
Security
Software Blade ClusterXL Virtual Systems
Gateway
in Bridge in Bridge Mode
in Bridge
Mode
Mode
IPsec VPN No No No
Mobile Access No No No
Notes:
1. Does not support the Anti-Virus in Traditional Mode.
2. HTTPS Inspection in Layer 2 works as Man-in-the-Middle, based on MAC
addresses:
n Client sends a TCP [SYN] packet to the MAC address X.
n Security Gateway creates a TCP [SYN-ACK] packet and sends it to the
MAC address X.
n Security Gateway in Bridge Mode does not need IP addresses, because
CPAS takes the routing and the MAC address from the original packet.
Note - To be able to perform certificate validation (CRL/OCSP download),
Security Gateway needs at least one interface to be assigned with an IP
address. Probe bypass can have issues with Bridge Mode. Therefore, we do not
recommend Probe bypass in Bridge Mode configuration.
3. Identity Awareness in Bridge Mode supports only the AD Query authentication.
Note - This procedure applies to both Check Point Appliances and Open Servers.
Item Description
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.
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Management Connection window, select the interface, through which
you connect to Gaia operating system.
n In the Internet Connection window, do not configure IP addresses.
n In the Installation Type window, select Security Gateway and/or Security
Management.
n 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.
n In the Dynamically Assigned IP window, select No.
n In the Secure Internal Communication window, enter the applicable
Activation Key (between 4 and 127 characters long).
You configure the Bridge interface in either Gaia Portal, or Gaia Clish.
Step Description
1 In the left navigation tree, click Network Management > Network Interfaces .
2 Make sure that the slave interfaces, which you wish to add to the Bridge interface,
do not have IP addresses assigned.
4 On the Bridge tab, enter or select a Bridge Group ID (unique integer between 1
and 1024).
Step Description
5 Select the interfaces from the Available Interfaces list and then click Add.
Notes:
n Make sure that the slave interfaces do not have any IP addresses
or aliases configured.
n Do not select the interface that you configured as Gaia
Management Interface.
n A Bridge interface in Gaia can contain only two slave interfaces.
6 On the IPv4 tab, enter the IPv4 address and subnet mask.
You can optionally select the Obtain IPv4 Address automatically option.
7 On the IPv6 tab (optional), enter the IPv6 address and mask length.
You can optionally select the Obtain IPv6 Address automatically option.
Important - First, you must enable the IPv6 Support and reboot.
8 Click OK.
Step Description
3 Make sure that the slave interfaces, which you wish to add to the Bridge interface,
do not have IP addresses assigned:
show interface <Name of Interface> ipv4-address
show interface <Name of Interface> ipv6-address
Step Description
Important - First, you must enable the IPv6 Support and reboot.
You can configure the ClusterXL object in either Wizard Mode, or Classic Mode.
Step Description
Step Description
4 In the Check Point Security Gateway Creation window, click Wizard Mode.
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:
n Select Open server / Appliance for all Check Point models 3000 and
higher.
n 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.
11 Click OK.
13 This Security Gateway object is now ready to receive the Security Policy.
Step Description
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 applicable 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.
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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
11 Click OK.
13 This Security Gateway object is now ready to receive the Security Policy.
4. Configure the applicable Security Policies for the Security Gateway in SmartConsole
Step Description
Step Description
4 Create the applicable rules in the Access Control and Threat Prevention policies.
Important - See the Supported Software Blades in Bridge Mode and
Limitations in Bridge Mode sections in "Deploying a Security Gateway or a
ClusterXL in Bridge Mode" on page 711.
Item Description
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.
Procedure:
Best Practice - If you configure Bridge Mode Active / Standby, then disable STP,
RSTP, and MSTP on the adjacent switches. See the applicable documentation for your
switches.
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select Security Gateway only.
b. In the Clustering section, select these two options:
l Unit is a part of a cluster
l ClusterXL
You can configure the ClusterXL object in either Wizard Mode, or Classic Mode.
Step Description
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 applicable 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.
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
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:
n 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.
n For cluster synchronization interfaces, select Cluster
Synchronization and select Primary only. Check Point cluster
supports only one synchronization network.
n 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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
For more information, click the (?) button in the top right corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right corner.
Important:
n Make sure the Bridge interface and Bridge slave interfaces are not
in the Topology.
n You cannot define the Topology of the Bridge interface. It is
External by default.
15 Click OK.
Step Description
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
For more information, click the (?) button in the top right corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right corner.
Important:
n Make sure the Bridge interface and Bridge slave interfaces are not
in the Topology.
n You cannot define the Topology of the Bridge interface. It is
External by default.
11 Click OK.
Step Description
4 Create the applicable rules in the Access Control and Threat Prevention policies.
Important - See the Supported Software Blades in Bridge Mode and
Limitations in Bridge Mode sections in "Deploying a Security Gateway or a
ClusterXL in Bridge Mode" on page 711.
Step Description
Step Description
Item Description
2 Run:
cpconfig
4 Enter y to confirm.
Step Description
Step Description
Cluster Mode: High Availability (Active Up, Bridge Mode) with IGMP Membership
Notes:
n This procedure applies to both Check Point Appliances and Open Servers.
n This procedure describes ClusterXL in Active/Active Bridge Mode deployed with
two or four switches.
Item Description
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.
8 Second Cluster Member in Bridge Mode (in the Active cluster state).
Item Description
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.
Item Description
3 Switch that connects the first network segment to one bridged slave interface (6) on the
ClusterXL in Bridge Mode.
Item Description
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.
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.
Procedure:
Step Description
3 During the First Time Configuration Wizard, you must configure these settings:
n In the Installation Type window, select Security Gateway and/or Security
Management.
n In the Products window:
a. In the Products section, select Security Gateway only.
b. In the Clustering section, select these two options:
l Unit is a part of a cluster
l ClusterXL
You configure the Bridge interface in either Gaia Portal, or Gaia Clish.
Step Description
1 In the left navigation tree, click Network Management > Network Interfaces .
2 Make sure that the slave interfaces, which you wish to add to the Bridge interface,
do not have IP addresses assigned.
4 On the Bridge tab, enter or select a Bridge Group ID (unique integer between 1
and 1024).
5 Select the interfaces from the Available Interfaces list and then click Add.
Notes:
n Make sure that the slave interfaces do not have any IP addresses
or aliases configured.
n Do not select the interface that you configured as Gaia
Management Interface.
n A Bridge interface in Gaia can contain only two slave interfaces.
6 On the IPv4 tab, enter the IPv4 address and subnet mask.
You can optionally select the Obtain IPv4 Address automatically option.
7 On the IPv6 tab (optional), enter the IPv6 address and mask length.
You can optionally select the Obtain IPv6 Address automatically option.
Important - First, you must enable the IPv6 Support and reboot.
8 Click OK.
Step Description
Step Description
3 Make sure that the slave interfaces, which you wish to add to the Bridge interface,
do not have IP addresses assigned:
show interface <Name of Interface> ipv4-address
show interface <Name of Interface> ipv6-address
You can configure the ClusterXL object in either Wizard Mode, or Classic Mode.
Step Description
Step Description
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 applicable 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 Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, 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:
n 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.
n For cluster synchronization interfaces, select Cluster
Synchronization and select Primary only. Check Point cluster
supports only one synchronization network.
n 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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
For more information, click the (?) button in the top right corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right corner.
Step Description
Important:
n Make sure the Bridge interface and Bridge slave interfaces are not
in the Topology.
n You cannot define the Topology of the Bridge interface. It is
External by default.
15 Click OK.
Step Description
Step Description
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.40.
c. In the OS field, select Gaia.
Step Description
If the Trust State field does not show Trust 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 SmartConsole, click Reset.
g. Enter the same Activation Key you entered in the cpconfig menu.
h. In SmartConsole, click Initialize.
Step Description
For more information, click the (?) button in the top right corner.
ii. Optional: Select Use Virtual MAC.
For more information, see sk50840.
iii. Select the Cluster Member recovery method.
For more information, click the (?) button in the top right corner.
Step Description
Important:
n Make sure the Bridge interface and Bridge slave interfaces are not
in the Topology.
n You cannot define the Topology of the Bridge interface. It is
External by default.
11 Click OK.
Step Description
Step Description
4 Create the applicable rules in the Access Control and Threat Prevention policies.
Important - See the Supported Software Blades in Bridge Mode and
Limitations in Bridge Mode sections in "Deploying a Security Gateway or a
ClusterXL in Bridge Mode" on page 711.
Step Description
Cluster Mode: High Availability (Active Up, Bridge Mode) with IGMP Membership
Important - In a Cluster, you must configure all the Cluster Members in the same way.
By default, Security Gateway and Cluster in Bridge mode allows Ethernet frames that carry protocols other
than IPv4 (0x0800), IPv6 (0x86DD), or ARP (0x0806) protocols.
Administrator can configure a Security Gateway and Cluster in Bridge Mode to either accept, or drop
Ethernet frames that carry specific protocols.
When Access Mode VLAN (VLAN translation) is configured, BPDU frames can arrive with the wrong VLAN
number to the switch ports through the Bridge interface. This mismatch can cause the switch ports to enter
blocking mode.
In Active/Standby Bridge Mode only, you can disable BPDU forwarding to avoid such blocking mode:
Step Description
1 Connect to the command line on the Security Gateway (each Cluster Member).
Item Description
2 Router
4 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
Configure the Security Gateway to reroute packets on the Bridge interface.
Set the value of the kernel parameter "fwx_bridge_reroute_enabled" to 1.
The Security Gateway makes sure that the MD5 hash of the packet that leaves the Management Interface
and enters the Bridge interface is the same.
Other packets in this connection are handled by the Bridge interface without using the router.
Notes:
n To make the change permanent (to survive reboot), you configure the value of
the required kernel parameter in the configuration file.
This change applies only after a reboot.
n To apply the change on-the-fly (does not survive reboot), you configure the
value of the required kernel parameter with the applicable command.
Step Description
7 After the reboot, make sure the Security Gateway loaded the new configuration:
fw ctl get int fwx_bridge_reroute_enabled
The output must return
fwx_bridge_reroute_enabled = 1
Services &
Name Source Destination VPN Action Track Install On
Applications
IPv6 Network object Network object Any neighbor-advertisement Accept Log Policy
Neighbor that represents that represents neighbor-solicitation Targets
Discovery the Bridged the Bridged router-advertisement
Network Network
router-solicitation
redirect6
To configure the Security Gateway to accept only specific protocols that are not IPv4, IPv6, or ARP:
Step Instructions
1 On the Security Gateway, configure the value of the kernel parameter fwaccept_unknown_
protocol to 0.
Important - In a Cluster, you must configure all the Cluster Members in the same way.
Step Instructions
\\
\\ User defined INSPECT code
\\
allowed_ethernet_protocols={ <0x0800,0x86DD,0x0806>);
dropped_ethernet_protocols={ <0x8137,0x8847,0x9100> );
endif /*__user_def__*/
3 In SmartConsole, install the Access Control Policy on this Security Gateway object.
Link State Propagation is supported on Check Point Appliances with these Expansion Line Cards:
You can configure the Link State Propagation in one of these modes:
Automatic port detection and port Security Gateways and Cluster Members automatically assign all
pair creation bridged ports to port pairs.
Manual port pair creation You manually configure the assignment of bridged ports to port
pairs.
Important:
n In a Cluster, you must configure all the Cluster Members in the
same way.
n Link State Propagation does not support Bond interfaces.
Step Description
1 Connect to the command line on the Security Gateway or each Cluster Member.
Step Description
8 Make sure the Security Gateway or Cluster Members loaded the new configuration:
fw ctl get int fw_link_state_propagation_enabled
The returned output must show:
fw_link_state_propagation_enabled = 1
Step Description
1 Connect to the command line on the Security Gateway or each Cluster Member.
Step Description
Step Description
8 Make sure the Security Gateway or Cluster Members loaded the new configuration:
a. Output of this command
fw ctl get int fw_link_state_propagation_enabled
must return
fw_link_state_propagation_enabled = 1
b. Output of this command
fw ctl get int fw_manual_link_state_propagation_
enabled
must return
fw_manual_link_state_propagation_enabled = 1
c. Output of this command
fw ctl get str fw_lsp_pair1
must return the names of the interfaces configured in this pair
<interface_name_1,interface_name_2>
d. Output of this command
fw ctl get str fw_lsp_pair2
must return the names of the interfaces configured in this pair
<interface_name_3,interface_name_4>
e. Output of this command
fw ctl get str fw_lsp_pair3
must return the names of the interfaces configured in this pair
<interface_name_5,interface_name_6>
f. Output of this command
fw ctl get str fw_lsp_pair4
must return the names of the interfaces configured in this pair
<interface_name_7,interface_name_8>
Baseline
Name of Policy Description
Security
Initial Policy InitialPolicy Security before a policy is installed for the first time, or when
Security Gateway failed to load the policy.
Important - If you disable the boot security or unload the currently installed policy, you
leave your Security Gateway, or a Cluster Member without protection.
Best Practice - 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.40 CLI Reference Guide:
Command Description
Boot Security
The Boot Security protects the Security Gateway and its networks, during the boot:
n Disables the IP Forwarding in Linux OS kernel
n Loads the Default Filter Policy
Important - In a Cluster, you must configure all the Cluster Members in the same way.
The Default Filter Policy (defaultfilter) protects the Security Gateway from the time it boots up
until it installs the user-defined Security Policy.
Boot Security disables IP Forwarding and loads the Default Filter Policy.
There are three Default Filters templates on the Security Gateway:
Default Filter
Default Filter Policy File Description
Mode
Default Filter
Default Filter Policy File Description
Mode
Step Description
1 Make sure to configure and install a Security Policy on the Security Gateway.
Step Description
n The new complied Default Filter file for IPv4 traffic is:
$FWDIR/state/default.bin
n The new complied Default Filter file for IPv6 traffic is:
$FWDIR/state/default.bin6
8 Copy new complied Default Filter file to the path of the Default Filter Policy file.
n For IPv4 traffic, run:
cp -v $FWDIR/state/default.bin
/etc/fw.boot/default.bin
n For IPv6 traffic, run:
cp -v $FWDIR/state/default.bin6
/etc/fw.boot/default.bin6
Important - If the new Default Filter Policy fails and blocks all access
through the network interfaces, you can unload that Default Filter
Policy and install the working policy.
Administrators with Check Point INSPECT language knowledge can define customized Default Filters.
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.
Step Description
6 Edit the new Default Filter Policy file to include the applicable INSPECT code.
Important - Your customized Default Filter must not use these
functions:
n Logging
n Authentication
n Encryption
n Content Security
n The new complied Default Filter file for IPv4 traffic is:
$FWDIR/state/default.bin
n 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.
n For IPv4 traffic, run:
cp -v $FWDIR/state/default.bin
/etc/fw.boot/default.bin
n For IPv6 traffic, run:
cp -v $FWDIR/state/default.bin6
/etc/fw.boot/default.bin6
Important - If the new Default Filter Policy fails and blocks all access
through the network interfaces, you can unload that Default Filter
Policy and install the working policy.
It is sometimes necessary to stop the Security Gateway for maintenance. It is not always practical to
disconnect the Security Gateway from the network (for example, if the Security Gateway is on a remote
site).
To stop the Security Gateway for maintenance and maintain security, you can run:
Command Description
Note - Only security rules that do not use user space processes continue
to work.
Note - During a Check Point upgrade, a SIC certificate reset, or license expiration, the
Initial Policy overwrites the user-defined policy.
The sequence of actions during boot of the Security Gateway until a Security Policy is loaded for the first
time:
Step Description
2 The Security Gateway disables IP Forwarding and loads the Default Filter policy.
5 The Security Gateway fetches the Initial Policy from the local directory.
6 Administrator installs the user-defined Security Policy from the Management Server.
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 policy.
There are different Initial Policies for Standalone and distributed setups:
n 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.
n 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:
l Allows the cpd and fwd daemons to communicate for SIC (to establish trust) and for Policy
installation.
l Does not allow CPMI connections through the Security Gateway.
The SmartConsole is 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
See the R80.40 CLI Reference Guide > Chapter Security Gateway Commands > Section cplic.
n When Security Gateways are not connected to the Internet, you can add, delete, attach, and detach
your licenses in SmartUpdate. See "Using SmartUpdate" on page 781.
When Security Gateways are connected to the Internet, they are able to get and update their
licenses and contracts without SmartUpdate.
Step Description
1 In SmartConsole, from the left navigation panel, click Gateways & Servers .
Column Description
Step Description
Step Description
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:
n Quota information, quota-dependent license statuses, and blade
information messages are only supported for R80 and above.
n The tooltip of the SKU is the product name.
The possible values for the Software Blade License Status are:
Status Description
Available The Software Blade is not active, but the license is valid.
About to The Software Blade is active, but the license will expire in 30 days (default) or less (7
Expire days or less for an evaluation license).
Quota The Software Blade is active, and the license is valid, but the quota of related objects
Exceeded (Security Gateways, files, Virtual Systems, and so on, depending on the blade) is
exceeded.
Quota The Software Blade is active, and the license is valid, but the number of objects of this
Warning blade is 90% (default) or more of the licensed quota.
Option Description
License To see and export license information for Software Blades on each specific Security
Status view Management Server, Security Gateway, or Log Server object.
License To see filter and export license status information for all configured Security
Status report Management Server, Security Gateway, or Log Server objects.
License To see filter and export license information for Software Blades on all configured
Inventory Security Management Server, Security Gateway, or Log Server objects.
report
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 Software Blade on Security Management Server.
The Gateways & Servers view in SmartConsole lets you view, filter, and export different license reports:
The Gateways & Servers view in SmartConsole lets you view and export the License Inventory
report.
Step Description
1 In SmartConsole, from the left navigation panel, click Gateways & Servers .
l License Statuses
l License statuses
l CK
l SKU
l Account ID
l Support Level
Step Description
The Logs & Monitor view in SmartConsole lets you view, filter, and export the License Status report.
Step Description
1 In SmartConsole, from the left navigation panel, click Logs & Monitor
Step Description
1 In the top right corner, click the Options button > click View Filter.
The Edit View Filter window opens.
Step Description
Step Description
The Logs & Monitor view in SmartConsole lets you view, filter, and export the License Inventory
report.
Step Description
1 In SmartConsole, from the left navigation panel, click Logs & Monitor
l License Statuses
l License statuses
l CK
l SKU
l Account ID
l Support Level
Step Description
1 In the top right corner, click the Options button > click Report Filter.
The Edit Report Filter window opens.
Step Description
Adding a license
Step Description
2 Click New.
The Add License window opens.
3 Enter the license data manually, or click Paste License to enter the data automatically.
Note - 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.
Deleting a license
Step Description
3 Click Delete.
Step Description
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:
1. Connect with SmartConsole to the (Primary) Security Management Server.
2. Open the Security Management Server object.
3. In the left tree, click Network Management.
4. Make sure to update the IP Address and topology.
5. Click OK.
6. Publish the SmartConsole session.
7. Install the database:
a. In the top left corner, click Menu > Install database.
b. Select all objects.
c. Click Install .
d. 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.
Step Description
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.
Step Description
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:
1. Connect with SmartConsole to the applicable Management Server that manages your
dedicated Log Server or SmartEvent Server.
2. Open the object of your dedicated Log Server or SmartEvent Server.
3. In the left tree, click Network Management.
4. Make sure to update the IP Address and topology.
5. Click OK.
6. Publish the SmartConsole session.
7. Install the database:
a. In the top left corner, click Menu > Install database.
b. Select all objects.
c. Click Install .
d. Click OK.
8. 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
When Security Gateways are not connected to the Internet, you can add, delete, attach, and detach your
licenses in SmartUpdate.
When Security Gateways are connected to the Internet, they are able to get and update their licenses and
contracts without SmartUpdate.
SmartUpdate distributes licenses and software packages for managed Check Point and OPSEC Certified
products.
SmartUpdate 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:
n Maintaining licenses
n Upgrading packages for R77.30 and below
n Adding packages to Package Repository for R77.30 and below
Important:
n The SmartUpdate GUI shows two tabs - Package Management and Licenses
& Contracts .
n For versions R80.10 and above, the tools in the Package Management tab are
no longer supported.
n To install packages on Gaia OS, use CPUSE (see sk92449), or Central
Deployment Tool (see sk111158).
For further information, see "Installing Software Packages on Gaia" on
page 153.
Accessing SmartUpdate
Step Description
C:\Program
Files\CheckPoint\SmartConsole\<
Rxx>\PROGRAM\SmartDistributor.exe
l 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.
Local The Local license is an older method of licensing that is still supported.
n A Local license is tied to the IP address of the specific Security Gateway.
n Cannot be transferred to a Security Gateway with a different IP address.
Add You can add any license that you receive from the User Center to the Licenses &
Contracts Repository .
n You can add the licenses directly from a User Center account.
n You can add the licenses from a file that you receive from the User Center.
n You can add the licenses manually by pasting or typing the license details.
When you add the Local license to the Licenses & Contracts Repository , it also
attaches it to the Security Gateway with the IP address, for which the license was issued.
See "Adding New Licenses to the Licenses & Contracts Repository" on page 787.
Attach You can attach a license from the Licenses & Contracts Repository to a managed
Security Gateway.
See "Attaching a License to a Security Gateway" on page 791.
Detach When you detach a license from a managed Security Gateway, you have to 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.
See "Detaching a License from a Security Gateway" on page 792.
Get 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 .
See "Getting Licenses from Security Gateways" on page 793.
Delete You can delete a license from the Licenses & Contracts Repository .
See "Deleting a License from the Licenses & Contracts Repository" on page 790.
Export You can export a license from the Licenses & Contracts Repository to a file.
See "Exporting a License to a File" on page 794.
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:
n Attached - Indicates that the license is associated with a managed Security
Gateway in the Licenses & Contracts Repository , and is installed on that Security
Gateway.
n 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.
n 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 This is a field in the Licenses & Contracts Repository that contains an error message
Status from the User Center when the License Upgrade process fails.
Local A Local License is tied to the IP address of the specific Security Gateway.
License You can only use a local license with a Security Gateway or a Security Management
Server with the same address.
Multi- This is a license file that contains more than one license.
License The "cplic put" and "cplic add" commands support these files.
File
Notes:
n Unattached Central licenses appear in the Licenses & Contracts Repository .
n When you add the Local license to the Licenses & Contracts Repository , the
Management Server attaches it to the Security Gateway with the IP address, for
which the license was issued.
n All licenses are assigned a default name in the format <SKU>@<Time Date> ,
which you can modify later.
Step Description
3 Click Licenses & Contracts menu at the top > Add License > From User Center.
Step Description
4 Click the Licenses & Contracts menu at the top > Add License > From File.
6 Click Open.
Step Description
4 Click the Licenses & Contracts menu at the top > Add License > Manually .
n Copy the applicable string from the User Center e-mail and click Paste
License.
n Paste the applicable information you copied from the User Center.
Note - If you leave the Name field empty, the license is assigned a
name in the format <SKU>@<Time Date> .
Step Description
6 Click OK.
Step Description
3 If you do not see the window License And Contract Repository , then click the Licenses &
Contracts menu at the top > click 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
3 Click the Licenses & Contracts menu at the top > click Attach.
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.
3 Click the Licenses & Contracts menu at the top > click Detach.
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
3 Click the Licenses & Contracts menu at the top > click Get all Licenses .
Step Description
3 If you do not see the window License And Contract Repository , then click the Licenses &
Contracts menu at the top > click 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 applicable file name and click Save.
Note - If the license file with such name already exists, the new licenses are added
to the existing file.
Step Description
3 If you do not see the window License And Contract Repository , then click the 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 applicable file name and click Save.
Note - If the license file with such name already exists, the new licenses are added
to the existing file.
Best Practice - We recommend to be aware of the pending expiration dates of all licenses.
Step Description
3 Click the Licenses & Contracts menu at the top > click Show Expired.
4 In the License/Contract Expiration window, the expired licenses appear in the Expired
License and Contracts section.
Step Description
3 Click the Licenses & Contracts menu at the top > click Show Expired.
4 In the License/Contract Expiration window, set the applicable number of days in the field
Search for licenses/contracts expiring within the next X days .
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
1 In the top left corner, click Menu > Global properties > Security Management Access .
3 Click OK.
Note - In some cases, the download process sends a minimal amount of required data
about your Check Point installation to the Check Point User Center.