CP R70 Internet Installation and UpgradeGuide

Installation and Upgrade Guide
Internet Security Product Suite

Version R70
701313 March 2, 2009

© 2003-2009 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.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
Please refer to http://www.checkpoint.com/copyright.html for a list of our trademarks
For third party notices, see http://www.checkpoint.com/3rd_party_copyright.html.

Contents
Installation Section
Chapter 1 Introduction
Welcome......................................................................................................... 15
Who Should Use This Guide.............................................................................. 16
R70 Documentation......................................................................................... 16
New Terms...................................................................................................... 17
Related Documentation .................................................................................... 18
For New Check Point Customers........................................................................ 19
Endpoint Security Integration............................................................................ 20
More Information ............................................................................................. 20
Feedback ........................................................................................................ 20
Chapter 2 Getting Started

Terminology .................................................................................................... 22
Provider-1/SiteManager-1 Terminology............................................................... 23
Hardware and Software Requirements................................................................ 24
Compatibility Tables ........................................................................................ 25
Product Notes ............................................................................................ 25
Platform Notes ........................................................................................... 26
Supported Upgrade Paths and Interoperability .................................................... 27
Upgrade Paths and Interoperability............................................................... 27
Upgrading Security Management Servers....................................................... 27
Backward Compatibility For Gateways ........................................................... 27
IPS-1 Upgrade Paths and Interoperability...................................................... 28
Licensing R70................................................................................................. 29
Licensing R70 ............................................................................................ 29
Licensing Provider-1/SiteManager-1 ............................................................. 30
Licensing IPS-1 .......................................................................................... 31
Licensing Eventia Suite ............................................................................... 31
Chapter 3 Setup and Installation

Overview ......................................................................................................... 34
Installing on SecurePlatform ............................................................................. 35
Installing SecurePlatform Using the CD ........................................................ 35
Installing SecurePlatform from the Network................................................... 37
Initially Configuring SecurePlatform.............................................................. 41
Installing R70 Products on SecurePlatform ................................................... 42
Table of Contents 5
Configuring SecurePlatform Using WebUI ..................................................... 43
Installing on Windows ...................................................................................... 44
Installing on Solaris or Linux............................................................................. 46
Installing on Nokia........................................................................................... 48
Enabling Native IPSO Security Servers.......................................................... 50
Initially Configuring Products ............................................................................ 51
Configuration Tool Overview ......................................................................... 51
Using the Configuration Tool on Windows Systems ......................................... 52
Using the Configuration Tool on Unix Systems ............................................... 54
Logging In for the First Time........................................................................ 55
Where To From Here?....................................................................................... 58
Chapter 4 Installing Provider-1

Overview ......................................................................................................... 60
Creating the Provider-1 Environment ................................................................. 61
Setting Up Provider-1 Networking ................................................................ 61
Install the Gateways .................................................................................... 62
Installing and Configuring the Primary MDS .................................................. 62
Installing SmartConsole and MDG Clients ..................................................... 70
Using the MDG for the First Time ...................................................................... 71
Launching the MDG .................................................................................... 71
Adding Licenses using the MDG ................................................................... 72
Where To From Here?....................................................................................... 75
Chapter 5 IPS-1 Setup and Installation

Overview ......................................................................................................... 78
IPS-1 System Architecture........................................................................... 78
Platforms ................................................................................................... 79
IPS-1 Deployment ........................................................................................... 80
IPS-1 Sensor Deployment ............................................................................ 80
IPS-1 Management Deployment ................................................................... 81
IPS-1 Management Installation and Setup ......................................................... 84
Installation of IPS-1 Management Servers ..................................................... 84
IPS-1 Sensor Appliances .................................................................................. 89
Introduction ............................................................................................... 89
IPS-1 Sensor Appliance Models ................................................................... 89
IPS-1 Sensor Installation.................................................................................. 94
Connecting to IPS-1 Sensors........................................................................ 94
Installing SecurePlatform and IPS-1 Sensors................................................. 94
Initial Configuration of IPS-1 Sensors ........................................................... 95
Initial Configuration of IPS-1 Power Sensor ................................................... 97
IPS-1 Management Dashboard Installation .................................................... 99
Post-Installation Steps ................................................................................... 100
Configuring NTP on SecurePlatform............................................................ 100
Completing IPS-1 Management Setup ........................................................ 101
Completing IPS-1 Sensor Setup ................................................................. 105
Where To From Here?..................................................................................... 108
6
Chapter 6 Installing Eventia Suite
Eventia Suite Installation................................................................................ 110
Standalone Installation vs. Distributed Installation............................................ 111
Installing Eventia Suite on Multiple Versions of Security Management Server
Management.......................................................................................... 111
Standalone Installation................................................................................... 112
Windows Platform ..................................................................................... 112
Solaris & Linux Platforms .......................................................................... 113
SecurePlatform......................................................................................... 113
Distributed Installation................................................................................... 114
Windows Platform ..................................................................................... 114
Solaris and Linux and SecurePlatform......................................................... 115
Enabling Connectivity Through a Firewall ......................................................... 116
Preparing Eventia Suite in Security Management server..................................... 117
Preparing Eventia Suite on Provider-1 MDS...................................................... 118
For Provider-1/SiteManager-1 Version R55 .................................................. 118
For Provider-1/SiteManager-1 Version R60 .................................................. 120
For Provider-1/SiteManager-1 Version R61 and Up ...................................... 121
Upgrade Section
Chapter 7 Introduction to the Upgrade Process
Documentation .............................................................................................. 126
Contract Verification ...................................................................................... 126
Supported Upgrade Paths and Interoperability .................................................. 127
Upgrading Management Servers ................................................................. 127
Backward Compatibility For Gateways ......................................................... 128
Obtaining Software Installation Packages ......................................................... 129
Terminology .................................................................................................. 130
Upgrade Tools ............................................................................................... 132
Upgrading Successfully .................................................................................. 132
Chapter 8 Service Contract Files

Introduction .................................................................................................. 133
Working with Contract Files ............................................................................ 134
Installing a Contract File on Security Management server................................... 134
On a Windows Platform ............................................................................. 135
On SecurePlatform, Linux, and Solaris ........................................................ 139
On IPSO .................................................................................................. 142
Installing a Contract File on a Gateway ............................................................ 143
On a Windows Platform ............................................................................. 143
On SecurePlatform, and Linux.................................................................... 150
On IPSO .................................................................................................. 154
Table of Contents 7
Managing Contracts with SmartUpdate ............................................................ 155
Managing Contracts .................................................................................. 155
Updating Contracts ................................................................................... 158
Chapter 9 Upgrading a Distributed Deployment

Introduction .................................................................................................. 160
Pre-Upgrade Considerations............................................................................ 161
Pre-upgrade Verification ............................................................................ 161
Web Intelligence License Enforcement........................................................ 161
Upgrading Products on a SecurePlatform Operating System .......................... 162
UTM-1 Edge Gateways Prior to Firmware Version 7.5 ................................... 162
Upgrading the Security Management Server ..................................................... 163
Using the Pre-Upgrade Verification Tool ...................................................... 163
Security Management Server Upgrade on a Windows Platform....................... 165
Security Management Server Upgrade on SecurePlatform ............................. 166
Gateway Upgrade on a UTM-1/Power-1 Appliance ........................................ 168
Security Management Server Upgrade on a Solaris Platform.......................... 169
Security Management Server Upgrade on a Linux Platform............................ 171
Security Management Server Upgrade on an IPSO Platform .......................... 173
Upgrading the Gateway .................................................................................. 175
Upgrading a Clustered Deployment ............................................................. 175
Upgrading the Gateway Using SmartUpdate ................................................ 176
Gateway Upgrade Process on a Windows Platform ........................................ 180
Gateway Upgrade on SecurePlatform .......................................................... 182
Gateway Upgrade on an IPSO Platform ....................................................... 183
Chapter 10 Backup and Revert for Security Gateways

Introduction .................................................................................................. 186
Backing Up Your Current Deployment .............................................................. 187
Restoring a Deployment.................................................................................. 188
SecurePlatform Backup and Restore Commands ............................................... 189
Backup .................................................................................................... 189
Restore .................................................................................................... 191
SecurePlatform Snapshot Image Management .................................................. 192
Snapshot ................................................................................................. 193
Revert...................................................................................................... 194
Reverting to Your Previous Deployment ............................................................ 195
Chapter 11 Upgrading a Standalone Deployment

Introduction .................................................................................................. 200
Pre-Upgrade Considerations............................................................................ 201
Upgrading Products on a SecurePlatform Operating System .......................... 201
Reverting to Your Previous Software Version ................................................ 201
Using the Pre-Upgrade Verification Tool ...................................................... 202
Standalone Security Gateway Upgrade on a Windows Platform ........................... 203
Standalone Security Gateway Upgrade on SecurePlatform.................................. 204
Uninstalling Packages ............................................................................... 205
8
Standalone Upgrade on a UTM-1/Power-1 Appliance......................................... 206
Uninstalling Packages ............................................................................... 206
Standalone Gateway Upgrade on an IPSO Platform ........................................... 207
Enabling Native IPSO Security Servers........................................................ 209
Uninstalling Previous Software Packages..................................................... 209
Chapter 12 Advanced Upgrade of Security Management servers & Standalone Gate-

ways
Introduction .................................................................................................. 212
Migrate Your Current Server Configuration and Upgrade..................................... 213
Introduction ............................................................................................. 213
Advanced Upgrade on a Windows Platform .................................................. 214
Advanced Upgrade on a Linux Platform....................................................... 215
Advanced Upgrade on SecurePlatform ........................................................ 219
Advanced Upgrade on an IPSO Platform ..................................................... 221
Advanced Upgrade on a Solaris Platform ..................................................... 223
Migration to a New Machine with a Different IP Address ............................... 226
Migrate Your Current Security Gateway Configuration & Upgrade ........................ 228
Advanced Upgrade on a Windows Platform .................................................. 228
Advanced Upgrade on a Linux Platform....................................................... 230
Advanced Upgrade on SecurePlatform ........................................................ 233
Advanced Upgrade on an IPSO Platform ..................................................... 235
Chapter 13 Upgrading ClusterXL Deployments

Tools for Gateway Upgrades ............................................................................ 237
Planning a Cluster Upgrade ............................................................................ 238
Permanent Kernel Global Variables ............................................................. 238
Ready State During Cluster Upgrade/Rollback Operations ............................. 239
Upgrading OPSEC Certified Third-Party Cluster Products .............................. 239
Minimal Effort Upgrade on a ClusterXL Cluster ................................................. 240
Zero Downtime Upgrade on a ClusterXL Cluster ................................................ 240
Supported Modes...................................................................................... 240
Full Connectivity Upgrade on a ClusterXL Cluster .............................................. 243
Understanding a Full Connectivity Upgrade ................................................. 243
Supported Modes...................................................................................... 244
Performing a Full Connectivity Upgrade ...................................................... 245
Chapter 14 Upgrading Provider-1

Introduction .................................................................................................. 250
Supported Versions and Platforms .............................................................. 250
Before You Begin ...................................................................................... 250
Provider-1 Upgrade Tools ............................................................................... 251
Pre-Upgrade Verifiers and Fixing Utilities .................................................... 251
Installation Script ..................................................................................... 252
export_database........................................................................................ 253
merge_plugin_tables ................................................................................. 255
migrate_assist .......................................................................................... 256
Table of Contents 9
cma_migrate ............................................................................................ 257
migrate_global_policies ............................................................................. 262
Backup and Restore .................................................................................. 262
Provider-1 Upgrade Practices.......................................................................... 264
In-Place Upgrade...................................................................................... 264
Replicate and Upgrade .............................................................................. 266
Gradual Upgrade to Another Machine ......................................................... 267
Migrating from Security Management to a CMA ........................................... 269
Upgrading in a Multi-MDS Environment ........................................................... 272
Pre-Upgrade Verification and Tools ............................................................. 272
Upgrading a Multi-MDS System ................................................................. 273
Restarting CMAs ............................................................................................ 276
Restoring Your Original Environment................................................................ 277
Before the Upgrade................................................................................... 277
Restoring Your Original Environment........................................................... 277
Renaming Customers ..................................................................................... 278
Identifying Non-Compliant Customer Names................................................ 278
High Availability Environment .................................................................... 278
Automatic Division of Non-Compliant Names............................................... 278
Resolving Non-Compliance ........................................................................ 279
Advanced Usage ....................................................................................... 280
Changing the MDS IP Address and External Interface........................................ 282
IP Address Change.................................................................................... 282
Interface Change ...................................................................................... 282
IPS in Provider-1 ........................................................................................... 283
Chapter 15 Upgrading SmartLSM ROBO Gateways

Planning the ROBO Gateway Upgrade .............................................................. 286
ROBO Gateway Upgrade Package to SmartUpdate Repository............................. 287
License Upgrade for a VPN-1 Power/UTM ROBO Gateway .................................. 287
Using SmartProvisioning to Attach the Upgraded Licenses............................ 287
License Upgrade on Multiple ROBO Gateways ............................................. 288
Upgrading a ROBO Gateway Using SmartProvisioning........................................ 289
Upgrading a VPN-1 Power/UTM ROBO Gateway ........................................... 289
Upgrading a UTM-1 Edge ROBO Gateway.................................................... 291
Upgrading a VPN-1 Power/UTM ROBO Gateway In Place .............................. 292
Using the Command Line Interface.................................................................. 293
SmartLSM Upgrade Tools .......................................................................... 293
Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli....................... 295
Upgrading a UTM-1 Edge ROBO Gateway Using LSMcli ............................... 296
Using the LSMcli in Scripts ....................................................................... 297
Chapter 16 Upgrading Eventia

Overview ....................................................................................................... 300
Upgrading Eventia Reporter ............................................................................ 300
For Standalone Deployments...................................................................... 300
For Distributed Deployments ...................................................................... 301
Advanced Eventia Reporter Upgrade ........................................................... 303
10
Enabling Eventia Analyzer after Upgrading Reporter ..................................... 305
Upgrading Eventia Analyzer ............................................................................ 306
Upgrading Eventia Analyzer to R70 ............................................................ 306
Verifying the Events Database Has Been Moved ........................................... 308
Enabling Eventia Reporter ......................................................................... 308
Chapter 17 Upgrading IPS-1

IPS-1 Upgrade Paths ..................................................................................... 310
Upgrading from R65.1 to R65.2 ................................................................ 310
Upgrading IPS-1 Management Servers ........................................................ 310
Upgrading IPS-1 Sensors................................................................................ 311
Upgrading IPS-1 Power Sensors ...................................................................... 311
Remotely Upgrading an IPS-1 Power Sensor................................................ 311
Reinstalling an IPS-1 Power Sensor ............................................................ 312
Upgrading Legacy Sensor Appliances............................................................... 313
100C and 200C ....................................................................................... 314
200F ....................................................................................................... 314
310C....................................................................................................... 314
320C....................................................................................................... 314
320F ....................................................................................................... 314
500C (pre-Jan 2006) ................................................................................ 314
500C (post-Jan 2006) .............................................................................. 315
500F (pre-Jan 2006) ................................................................................ 315
500F (post-Jan 2006)............................................................................... 315
Table of Contents 11
12
Installation Section
This section covers installing the current version
14
Chapter 1
Introduction
In This Chapter
Welcome page 15
Who Should Use This Guide page 16
R70 Documentation page 16
Related Documentation page 18
For New Check Point Customers page 19
Endpoint Security Integration page 20
More Information page 20
Feedback page 20
Welcome
Thank you for choosing Check Point’s Internet Security Product Suite. 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.
15
Who Should Use This Guide
To extend your organization’s growing security infrastructure and requirements, we

recommend that you consider adopting the OPSEC platform (Open Platform for
Security). OPSEC is the industry's open, multi-vendor security framework, which
has over 350 partners and the largest selection of best-of-breed integrated
applications and deployment platforms.
For additional information on the Internet Security Product Suite and other security
solutions, go to: http://www.checkpoint.com or call Check Point at 1(800)
429-4391. For additional technical information, go to:
http://support.checkpoint.com.
For more information about the current release, see the latest version of the
Release Notes at:
http://support.checkpoint.com
Welcome to the Check Point family. We look forward to meeting all of your current
and future network, application, and management security needs.
Who Should Use This Guide

This guide is intended for administrators responsible for installing and upgrading
Check Point security products on the corporate network.
R70 Documentation
Technical documentation is available on your CD-ROM at:
CD3\Docs\CheckPoint_Suite. These documents can also be found at:
To find out about what's new in R70, read the R70 Getting Started Guide.
For upgrading Endpoint Security, refer to the Endpoint Security Installation Guide.
16
New Terms
New Terms
The following product and technology names have been changed for this version.
Table 1: Product and Technology Names
Versions NG and NGX Products and Version R70 Products and
Technologies Technologies
Firewall-1 Firewall
Integrity Endpoint Security
Integrity Clientless Security Endpoint Security On Demand
ROBO Gateway Check Point SmartLSM Security
Gateway
SmartCenter server Security Management server
SmartDefense IPS
SmartLSM management SmartProvisioning
SmartPortal Management Portal
VPN-1 (Power/UTM) Gateway Check Point Security Gateway
VPN-1 UTM Edge UTM-1 Edge
Web Filtering URL Filtering
Web Intelligence IPS Web Intelligence
Table 2: SmartDashboard Tab Titles

Versions NG and NGX SmartDashboard Version R70 Products
Tabs SmartDashboard Tabs
Address Translation NAT
Connectra SSL VPN
Content Inspection Anti-Virus and URL Filtering
Messaging Security Anti-Spam and Mail
Security Firewall
VPN IPSec VPN
Chapter 1 Introduction 17
Related Documentation
Related Documentation
The current release includes the following documentation.
TABLE P-1 Check Point Documentation
Title Description
Internet Security Contains detailed installation instructions for Check
Installation and Upgrade Point network security products. Explains the
Guide available upgrade paths from versions R60 to the
current version.
High-End Installation and Contains detailed installation instructions for the
Upgrade Guide Provider-1 and VSX products, including hardware
and software requirements and licensing
requirements. Explains all upgrade paths for Check
Point products specifically geared towards
upgrading to the current version.
Security Management Explains Security Management solutions. This guide
Administration Guide provides solutions for control over configuring,
managing, and monitoring security deployments.
Firewall Administration Describes how to control and secure network access
Guide and VoIP traffic; how to use integrated web security
capabilities; and how to optimize Application
Intelligence with capabilities such as Content
Vectoring Protocol (CVP) applications, URL Filtering
(UFP) applications.
IPS Administration Guide Describes how to use IPS to protect against attacks.
VPN Administration Guide Describes the basic components of a VPN and
provides the background for the technology that
comprises the VPN infrastructure.
18
For New Check Point Customers
TABLE P-1 Check Point Documentation (continued)
Title Description
Eventia Reporter Explains how to monitor and audit traffic, and
Administration Guide generate detailed or summarized reports in the
format of your choice (list, vertical bar, pie chart
etc.) for all events logged by Check Point Security
Gateways, SecureClient and IPS.
SecurePlatform/ Explains how to install and configure
SecurePlatform Pro SecurePlatform. This guide will also teach you how
Administration Guide to manage your SecurePlatform machine and
explains Dynamic Routing (Unicast and Multicast)
protocols.
Provider-1/SiteManager-1 Explains the Provider-1 security management
Administration Guide solution. This guide provides details about a
three-tier, multi-policy management architecture
and a host of Network Operating Center oriented
features that automate time-consuming repetitive
tasks common in Network Operating Center
environments.
For New Check Point Customers

New Check Point customers can access the Check Point User Center in order to:
• Manage users and accounts
• Activate products
• Get support offers
• Open service requests
• Search the Technical Knowledge Base
To access the Check Point User Center, go to:
https://usercenter.checkpoint.com/pub/usercenter/get_started.html.
Chapter 1 Introduction 19
Endpoint Security Integration
Endpoint Security Integration

For in-depth documentation of Provider-1/Security Management server integration
with Check Point Endpoint Security products, refer to:
• Endpoint Security Installation Guide
• R70 Security Management Server Administration Guide
More Information
• For additional technical information about Check Point products, consult Check
Point’s SecureKnowledge at http://support.checkpoint.com.
• To view the latest version of this document in the Check Point User Center, go
to: http://support.checkpoint.com.
Feedback
Check Point is engaged in a continuous effort to improve its documentation. Please
help us by sending your comments to:
cp_techpub_feedback@checkpoint.com
20
Chapter 2
Getting Started
In This Chapter
Terminology page 22
Provider-1/SiteManager-1 Terminology page 23
Hardware and Software Requirements page 24
Compatibility Tables page 25
Supported Upgrade Paths and Interoperability page 27
Licensing R70 page 29
This chapter contains information and terminology related to installing R70.
21
Terminology
Terminology
The following terms are used throughout this chapter:
• Distributed Deployment: When the gateway and the Security Management
server are installed on separate machines.
• Gateway: The software component that enforces the organization’s security
policy and acts as a security enforcement point.
• Security Policy: The policy created by the system administrator that regulates
the flow of incoming and outgoing communication.
• Security Management server: The server used by the system administrator to
manage the security policy. The organization’s databases and security policies
are stored on the Security Management server and downloaded to the gateway.
• SmartConsole: GUI applications that are used to manage various aspects of
security policy enforcement. For example, SmartView Tracker is a SmartConsole
application that manages logs.
• SmartDashboard: A SmartConsole GUI application that is used by the system
administrator to create and manage the security policy.
• Standalone Deployment: When Check Point components responsible for the
management of the security policy (the Security Management server and the
gateway) are installed on the same machine.
22
Provider-1/SiteManager-1 Terminology
Provider-1/SiteManager-1 Terminology
The following Provider-1/SiteManager-1 terms are used throughout this chapter.
• Customer: A business entity or subdivision of a business entity whose networks
are protected by security gateways, UTM-1 Edge appliances or other Check
Point compatible firewalls. The Customer’s security policies and network access
are managed using Provider-1/SiteManager-1.
• Customer Log Module (CLM): A log server for a single Customer.
• Customer Management Add-on (CMA): The Provider-1 equivalent of the Security
Management server for a single Customer. Using the CMA, an administrator
creates security policies and manages customer gateways.
• GUI Client: A computer running Check Point GUI interfaces, such as the
Provider-1 MDG, and other SmartConsole applications.
• Internal Certificate Authority (ICA): In addition to authenticating administrators
and users, the ICA creates and manages X.509 compliant certificates for
Secure Internal Communication (SIC) between security gateways. The MDS has
an ICA that secures the Provider-1 management domain. Each CMA has its own
ICA to secure its customer’s management domain.
• Multi-Domain Log Module (MLM): An MDS Container dedicated to collecting
and storing logs. An MLM is a Container of Customer Log Modules (CLMs).
• Multi-Domain Server (MDS): A server that houses Provider-1 system
information. The MDS contains information on Provider-1 deployment,
administrators, and customer management. The MDS has two modes:
• Manager: Runs the Provider-1 deployment and is the administrator’s entry
point into the Provider-1 environment.
• Container: Holds the Customer Management Add-ons (CMAs).
An MDS can be a Manager, a Container or both.
• Provider-1 Administrator: A security administrator, assigned with granular

permissions, that manages specific parts of the Provider-1 system.
Administrators can be assigned one of the following four permission levels:
• Provider-1 Superuser: Manages the entire Provider-1 system, which includes
all MDS servers, administrators (with all permission levels), Customers and
customer networks.
• Customer Superuser: Manages all administrators (with lower permission
levels), Customers and customer networks.
Chapter 2 Getting Started 23

Hardware and Software Requirements
• Global Manager: A new type of administrator account in the MDG. With

access to Global SmartDashboard, a Global Manager is capable of managing
global policies and global objects. For a Global Manager to have additional
access to CMA policies, read-write or partial access rights must be
specifically assigned.
• Customer Manager: Manages customer networks for specific Customers.
Administrators with this permission level can use the MDG application, but
they can only view and manage their assigned customers.
• None: Manages customer networks for specific Customers, but cannot
access the MDG application.
Hardware and Software Requirements

For all hardware and software requirements for each product and platform, see the
latest version of the relevant Release Notes at:
24
Compatibility Tables
Compatibility Tables
If the existing Check Point implementation contains products that are not
supported by R70, the R70 installation process terminates. Table 2-1 and
Table 2-2 lists supported Check Point products and VPN clients by platform.
Table 2-1 Supported Products by Platform
Product / Management Blade Platform and Operating System
Check RHEL
Point Windows 5.0 Nokia Crossbeam Solaris
Secure Server Server kernel IPSO X-Series
Ultra-
Platform 2003 2008 2.6.18 6.0.7
SPARC
(SP1-2)
8, 9, 10
Check Point Security Gateway X X X X X

Security Management X X X X X X
Provider-1/SiteManager-1
X X X
Server (MDS)
Performance Pack X X X
Advanced Routing X X X
Management Portal X X X X X
Eventia Suite X X X X X
ClusterXL X X X X X
CoreXL X X X
SmartProvisioning - Enabled
X X X X
SmartLSM Gateways
SmartProvisioning - Enabled
X X X X X
Management
SSL Network Extender Server X X X X
Endpoint Security Server X X X X
VSX Security Gateway X (IPSO 5) X
OSE Supported Routers Cisco OS Versions: 9.x, 10.x, 11.x, 12.x
Product Notes
1. Anti-Virus and Web Filtering are included on SecurePlatform.
2. Eventia Suite includes Eventia Reporter Server, Eventia Analyzer Server, and
Eventia Analyzer Correlation Unit.

Platform Notes
3. ClusterXL is supported only in third party mode with VRRP or IP Clustering. The
maxiumum number of cluster members is eight.
4. Management Portal is supported on the following Web browsers: Internet
Explorer 6 and 7, and Mozilla Firefox 1.5-2.0.
Platform Notes
1. UTM-1 Edge devices cannot be managed from a Security Management running
on a Nokia IPSO platform.
2. UserAuthority is not supported on Nokia flash-based platforms.
3. HA Legacy mode is not supported on Windows Server 2003.
4. Only UltraSPARC 64-bit is supported; for Security Management only (not for
gateways).
Table 2-2 Supported Clients by Platform
Check Point Product Platform and Operating System

Windows 1 Mac Mac Linux
2000 Server / 2000 Pro Mobile Server Vista Server OS OS
Advanced (SP1-4)/ 2003 2003 (SP1) 2008 10.4 10.5
Server XP Home & Pro 2003SE (SP1-2)
(SP1-4) (SP3) 5.0, 6.0,
6.1
SmartConsole X X X X X
Provider-1/SiteManager-1 MDG X X X X X
SecuRemote X X X
SecureClient X X X X X X
SecureClient Mobile X
SSL Network Extender X X X X X
Endpoint Security Client X X
Endpoint Connect Client X X
Notes to Supported by Platform Table

1. To run SmartConsole applications on Windows 2000, you must have Microsoft
Installer 3.0 installed.
2. Microsoft Installer support is required for installation of Endpoint Security
clients.
26
Supported Upgrade Paths and Interoperability
Supported Upgrade Paths and

Interoperability
In This Section:
Upgrade Paths and Interoperability page 27

Upgrading Security Management Servers page 27
Backward Compatibility For Gateways page 27
IPS-1 Upgrade Paths and Interoperability page 28
Upgrade Paths and Interoperability

Security Management servers and security gateways exist in a wide variety of
deployments. Consult Table 2-3 and Table 2-4 to determine which versions of your
management server and gateways can be upgraded to R70.
Upgrading Security Management Servers

The following Security Management server versions can be upgraded to R70:
Table 2-3 Security Management server Upgrade Paths
Release Version
NGX
R60, R60A, R61, R62, R65
R65 with HFA 30 with the Connectra NGX R66 Plug-in
R65 with Messaging Security
R65 with the VPN-1 Power VSX NGX R65 Management Plug-in
R65 with the SmartProvisioning Plug-in
R65 UTM-1
R65 Power-1
Backward Compatibility For Gateways

R70 Security Management server supports the following gateway versions:

IPS-1 Upgrade Paths and Interoperability
Table 2-4 Backward Compatibility for Gateways

Release Version
NGX R60, R60A, R61, R62, R65
InterSpect NGX R60
Connectra NGX R61, R62, R62CM, R66
UTM-1 Edge 7.5.x and above
Endpoint Security
Note - R70 cannot manage gateway versions NG, NG FP1, or NG FP2
IPS-1 Upgrade Paths and Interoperability

Upgrade Paths
Non-Power Sensors installed on SecurePlatform cannot be upgraded to the current
version. A new installation is required.
Alerts Concentrators and IPS-1 Management Servers, including NFR Sentivist
Servers and Enterprise Servers, and IPS-1 Power 1000 and 2000 Sensors, of
versions 5.x, can be upgraded to the current version. From earlier versions,
completely reinstall.
Interoperability
Management components of the current release, such as IPS-1 Management
Server, Alerts Concentrators and Management Dashboard, are compatible with
Sensors of versions 4.1 onwards.
The different management components (IPS-1 Management Server, Alerts
Concentrators and Management Dashboard) must always be of the same version.
28
Licensing R70
Licensing R70
Most of the software on this CD is automatically enabled for a 15-day evaluation period. To obtain
a permanent license, or to extend the evaluation period, go to the Check Point User Center at:
https://usercenter.checkpoint.com
Customers new to the Check Point User Center should go to:
https://usercenter.checkpoint.com/pub/usercenter/get_started.html
For further licensing assistance, contact Account Services at:
AccountServices@checkpoint.com, or US +1 972-444-6600, option 5.
Licensing R70
Licenses are required for the Security Management server and security gateways.
No license is required for SmartConsole management clients.
Check Point gateways enforce the license installed on the gateway by counting the
number of users that have crossed the gateway. If the maximum number of users is
reached, warning messages are sent to the console.
The Check Point software is activated using a certificate key, which is located on
the back of the software media pack. The certificate key is used to generate a
license key for products that you want to evaluate or purchase. To purchase Check
Point products, contact your reseller.
Obtaining a License Key

To obtain a license key from the Check Point User Center:
1. Add the required Check Point products/evaluations to your User Center account
by selecting Accounts & Products > Add Products.
2. Generate a license key for your products/evaluations by selecting Accounts &
Products > Products.
Select your product(s) and click Activate License. The selected product(s)
evaluations have been assigned license keys.
3. Complete the installation and configuration process by doing the following:
a. Read and accept the End Users License Agreement.

Licensing Provider-1/SiteManager-1
b. Import the product license key. Licenses are imported using the Check
Point Configuration Tool or SmartUpdate. SmartUpdate allows you to
centrally upgrade and manage Check Point software and licenses. The
certificate keys associate the product license with the Security Management
server, which means that:
• The new license remains valid even if the IP address of the Check Point
gateway changes.
• Only one IP address is needed for all licenses.
• A license can be detached from one Check Point gateway and assigned
to another.
Upgrading Licenses
The upgrade procedure is free of charge to purchasers of the Software Subscription
service (Enterprise Base Support).
The license upgrade procedure runs the license_upgrade command, which makes it
easy to automatically upgrade licenses.
Licensing Provider-1/SiteManager-1
Provider-1/SiteManager-1 licenses are associated with the IP address of the
licensed entity. The Provider-1 Multi-Domain Server (MDS) license is based on the
server type: Manager, Container, Combined Manager and Container, or
Multi-Domain Log Manager (MLM).
Manager: A license for the administrator's entry point into the
Provider-1/SiteManager-1 environment. The Multi-Domain GUI (MDG) and the
Global SmartDashboard tools can connect only to MDS servers with this license.
Container: A license that defines the maximum number of CMAs running on the
MDS machine. With the exception of Provider-1 Enterprise Edition licenses,
multiple container licenses can be added together on one container to enable the
container to hold up to a maximum of 250 CMAs. In addition, each CMA requires
its own CMA license. CMA Pro Add-on licenses, allowing additional management
features at the CMA level, can be purchased in bulk. These purchase packages are
called Pro Add-ons for MDS.
Combined Manager and Container: These licenses combine a Manager license with
a Container license for a specific number of CMAs. In the case of SiteManager-1
licenses, there are no separate Manager and Container versions available, only the
Combined Manager and Container license.
30
Licensing IPS-1
MLM: A comprehensive license that includes the Customer Log Modules (CLMs) it
hosts. There is no need for a separate CLM license if CLMs are hosted on an MLM.
A CLM hosted on an MDS server requires its own CLM license.
Each gateway requires its own license. Licenses are determined according to the
number of computing devices (nodes) protected by the gateway. Provider-1 licenses
can be imported using the Check Point command-line licensing tool or Provider-1's
MDG. For additional information, refer to the Provider-1/SiteManager-1
Administration Guide.
Licensing IPS-1
The IPS-1 Management Server requires a license, defined with the ability to
manage a fixed maximum number of Sensors. In a Combined installation where the
Alerts Concentrator installed together with the IPS-1 Management Server, the Alerts
Concentrator shares the IPS-1 Management Server’s license.
For any separate Alerts Concentrators and for all Sensors, obtain and add licenses.
Licenses are added using IPS-1’s Management Dashboard.
The IPS-1 Management Dashboard does not require a license. However, without a
licensed IPS-1 Management Server, the IPS-1 Dashboard will function only in
Demo mode.
All licenses are stored on the IPS-1 Management Server and must have been
generated according to the IPS-1 Management Server’s IP address.
Licensing Eventia Suite

All Eventia Suite licenses are installed on the Eventia Suite Server (not on the
Security Management server).
Correlation Units are licensed by the number of units that are attached to the
Eventia Analyzer Server.

Licensing Eventia Suite
32
Chapter 3
Setup and Installation
In This Chapter
Overview page 34
Installing on SecurePlatform page 35
Installing on Windows page 44
Installing on Solaris or Linux page 46
Installing on Nokia page 48
Initially Configuring Products page 51
Where To From Here? page 58
33
Overview
Overview
Check Point software is designed to work across multiple platforms and
pre-configured appliances. Each installation differs depending on the product and
the platform.
For upgrading an existing installation, see the upgrade section.
Check Point products can be installed in the following two types of deployments:
• Standalone Deployment: Check Point components that are responsible for the
management of the security policy (the Security Management server and the
gateway) are installed on the same machine.
• Distributed Deployment: The Security gateway and the Security Management
server are installed on different machines.
In both deployments, SmartConsole can be installed on any machine by performing
the following steps:
• Install the components that manage or enforce the security policy (for example,
the Security Management server, the security gateway, and the log server).
• Install one or more SmartConsole clients to manage different aspects of the
deployment. For example, SmartDashboard is used by the system administrator
to manage and create the security policy. Any number of SmartConsole GUI
applications can be installed on the same machine
Note - The TCP/IP network protocol must be installed, properly configured, and operational
before you begin the installation process.
34
Installing on SecurePlatform
Installing on SecurePlatform
In This Section:
Installing SecurePlatform Using the CD page 35

Installing SecurePlatform from the Network page 37
Initially Configuring SecurePlatform page 41
Installing R70 Products on SecurePlatform page 42
Configuring SecurePlatform Using WebUI page 43
Installing SecurePlatform Using the CD

To install SecurePlatform using the CD:
1. Insert CD1 from the media pack into the CD drive, and boot the computer from
the CD. After booting, the Welcome message appears. If you do not press Enter
within 90 seconds, the computer boots from the hard drive.
The installation program is loaded.
2. The following options are displayed:
• Device List: When selected, the Hardware Scan Details menu displays.
• Add Driver: When selected, the Devices menu opens. Sometimes updated
hardware is incompatible with the previous version’s driver and you receive
an error message during installation because the operating system could not
find the appropriate hard disk driver. Alternatively, the installation may be
complete, but the hardware does not function properly. The Add Driver
option enables you to add the missing driver during the installation process.
To continue, Select OK.
3. A list of software blades is displayed:
Security Gateway
Security Management server
Eventia Suite
Endpoint Security (CD2)
Performance Pack
Management Portal
Chapter 3 Setup and Installation 35

Installing SecurePlatform Using the CD
4. Use the space bar to select the appropriate products and select OK.
5. Select the type of system to install:
• SecurePlatform
• SecurePlatform Pro (which includes the advanced dynamic routing suite)
6. The Keyboard Selection menu opens.
7. Select a keyboard type.
8. From the Network Interface Configuration menu, define the
• IP address of the management interface
• Netmask and Default gateway for the first network interface (eth0 on most
systems).
9. From the HTTPS Server Configuration menu, enable or disable web-based
configuration using SecurePlatform’s WebUI.
Note - If you intend to deploy remote access or Endpoint Security software, select a port
other than 443.
10. Select OK.

A message confirms that you are about to format your hard drive.
Warning - The formatting procedure erases all information located on your hard drive.
11. Select OK to:
• Format your hard drive
• Extract, copy files, and install SecurePlatform software blades.
• Perform post install configuration
• Install the boot loader
The installation process can take several minutes to complete.
12. When the Installation Complete message appears, remove the installation CD
from the drive, and select OK to reboot the system.
Continue to “Initially Configuring SecurePlatform” on page 41.
36
Installing SecurePlatform from the Network

In This Section
General Workflow page 37

Client Setup page 38
Server Setup page 38
General Workflow
The client’s requirements are minimal. Only PXE is required. On the server, you
must install:
• A DHCP daemon,
• A TFTP daemon,
• The PXE boot loader,
• The kernel
• The ramdisk.
Then:
1. The client boots from the network, using the PXE network loader.
2. The client sends a broadcast request, using the BOOTP protocol.
3. The server responds to the client, by providing the client’s assigned IP address
and a filename (pxelinux.0 by default), to which to download the PXE boot
loader.
4. The client downloads the PXE Boot Loader, using TFTP, and executes it.
5. The PXE boot loader downloads a PXE configuration file from the server,
containing the names of the kernel and the ramdisk that the client requires.
6. The PXE boot loader downloads the kernel and the ramdisk.
7. The kernel is run, using ramdisk as its environment.
8. The Installer is executed.
9. At this point the installation can be configured to load files from the FTP
server.

Client Setup
On the client machine, enable the network boot, using PXE, from the BIOS setup.
(It sometimes appears as DHCP.)
Server Setup
In This Section
Required Packages page 38

DHCP Daemon Setup page 39
TFTP and FTP Daemon Setup page 40
Hosting Installation Files page 41
Required Packages
The following packages are required for server setup:
• DHCP daemon (located on the Checkpoint CDROM and installed, by default, on
SecurePlatform)
• Xinetd (/SecurePlatform/RPMS/xinetd-2.3.11-4cp.i386.rpm on the Checkpoint
CDROM)
• TFTP daemon (/SecurePlatform/RPMS/tftp-server-0.32-5cp.i386.rpm)
• FTP server (/SecurePlatform/RPMS/ftpd-0.3.3-118.4cp.i386.rpm)
• TCP-Wrappers package
(/SecurePlatform/RPMS/tcp_wrappers-7.6-34.4cp.i386.rpm)
• Kernel (can be found on the SecurePlatform CD at /SecurePlatform/kernel)
• Ramdisk (can be found on the SecurePlatform CD at
/SecurePlatform/ramdisk-pxe)
Note - To access files on Check Point CDROM, insert the CDROM into the CDROM drive
and enter the command: # mount/mnt/cdrom
38
PXELINUX Configuration Files

/SecurePlatform/RPMS/tftp-server-0.32-4cp.i386.rpm includes a default
configuration file (located under /tftpboot/pxelinux.cfg) that will serve the kernel
and ramdisk to any host. Because more than one system may be booted from the
same server, the configuration file name depends on the IP address of the booting
machine.
PXELINUX will search for its config file on the boot server in the following way:
1. PXELINUX will search for its config file, using its own IP address, in upper case
hexadecimal, e.g. 192.0.2.91 -> C000025B.
2. If that file is not found, PXELINUX will remove one hex digit and try again.
Ultimately, PXELINUX will try looking for a file named default (in lower case).
As an example, for 192.0.2.91, PXELINUX will try C000025B, C000025,
C00002, C0000, C000, C00, C0, C, and default, in that order.
Assuming the kernel and ramdisk files are named kernel and ramdisk,
respectively, a default configuration file, which will serve these to all clients, will
look like this:
default bootnet
label bootnet
kernel kernel
append initrd=ramdisk lang= devfs=nomount \
ramdisk_size=80024 console=tty0
DHCP Daemon Setup

To setup the DHCP Daemon, perform the following procedure:
1. Enter the sysconfig utility and enable the DHCP server.

2. Edit the daemon’s configuration file, found at /etc/dhcpd.conf. The

configuration file should include a subnet declaration for each subnet, the
DHCP server is connected to. In addition, configuration should include a host
declaration, for each host that will use this server for remote installation. A
sample configuration file follows:
subnet 192.92.93.0 netmask 255.255.255.0 {
}host foo {
# The client’s MAC address
hardware ethernet xx:xx:xx:xx:xx:xx;
# The IP address that will be assigned to the
# client by this server

fixed-address 192.92.93.32;
# The file to upload
filename "/pxelinux.0";
TFTP and FTP Daemon Setup

To setup the TFTP and FTP Daemons, perform the following procedure:
1. Install /SecurePlatform/RPMS/tcp_wrappers-7.6-34.4cp.i386.rpm (The TCP
wrappers package)
2. Install /SecurePlatform/RPMS/xinetd-2.3.11-4cp.i386.rpm. (The xinetd
package is a prerequisite for the tftp-server and ftpd.)
3. Install the TFTP Daemon RPM:
# rpm -i/SecurePlatform/RPMS/tftp-server-0.32-5cp.i386.rpm
4. Install the FTP Daemon RPM:
# rpm -i/SecurePlatform/RPMS/ftpd-0.3.3-118.4cp.i386.rpm
5. Force xinted to reread its configuration:
# service xinetd restart
40
Initially Configuring SecurePlatform
Hosting Installation Files

An FTP server installed on SecurePlatform will be used to host the installation
files. During the installation process, you will be asked to supply the IP of the
installation server, the credentials on that server, and the path to the installation
packages. Supply the IP of the SecurePlatform installation server, the
Administrator's credentials, and the path to the SecurePlatform packages.
You can also use different FTP servers, or HTTP servers, to host SecurePlatform
installation files.
Initially Configuring SecurePlatform

After the operating system installation is complete and the computer has rebooted:
1. From the SecurePlatform boot menu, Start in normal mode.
2. Log in using admin as your username and password.
3. When prompted, change the default username and password. Ensure that the
new password contains more than six characters and has a combination of
upper and lower cases letters and numbers.
4. On the command line, run: cpconfig.
5. A first-time configuration wizard for the SecurePlatform device opens, and
displays a Welcome message.
6. Press n to proceed to the next menu.
The following Network Configuration menu options are displayed:
Option Purpose
Host Name Sets and displays the host name
Domain Name Sets and displays the Domain name
Domain Name Adds, removes, displays Domain name servers
Servers
Network Adds, configures, removes, displays network connections.
Connections
Routing Sets and shows a default gateway
7. Use the menu options to configure:
• The host name
• The domain name and at least one DNS server

Installing R70 Products on SecurePlatform
• The computer’s network interfaces

• The default gateway (if required)
8. Once Network Configuration is complete, select the Time and Date Configuration
menu option and configure the following:
• Time zone
• Date
• Local time
• Show date and time settings
9. Press n.
The Import Check Point Products Configuration window opens and displays the
Fetch Import file from TFTP Server option. If you exported the configuration of
another SecurePlatform installation, you can now import that configuration.
For additional information, see: “Advanced Upgrade on SecurePlatform” on
page 219.
10. Press n to continue to products installation.
Installing R70 Products on SecurePlatform

The Check Point product installation wizard continues from SecurePlatform’s
first-time system configuration (sysconfig) wizard.
1. The welcome message appears, beginning the installation wizard. Press n.
2. Read and accept the End User License agreement.
3. Select either:
• New Installation
• Installation Using Imported Configuration
4. A product list is displayed:
Security Gateway
User Authority
Security Management
Eventia Suite
42
Configuring SecurePlatform Using WebUI
Endpoint Security (CD2 required)

Performance Pack
Management Portal
5. Select the appropriate products and press n.

6. If you selected Security Management server, decide whether it should be
installed as a primary or secondary Security Management server and whether a
Log server should also be installed.
7. If you selected Eventia Suite, select Eventia product should be installed:
Reporter, Coorelation unit, or Analyzer.
8. A message validates your choice of products. Press n.
The required installation files are extracted and products installed. If you chose
to install Security Management server, the Check Point Configuration program
opens and guides you through the configuration of:
a. Licenses
b. Administrators (name and password)
c. GUI clients
d. A random pool of data for cryptographic operations
e. A Certificate authority and saving the fingerprint
See: “Using the Configuration Tool on Unix Systems” on page 54.
9. Reboot the machine. IP forwarding is automatically disabled and a default
security policy is applied to the gateway. The default Security Policy forbids all
inbound connections, except for control connections, for example, install policy
operations. This policy remains in place until you have installed the first
Security Policy.
Configuring SecurePlatform Using WebUI

You can also use the WebUI to configure network settings, apply a license, and
install and configure products. After system reboot, use your browser to connect to
the IP address specified in step 8 on page 36.

Installing on Windows
The installation on a Windows platform is GUI based. The windows displayed
during installation differ depending on the installed Check Point components.
To perform a new installation on a Windows platform:
1. Log on as Administrator and insert the CD. The installation wizard automatically
starts and a Congratulations message displays.
2. Review the Evaluation Options then click Forward.
3. Accept the terms of the End Users License Agreement.
4. Select one of the following installation options:
• Demo installation (SmartConsole only)
• New installation
• Installation using an imported configuration (for additional information, see:
“Advanced Upgrade on a Windows Platform” on page 228.
5. Click Forward.
If you selected Installation Using Imported Configuration, you are prompted to
provide the location of the imported configuration file.
A list of products is displayed:
6. Select the products you wish to install and click Forward.

installed as a primary or secondary Security Management server and whether a
8. Confirm installation of selected products. Click Forward.
The selected products are installed. For first time installations, the Check Point
Configuration Tool runs automatically and prompts you to (for Security
Management server):
44
a. Add licenses
b. Add administrators
c. Specify remote clients from which an administrator can log into Security
Management server
d. Initialize the Internal Certificate Authority
e. Export the Security Management server fingerprint to a text file
For additional information, refer to the “Configuration Tool Overview” on
page 51.
9. Reboot the machine. IP forwarding is automatically disabled and a default
security policy is applied to the gateway. The default Security Policy forbids all
inbound connections, except for control connections, for example, install policy
operations. This policy remains in place until you have installed the first
Security Policy.

Installing on Solaris or Linux

Installation on Linux and Solaris platforms is run from a command line, with a
wizard that guides you through installation. For SecurePlatform there is a separate
installation procedure which is described in “Installing on SecurePlatform” on
page 35.
To perform a new installation on a Linux or Solaris platform:
1. Mount the CD on the appropriate subdirectory.
2. From the root directory of the CD, run:
./UnixInstallScript
The wrapper welcome message appears, beginning the installation wizard. Press
n.
3. Read and accept the terms of the End User License Agreement.
4. Select New Installation and press n.
5. A product list is displayed:
Security Gateway
User Authority
Security Management
Eventia Suite
Endpoint Security
Performance Pack
Management Portal
6. Select the products you wish to install and press n.

installed as a primary or secondary Security Management server, and whether a
8. Confirm the selected products by pressing n.
9. Once product installation is complete, the Check Point Configuration tool will
prompt for various configuration options. For a Security Management server, the
stages are:
46
a. Add licenses. The Check Point Configuration program only manages local
licenses on this machine. The recommended way to manage licenses is
using SmartUpdate.
b. Configure GUI clients (a list of hosts that are able to connect to the
Security Management server using SmartConsole).
c. Configure group permissions by specifying a group name.
d. Configure the Certificate Authority, and save the CA’s Fingerprint to a file.
10. Reboot the machine.
IP forwarding is automatically disabled and a default security policy is applied to
the gateway. The default Security Policy forbids all inbound connections, except for
control connections such as install policy operations. This policy remains in place
until you have installed the first security policy.

Installing on Nokia
Installing on Nokia
Installation on Nokia platforms is performed from a console or Nokia Network
Voyager (a secure web-based network element management application). Use a
console to perform the initial configuration.
You can also use Nokia Horizon Manager to install and configure Check Point
components on multiple Nokia appliances simultaneously. For additional
information, refer to Nokia Horizon Manager documentation on the Nokia Support
website:
http://support.nokia.com
A software package for Nokia IPSO 6.07 is available from the Check Point
download center at:
http://www.checkpoint.com/techsupport/downloads.jsp.
If you have a Nokia gateway with IPSO 4.2 already installed, then skip to step 13
on page 49.
Note - Verify from Nokia that you have IPSO 4.2 with UTM compatibility (IPSO 4.2 Build
041)
If you are performing a new installation on an older IPSO gateway, then start here:
Before Installing:
• From the Check Point website, download: IPSO_Wrapper_R70.tgz.
• From Nokia, download: UTM-Base Build 004
To install with UTM functionality:
1. Enter the Network Voyager and open a CLI console.
2. Click System Configuration > Install New IPSO Image.
The New Image Installation Upgrade window opens.
3. Enter the following information (for IPSO 4.2):
Enter URL to the image location
Enter HTTP Realm (for HTTP URLs only)
Enter Username (if applicable)
Enter Password (if applicable)
48
Installing on Nokia
4. Click Apply.
You are informed that the file download and image installation may take some
time.
5. Click Apply.
A message is displayed indicating that the new image installation process has
started.
6. When you receive a Success message, click UP > UP > Manage IPSO Images.
The IPSO Image Management window opens.
7. Under the title Select an image for next boot, select the last downloaded image:
IPSO 4.2
8. Click Test Boot.
9. Access the CLI console to see when the Reboot is complete. Once the Reboot
is complete, go back to the Network Voyager to verify that the image was set
properly.
10. In the Network Voyager, click Refresh and log in.
11. If you are not returned to the last window you were in, click
System Configuration > Manage IPSO Images.
You should be able to see that the relevant IPSO Image is selected.
12. Select Commit testboot and click Apply.
13. Access the CLI console, and log in.
14. Type newpkg, and press Enter.
15. Use the FTP menu option to transfer the UTM-Base package.
16. Install the UTM-Base package.
Wait until a message informs you that the process is complete.
17. Activate the UTM-Base package.
18. In Voyager, verify that the UTM Base package is turned ON.
19. On the CLI, type newpkg, and press Enter.
20. Use the FTP menu option to transfer the IPSO_Wrapper_<version_number>.tgz
package.
21. Install the IPSO_Wrapper_R70 package.

Enabling Native IPSO Security Servers
22. Type Reboot and press Enter.

23. From a console connection, run cpconfig.
24. Select an installation type, Stand Alone or Distributed.
25. Select Security Management server from the selection list.
26. Specify the Security Management server type as Primary or Secondary.
Note - Only relevant for a distributed deployment.
27. Add Licenses.
28. Configure an administrator name and password.
29. Configure the GUI clients and hosts which can access the Security
Management server using SmartConsole.
30. Configure Group Permissions.
31. Configure a pool of characters for use in cryptographic operations. Type
randomly until the progress bar is full.
32. Configure the Certificate Authority, and save the CA’s Fingerprint to a file.
33. Start the installed products.
If you opt not to start the installed products at this time, they can be started
later by running cpstart.
34. Reboot.

Once Anti-virus and Web filtering is enabled, the relevant traffic is blocked from
passing through the gateway. If the relevant traffic is not blocked, run the
fwlinux2ipso command on the gateway to manually activate the native IPSO
security servers. (When the UTM-Base package was installed and activated, the
native IPSO security servers should have been activated as well).
50
Initially Configuring Products
Initially Configuring Products

In This Section:
Configuration Tool Overview page 51

Using the Configuration Tool on Windows Systems page 52
Using the Configuration Tool on Unix Systems page 54
Logging In for the First Time page 55
Configuration Tool Overview

The Configuration Tool runs automatically once the installation process is complete.
The Configuration Tool can also be run manually by running the cpconfig command.
The configuration options vary according to installed product. The examples in this
chapter are for a Security Management server.
The Configuration Tool is used to configure:
• Licenses: Generates a license for the Security Management server and the
gateway.
• Administrators: Creates an administrator with Security Management server
access permissions. The administrator must have Read/Write permissions in
order to create the first security policy.
• GUI Clients: Creates a list of names or IP addresses for machines that can
connect to the Security Management server using SmartConsole.
• Key Hit Session: Creates a random seed for use in various cryptographic
operations.
• Certificate Authority: Provides definitions that are used to initiate the Internal
Certificate Authority, which enables secure communication between the
Security Management server and its gateways. For some operating systems,
such as Windows, you must specify the name of the host where the ICA resides.
You may use the default name or provide your own. The ICA name should be in
the hostname.domain format, for example, ica.checkpoint.com.
• Fingerprint: Verifies the identity of the Security Management server the first
time you log in to SmartConsole. Upon SmartConsole login, a Fingerprint is
displayed. This Fingerprint must match the Fingerprint shown in the

Using the Configuration Tool on Windows Systems
Configuration Tool window in order for authentication to succeed. You may want
to export this Fingerprint for verification purposes when you log in to
SmartConsole for the first time.

To configure using the Configuration Tool on Windows systems:
1. Open the Configuration Tool by selecting Start > Run > cpconfig.
2. In the Licenses tab, perform one or both of the following procedures:
a. Fetch one or more licenses from a file.
i. Click Fetch from File.
ii. Browse to the license file, select it and click Open. The license(s) that
belong to this host are added.
b. Add a license manually.
i. Click Add. The Add License window opens.
ii. Configure the appropriate options in the Add License window.
iii. Click OK to add the newly configured license.
3. Click Next.
4. In the Administrators tab, click Add. Add an administrator that uses
SmartConsole to connect to the Security Management server. From NGX version
R60, only one administrator can be added using the Configuration Tool.
Additional administrators can be added using SmartDashboard.
5. From the Add Administrator window, configure the required parameters and click
OK.
6. Click Next.
7. On the GUI Clients tab, add a GUI client.
Note - If you do not define at least one GUI client, you can only manage the Security
Management server from a GUI client that runs on the same machine as the Security
Management server.
8. Type the GUI client’s name in the Remote hostname field.

9. Click Add. You can add a GUI client using any of the following formats:
• IP address: For example, 1.2.3.4.
52
• IP/netmask: A range of IP addresses, for example,

192.168.10.0/255.255.255.0.
• Machine name: For example, Alice, or Alice.checkpoint.com.
• Any: Any IP address.
• IP1-IP2: A range of IP addresses, for example, 192.168.10.8 -
192.168.10.16.
• Wild cards: For example, 192.168.10.
10. Click Next.
11. In the Certificate Authority tab, add a name using the <hostname>.<domain name>
format, for example, <hostname>.checkpoint.com. This option enables you to
initialize an Internal Certificate Authority (ICA) on the Security Management
server and a Secure Internal Communication (SIC) certificate for the Security
Management server. SIC certificates authenticate communication between
Check Point communicating components, or between Check Point
communicating components and OPSEC applications.
Note - Components can communicate with each other only once the Certificate Authority is
initialized and each component has received a SIC certificate.
12. Click Next. The Fingerprint window opens and displays the Fingerprint of the
Security Management server. The Fingerprint, a text string derived from the
Security Management server certificate, is used to verify the identity of the
Security Management server that is being accessed through SmartConsole.
13. From the Fingerprint window, click Export to file and save the file. The
Fingerprint is exported to a text file that can be accessed from the
SmartConsole client machine(s) and used to confirm the Fingerprint of the
Security Management server.
14. Once configuration using the Configuration Tool is complete, do the following:
a. From SmartConsole, perform a first time connection to the Security
Management server. The Fingerprint of the Security Management server
displays.
b. Ensure that the Security Management server Fingerprint matches the
Fingerprint displayed in SmartConsole.
Note - Do not perform a first time connection to the Security Management server from
SmartConsole unless the Security Management server Fingerprint is accessible and you can
confirm that it matches the Fingerprint displayed in SmartConsole.

Using the Configuration Tool on Unix Systems
15. Close the Configuration Tool.
Using the Configuration Tool on Unix Systems

To complete the installation process, use the Check Point Configuration Tool to
configure the Security Management server or security gateway.
To configure using the Configuration Tool on Unix systems:
1. Access the Configuration Tool.
Note - For first time installations, the Configuration Tool runs automatically. The
Configuration Tool can also be run after installation is complete using the cpconfig
command.
1. Add licenses. A license can be added manually or fetched from a file.

2. Add administrators. Add an administrator that uses SmartConsole to connect to
the Security Management server. Only one administrator can be added using
the Configuration Tool. Additional administrators can be added using
SmartDashboard.
3. Define GUI clients. You can add GUI clients using any of the following formats:
• IP address: For example, 1.2.3.4.
• IP/netmask: A range of IP addresses, for example,
192.168.10.0/255.255.255.0.
• Machine name: For example, Alice, or Alice.checkpoint.com.
• Any: Any IP address.
• IP1-IP2: A range of IP addresses, for example, 192.168.10.8 -
192.168.10.16.
• Wild cards: For example, 192.168.10.
4. Initialize the Internal Certificate Authority.
54
Logging In for the First Time
This option enables you to initialize an Internal Certificate Authority (ICA) on

the Security Management server and a Secure Internal Communication (SIC)
certificate for the Security Management server. SIC certificates authenticate
communication between Check Point communicating components, or between
Check Point communicating components and OPSEC applications.
Note - Components can communicate with each other only once the Certificate
Authority is initialized and each component has received a SIC certificate.
5. Export the Security Management server’s fingerprint to a text file. The

fingerprint, a text string derived from the Security Management server
certificate, is used to verify the identity of the Security Management server that
is being accessed through SmartConsole. The first time SmartConsole connects
to the Security Management server, compare this string to the string displayed
in SmartDashboard.
6. Start the installed products.

The Login Process
Administrators connect to the Security Management server through
SmartDashboard using the same process as SmartConsole clients. The
administrator and the Security Management server are first authenticated (to create
a secure channel of communication) and then the selected SmartConsole starts.
After the first login, the administrator can create a certificate for subsequent
logins. For additional information on how to create a certificate, refer to the R70
Security Management server Administration Guide.
Authenticating the Administrator
To authenticate the administrator:

1. Open SmartDashboard by selecting Start > Programs > Check Point SmartConsole
> SmartDashboard.
2. Log in using the User Name and Password defined in the Configuration Tool’s
Administrators page during the Security Management server installation.
If you are using a locally stored certificate to authenticate your connection,
browse to its location and enter the certificate’s password. The certificate’s
password can be changed by expanding the More Options link and clicking
Change Password.
3. Specify the name or IP address of the target Security Management server and
click OK.
4. Decide whether to connect in Read Only mode. This mode enables you to view
the current configuration without accidentally changing it. It also gives access
to Security Management server when another designated administrator is
already connected.
5. More Options. Clicking the More Options link enables you to fine tune how
SmartDashboard connects to Security Management server.
• The Change Password button in the Certificate Management area of the dialog
enables you to change the password that protects the certificate.
56
• Session Description. Descriptive information entered here populates the

Session ID field available in SmartView Tracker’s Audit Mode. The field can
be used to explain why a particular administrator is connecting to Security
Management server.
• Use compressed connection. This option optimizes the connection to
Security Management server. By default, the connection to Security
Management server is compressed. For a very large configuration database,
disabling the compression may help reduce load on the Security
Management server.
• Do not save recent connections information. By default, SmartDashboard
server remembers the last user ID and Security Management server to which
a connection was made. Select this option to prevent SmartDashboard from
displaying the last administrator and Security Management server to which
the administrator successfully connected.
• Plug-in Demo Mode. This option enables SmartDashboard demo mode to
display windows and options specific to a particular Plug-in. Select the
Plug-in from the Versions drop-down box.
6. Manually authenticate the Security Management server using the Fingerprint
provided during the configuration process.
Note - This step is only necessary the first time you log in from a given client computer,
since once the Security Management server is authenticated, the Fingerprint is saved in
the SmartConsole computer’s registry.

Where To From Here?
Where To From Here?

You have now learned the basics that you need to get started. The next step is to
obtain more advanced knowledge of your Check Point software.
Check Point documentation is available in PDF format on the Check Point CD and
the Technical Support download site at: http://support.checkpoint.com
Be sure to also use the Check Point Online Help when you are working with the
Check Point SmartConsole clients.
For additional technical information about Check Point products, consult Check
Point’s SecureKnowledge at: http://support.checkpoint.com
58
Chapter 4
Installing Provider-1
In This Chapter:
Overview page 60
Creating the Provider-1 Environment page 61
59
Overview
Overview
A typical Management Service Provider (MSP) manages and protects many
customer networks. Provider-1 ensures compatibility with a wide range of security
schemes and product deployments.
Figure 4-1 Sample Provider-1 Deployment
The components of a basic Provider-1 deployment are:

• MDS: Each Provider-1 network must have at least one Manager and one
Container. They can be installed on the same server or separately.
• MDG and SmartConsole Applications: Installed on a GUI client (a computer
running Check Point GUI) and support centralized system management.
• CMAs: Installed on a Container MDS. Each CMA manages the network of a
single customer domain.
• Customer Gateways: Protect the customer’s networks.
• NOC Gateways: Protect the MSP headquarters and network/security operations
centers:
Note - Depending on your system specifications, you must decide whether to manage NOC
gateways with a standalone Security Management server or with a Provider-1 system. For
Provider-1 systems, a Provider-1 customer is typically dedicated to serve as the NOC
customer.
60
Creating the Provider-1 Environment
Creating the Provider-1 Environment

In This Section
Overview page 60
Creating the Provider-1 Environment page 61
This section describes the process for provisioning a Provider-1 environment. The
following is a typical workflow:
Figure 4-2 Workflow
Setting Up Provider-1 Networking

The MDS and customer Security Gateways should be TCP/IP ready. An MDS server
should contain at least one interface with a routable IP address and should be able
to query a DNS server in order to resolve the IP addresses of other machine names.
As applicable, ensure that routing is properly configured to allow IP communication
between:
• The CMA/CLM and its managed gateways.
• An MDS and other MDSs in the system.
• A CMA and CLMs of the same customer.
• A CMA and its high availability CMA peer.
• A GUI client and MDS managers.
• A GUI client and CMAs/CLMs.
Chapter 4 Installing Provider-1 61

Install the Gateways
Install the Gateways

Install the Network Operation Center (NOC) gateway and customer gateways using
CD1in the Internet Security Product Suite. Refer to the Internet Security Product
Suite Installation and Upgrade guide for details.
Installing and Configuring the Primary MDS

The next step is to install the primary MDS on a dedicated, fresh computer. You
can install the primary on a Secure Platform, Linux or Solaris platform. The
installation procedure for Secure Platform varies slightly from the other platforms.
The Multi-Domain Server (MDS) contains Provider-1 system information including
details of the Provider-1 deployment, its administrators and customer management
information. An MDS may be defined as one of the following types:
• Manager: Hosts the Provider-1 management database and serves as the
administrator’s entry point into the Provider-1 environment.
• Container: Hosts the Customer Management Add-Ons (CMAs).
• Manager and Container: Hosts both the manager and container on a single
platform.
Note - If you define the primary MDS as a Manager only, you will need to install and
configure one or more container MDSs on separate platforms.
Installing SecurePlatform for Provider-1

To install and configure SecurePlatform for the initial primary MDS:
1. Insert the Provider-1 Secure Platform Distribution CD into a drive and boot the
computer. he following welcome message appears:
62
2. Press Enter to confirm the installation.
If your hardware is found not to be suitable, the reason for this is displayed as
part of the Welcome message, for example:
If a hardware device on the target machine is unsuitable, select Device List,

which displays a complete list of devices discovered by the hardware scan.
Compare this list with the Hardware Compatibility list at:
http://www.checkpoint.com/products/supported_platforms/recommended/ngx/ind
ex.html
Adjust your hardware accordingly.

3. Select OK to proceed with the installation. The Keyboard Selection window

opens.
4. Select a keyboard type from the list, then select OK. The Networking Device
window opens.
5. Select the interface to be used by the MDS for accessing the management
server and then OK. The Network Interface Configuration window opens.
64
6. Type the appropriate information in the IP address, net mask, and optionally,
the default gateway fields and select OK. The Host Name Configuration window
opens).
7. Enter a host name that is different from the default host name (cpmodule) and
select OK. The Confirmation window opens.
8. Select OK to proceed or Cancel to abort the installation process. The following
installation operations are performed:
• Hard drive formatting
• Package installation
• Post installation procedures

This procedure may take 10-12 minutes, after which the Installation Complete
window opens.
9. Select OK to complete SecurePlatform installation. The system reboots

automatically. Ensure that you remove the CD-ROM that you used during the
installation process.
10. When the Provider-1 Welcome screen appears, enter ‘n’ to continue.
11. On the Network Configuration screen, select 1 - Host Name.
12. Enter the computer name for the MDS host.
66
13. On the Choose network connections Configure your interfaces and network
connections as required. Follow the instructions on the screen.
When finished, enter ‘e’ and then ‘n’ to proceed to the next screen.
14. On the time and date screen, set the time zone, date and time as required.
15. Continue with “Installing the MDG” on page 70
Preparing to Install an MDS on Linux or Solaris

To create the first primary MDS on a Linux or Solaris Platform:
1. Install the Linux or Solaris operating system on the designated platform (If
required).
2. Log on as a user with superuser privileges.
3. From the mounted directory, navigate to the subdirectory that matches the
operating system of your MDS - solaris or linux.
4. Run the mds_setup script, and continue with “Installing the MDG” on page 70.
Installing Provider-1 on an MDS

To complete installing Provider-1 on the MDS:
1. On the Provider-1 Welcome screen, enter ‘n’.

2. In the following screen, select the MDS type as either (1) MDS Manager or (3)
MDS Manager and Container station. The first primary MDS must be one of these
two types.
3. Enter ‘Y’ in response to “Are you installing the Primary MDS Manager?”.
Note - Any information that you enter after this stage can be modified later using the
mdsconfig utility.
4. Specify whether the MDS should start automatically with each reboot
(recommended). If you choose to restart automatically, select a default base
directory when prompted.
5. Enter the name of the primary interface — the interface through which the MDS
will communicate with other MDSs in the Provider-1 network.
6. After the installation routine finishes installing packages, read and accept the
license agreement as directed.
68
7. Optionally add a Check Point license. You can always add licenses later using
the MDG.
8. Optionally, select an operating system user group that is allowed to access to

the MDS files. If you do not select a users group, the root users group is given
permissions to the files.
9. Press Enter to initialize the Certificate Authority.
10. Configure at least one Provider administrator and assign superuser privileges as
directed. Optionally add this administrator to a group.
11. When the installation utility finishes, set the source path by running
(according to your shell):
• For csh - source /opt/CPshared/5.0/tmp/.CPprofile.csh
• For sh - . /opt/CPshared/5.0/tmp/.CPprofile.sh
To avoid running the source path command each time you start the MDS, it is
recommended to add these lines to your .cshrc or . profile files, respectively.
12. Reboot the computer.
13. Start the MDS by executing the mdsstart command.

Installing SmartConsole and MDG Clients
Installing SmartConsole and MDG Clients

The following instructions are used when installing SmartConsole applications on
Windows platforms.
Installing SmartConsole
To install the SmartConsole on Windows platforms:
1. Access the windows/SmartConsole directory on the Provider-1 product CD.
2. Copy the SmartConsole executable to a temporary directory.
3. Start the installation by double-clicking the SmartConsole executable.
4. When the installation has completed, run SmartConsole applications from the
Windows Start > Programs > Check Point SmartConsole R70 > SmartDashboard
menu option.
Installing the MDG

To install the MDG package:
1. Access the windows/MDG directory on the Provider-1 product CD.
2. Copy the Prov1Gui executable to a temporary directory.
3. Start the installation by double-clicking the Prov1Gui executable.
4. When the installation has completed, run the MDG from the Windows Start >
Programs > Check Point SmartConsole R70 > Provider-1 menu option.
Uninstalling the MDS or the MDG

To uninstall an MDS on Linux and Solaris, execute the mds_remove command.
Note - This command is not available on SecurePlatform.
To uninstall the MDG and SmartConsole applications:

From the Windows Start menu, select Settings > Control Panel > Add/Remove
Programs.
70
Using the MDG for the First Time
Using the MDG for the First Time

Once you have set up your primary MDS, use the MDG to configure and manage the
Provider-1 deployment. Ensure that you have installed the MDG software on your
computer and that your computer is a trusted GUI Client. You must be an
administrator with appropriate privileges (Superuser, Global Manager, or Customer
Manager) to run the MDG.
Launching the MDG

To start the MDG:
1. Select: Start > Programs > Check Point SmartConsole > Provider-1.
2. Enter your User Name and Password or browse to your Certificate and enter the
password to open the certificate file.
3. Enter the MDS Manager computer name or IP address to which to you intend to
connect.
4. After a brief delay, the MDG opens, showing those network objects and menu
commands accessible according to your SecurePlatform permissions.
Figure 4-3 MDG before Customers are added

Adding Licenses using the MDG
Demo Mode
When starting the MDG, you can elect to open it in Demo mode. This mode does
not require authentication or a connection to the MDS. Demo mode is used when
you want to experiment with different objects and features before you create a real
system. It demonstrates several pre-configured sample customers, CMAs, gateways
and policies.
It is recommended that you use the Demo mode to familiarize yourself with the
MDG’s various views and modes. Operations performed while in Demo mode are
stored in a local database, which allows you to continue a Demo session from the
point at which you left off in a previous session.

To add a license to an MDS or MLM using the MDG:
1. In the MDG, Select the General View and the MDS Contents page.
72
2. Double-click on an MDS or MLM. The MDS Configuration window opens.
3. Select the License tab.

4. Install licenses using one of the following methods:

Fetch License File
a. Click Fetch From File.
b. In the Open window, browse to and double-click the desired license file.
Add License Information Manually
a. Click Add.
b. In the email message that you received from Check Point, select the entire
license string (starting with cplic putlic... and ending with the last
SKU/Feature) and copy it to the clipboard.
c. In the Add License window, click Paste License to paste the license details
you have saved on the clipboard into the Add License window.
d. Click Calculate to display your Validation Code. Compare this value with the
validation code that you received in your email. If validation fails, contact
the Check Point licensing center, providing them with both the validation
code contained in the email and the one displayed in this window.
74
Where To From Here?
Where To From Here?

obtain more detailed knowledge of your Check Point software. Check Point
documentation provides additional information and is available in PDF format on
the Check Point CD as well as on the Technical Support download site at:
http://www.checkpoint.com/support/technical/documents.

Where To From Here?
76
Chapter 5
IPS-1 Setup and Installation
In This Chapter
Overview page 78
IPS-1 Deployment page 80
IPS-1 Management Installation and Setup page 84
IPS-1 Sensor Appliances page 89
IPS-1 Sensor Installation page 94
IPS-1 Management Dashboard Installation page 99
Post-Installation Steps page 100
77
Overview
Overview
In This Section:
IPS-1 System Architecture page 78

Platforms page 79
IPS-1 System Architecture

Check Point’s IPS-1 is a dedicated intrusion prevention system (IPS) that delivers:
• Mission-critical protection against known and unknown attacks
• Unmatched management capabilities
• Granular forensic analysis
• Flexible deployment
• Confidence Indexing
An IPS-1 deployment includes the following components:
• IPS-1 Sensor: Detects and prevents internal network attacks, and sends alerts
to the Alerts Concentrator.
• Alerts Concentrator: Manages and receives alerts from a group of Sensors, and
stores the alerts in a MySQL database (included in the Alerts Concentrator
installation). Multiple IPS-1 Alerts Concentrators can be distributed throughout
the network as needed.
• IPS-1 Management Server: The central management server for the entire
deployment. Receives and correlates relevant alert information from the Alerts
Concentrator(s). Alert information is stored in a MySQL database, which is
included in the IPS-1 Management Server installation.
• IPS-1 Management Dashboard: Windows-based remote graphical user interface
(GUI) to the IPS-1 Management Server, for managing the IPS-1 system and for
monitoring alerts. The IPS-1 Dashboard includes a number of independent
interlinked windows, primarily:
• Policy Manager for configuring protections and managing the entire IPS-1
system.
• Alert Browser for viewing, tracking, and analyzing real-time alerts.
There are two deployment configurations for IPS-1:
78
Platforms
• Combined Deployment - An Alerts Concentrator is installed together with the

IPS-1 Management Server on the same computer.
• Distributed Deployment - The IPS-1 Management Server connects to one or
more Alerts Concentrators installed on separate computers.
The following diagram illustrates the components of the IPS-1 system architecture
with two Alerts Concentrators in a Distributed Deployment:
Figure 5-1 The IPS-1 System
Platforms
The IPS-1 Server and Alerts Concentrator can be installed on Check Point’s
SecurePlatform or on other supported operating systems. SecurePlatform is
provided with the IPS-1 installation media.
The IPS-1 Server can be installed together with a Security Management server for
managing security gateways and IPS-1 Sensors from the same platform. In this
case, it is possible to log into the IPS-1 Server via the IPS-1 Management
Dashboard with a Security Management server administrator username and
password. For usernames common to both IPS-1 and the Security Management
Server, the IPS-1 password and privileges override Security Management Server
settings.
IPS-1 (non-Power) Sensors are supported only on Check Point’s SecurePlatform.
Chapter 5 IPS-1 Setup and Installation 79

IPS-1 Deployment
IPS-1 Deployment
In This Section:
IPS-1 Sensor Deployment page 80

IPS-1 Management Deployment page 81
IPS-1 Sensor Deployment

This section covers deploying the IPS-1 Sensor.
Sensor Placement
IPS-1 Sensors should be deployed at natural choke points according to network
topology. Usually, Sensors should be just within the network firewall.
Placing Sensors outside the firewall is not recommended, because the Sensor is not
then protected by the firewall, and the unfiltered traffic places a heavier load on
the Sensor.
Ideally, network cores should also be protected with Sensors. In most cases,
network core topology does not enable these Sensors to be placed inline, in which
case the Sensors should be used for intrusion detection in passive mode.
Sensor Topology
In most cases, IPS-1 Sensors should be placed inline, enabling intrusion
prevention. In some cases, such as in a complex switching environment in a
network core, Sensors need to be used for intrusion detection in passive mode.
Sensors’ monitoring interfaces are layer-3 transparent and do not have IP
addresses. Each Sensor has a management interface that requires an IP address,
routable to and from the Alerts Concentrator. For enhanced security, it is
recommended that management be on a separate, out-of-band network.
For full information on Sensor modes, see the IPS-1 Administration Guide.
Inline Intrusion Prevention

For intrusion prevention, Sensors should be connected inline, so that all of the
traffic to be monitored flows through the IPS-1 Sensor. In this configuration,
Sensors can drop traffic containing attacks, according to defined and configurable
confidence indexing.
80
IPS-1 Management Deployment
Inline Sensors’ behavior upon failure can be configured to either open, passing
through all traffic; or closed, severing the traffic path.
Inline Sensors can be set to Bridge (Monitor-Only) mode, to avoid the possibility of
false-positive traffic dropping. In bridge mode, you can track what the Sensor
would have done in prevention mode. You can fine-tune your prevention settings in
bridge mode, and later change to prevention mode.
Passive Intrusion Detection

The IPS-1 Sensor can be placed out of the path of network traffic, in which case it
performs intrusion detection only.
For the Sensor to monitor traffic, a monitoring interface of the Sensor should be
connected to one of the following:
• A hub’s port
• A switch’s SPAN (or ‘mirror’) port
• A network tap
A network tap has advantages over a switch’s SPAN port. For example, the switch
could prevent (or be unable to send) some traffic out of the SPAN port.
For information on configuring and connecting the switch or tap, see the switch’s or
tap’s documentation.

In This Section:
Required IPS-1 Management Components page 81

IPS-1 Management Network page 82
Alerts Concentrator High Availability page 83
Required IPS-1 Management Components

Every IPS-1 deployment must have exactly one IPS-1 Management Server.
At least one installation of the IPS-1 Management Dashboard on a Windows client
host is necessary for managing the IPS-1 environment and for viewing and
analyzing alerts.

The appropriate number of Alerts Concentrators varies according to the network and
to administrative needs. The following rough guidelines should be considered:
• Each Alerts Concentrator is usually capable of handling around ten Sensors.
• It is not recommended for a single Alerts Concentrator’s database to approach
40 GB; If it does, an additional Alerts Concentrator is recommended.
For a rough estimate of appropriate database size, multiply the volume of
monitored traffic (in Gbps) by the number of months of alerts you plan to maintain.
The database size (in GB) should approach half of that product.
For example, if the Sensors that send alerts to a particular Alerts Concentrator
collectively monitor 5Gbps, and you want to maintain six months of back alerts, the
database should be 12-15 GB. However, appropriate database size is also
dependent on other factors, such as fine-tuning protections for your system to
minimize false positives.
Optionally, one Alerts Concentrator can be installed together with the IPS-1
Management Server in a Combined installation. This Alerts Concentrator will share
a license and some processes with the IPS-1 Management Server, but alert
information is stored in separate database tables.
IPS-1 Management Network

For enhanced security, it is recommended that management be on a separate,
out-of-band network.
TCP connectivity is required as follows:
• Connect from the IPS-1 Management Dashboard to the IPS-1 Management
Server on port 8443
• Connect from the IPS-1 Management Server to any Alerts Concentrators on port
18272
• Connect from each Alerts Concentrator to the management interfaces of its
IPS-1 Sensors, and vice versa, on port 1968
• (optional) Connect from the IPS-1 Management Server to the online update
server (ips-packages.checkpoint.com) on port 2013
Make sure the firewalls in between each component are configured to allow this
traffic.
82
Alerts Concentrator High Availability

To ensure continuity of information flow from IPS-1 Sensors to the IPS-1
Management Server in the event of an IPS-1 Alerts Concentrator failure, you can
configure an IPS-1 Sensor to report to a secondary IPS-1 Alerts Concentrator. This
automatically redirects alerts and event data to the secondary Alerts Concentrator if
the active Alerts Concentrator or the Sensor’s connection with it fails. You can
deploy the secondary Alerts Concentrator in the same network as the active Alerts
Concentrator.
For information on configuring Alerts Concentrator High Availability, see the IPS-1

IPS-1 Management Installation and Setup
IPS-1 Management Installation and Setup

In This Section:
Installation of IPS-1 Management Servers page 84

IPS-1 Management Dashboard Installation page 99
Completing IPS-1 Management Setup page 101
Installation of IPS-1 Management Servers

This section discusses installing the IPS-1 Management Server and Alerts
Concentrator.
The IPS-1 Management Server and Alerts Concentrator can be installed on Check
Point’s SecurePlatform or on other supported operating systems.
To install IPS-1 management servers together with a Security Management Server,
first install the Security Management Server according to the instructions in “Setup
and Installation” on page 33. Then follow the instructions in “Installation on an
Existing Operating System” on page 86.
To install Check Point’s SecurePlatform, follow the instructions in “Installation of
SecurePlatform for IPS-1 Management” on page 84.
To install IPS-1 management servers on already installed and configured operating
systems, follow the instructions in “Installation on an Existing Operating System”
on page 86.
In This Section:
Installation of SecurePlatform for IPS-1 Management page 84

Installation on an Existing Operating System page 86
Initial Configuration of Management Servers page 87
Installation of SecurePlatform for IPS-1 Management

To install SecurePlatform with the IPS-1 Management Server and/or Alerts
Concentrator:
the CD.
84
After booting, Welcome to Check Point SecurePlatform appears. Make sure to

press Enter within 90 seconds.
The following options are displayed:
2. Select OK to install.
The IPS-1 Products window appears.
3. Select Management Server, and OK.
4. Depending on the license you purchased, select one of the following options:
• SecurePlatform
• SecurePlatform Pro (includes the Advanced Routing Suite and additional
enhancements such as RADIUS authentication for administrators)
5. Select a keyboard type.
6. In the Management Interface Configuration window, define the management
interface IP address, netmask and default gateway. Select OK.
7. Select OK to format your hard drive, and extract and install SecurePlatform
software components. The installation process can take several minutes to
complete.
8. Press Enter to reboot.
9. When the computer is finished booting, log in with username: admin , and
password: admin.
10. As prompted, change the password and username.
11. Run:
sysconfig
The first-time system configuration wizard begins.

The following Network Configuration menu options are displayed:
Option Purpose
Host Name Sets and displays the host name
Domain Name Sets and displays the Domain name
Domain Name Servers Adds, removes, displays Domain name servers
Network Connections Adds, configures, removes, displays
network connections.
Routing Sets and shows a default gateway
• The hostname
• The computer’s network interfaces
• The default gateway (if required)
Note - Make sure the hostname and IP address are correctly defined at this stage. The
IPS-1 software will take this information from the operating system at installation time.
Subsequent changing of the hostname will not be reflected in the application.
14. Once Network Configuration is complete, press n to continue to Time and Date
Configuration. Configure the following:
• Time zone
• Date
• Local time
15. Press n.
Note - Network Time Protocol (NTP) can be configured through the command line interface
after the all of the installation procedures are complete. For more information, see
“Configuring NTP on SecurePlatform” on page 100.
16. Continue to “Initial Configuration of Management Servers” on page 87.
Installation on an Existing Operating System

To install an IPS-1 Management Server and/or Alerts Concentrator on an already
installed and configured supported operating system:
86
1. Before installing an IPS-1 Management Server on Red Hat Linux, ensure proper
connectivity between IPS-1 Management Dashboard and the IPS-1
Management Server by verifying that there is an /etc/hosts table entry for your
IP address and server name. For example:
127.0.0.1 localhost localhost.localdomain
192.168.13.5 servername servername.example.com
2. Before an upgrade, do the following:
a. Stop the IPS-1 processes.
b. As a precaution, back up database files by copying the contents of the
sdb/data directory to another host.
3. Make sure the hostname and IP address are correctly defined in the operating
system. The IPS-1 software will take this information from the operating system
at installation time. Subsequent changing of the hostname will not take effect.
4. Insert CD6 from the media pack, and mount it on the appropriate subdirectory.
5. From the CD’s root directory, run:
./UnixInstallScript [-splat]
On SecurePlatform, include the -splat flag. On other supported operating
systems, omit the flag.
6. Continue here to the following section for the configuration process.
Initial Configuration of Management Servers

1. Press Enter to scroll down and read the End-User License Agreement. Then
press y to accept.
IPS-1 packages are installed. This may take some time.
2. Answer whether this is an upgrade (y/n). If this is an upgrade, you are then
prompted for the previous installation location.
3. Select an IPS-1 product to install:
a. IPS-1 Management Server (all components)
This installs the IPS-1 Management Server as a Combined Deployment, that
is an IPS-1 Management Server with an Alerts Concentrator.
b. IPS-1 Management Server (without Alerts Concentrator)
This installs the IPS-1 Management Server as a Distributed Deployment,
that is an IPS-1 Management Server only, without an Alerts Concentrator.

c. IPS-1 Alerts Concentrator

4. When installing an Alerts Concentrator, enter and then confirm an activation
key with which the Alerts Concentrator will authenticate the IPS-1 Management
Server. You will need this activation key when you add the Alerts Concentrator
from the IPS-1 Dashboard.
5. When installing an IPS-1 Management Server or Combined installation, type
and then confirm an IPS-1 login password. This will be the password to use
when logging into the IPS-1 Management Server with the IPS-1 Dashboard for
the first time with username: admin .
6. Select whether IPS-1 should start when the computer is booted.
IPS-1 processes start. This completes the installation process.
The IPS-1 Power Sensor is now configured. Continue to “Post-Installation
Steps” on page 100.
88
IPS-1 Sensor Appliances
IPS-1 Sensor Appliances

Introduction
This chapter discusses setting up Check Point pre-installed appliances. For
third-party hardware, set up the hardware according to the third-party
documentation, and then continue to “IPS-1 Sensor Installation” on page 94.
For considerations for Sensor location and network topology, see “IPS-1 Sensor
Deployment” on page 80.
IPS-1 Sensor Appliance Models

Check Point currently delivers the following Sensor appliances with the interface
configurations listed:
IPS-1 Sensor 50C
Front — Two 10/100Mbps copper Ethernet front-panel interfaces used in IPS

(inline) mode as an IPS pair with bypass support, or in IDS (passive) mode
as two monitoring interfaces
Two 10/100/1000Mbps copper Ethernet front-panel interfaces, of which
one is the management interface and the other can be used in IDS
(passive) mode as an additional monitoring interface
IPS-1 Sensor 200C
Front — Four 10/100/1000Mbps copper Ethernet front-panel interfaces used in

IPS (inline) mode as IPS pairs with bypass support, or in IDS (passive)
mode as monitoring interfaces
Back — Four 10/100/1000Mbps copper Ethernet back-panel interfaces, of which

one is the management interface and the others can be used in IPS (inline)
mode as IPS pairs without bypass support, or in IDS (passive) mode as
additional monitoring interfaces

IPS-1 Sensor 200F

Four 1000Mbps Fiber front-panel interface with bypass support

mode as IPS pairs without bypass support, or in IDS (passive) mode as
IPS-1 Sensor 500C
Front — Eight 0/100/1000Mbps copper Ethernet front-panel interfaces used in


mode as IPS pairs with bypass support, or in IDS (passive) mode as
IPS-1 Sensor 500F

Four 1000Mbps Fiber front-panel interface with bypass support
90

mode as IPS pairs with bypass support, or in IDS (passive) mode as
IPS-1 Sensor 1000C
• Eight 10/100/1000 copper Ethernet back-panel interfaces used in IPS

(inline) mode as IPS pairs with bypass support, or in IDS (passive) mode as
monitoring interfaces
• Two 10/100/1000 built-in copper Ethernet back-panel interfaces, of which
one is the management interface and the other should remain unused
IPS-1 Sensor 1000F
Note - The interface labels of the 1000F model are the same as
the interface labels for the 1000C model.
• Eight Gigabit fiber Ethernet back-panel interfaces used in IPS (inline) mode
as IPS pairs with bypass support, or in IDS (passive) mode as monitoring
interfaces
• Two 10/100/1000 copper Ethernet back-panel interfaces, of which one is
the management interface and the other should remain unused
IPS-1 Power Sensor 1000C/F
Note - For detailed diagram of the Power Sensor interfaces, see

Setting Up Sensor Appliance Network Connections page 93.
• Eight 10/100/1000 Mbps copper Ethernet interfaces (C model) or Gigabit
fiber Ethernet interfaces (F model), used in IPS (inline) mode as IPS pairs
or in IDS (passive) as monitoring interfaces
• One front-panel 10/100Mbps copper Ethernet front-panel interface for
management
IPS-1 Power Sensor 2000C/F

• A Primary chassis unit, including:

• Eight 10/100/1000 Mbps copper Ethernet interfaces (C model), or

Gigabit fiber Ethernet interfaces (F model), used in IPS (inline) mode as
IPS pairs, or in IDS (passive) as monitoring interfaces
• One front-panel 10/100Mbps copper Ethernet front-panel interface for
management
• An Expansion chassis unit, adding processors and RAM
Preparing the Sensor’s Environment

The IPS-1 Sensors require the following:
Table 5-1 IPS-1 Sensor Environmental Requirements
50C 200C/F 500C/F Power C/F

Chassis size 1 Rack Unit (RU), 19” 2 chassis
units x
2RU, 19”
Amps AC 6.0/3.0 8.2/4.1 6.7/3.4 4/2 per
chassis
unit
Voltage Input 100-240 100-127/ 100-127/ 90-255
Range 200-240 200-240
Operating 0°C to +10°C to +10°C to 0°C to
Temperature +40°C +35°C +35°C +55°C
Non-Operating -20°C to -40°C to -40°C to -10°C to
Temperature +80°C +70°C +70°C +70°C
Non-Operating 10-90%, 90%, 90%, 10-90%,
Relative non- non- non- non-
Humidity condensi condensi condensi condensin
ng @ ng @ ng g @35°C
35°C 35°C @35°C
Emissions FCC Class A Device
Mount each unit onto the equipment rack.
Connect the power supply. For the Power Sensor, connect two power supplies to
each of the two chassis units.
92
Setting Up Sensor Appliance Network Connections

Connect the management interface to the management network. On the 50C and
Power 2000 models, the management interface is on the front panel. On other
models, it should be one of the two built-in interfaces on the rear panel.
For working in IDS (passive), any or all of the remaining interfaces can be used as
monitoring ports.
For working in inline IPS mode, the inline pairs must conform to hardware
configuration:
• For the 50C, the inline pair is marked on the front panel.
• For the 200 and 500 models, inline pairs are in vertical groupings.
• For the Power Sensors, inline interfaces are on the rear panel, horizontally
paired. For example, in the diagram below, s1.e0 is paired with s1.e1 .
Connecting the Power Sensor Chassis Units

With the supplied expansion cable, connect the Primary chassis unit’s Expansion slot A to the
Expansion chassis unit’s Expansion slot B:

IPS-1 Sensor Installation
IPS-1 Sensor Installation

In This Section:
Connecting to IPS-1 Sensors page 94

Installing SecurePlatform and IPS-1 Sensors page 94
Initial Configuration of IPS-1 Sensors page 95
Initial Configuration of IPS-1 Power Sensor page 97
Connecting to IPS-1 Sensors

You can run commands on the IPS-1 Sensor in one of three ways, depending on
hardware configuration:
• A connected keyboard and monitor.
• A serial console (DTE to DTE), using terminal emulation software such as
HyperTerminal (for Windows) or Minicom (for Unix/Linux systems). Connection
parameters for Check Point appliances are:
• For a regular (non-Power) IPS-1 Sensor appliance: 9600bps, no parity, 1
stop bit (8N1).
• For an IPS-1 Power Sensor: 115200bps, 8 bit, no parity, 1 stop bit, no
hardware or software (xon/xoff) flow control
For third-party hardware connection parameters, see the third-party
documentation.
• An SSH connection to the Sensor’s management interface (if sshd is
configured).
Installing SecurePlatform and IPS-1 Sensors

The following instructions are for installing IPS-1 Sensor software on third-party
hardware, or for reinstalling on a Check Point appliance.
IPS-1 (non-Power) Sensors are supported only on Check Point’s SecurePlatform
operating system version NGX R65 and above. The IPS-1 Sensor is installed with
SecurePlatform in one installation process. You cannot reinstall the Sensor without
reinstalling the operating system and formatting the hard disk.
To install SecurePlatform and the IPS-1 Sensor:
94
Initial Configuration of IPS-1 Sensors
the CD.
After booting, Welcome to Check Point SecurePlatform appears. Make sure to
press Enter within 90 seconds.
The following options are displayed:
2. Select OK to install.
The IPS-1 Products window appears.
3. Select Sensor, and OK.
4. Select the type of hardware you are using. If you are installing on hardware
provided by Check Point (or old hardware provided by NFR), select Appliance. If
you are installing on hardware supplied by another vendor, select Open Sensor.
For Sensor 1000 models, you should select Open Sensor even though the
hardware is supplied by Check Point.
5. Select a keyboard type. Select OK.
6. In the Networking Device window, select the management interface. Select OK.
7. In the Management Interface Configuration window, define the management
interface IP address, netmask and default gateway. Select OK.
8. Select OK to format your hard drive, and extract and install SecurePlatform
software components. The installation process can take several minutes to
complete.
9. When installation is complete, remove the CD.
10. Press Enter to reboot.

Upon initial boot of an IPS-1 Power Sensor, follow the instructions in “Initial
Configuration of IPS-1 Power Sensor” on page 97.

Upon initial boot of a freshly installed IPS-1 Sensor, including a new regular
(non-Power) preinstalled appliance, configure it as follows:
1. Log in with username: admin and password: admin .
2. When prompted, change the password and (optionally) the username.
3. Run:
sysconfig
The first-time system configuration wizard begins.
The Network Configuration menu options appear.
• The hostname
• The management interface
6. Once Network Configuration is complete, press n to continue to Time and Date
Configuration. Configure the following:
• Date
• Time and time zone
Enter n.
Note - Network Time Protocol (NTP) can be configured through the command line interface
after the all of the installation procedures are complete. For more information, see
“Configuring NTP on SecurePlatform” on page 100.
7. Configure the following Alerts Concentrator options for the Sensor:

• IP address of primary Alerts Concentrator.
• For Alerts Concentrator High Availability, type an IP address of a second
Alerts Concentrator. For more information on Alerts Concentrator High
Availability, see the IPS-1 Administration Guide.
• An Activation Key, a character string of your choice, which you will enter
into the IPS-1 Dashboard when adding the Sensor to an Alerts
Concentrator.
Select Next.
96
Initial Configuration of IPS-1 Power Sensor
8. Configure the Operating Mode options. For each field, select the field with the
Enter key, and select the appropriate value.
• Operating Mode - one of the following:
• IDS (passive): intrusion detection, no prevention. Packets do not pass
from one interface to another.
• IPS (inline, fail-closed): inline intrusion prevention. In fault conditions,
all packets are dropped.
• IPS (inline, fail-open): inline intrusion prevention. In fault conditions, all
packets are passed through.
• IPS Monitor-Only (inline, fail-open): inline bridge mode, but without
actual prevention.
For more information on Sensor modes, see the IPS-1 Administration Guide.
• Management Interface - displays (read-only) the IP address configured in the
operating system.
• Inline Pair(s) - pairs of monitoring interfaces. Depending on your hardware,
you may need to define the interface pairs that you will be using.
Select Next to complete the wizard.
You can modify the Sensor’s settings at anytime by running the cpconfig command.
The IPS-1 Sensor is now installed and configured. Continue to “Post-Installation

Configure a freshly delivered or reinstalled IPS-1 Power Sensor as follows:
1. Log in as user ips1 with the displayed password.
2. Set a new login password, and select Next.
3. Set the date and (optional) define an NTP server. Select Next.
4. Set the following:
• Hostname and domain name
• The Sensor’s IP information
Select Next.
5. Set the following:

• The IP address of the Primary Alerts Concentrator, and, for an Alerts

Concentrator High Availability deployment, the IP address of the second
Alerts Concentrator. For more information on Alerts Concentrator High
Availability, see the IPS-1 Administration Guide.
• An Activation Key, a character string of your choice, which you will enter
into the IPS-1 Dashboard when adding the Sensor to an Alerts
Concentrator.
Select Next.
6. Press Enter to see the following available operation modes:
• IDS (passive): intrusion detection, no prevention.
• IPS (inline, fail-closed): inline intrusion prevention. In fault conditions, all
packets are dropped.
• IPS (inline, fail-open): inline intrusion prevention. In fault conditions, all
packets are passed through.
• IPS Monitor-Only (inline, fail-open): inline bridge mode, but without actual
prevention.
• For more information about Sensor modes, see the IPS-1 Administration
Guide.
Select an operation mode and select Next. The system reboots.
7. The IPS-1 Power Sensor uses an internal network between components. The
network address for this network is preset to 10.10.10.0/24. If this conflicts
with your network addressing (for example, the Alerts Concentrator or Sensor
are in a network with that same address), reconfigure the internal network
address as follows:
a. Log into the IPS-1 Power Series appliance as admin . The password is the
same as for the nfr user
b. At the prompt, type:
configure system
c. At the next prompt, type:
set mccp subset address <address>
98
IPS-1 Management Dashboard Installation
where <address> is an available 24-bit network address (For example,

192.168.1.0)
Note - You can modify the Sensor’s settings at any time by logging on as the ips1 user. But
reconfiguring the internal network address is the ony reason you should ever need to login
as Admin to a power sensor.
The IPS-1 Power Sensor is now configured. Continue to “Post-Installation

IPS-1 Management Dashboard Installation

IPS-1 Dashboard is a Java application and is supported on:
• Windows 2000 Professional with SP4
• Windows XP Professional with SP2
IPS-1 Dashboard can be installed from CD2. The installation files are also located
on CD6 of the media pack in: windows\CPipsClient
Run the setupwin32 executable, and follow instructions.

Post-Installation Steps
Post-Installation Steps
In This Section:
Configuring NTP on SecurePlatform page 100

Completing IPS-1 Management Setup page 101
Completing IPS-1 Sensor Setup page 105
Once the IPS-1 components have been installed, one of the following procedures
may be required before deploying them in the network.
Configuring NTP on SecurePlatform

IPS-1 components rely on Network Time Protocol (NTP) to coordinate the time on
each component. Use the following commands to configure and manage NTP.
ntp
Configure and start the Network Time Protocol polling client.
Syntax
ntp <MD5_secret> <interval> <server1> [<server2>[<server3>]]
ntp -n <interval> <server1> [<server2>[<server3>]]
Parameters
Table 5-2 ntp Parameters
parameter meaning
MD5_secret pre-shared secret used to authenticate against the NTP server;
use “-n” when authentication is not required.
interval polling interval, in seconds
server[1,2,3 IP address or resolvable name of NTP server
]
ntpstop
Stop polling the NTP server.
100
Completing IPS-1 Management Setup
Syntax
ntpstop
ntpstart
Start polling the NTP server.
Syntax
ntpstart

In This Section:
First Login page 101

The Setup IPS-1 Wizard page 102
First Login
After installation, your initial login user name is: admin , and the password is the
one you entered during the IPS-1 Management Server installation. Begin managing
the IPS-1 system as follows:
1. Use the following command to verify that the IPS-1 Server (or Alerts
Concentrator) processes are running:
a. On SecurePlatform, enter expert mode by typing expert and pressing enter.
On other operating systems, login as root.
b. Run:
/etc/init.d/ips1 start

2. On the client computer, start the IPS-1 Management Dashboard. A login

window appears:
3. Type your username and password, and specify the IPS-1 Server’s IP address or
resolvable hostname. By default, port number is 8443.
Note - The default username is admin. When upgrading from a previous version of IPS-1,
login with the pre-existing usernames. The default username for prior versions of IPS-1 is
nfr.
4. If you are trying to connect to the IPS-1 Server through a proxy server, expand
the login window by clicking More Options and check Use Proxy. Type the proxy
server’s connection and authentication information. Note that for Digest Proxy
only HTTP is supported, not HTTPS.
5. Upon first login, you are prompted to Verify IPS-1 Management Server Certificate.
If you are sure the presented certificate is coming from your IPS-1 Management
Server, click Trust for the IPS-1 Management Dashboard on the host you are
working on to trust this IPS-1 Management Server in the future.
The Setup IPS-1 Wizard

If additional initial configuration is required, the Setup IPS-1 wizard starts after the
initial login. The following sections explain the wizard pages that may appear.
Manage Licenses
A freshly installed IPS-1 Management Server comes with a fifteen day trial license.
If the trial license has expired, you must add an IPS-1 Management Server license
obtained from Check Point’s User Center in order to continue working with IPS-1.
All licenses are stored on the IPS-1 Management Server and must have been
generated according to the IPS-1 Management Server’s IP address.
102
To add a license:
1. Copy your license string, obtained from Check Point’s user center, to the
clipboard.
A license string will include the following:
cplic putlic x.x.x.x 1Jan2001 xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx
CPMP-IPS-5-NGX xx-xxxxxxxxxxx
2. In the License Manager, click Add.
3. Populate the fields by clicking Paste License. Click OK.

The added license appears in the license list.
In a Distributed Deployment, click Next to continue to the Add Alerts
Concentrators page. In a Combined Deployment, the Alerts Concentrator
installed with the Server will automatically be added.
Add Alerts Concentrators

Alerts Concentrators can be added now or later, but you must have at least one to
proceed.
To add an Alerts Concentrator:
1. Click New.

The New Alerts Concentrator window appears:
Configure the Alerts Concentrator settings as follows:
2. In the Host field, type the Alerts Concentrator’s IP address or resolvable

hostname.
Note - Entering the Alert Concentrator’s IP address is preferred to better protect against
DNS spoofing.
3. Type and confirm the activation key that you specified during the Alerts
Concentrator installation.
Note - f you don’t have the activation key, log onto the Alerts Concentrator and set the
activation key via the set_activation_key command.
4. If there is a proxy server between the IPS-1 Server and the Alerts Concentrator,
select Use Proxy and type the proxy’s connection and authentication
information.
5. Make sure Receive Alerts is On.
104
Completing IPS-1 Sensor Setup
6. If this Alerts Concentrator or the IPS-1 Server’s communication with it might be

slower than others, select Avoid this server for help text. When an Alert Browser
user right-clicks an alert and selects Alert Details, the IPS-1 Server first
attempts to retrieve the Help Text from another Alerts Concentrator.
7. Click OK.
The Alerts Concentrator is added.

Once the IPS-1 Sensor is installed and configured, for it to be managed and
monitored by IPS-1 management, it needs to be added in the IPS-1 Management
Dashboard.
In Policy Manager, add the Sensor to the IPS-1 system, as follows:
1. In Policy Manager’s Sensors and Concentrators tab, select the Alerts
Concentrator to which you are adding the new Sensor and click New Sensor.
The Add New Sensor window appears:
2. Type the Sensor Name exactly as defined on the Sensor itself, and click Next.

3. Type the Sensor’s IP address or resolvable Hostname.

4. Type and confirm the Activation Key, as defined during Sensor installation or in
the Sensor’s Management Menu.
Note - You can reset the Activation key on the Sensor with the cpconfig command, or, in
the case of an IPS-1 Power Sensor, by logging in as the nfr user.
5. Click Next.
6. Select the Local Network Addresses that you want the IPS-1 Sensor to protect
from the list of Recently Used Values and use the arrow buttons in the middle of
the window to add, remove or change the order of the addresses in list of
Selected Host Types.
If your network does not appear in the Recently Used Values list, type the
network address and netmask information into the field at the bottom of the
window and press enter.
When all of your network addresses are listed in the Selected Host Types, click
Next.
7. Select the Local Broadcast Addresses for the protected networks from the
Recently Used Values and use the arrow buttons in the middle of the window to
add or remove addresses from the list of Selected Host Types.
If your broadcast address does not appear in the Recently Used Values list, type
the broadcast address into the field at the bottom of the window and press
enter.
When all of your broadcast addresses are listed in the Selected Host Types, click
Next.
8. Click New to assign descriptive names to your interfaces.
The Edit Interface Description window appears:
Enter the raw interface name as it is listed in the Sensor, and enter the
descriptive name that you want to assign to that interface. Click OK.
9. Once you have finished modifying the names of the interfaces, press Finish to
add the new Sensor to the Alerts Concentrator.
106
10. To apply the changes, click Install Policy.

For configuring protections and other settings, see the IPS-1 Administration Guide.

Where To From Here?
Where To From Here?

obtain more advanced knowledge of your Check Point software. Information
regarding configuration and deployment of IPS-1 can be found in the Check Point
IPS-1 Administration Guide.
Check Point documentation is available in PDF format on the Check Point CD and
the Technical Support download site at: http://support.checkpoint.com
Be sure to also use the Check Point Online Help when you are working with the
Check Point SmartConsole clients.
For additional technical information about Check Point products, consult Check
Point’s SecureKnowledge at: http://support.checkpoint.com
108
Chapter 6
Installing Eventia Suite
In This Chapter
Eventia Suite Installation page 110

Standalone Installation vs. Distributed Installation page 111
Standalone Installation page 112
Distributed Installation page 114
Enabling Connectivity Through a Firewall page 116
Preparing Eventia Suite in Security Management server page 117
Preparing Eventia Suite on Provider-1 MDS page 118
109
Eventia Suite Installation
Eventia Suite Installation

This chapter covers installing Eventia Suite. Eventia Suite is comprised of:
• Eventia Reporter, which consists of the Eventia Reporter Server and the Eventia
Reporter Client.
• Eventia Analyzer, which consists of the Eventia Analyzer Server, Correlation
Unit and the Eventia Analyzer Client.
For Hardware Requirements and Supported Platforms please refer to the Release
Notes document.
This installation process consists of three phases:
1. Install Eventia Suite.
2. Prepare Eventia Suite in Security Management server (refer to “Preparing
Eventia Suite in Security Management server” on page 117).
3. Configuring Eventia Suite (refer to Eventia Analyzer and Eventia Reporter User
Guides respectively).
110
Standalone Installation vs. Distributed Installation
Standalone Installation vs. Distributed

Installation
Eventia Reporter can be installed in either a “Standalone” installation or a
“Distributed” installation, while the Eventia Analyzer can only be installed on a
“Distributed” installation:
• Standalone installation — Eventia Reporter is installed on the same machine as
Security Management server.
• Distributed installation — Eventia Reporter and Eventia Analyzer are installed
on a machine dedicated to reporting.
• When working with Provider-1/SiteManager-1 or Security Management server on
Nokia, Eventia must be installed on a separate machine (distributed).
A distributed installation requires establishing Secure Internal Communication
(SIC) between the two machines. The distributed installation is recommended for
better performance.
Note - For Eventia Suite to read logs from a distributed log server, the database must be
installed on the log server after the Eventia Suite installation is complete.
Installing Eventia Suite on Multiple Versions of

Security Management Server Management
Eventia Suite in a Distributed installation can work with multiple versions of
Security Management server Management from R54 and up.
When installed on a Distributed deployment, Eventia Suite recognizes all the
Network Objects in the Security Management server database via an internal
process referred to as dbsync. With dbsync Eventia Suite can recognize objects
from multiple versions (that is, from R54 and up).
Chapter 6 Installing Eventia Suite 111

Standalone Installation
Standalone Installation
In This Section:
Windows Platform page 112

Solaris & Linux Platforms page 113
SecurePlatform page 113
Windows Platform
1. To install, login as an administrator and launch the wrapper by double-clicking
on the setup executable.
2. Click Next, and accept the terms of the license agreement.
3. Select either:
• Check Point Power
• Check Point UTM
Click Next.
4. Select New Installation.
5. From the Products list, select Eventia Suite. Security Management server is
automatically installed along with Eventia Reporter.
Security Management server is needed because of its log server component.
6. Specify the type of Security Management server to install:
• Primary Security Management server
• Secondary Security Management server
• Log Server
If you want a distributed deployment, select Log Server. If you want a
standalone deployment, select Primary Security Management server.
7. From the list of Eventia Suite components, select Eventia Reporter.
8. Click Next, and a list of products to install is displayed.
9. Verify the default install directory, or browse to new location.
10. The Check Point Configuration program, CPConfig, opens.
112
Solaris & Linux Platforms
11. Select Add and enter the Product License information provided by Check Point.
Alternatively, you may use the 15-day evaluation license. Select OK, and then
Next.
12. The Administrators window appears. Select Add and enter the administrator
name and password. Select OK. Then set permissions for the administrator. Add
more administrators if you like, and then select Next.
13. The GUI Clients window appears. Type in the IP address for a machine that will
run the Eventia Analyzer Client in the Remote Hostname field. Select Add. Add
more GUI Clients if you like, and then select Next.
14. To ensure secure communication between the Eventia Analyzer and Security
Management servers, an identical Activation Key must be set on both. Enter a
Secure Internal Communication (SIC) activation key and record it to be entered
later on the Security Management server. Select Finish.
Return to the wrapper.
15. To complete the installation of the Eventia Reporter and to continue with the
next phase of the installation, click Next and reboot the machine.
16. Launch SmartDashboard.
17. Install the Security Policy, (Policy>Install) or install the database (Policy>Install
Database).
Solaris & Linux Platforms

1. Mount the CD on the relevant subdirectory.
2. In the mounted directory, run the script: UnixInstallScript.
3. Read the End-User License Agreement (EULA) and if you accept click Yes.
4. Select whether you would like to perform an upgrade or create a new
installation.
5. Continue from step 5 on page 112 in order to complete the installation.
SecurePlatform
1. After you install SecurePlatform from the CD, select the Eventia Reporter
product from cpconfig or from the SecurePlatform Web GUI.
2. Select whether you would like to perform an upgrade or create a new
installation.
3. Continue from step 5 on page 112 in order to complete the installation.

Distributed Installation
Distributed Installation
In This Section:

Solaris and Linux and SecurePlatform page 115
In a distributed installation, Eventia Suite and Security Management server are

installed on separate machines.
Windows Platform
On the machine that will hold the Eventia Suite:
1. Login as an administrator and launch the wrapper by double-clicking on the
setup executable.
2. Click Next, and accept the terms of the license agreement.
3. Select either:
• Check Point Power
• Check Point UTM
Click Next.
4. Select New Installation.
5. From the Products list, select Eventia Suite.
6. Specify Log Server as the type of Security Management server to install.
Security Management server is needed because of its log server component.
7. From the list of Eventia Suite components, select the components that you
want to install (Eventia Analyzer Server, Eventia Correlation Unit, Log
Consolidator).
8. Click Next, and a list of products to install is displayed.
9. Verify the default install directory, or browse to new location.
10. The Check Point Configuration program, CPConfig, opens.
11. Select Add and enter the Product License information provided by Check Point.
Alternatively, you may use the 15-day evaluation license. Select OK, and then
Next.
114
Solaris and Linux and SecurePlatform
12. The Administrators window appears. Select Add and enter the administrator
name and password. Select OK. Then set permissions for the administrator. Add
more administrators if you like, and then select Next.
13. The GUI Clients window appears. Type in the IP address for a machine that will
run the Eventia Analyzer Client in the Remote Hostname field. Select Add. Add
more GUI Clients if you like, and then select Next.
14. To ensure secure communication between the Eventia Analyzer and Security
Management servers, an identical Activation Key must be set on both. Enter a
Secure Internal Communication (SIC) activation key and record it to be entered
later on the Security Management server. Select Finish.
15. Return to the wrapper.
16. To complete the installation of Eventia Suite and continue with the next phase
of the installation, click Next and reboot the machine.
Solaris and Linux and SecurePlatform

1. Mount the CD from the relevant subdirectory and launch the wrapper.
2. From the list of Eventia Suite components, select the components that you
want to install (Eventia Analyzer Server, Eventia Correlation Unit, Log
Consolidator).
3. When prompted, perform a short random keystroke session to collect random
data for cryptographic operations.
4. When prompted, create an activation key. Remember this key for later.
5. Enter Finish to complete the installation.

Enabling Connectivity Through a Firewall
Enabling Connectivity Through a Firewall

Certain additions to the Rule Base need to be made if a Firewall exists between any
Eventia Suite components and the Management Server, and either of the following
conditions apply:
• the management is prior to NGX (R60)
• the implied rules have been disabled
If either of these conditions is true, modify the Rule Base to enable connectivity
between components as follows:
Table 6-1 Additions to the Rule Base to Enable Connectivity
Source Destination Service

Eventia Analyzer Client Eventia Analyzer Server CPMI
Eventia Reporter Client Eventia Reporter Server CPMI
Management Server Eventia Analyzer and Reporter CPMI, FW1_ica_push
Server
Eventia Analyzer Server Management Server FW1_sam
Eventia Analyzer Server Correlation Unit CPD, CPD_amon
Correlation Unit Eventia Analyzer Server CPD_seam (TCP/18266)
Third-party devices that issue Log Server enabled to receive UDP syslog
syslog messages syslog messages
For an R65 level Security Management server (or above) the following rule needs to
be added to the Rule Base if a firewall exists between any Eventia Analyzer
components and the Management Server:
Source Destination Service

Correlation Unit Log Server LEA
116
Preparing Eventia Suite in Security Management server
Preparing Eventia Suite in Security

Management server
2. Create a new host for each Eventia Suite machine that contains an Eventia
Suite component:
Manage > Network Object > New > Check Point > Host
3. In the General Properties window, click Communication and enter the activation
key.
4. The version is not automatically entered if the Eventia Suite’s version is newer
than Security Management server. If so, select the most recent version available
from the Version drop-down list.
5. In the Check Point product list, select the appropriate Eventia Suite component
that you installed on the host that you created in step 2. If the Security
Management server version is pre-NGX, select both SmartView Reporter and Log
Server in place of Eventia Analyzer Server or Eventia Correlation Unit.
6. Install the Security Policy, (Policy > Install) or install the database (Policy >
Install Database) to make the Eventia Suite functional. This must be performed
in order for Eventia Analyzer to function as a log server.
7. To enable the log server on the Eventia server, perform install database in
SmartDashboard and select the Eventia server as one of the targets.

Preparing Eventia Suite on Provider-1 MDS
Preparing Eventia Suite on Provider-1 MDS

Preparing Eventia Suite on Provider-1 MDS varies according to the version you are
currently working with. Refer to the appropriate section below based on your version
of Provider-1.
In This Section:
For Provider-1/SiteManager-1 Version R55 page 118

For Provider-1/SiteManager-1 Version R60 page 120
For Provider-1/SiteManager-1 Version R61 and Up page 121
For Provider-1/SiteManager-1 Version R55

In Provider-1/SiteManager-1 R55, Eventia Suite can read the logs of multiple CMAs
with the use of putkey operations.
1. In the Provider-1/SiteManager-1 Global SmartDashboard, create a Check Point
Host Object, name it, enter its IP address and enable the product SmartView
Reporter.
2. Select Communication and enter the activation key you created during
installation. Select Initialize to establish communication.
Note - Do not run the Get Version operation. Instead, specify the most recent version
possible.
3. Select Close and OK.

4. From the File menu, select Save.
5. From the MDG, install Global Policy on all CMAs participating with Eventia
Suite.
6. For each CMA participating with Eventia Suite, open its SmartDashboard, select
Policy > Install Database, and select only the Log Servers and the CMA from
which you want the Eventia Suite to read logs.
7. To enable the syslog server run, the following commands from the command
ilne of the Eventia machine:
a. syslog -r
b. cpstop
118
c. cpstart
Note - Wait a couple of minutes for the objects to synchronize between the MDS and
Eventia Analyzer.
8. On the Eventia Suite machine and/or the Correlation Unit machine that will
read logs from a CMA, run the command cpstop.
9. Edit the file sic_policy.conf, which is located in the directory $CPDIR/conf.
Search for the section [Outbound rules], and change the following lines from:
# for log_export tool and Abacus analyzer
ANY ;ANY ;ANY; lea ; sslca
to:
# for log_export tool, Eventia Analyzer Provider-1
ANY ;ANY ;ANY; lea ; ssl , sslca
Note - Be sure to insert ssl , before sslca.
10. On the Eventia Suite machine, run the command cpstart.

11. On the Provider-1/SiteManager-1 MDS, run the command mdsstop.
12. Edit the file sic_policy.conf, which is located in the directory $CPDIR/conf. In
the section [Inbound rules], locate the following two lines:
# log export to DB utility (lea client from any SVN host)
ANY ; CP_PRODUCT; ANY; lea ; sslca
Add the following rule after these lines:
ANY ;ANY ;ANY; lea ; ssl
13. Run the command mdsstart.
14. Execute the putkey operation in the following manner:
a. On the Eventia Suite machine, run cpstop and fw putkey -p
[shared_password] [CMA_IP].

b. On the MDS, while in the CMA environment, run mdsstop_customer [CMA_IP]

and fw putkey -p [shared_ password] [Eventia Suite Server_IP
Note - Enter the command mdsenv <customer_name> to switch to the appropriate CMA
environment. To return to the MDS environment, enter the command mdsenv.
c. Run mdsstart_customer [CMA_IP] on the CMA.

d. Run cpstart on the Eventia Suite machine

1. In Global SmartDashboard, create a Check Point Host Object, name it, and enter
its IP address.
possible.
3. .Select Close and OK.

4. Make sure that the products Eventia Reporter is enabled.
Suite.
which you want Eventia Analyzer or Reporter to read logs.
8. To enable the syslog server run the following commands from the command line
of the Eventia server:
a. syslog -r
b. cpstop
c. cpstart
Note - Wait a couple of minutes for the objects to synchronize between the MDS and
Eventia Suite.
120
For Provider-1/SiteManager-1 Version R61 and Up

1. In Global SmartDashboard, create a Check Point Host Object, name it, and enter
its IP address.
possible.
3. Select Close and OK.

4. Make sure that the appropriate products (Eventia Reporter, Eventia Analyzer
Server, Eventia Correlation Unit and Log Server) are enabled.
5. In the properties of the new Host object, select Log and Masters > Additional
Logging Configuration, and enable the property Accept Syslog messages.
Suite.
which you want Eventia Analyzer or Reporter to read logs.

122
Upgrade Section
This section covers upgrading to the current version
124
Chapter 7
Introduction to the Upgrade
Process
In This Chapter
Documentation page 126

Contract Verification page 126
Supported Upgrade Paths and Interoperability page 127
Obtaining Software Installation Packages page 129
Terminology page 130
Upgrade Tools page 132
Upgrading Successfully page 132
Note - Only versons NGX R60 and above can be upgraded to R70.
125
Documentation
Documentation
This guide covers all available upgrade paths for Check Point products from NGX
R60 forward. Before you begin:
• Make sure that you have the latest version of this document by checking in the
User Center at:
• It is a good idea to have the latest version of the R70 Release Notes handy.
Download them from:
For a new features list, refer to the “R70 What’s New Guide”:
Contract Verification
Contract verification is now an integral part of the Check Point licensing scheme.
Before upgrading to the latest version, your licensing agreements are verified
through the User Center.
See: “Service Contract Files” on page 133” for more information.
126
Supported Upgrade Paths and Interoperability
Supported Upgrade Paths and

Interoperability
Management servers and gateways exist in a wide variety of deployments. Consult
Table 7-1and Table 7-2 to determine which versions of your management server
and gateways can be upgraded to R70.
Upgrading Management Servers

The following management versions can be upgraded to Security Management
server R70:
Table 7-1 Upgradeable management versions
Release Version
NGX
R60, R60A, R61, R62, R65
R65 with HFA 30 with the Connectra NGX R66 Plug-in
R65 with Messaging Security
R65 with the VPN-1 Power VSX NGX R65 Management Plug-in
R65 with the SmartProvisioning Plug-in
R65 UTM-1
R65 Power-1
Chapter 7 Introduction to the Upgrade Process 127


R70 supports backward compatibility for the following gateway versions:
Table 7-2 Supported gateways
Release Version
NGX R60, R60A, R61, R62, R65
InterSpect NGX R60
Endpoint Security
Note - R70 cannot manage gateway versions NG, NG FP1, or NG FP2.
128
Obtaining Software Installation Packages
Obtaining Software Installation Packages

R70 software installation packages for Solaris, Windows, Linux and SecurePlatform
are available on the product CD.
R70 software packages for Nokia are available from:
http://www.checkpoint.com/techsupport/downloads.jsp
Note - R70 is only supported on IPSO 6.0

Terminology
Terminology
Advanced Upgrade: In order to avoid unnecessary risks, it is possible to migrate the
current configuration to a spare server. The upgrade process is then performed on
the migrated server, leaving the production server intact.
ClusterXL: A software-based load sharing and high availability solution for Check
Point gateway deployments. It distributes traffic between clusters of redundant
gateways so that the computing capacity of multiple machines may be combined to
increase total throughput. In the event that any individual gateway becomes
unreachable, all connections are re-directed to a designated backup without
interruption. Tight integration with Check Point's Security Management server and
security gateway solutions ensures that ClusterXL deployment is a simple task for
security gateway administrators.
Distributed Deployment: A distributed deployment is performed when the gateway
and the Security Management server are deployed on different machines.
Gateway or Check Point Gateway: A gateway is the software component which
actively enforces the Security Policy of the organization.
In Place Upgrade: In Place upgrades are upgrades performed locally.
SmartProvisioning: Enables enterprises to easily scale, deploy, and manage VPNs
and security for thousands of remote locations.
Package Repository: This is 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 Gateways.
SmartLSM Security Gateway: A Remote Office/Branch Office Gateway. (formerly
ROBO gateway)
ROBO Profile: An object that you define to represent properties of multiple ROBO
gateways. Profile objects are version dependent; therefore, when you plan to
upgrade ROBO gateways to a new version, first define new Profile objects for your
new version. In general, it is recommended that you keep the Profile objects of the
previous versions until all ROBO Gateways of the previous version are upgraded to
SmartLSM Security gateways. For further information about defining a ROBO
Profile, refer to the CheckPoint SmartProvisioning Administration Guide.
Security Policy: A Security Policy is created by the system administrator in order to
regulate the incoming and outgoing flow of communication.
130
Terminology
Security Management server: The Security Management server is used by the

system administrator to manage the Security Policy. The databases and policies of
the organization are stored on the Security Management server, and are downloaded
from time to time to the gateways.
SmartConsole Clients: The SmartConsole Clients are the GUI applications that are
used to manage different aspects of the Security Policy. For example, SmartView
Tracker is a GUI client used to view logs.
SmartDashboard: A GUI client that is used to create Security Policies.
SmartUpdate: A tool that enables you to centrally upgrade and manage Check Point
software and licenses.
Standalone Deployment: A standalone deployment is performed when the Check
Point components that are responsible for the management of the Security Policy
(the Security Management server and the gateway) are installed on the same
machine.

Upgrade Tools
Upgrade Tools
Various upgrade tools are provided for migration and compatibility verification of
your current deployment. These tools help you successfully upgrade to R70.
The upgrade tools can be found in the following locations:
• in the R70 $FWDIR/bin/upgrade_tools directory.
• http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/utilities.html
Upgrading Successfully
Note that:
• Check Point Suite Products before version NGX R60 cannot be upgraded to
NGX R70.
• When upgrading NGX R65, only the following Plug-ins may be present:
Connectra, SmartProvisioning, VSX, and Messaging Security. The presence of
any other Plug-in will cause the upgrade process to fail.
Warning - If you upgrade from NGX R65 (with Plug-ins) to R70, and later want to uninstall
R70 (rollback to NGX R65), follow the instructions in sk37252
(http://supportcontent.checkpoint.com/solutions?id=sk37252) to avoid potential problems.
If you encounter unforeseen obstacles during the upgrade process, contact your
Reseller or our SecureKnowledge support center at:
https://secureknowledge.checkpoint.com
132
Chapter 8
Service Contract Files
In This Chapter
Introduction page 133

Working with Contract Files page 134
Installing a Contract File on Security Management server page 134
Installing a Contract File on a Gateway page 143
Managing Contracts with SmartUpdate page 155
Introduction
Before upgrading a gateway or Security Management server to R70, you need to
have a valid support contract that includes software upgrade and major releases
registered to your Check Point User Center account. The contract file is stored on
Security Management server and downloaded to security gateways during the
upgrade process. By verifying your status with the User Center, the contract file
enables you to easily remain compliant with current Check Point licensing
standards.
133
Working with Contract Files
Working with Contract Files

As in all upgrade procedures, first upgrade your Security Management server or
Provider-1/SiteManager-1 before upgrading the gateways. Once the management
has been successfully upgraded and contains a contract file, the contract file is
transferred to a gateway when the gateway is upgraded (the contract file is retrieved
from the management).
Note - Multiple user accounts at the User Center are supported.
Installing a Contract File on Security

Management server
The following section covers obtaining and installing the contract file for Security
Management server:
• On a Windows Platform
• On SecurePlatform, Linux and Solaris
• On IPSO
134
On a Windows Platform
When upgrading Security Management server, the upgrade process checks to see
whether a contract file is already present on the server. If not, the main options for
obtaining a contract are displayed:
You can:
• Download a contracts file from the User Center
If you have Internet access and a valid user account, you may download a
contract file directly from the User Center. The contract file obtained
through the user center contains contract information for all of your
accounts at the User Center. The contract file obtained through the user
center conforms with the terms of your licensing agreements.
i. Click Next.
Chapter 8 Service Contract Files 135

ii. Enter your User Account credentials.
If the connection succeeds but the downloaded contract file does not
cover the Security Management server, a message informs you that the
Security Management server is not eligible for upgrade.
However, the absence of a valid contract file will not prevent the
upgrade from taking place. Once the upgrade is complete, contact your
local support provider to obtain a valid contract.
• Import a local contract file
If the server being upgraded does not have Internet access, then:
i. On a machine with Internet access, browse to:
https://usercenter.checkpoint.com/usercenter/index.jsp
ii. Log in to the User Center
iii. Browse to Support.
136
iv. On the Additional Services page, in the Service Contract File Download
section, click Download Now:
v. Transfer the downloaded file to the management server. After selecting

Import a local contracts file, you can then browse to the location where
you stored the contract file:

If the contract file does not cover the Security Management server, a
message informs you that the Security Management server is not
eligible for upgrade. However, the absence of a valid contract file will
not prevent the upgrade from taking place. Once the upgrade is
complete, contact your local support provider to obtain a valid contract.
vi. Click Next to continue with the upgrade process
• Continue without contract information
Select this option if you intend to obtain and install a valid contract file at
a later date. Note that at this point your gateway is not strictly eligible for
an upgrade; you may be in violation of your Check Point Licensing
Agreement, as shown in the final message of upgrade process:
For more information, see: “Managing Contracts with SmartUpdate” on

page 155.
138
On SecurePlatform, Linux, and Solaris

When upgrading Security Management server, the upgrade process checks to see
whether a contract file is already present on the server. If not, the main options for
obtaining a contract are displayed:
You can:
If you have Internet access and a valid user account, then download a
through the user center conforms with the terms of your licensing
agreements. If you choose to download contract information from the User
Center, you are prompted to enter your:
• User name
• Password

• Proxy server address (if applicable):
message informs you that the Security Management server is not eligible for
upgrade. However, the absence of a valid contract file will not prevent the
upgrade from taking place. Download a valid contract at a later date using
SmartUpdate (see: “Managing Contracts with SmartUpdate” on page 155
for more information on using SmartUpdate).
iii. Browse to Support
140
iv. On the Downloads page, in the Service Contract File Download section,
click Download Now:
Transfer the downloaded file to the management server. After selecting

Import a local contracts file, enter the full path to the location where you
stored the file:
message informs you that the Security Management server is not eligible for
upgrade. However, the absence of a valid contract file will not prevent the
upgrade from taking place. Download a valid contract at a later date using
SmartUpdate (see: “Managing Contracts with SmartUpdate” on page 155
for more information on using SmartUpdate).

On IPSO
Agreement, as shown in the final message of the upgrade process:

page 155.
On IPSO
Contract verification on IPSO is not interactive. When upgrading an IPSO Security
Management server to R70, the upgrade process will check to see if there is a valid
contract already present on the Security Management server. If a contract is not
present, the upgrade process proceeds as normal. After successfully upgrading the
gateway, the following message is displayed:
The upgrade process requires a valid contract file in order to
verify that your gateway complies with Check Point licensing
agreements. While the absence of a contract file does not prevent
this upgrade, it is recommended that you obtain a contract file via
SmartUpdate (Licenses & Contracts menu -> Update Contracts).
For further details see:
http://www.checkpoint.com/ngx/upgrade/contract/
At the earliest opportunity, obtain a valid contract file from the Check Point user
center.
142
Installing a Contract File on a Gateway
Installing a Contract File on a Gateway

The following section covers obtaining and installing the contract file for gateways:
• On a Windows Platform
• On SecurePlatform, Linux and Solaris
• On IPSO
After accepting the End User License Agreement (EULA), the following message is
displayed:

After clicking Next, the upgrade process checks to see if a valid contract file is
installed on the gateway. If no contract file exists, the upgrade process attempts to
retrieve a contract file from the Security Management server that manages the
gateway. If a contract file cannot be retrieved from Security Management server,
the main options for obtaining a contract file for the gateway are displayed:
You can:
agreements.
144
i. Enter your User Account credentials.
If the connection succeeds but the downloaded contract file does not
cover the gateway, the following message appears:
However, this will not prevent the upgrade from taking place.

If a valid contract is available, the following message is displayed:
ii. After clicking Next, the upgrade process continues.

146
click Download Now:
v. Transfer the downloaded file to the gateway. After selecting Import a

local contracts file, you can then browse to the location where you stored
the file:
vi. Click Next.

If the local contract file does not cover the gateway, the following
message is displayed:
However, this will not prevent the upgrade from taking place. If the
contract file covers the gateway, the following message is displayed:
vii. Click Next to continue with the upgrade process
148

Agreement, as shown in the final message of upgrade process:

page 155.

On SecurePlatform, and Linux

After accepting the End User License Agreement (EULA), the following message is
displayed:
The upgrade process searches for a valid contract on the gateway. If a valid
contract is not located, the upgrade process attempts to retrieve the latest contract
file from the Security Management server that manages the gateway. If a valid
contract file is not located on the Security Management server, the main options for
obtaining a contract file for the gateway are displayed:
150
You can:
agreements. If you choose to download contract information from the User
Center, you are prompted to enter your:
• User name
• Password
• Proxy server address (if applicable):

If, according to information gathered from your User Center account, your
gateway is not eligible for upgrade, the following message is displayed:
You may still upgrade the gateway but are advised to download a valid contract
at a later date using SmartUpdate (see: “Managing Contracts with
SmartUpdate” on page 155 for more information on using SmartUpdate).
152

click Download Now:
Transfer the downloaded file to the gateway. After selecting Import a

local contracts file, enter the full path to the location where you stored
the file:

On IPSO
If the contract file does not cover the gateway, a message informs you
that the gateway is not eligible for upgrade. However, the absence of a
valid contract file will not prevent the upgrade from taking place. Once
the upgrade is complete, contact your local support provider to obtain a
valid contract.
Agreement, as shown in the final message of the upgrade process:

page 155.
On IPSO
Contract verification on IPSO is not interactive. When upgrading an IPSO gateway
to R70, the upgrade process will check to see if there is a valid contract available
on the Security Management server that manages the gateway. If none is available,
the upgrade process proceeds. After successfully upgrading the gateway, the
following message is displayed:
The upgrade process requires a valid contract file in order to
verify that your gateway complies with Check Point licensing
agreements. While the absence of a contract file does not prevent
this upgrade, it is recommended that you obtain a contract file via
SmartUpdate (Licenses & Contracts menu -> Update Contracts).
For further details see:
http://www.checkpoint.com/ngx/upgrade/contract/
At the earliest opportunity, obtain a valid contract file from the Check Point user
center.
154
Managing Contracts with SmartUpdate
Managing Contracts with SmartUpdate

Once you have successfully upgraded Security Management server, you can use
SmartUpdate to display and manage your contracts. From the License management
window, it is possible to see whether a particular license is associated with one or
more contracts:
Managing Contracts
The license Repository window in SmartUpdate displays contracts as well as regular
licenses:

Managing Contracts
Clicking on a specific license shows the properties of the license:
Clicking Show Contracts displays the contracts associated with this license:
156
Managing Contracts
Selecting a specific contract, then Properties displays the contract’s properties,

such as contract ID and expiration date as well as which licenses are covered by
the contract:

Updating Contracts
Updating Contracts
Licenses & Contracts on the File menu has enhanced functionality for handling
contracts:
• Licenses & Contracts > Update Contracts
This option installs contract information on Security Management server. Each
time you purchase a new contract, use this option to make sure the new
contract is displayed in the license repository:
• Licenses & Contracts > Get all Licenses

a. Collects licenses of all gateways managed by the Security Management
server
b. Updates the contract file on the server if the file on the gateway is newer
158
Chapter 9
Upgrading a Distributed
Deployment
In This Chapter

Upgrading the Security Management Server page 163
Upgrading the Gateway page 175
159
Introduction
Introduction
This chapter describes the process of upgrading a distributed deployment to R70.
A distributed deployment consists of at least one Security Management server and
one or more gateways. The Security Management server and gateway do not reside
on the same physical machine. Since backward compatibility is supported, a
Security Management server that has been upgraded to R70 can enforce and
manage gateways from previous versions. In some cases, however, new features
may not be available on earlier versions of the gateway.
The R70 Security Management server can manage the following gateways:
Release Version
NGX R60, R60A, R61, R62, R65
InterSpect NGX R60
Endpoint Security
R70 is not backwardly compatible with:

• VPN-1 Pro/Express NG
• VPN-1 Pro/Express NG FP1
• VPN-1 Pro/Express NG FP2
160
Pre-Upgrade Considerations
In This Section
Pre-upgrade Verification page 161

Web Intelligence License Enforcement page 161
Upgrading Products on a SecurePlatform Operating System page 162
UTM-1 Edge Gateways Prior to Firmware Version 7.5 page 162
Pre-upgrade Verification
Use of the Pre-Upgrade verification tool can reduce the risk of incompatibility with
the deployment to R70. It is used to test the current gateway prior to upgrading to
R70. The Pre-Upgrade verification tool produces a detailed report indicating the
appropriate actions that should be taken before performing an upgrade to R70
(refer to “Using the Pre-Upgrade Verification Tool” on page 163).
Web Intelligence License Enforcement

A gateway or gateway cluster requires a Web Intelligence license if it enforces one
or more of the following protections:
• Malicious Code Protector
• LDAP Injection
• SQL Injection
• Command Injection
• Directory Listing
• Error Concealment
• ASCII Only Request
• Header Rejection
• HTTP Methods
The actual license required depends on the number of Web servers protected by the
gateway or gateway cluster.
For NGX R60 and later versions, if the correct license is not installed, it is not
possible to install a Policy on a gateway.
Chapter 9 Upgrading a Distributed Deployment 161

Upgrading Products on a SecurePlatform Operating

System
When you upgrade from R60 (and above) to R70, both the SecurePlatform
operating system and software components are upgraded.
To upgrade products installed on SecurePlatform, refer to the “Security
Management Server Upgrade on SecurePlatform” on page 166.
The process upgrades all of the installed components (Operating System and
software packages) in a single upgrade process. No further upgrades are required.
UTM-1 Edge Gateways Prior to Firmware Version

7.5
Before you upgrade your deployment to R70, it is recommended that UTM-1 Edge
gateways should be at least version 7.5. By default, Security Management server
R70 is compatible with UTM-1 Edge gateways 7.5 and above.
Enabling Policy Enforcement on UTM-1 Edge Gateways

Pre-Firmware version 7.5
To enforce policies on earlier versions of UTM-1 Edge gateways, the following
workaround is needed:
Note - Once the workaround is complete, features new to R70 may not be available on
the gateway.
1. In a text editor, open the:

• /var/opt/CPEdgecmp/conf/SofawareLoader.ini file for Solaris, or
• c:\Program Files\CheckPoint\Edgecmp\R70\SofawareLoader.ini file in
Windows.
2. In the [Server] section, add the following:
TopologyOldFormat=1
3. Save and close the file.
The change takes effect without running the commands cpstop and cpstart.
162
Upgrading the Security Management Server

This section describes how to upgrade a Security Management server to R70.
Upgrades can be performed incrementally so that you do not have to upgrade the
Security Management server and all of the gateways at the same time. Once the
Security Management server is upgraded, you can still manage gateways from the
previous version, even though the gateways may not support the new features. You
can upgrade the gateways at your convenience.
Use of the Pre-Upgrade verification tool can reduce the risk of incompatibility with
the deployment to R70. It is used to test the current Security Management server
prior to upgrading to R70. The Pre-Upgrade verification tool produces a detailed
report indicating the appropriate actions that should be taken before performing an
upgrade to R70 (refer to “Using the Pre-Upgrade Verification Tool” on page 163).
There are two upgrade methods available for the Security Management server:
• Upgrade your Production Security Management server
Perform the upgrade process on the production Security Management server
(refer to the procedures in this section).
• Migrate and Upgrade to a New Security Management server
Perform a migration process (refer to “Migrate Your Current Security Gateway
Configuration & Upgrade” on page 228) of the currently installed version to a
new server, and upgrade the migrated system.
Using the Pre-Upgrade Verification Tool

Pre-upgrade verification runs automatically (or manually if desired) during the
upgrade process. Pre-upgrade verification performs a compatibility analysis of the
currently installed Security Management server and its current configuration. A
detailed report is provided, indicating appropriate actions that should be taken
before and after the upgrade process.
On SecurePlatform and Linux, running the patch add cd command presents three
options, one of which is: Run the pre-upgrade verification script.

Usage:
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion
-t TargetVersion [-f FileName] [-w]
or
-i[-f FileName][-w]
-p Path of the installed SmartCenter Server (FWDIR)
-c Currently installed version
-t Target version
-i Check originality of INSPECT files only
-f Output in file
-w Web format file
Where the currently installed version is one of the following:
For Release Version is:

NGX NGX_R65
NGX_R62
NGX_R61
NGX_R60A
NGX_R60
The target version is: R70.
Action Items Before and After the Pre-Upgrade Process

• errors - Items that must be repaired before and after performing the upgrade. If
you proceed with the upgrade while errors exist, the upgrade will fail.
• warnings - Items that you should consider repairing before and after performing
the upgrade.
164
Security Management Server Upgrade on a

Windows Platform
This section describes the upgrade process using the R70 CD. It is recommended
to back up your current configuration before you perform the upgrade process. For
additional information, refer to: “Backup and Revert for Security Gateways” on
page 185. If a situation arises in which a revert to your previous configuration is
required, refer to “Revert” on page 194 for details.
To perform an upgrade on a Windows platform:
1. Access your R70 CD.
2. Execute the Installation package.
3. After accepting the EULA, verify your contract information.
For more information on contracts, see: “Installing a Contract File on Security
Management server” on page 134
4. From the Upgrade Options screen, select Upgrade.
5. When the pre-upgrade verification recommendation appears, select whether or
not the Pre-upgrade verification tool should be executed (refer to “Using the
Pre-Upgrade Verification Tool” on page 163). Pre-upgrade verification performs
a compatibility analysis of the currently installed Security Management server
and of its current configuration. A detailed report is provided, indicating
appropriate actions that should be taken before and after the upgrade process.
The tool can be used manually as well.
6. From the Upgrade Options screen, select Upgrade again.
Another verification is run.
7. When prompted, reboot your Security Management server.
Uninstalling Packages
Uninstall Check Point packages on the Windows platform using the Add/Remove
applet in the Control Panel. Check Point packages need to be uninstalled in the
opposite order to which they were installed. For example, since CPsuite is the first
package installed, it should be the last package uninstalled.

Security Management Server Upgrade on

SecurePlatform
Upgrading to R70 on a SecurePlatform operating system requires updating both the
operating system and the installed software products. The procedure in this section
applies to the NGX management versions:
• R65
• R62
• R61
• R60A
• R60
The process described in this section upgrades all of the components (Operating
System and software packages) in a single upgrade process. No further upgrades
are required. Refer to the CheckPoint R70 SecurePlatform/SecurePlatformPro
Administration Guide for additional information.
If a situation arises in which a revert to your previous configuration is required,
refer to “Reverting to Your Previous Deployment” on page 195 for details.
To perform an upgrade on a SecurePlatform:
1. Insert CD1 of the R70 media kit into the CD drive.
2. At the command prompt, enter patch add cd.
3. Select SecurePlatform R70 Upgrade Package
(CPspupgrade_<version_number>.tgz).
4. Enter y to accept the checksum calculation.
5. When prompted, create a backup image for automatic revert.
Note - Creating the snapshot image can take up to twenty minutes, during which Check
Point products are stopped.
6. The welcome message is displayed. Enter n.

7. Accept the license agreement, and verify your contract information.
For more information on contracts, see: “On SecurePlatform, and Linux” on
page 150
166
8. Three upgrade options are displayed:

• Upgrade
• Export the configuration
• Perform pre-upgrade verification only
i. Run the pre-upgrade verification script, and follow the
recommendations contained in the pre-upgrade verification results.
Repeat the process until you see Your configuration is ready for upgrade.
ii. Export the configuration.
iii. Upgrade the installation.
9. Enter c to agree to the license upgrade.
The license upgrade process also handles gateway licenses in the SmartUpdate
License Repository. Select one of the following:
• Enter [L] to view the licenses installed on your machine.
• Enter [C] to check if currently installed licenses have been upgraded.
• Enter [S] to simulate the license upgrade.
• Enter [U] to perform the license upgrade, or generate a license file that can
be used to upgrade licenses on a machine with no Internet access to the
User Center.
• Enter [O] to perform the license upgrade on a license file that was
generated on machine with no Internet access to the User Center.
• Enter [Q] to quit.
10. Select a source for the upgrade utilities.
Either download the most updated files from the Check Point website or use
the upgrade tools contained on the CD. The exported configuration is
automatically imported during the upgrade process.
11. Open SmartUpdate and attach new licenses to the gateways.
Check Point packages need to be uninstalled in the opposite order to which they
were installed. For example, since CPsuite is the first package installed, it should
be the last package uninstalled.
Run the rpm -e <package name> to view a list of all the installed packages.

Gateway Upgrade on a UTM-1/Power-1 Appliance

operating system and the installed software products using the WebUI.
To upgrade your appliance using the WebUI:
1. Download an upgrade package, as directed.
2. Select the upgrade package file.
3. Click Upload upgrade package to appliance.
The Upload Package to Appliance window opens.
4. Browse to the upgrade (tgz) file and select it.
5. Click Upload and wait until the package uploads
6. Click Start Upgrade.
7. Before the upgrade begins, an image is created of the system and is used to
revert to in the event the upgrade is not successful. The Save an Image before
Upgrade page, displays the image information.
8. Click Next.
9. In the Safe Upgrade section, select Safe upgrade to require a successful login
after the upgrade is complete. If no login takes place within the configured
amount of time, the system will revert to the saved image.
Click Next.
10. The Current Upgrade File on Appliance section displays the information of the
current upgrade.
To begin the upgrade, click Start.
were installed. For example, since CPsuite is the first package installed, it will be
the last package uninstalled.
Run the rpm -e <package name> to view a list of all the installed packages.
168
Security Management Server Upgrade on a Solaris

Platform
that you back up your current configuration before you perform an upgrade process.
For additional information, refer to: “Backup and Revert for Security Gateways” on
page 185. If a situation arises in which a revert to your previous configuration is
required, refer to “Revert” on page 194 for details.
To perform an upgrade on a Solaris machine in a production environment:
1. Insert CD3 of the R70 media kit into the CD drive, and mount the CD.
2. Run UnixInstallScript.
The wrapper welcome message is displayed.
3. Enter n.
4. Enter y to agree to the End-user License Agreement, and verify your contract
information.
page 150
5. Select upgrade.
(It is also possible to upgrade using an imported configuration.)
6. Enter n.
Although the R70 upgrade utilities are on the R70 CD, it is recommended to
download the latest tools from the Check Point website at:
http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/utilities.html
8. The pre-upgrade verification process runs automatically. View the results and
follow any recommendations. Then, run the pre-upgrade verifier again. This
message is displayed: The pre-Upgrade Verification was completed successfully.
Your configuration is ready for upgrade.
9. To perform the upgrade, select Upgrade installed products.
To install additional products, select Upgrade installed products and install new
products. You are prompted to select the products from a list. Enter n.
10. Enter n to validate the products to install.
The products are upgraded. Wait until the successful message is displayed.

11. Enter e to exit.

12. Reboot.
were installed. Since CPsuite is the first package installed, it will be the last
package uninstalled.
Run the pkgrm command to view a list of the installed packages.
170
Security Management Server Upgrade on a Linux

Platform
that you back up your current configuration, before you perform an upgrade
process.
To perform an in-place upgrade:
2. From the root directory, run UnixInstallScript.
3. Enter n.
4. Enter y to agree to the End-user License Agreement, and verify your contract
information.
page 150
5. Select upgrade.
6. Enter n.
Although the R65 upgrade utilities are on the R70 CD, it is recommended to
download the latest tools from the Check Point website:
follow any recommendations. Then, run the pre-upgrade verifier again. This
message is displayed: The pre-Upgrade Verification was completed successfully.
Your configuration is ready for upgrade.
9. To perform the upgrade, specify Upgrade installed products.
To install new products, select Upgrade installed products and install new
products, select the products, and enter n.
The products are upgraded.
11. Enter e to exit.
12. Reboot.

were installed. Since CPsuite is the first package installed, it should be the last
Run the rpm -e <package name> to view a list of the installed packages.
172
Security Management Server Upgrade on an IPSO

Platform
Before beginning the upgrade process:
• It is recommended that you back up your current configuration, in case the
upgrade process is unsuccessful. IPSO has its own backup and restore facility.
For additional information, refer to the Nokia Network Voyager Reference Guide.
• Download and run the pre-upgrade verifier (PUV) for IPSO from:
For details on using the PUV, refer to “Using the Pre-Upgrade Verification Tool”
on page 163.
To perform an upgrade on an IPSO Platform:
1. From the Check Point website, download the R70 upgrade package:
IPSO_Wrapper_<version_number>.tgz
Note - For R70, you must first install IPSO 6.0
3. Click System Configuration > Install New IPSO Image (Upgrade).

4. Enter the following information:
5. Click Apply.
time.
6. Click Apply.

7. The new image installation process begins. Click the provided link to get the
upgrade status.
8. When the upgrade is complete, click the link to the IPSO Image Management
page.
9. Under the title Select an image for next boot, select the last downloaded image.
10. Click Test Boot.
properly.
15. Access the CLI console and log in.
16. Perform an FTP using bin mode to transfer the
IPSO_Wrapper_<version_number>.tgz package.
17. Type newpkg -S -m LOCAL -n <CPsuite package path> -o $FWDIR and press Enter.
This command:
• Deactivates previous Check Point packages but does not delete them.
• Finds the upgrade tools in $FWDIR and performs an import/export operation
to preserve the previous configuration.
When the process is complete, you should receive a message indicating that the
process was successful, along with a reminder to update your contract
information. For more information on contracts, see: “On IPSO” on page 154.
18. Log off the console connection, and then log back on to set the environment
variables.
19. Start the installed products by running cpstart.
Note - The previous Check Point packages remain installed but deactivated. Should the
need arise, the previous packages can be activated through the Network Voyager.
174
Upgrading the Gateway

There are two upgrade methods available:
• SmartUpdate Upgrade: Allows you to centrally upgrade and manage Check
Point software and licenses.
• Local Upgrade: Performs a local upgrade on the gateway itself.
In This Section
Upgrading a Clustered Deployment page 175

Upgrading the Gateway Using SmartUpdate page 176
Gateway Upgrade Process on a Windows Platform page 180
Gateway Upgrade on SecurePlatform page 182
Gateway Upgrade on an IPSO Platform page 183
Upgrading a Clustered Deployment

You can select one of the following options, when upgrading a Clustered
deployment:
• Minimal Effort Upgrade: Select this option if you have a period of time
during which network downtime is allowed. The minimal effort method is
much simpler because the clusters are upgraded as gateways and therefore
can be upgraded as individual gateways.
• Zero Downtime: Select this option if network activity is required during the
upgrade process. The zero downtime method assures both inbound and
outbound network connectivity at all times during the upgrade. There is
always at least one active member that handles traffic.
For additional information, refer to “Upgrading ClusterXL Deployments” on
page 237.

Upgrading the Gateway Using SmartUpdate

SmartUpdate is an optional module that automatically distributes software
packages and remotely performs upgrades of gateways and various OPSEC
products. It provides a centralized means to guarantee that the latest software
versions are used throughout the enterprise network. SmartUpdate takes
time-consuming tasks, which could otherwise be performed only by experts, and
turns them into simple point and click operations.
The following products can be upgraded to R70:
• NGX level Gateways
• SecurePlatform
• Performance Pack
• SmartView Monitor (as part of the R70 software package)
• Eventia Reporter
• UserAuthority Server
• PolicyServer (as part of the R70 software package)
• QoS (as part of the R70 software package)
• Nokia OS
• UTM-1/Power-1
SmartUpdate Options
SmartUpdate is the primary tool used for upgrading Check Point gateways. The
following features and tools are available in SmartUpdate:
• Upgrade All Packages: This feature allows you to upgrade all packages installed
on a gateway. For IPSO and SecurePlatform, this feature also allows you to
upgrade your operating system as a part of your upgrade. In R70,
SmartUpdate's “Upgrade all Packages” supports HFAs, i.e., it will suggest
upgrading the gateway with the latest HFA if a HFA package is available in the
Package Repository. "Upgrade All" is the recommended method. In addition,
there is an advanced method to install (distribute) packages one by one.
• Add Package to Repository: SmartUpdate provides three “helper” tools for
adding packages to the Package Repository:
• From CD: Adds a package from the Check Point CD.
• From File: Adds a package that you have stored locally.
176
• From Download Center: Adds a package from the Check Point Download
Center.
• SmartUpdate’s Get Check Point Gateway Data: This tool updates SmartUpdate
with the current Check Point or OPSEC third-party packages installed on a
specific gateway or for your entire enterprise.
• Check for Updates: This feature, available from the SmartDashboard Tools
menu, locates the latest HFA on the Check Point Download Center, and adds it
to the Package Repository.
Configuring the Security Management Server for

SmartUpdate
To configure the Security Management server for SmartUpdate:
1. Install the latest version of SmartConsole, including SmartUpdate.
2. Define the remote Check Point gateways in SmartDashboard (for a new Security
Management server installation).
3. Verify that your Security Management server contains the correct license to use
SmartUpdate.
4. Verify that the Administrator SmartUpdate permissions (as defined in the
cpconfig configuration tool) are Read/Write.
5. To enable SmartUpdate connections to the gateways, make sure that Policy
Global Properties > FireWall > Firewall Implied Rules > Accept SmartUpdate
Connections (SmartUpdate) is selected. By default, it is selected.

Add Packages to the Package Repository

Use SmartUpdate to add packages to and delete packages from the Package
Repository:
• directly from the Check Point Download Center website (Packages > Add > From
Download Center...),
• by adding them from the Check Point CD (Packages > Add > From CD...),
• by importing a file (Packages > Add > From File...).
When adding the package to the Package Repository, the package file is transferred
to the Security Management server. When the Operation Status window opens, you
can verify the success of the operation. The Package Repository is then updated to
show the new package object.
Gateway Upgrade Process Using SmartUpdate

To update a gateway using SmartUpdate:
1. From SmartUpdate > Packages > Upgrade All Packages select one or more
gateways and click Continue.
The Upgrade All Packages window opens, and in the Upgrade Verification list you
can see which gateways can or cannot be upgraded.
• To see a list of which packages will be installed on the gateways that can be
upgraded, select the gateway and click the Details button.
• For an explanation as to why a gateway cannot be upgraded, select the
relevant gateway and click the Details button.
2. From the list provided, select the gateways that can be upgraded and click
Upgrade.
Note - The Allow reboot... option (selected by default) is required in order to activate
the newly installed packages.
The Operation Status pane opens and shows the progress of the installation.
Each operation is represented by a single entry. Double click the entry to open
the Operation Details window, which shows the operation history.
The following operations are performed during the installation process:
• The Check Point Remote Installation Daemon connects to the Check Point
gateway.
• Verification for sufficient disk space.
178
• Verification of the package dependencies.

• The package is transferred to the gateway if it is not already there.
• The package is installed on the gateway.
• Enforcement policies are compiled for the new version.
• The gateway is rebooted if the Allow Reboot... option was selected and the
package requires it.
• The gateway version is updated in SmartDashboard.
• The installed packages are updated in SmartUpdate.

Gateway Upgrade Process on a Windows Platform

This section describes the upgrade process using the R70 Installation CD.
To upgrade a gateway in a Windows platform:
4. Select one of the following upgrade options:
• Download Most Updated Upgrade Utilities (recommended method).
This download provides the most recent upgrade code available.
• I have already downloaded and extracted the Upgrade Utilities. The files are on
my local disk.
This option should be used when software packages have been previously
downloaded. This method is useful when Internet access is not available
from the Security Management server machine.
• Use the CD version.
not the Pre-upgrade verification tool should be executed (refer to the “Using
the Pre-Upgrade Verification Tool” on page 163). The Pre-upgrade verification
tool performs a compatibility analysis of the currently installed gateway and its
current configuration. A detailed report is provided, indicating the appropriate
actions that should be taken before and after the upgrade process. The tool can
be used manually as well.
7. When prompted, reboot the gateway.
180
8. When the upgrade process is complete, do the following:

a. Using SmartDashboard, log in to the R70 Security Management server that
controls the upgraded gateway.
b. Open the gateway object properties window that represents the upgraded
gateway and change the version to R70.
c. Perform Install Policy on the upgraded gateway.

Gateway Upgrade on SecurePlatform

Upgrading to R70 on a SecurePlatform operating system requires updating both
operating system and software products installed. SecurePlatform users should
follow the relevant SecurePlatform upgrade process. The upgrade process is
supported for:
• R62
• R61
• R60A
• R60
The process described in this section upgrades all components (Operating System
and software packages) in a single upgrade process. No further upgrades are
required. The single upgrade package contains all necessary software items. Refer
to the CheckPoint R65 SecurePlatform/SecurePlatformPro Administration Guide
for additional information.
Upgrading SecurePlatform Using a CD ROM

This section describes how to upgrade SecurePlatform R54 and later versions using
a CD ROM drive.
To upgrade SecurePlatform using a CD:
1. Log in to SecurePlatform (expert mode is not necessary).
2. Apply the SecurePlatform R70 upgrade package: # patch add cd.
3. Select the SecurePlatform upgrade package
(CPspupgrade_<version_number>.tgz)
4. Enter y to accept the MD5 checksum calculation.
A Safe Upgrade will be performed. Safe Upgrade automatically takes a
snapshot of the entire system so that the entire system (operating system and
installed products) can be restored if something goes wrong during the Upgrade
process (for example, hardware incompatibility). If the Upgrade process detects
a malfunction, it automatically reverts to the Safe Upgrade image.
182
When the Upgrade process is complete, upon reboot you are given the option to
manually start the SecurePlatform operating system using the upgraded version
image or using the image created prior to the Upgrade process.
6. After you complete the upgrade process, do the following:
a. Using SmartDashboard, log in to the R70 Security Management server that
controls the upgraded gateway.
b. Open the gateway object properties window for the upgraded gateway and
change the version to R70.
c. Perform Install Policy on the upgraded gateway.
Gateway Upgrade on an IPSO Platform

The procedure is the same as for a standalone Gateway upgrade. See: “Standalone
Gateway Upgrade on an IPSO Platform” on page 207.

184
Chapter 10
Backup and Revert for
Security Gateways
In This Chapter

Backing Up Your Current Deployment page 187
Restoring a Deployment page 188
SecurePlatform Backup and Restore Commands page 189
SecurePlatform Snapshot Image Management page 192
Reverting to Your Previous Deployment page 195
185
Introduction
Introduction
Before you perform an upgrade process, you should back up your current
configuration. The purpose of the backup process is to back up the entire
configuration, and to restore it if necessary, for example, in the event that the
upgrade process is unsuccessful.
To back up your configuration, use the Export utility tool of the version for which
you are creating a backup file. For example, if you are backing up NG with
Application Intelligence R55, use the NG with Application Intelligence Export utility
tool. The backup file contains your current system configuration (for example,
objects, rules, and users) and can be used to restore your previous configuration if
the upgrade process fails. The restoration procedure restores the configuration in
effect when the backup procedure was executed.
Note - Operating system level configurations (for example, network configuration) are not
exported.
If you are performing an upgrade process on SecurePlatform, you do not have to

back up your configuration using the Export utility. SecurePlatform provides the
option of backing up your configuration during the Upgrade process.
186
Backing Up Your Current Deployment
Backing Up Your Current Deployment

To back up your current deployment:
1. In the original Security Management server, insert the product CD for the
version you are backing up.
2. Select the Export option in the installation wizard, or use the Export tool located
in the relevant operating system directory on the product CD.
Once the Export utility process is complete, the configuration file is created in
the chosen destination path in a tar gzipped format (.tgz).
Warning - The configuration file (.tgz) contains your product configuration. It is highly
recommended to delete it after completing the import process.
Chapter 10 Backup and Revert for Security Gateways 187

Restoring a Deployment
Restoring a Deployment
To restore a deployment:
1. Copy the exported.tgz file to the target Security Management server.
2. In the Security Management server, insert the product CD for the version being
restored.
3. Using the available options, perform an installation using an imported
configuration file.
188
SecurePlatform Backup and Restore Commands
SecurePlatform Backup and Restore

Commands
In This Section
Backup page 189

Restore page 191
SecurePlatform provides a command line or Web GUI capability for conducting

backups of your system settings and products configuration.
The backup utility can store backups either locally on the SecurePlatform machine
hard drive, or remotely to a TFTP server or an SCP server. The backup can be
performed on request, or it can be scheduled to take place at set intervals.
The backup files are kept in tar gzipped format (.tgz). Backup files, saved locally,
are kept in /var/CPbackup/backups.
The restore utility is used for restoring SecurePlatform settings and/or product
configurations from backup files.
Expert permissions are required to perform the backup and restore procedures.
Backup
This command is used to back up the system configuration. You can also copy
backup files to a number of SCP and TFTP servers for improved backup robustness.
The backup command, when run by itself without any additional flags, uses default
backup settings and performs a local backup.
Syntax
backup [-h] [-d] [-l] [--purge DAYS] [--sched [on hh:mm <-m DayOfMonth>
| <-w DaysOfWeek>] | off] [[--tftp <ServerIP> [-path <Path>]
[<Filename>]] |
[--scp <ServerIP> <Username> <Password> [-path <Path>][<Filename>]] |
[--file [-path <Path>][<Filename>]]

Backup
Parameters
Table 10-1 Backup Parameters
Parameter Meaning
-h obtain usage
-d debug flag
-l Enables VPN log backup (By default, VPN logs are
not backed up.)
--purge DAYS Deletes old backups from previous backup attempts
[--sched [on hh:mm <-m Schedule interval at which backup is to take place
DayOfMonth> | <-w
• On - specify time and day of week, or day of
DaysOfWeek>] | off]
month
• Off - disable schedule
--tftp <ServerIP> [-path List of IP addresses of TFTP servers, on which the
<Path>][<Filename>] configuration is to be backed up, and optionally the
filename
--scp <ServerIP> List of IP addresses of SCP servers, on which the
<Username> configuration is to be backed up, the username and
<Password>[-path <Path>] password used to access the SCP server, and
[<Filename>] optionally the filename
--file [-path When the backup is performed locally, specify an
<Path>]<Filename> optional filename
190
Restore
Restore
This command is used to restore the system configuration.
Syntax
restore [-h] [-d][[--tftp <ServerIP> <Filename>] |
[--scp <ServerIP> <Username> <Password> <Filename>] |
[--file <Filename>]]
Parameters
Table 10-2
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of TFTP server, from which the
[<Filename>] configuration is restored, and the filename
--scp <ServerIP> IP address of SCP server, from which the
<Username> <Password> configuration is restored, the username and
[<Filename>] password used to access the SCP server, and the
filename
--file <Filename> Specify a filename for restore operation, performed
locally
For additional information about the backup and restore utilities, refer to the
System Commands section in the CheckPoint R65
SecurePlatform/SecurePlatformPro Administration Guide.

SecurePlatform Snapshot Image Management
SecurePlatform Snapshot Image

Management
In This Section
Snapshot page 193

Revert page 194
SecurePlatform provides the option of backing up the entire SecurePlatform

operating system and all of its products using the snapshot command.
A snapshot of the system can be taken manually using the snapshot command or
automatically during an upgrade procedure using the SafeUpgrade option.
Having a snapshot of the entire operating system enables you to restore
SecurePlatform if needed. Similar to Backup and Restore, the Snapshot and Revert
features ensure easy maintenance and management, even if a situation arises that
demands that you undo an upgrade and revert to a previous deployment.
The snapshot and revert commands can use a TFTP server or an SCP server to
store snapshots. Alternatively, snapshots can be stored locally.
Note - The snapshot and revert commands are relevant only for reverting R70 to a
previous version on SecurePlatform; because this involves reverting the entire platform.
If you are using another platform, see “Reverting to Your Previous Deployment” on
page 195.
192
Snapshot
Snapshot
This command creates an image of SecurePlatform. The snapshot command, run by
itself without any additional flags, uses the default backup settings and creates a
local snapshot.
Syntax
snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] |
Parameters
Table 10-3 Snapshot Parameters
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is taken, as well as the filename of the
snapshot
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is taken, the username and password
<Filename> used to access the SCP server, and the filename of
the snapshot
--file <Filename> When the snapshot is made locally, specify a
filename

Revert
Revert
This command restores SecurePlatform from a snapshot file, reverting the machine
to a previous deployment. The revert command, run by itself without any additional
flags, uses default backup settings, and reboots the system from a local snapshot.
revert [-h] [-d] [[--tftp <ServerIP> <Filename>] |
Parameters
Table 10-4 Revert Parameters
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is rebooted, as well as the filename of the
snapshot
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is rebooted, the username and password
<Filename> used to access the SCP server, and the filename of
the snapshot
--file <Filename> When the snapshot is made locally, specify a
filename
The revert command functionality can also be accessed from the Snapshot image
management boot option.
194
Reverting to Your Previous Deployment

In This Section
To an Earlier Version on a Nokia Platform page 195

To an Earlier Version on a Windows Platform page 196
To an Earlier Version on a Solaris Platform page 196
To an Earlier Version on a Linux Platform page 196
ICA Considerations page 197
If you are deploying on SecurePlatform, see “SecurePlatform Snapshot Image

Management” on page 192.
To revert to a version that was active before it was upgraded to R70, perform the
uninstall procedure described in this section, according to the platform you have.
This will uninstall the last active version only, and leave the previously installed
version as the now-active version.
Note - Make sure to remove all R70 products and compatibility packages before removing
the R70 CPsuite.
To an Earlier Version on a Nokia Platform

To revert to a prior software version on a Nokia platform, do one of the following.
• If you are reverting to an NG or NGX version that is compatible with your
current IPSO version:
1. Deactivate the R70 products.
2. Deactivate the previous suite version last of all.
3. Reactivate the previous product versions.
or
• If you are reverting to an NG version that requires an earlier IPSO version:
1. On the IPSO Image Management page in Network Voyager, select the earlier
IPSO image and reboot.
When you revert to the earlier image, IPSO automatically reverts to the
saved configuration set associated with that image.

2. On the Manage Packages page, confirm that the previous versions of Check
Point packages are enabled and the R70 versions are disabled.
Note - On flash-based platforms, the R70 packages no longer appear in the Manage
Packages page since they were never part of the previous configuration set.
To an Earlier Version on a Windows Platform

To revert to a prior software version on a Windows platform:
1. In Add/Remove Programs, select Check Point <product> R70.
2. Click Remove.
The latest version is uninstalled, and the previous version is active.
To an Earlier Version on a Solaris Platform

To revert to a prior software version on a Solaris platform:
1. For each installed package, other than CPSuite, run the command:
pkgrm <file>-R70.
2. Run the command: pkgrm CPsuite-R70.

To an Earlier Version on a Linux Platform

To revert to a prior software version on a Linux platform:
1. For each installed package, other than CPSuite, run the command:
rpm -e <file>-R70-00.
2. Run the command: rpm –e CPsuite-R70-00.

196
ICA Considerations
Once the Revert process is complete, certificates issued during the use of R70
remain valid. While these certificates are valid, they cannot be processed by the
Internal CA.
To resume management of older certificates after the Revert process:
1. Back up the InternalCA.NDB and ICA.crl files (located in the $FWDIR/conf
directory) and all *.crl files (located in the $FWDIR/conf/crl directory) from
the version prior to R70 to a suitable location.
2. Copy the R70 InternalCA.NDB, ICA.crl and the *.crl files (located in the
$FWDIR/conf directory) from the current R70 version and use them to overwrite
the files in the location specified in step 1 (in the $FWDIR/conf directory).
Note - If the Upgrade process was performed on a machine that runs a different operating
system than the original machine, the InternalCA.NDB file must be converted after it is
copied to the reverted environment. To do this, run the ‘cpca_dbutil d2u’ command
line from the reverted environment.
3. Once the Revert process is complete, use the ICA Management Tool to review
certificates created using R70 in the reverted environment. For example, the
subject to which a specific certificate was issued may no longer exist. In such
a case, you may want to revoke the specific certificate.
For additional information, refer to The Internal Certificate Authority (ICA) and
the ICA Management Tool chapter in the Security Management Server

198
Chapter 11
Upgrading a Standalone
Deployment
In This Chapter

Pre-Upgrade Considerations page 201
Standalone Security Gateway Upgrade on a Windows Platform page 203
Standalone Security Gateway Upgrade on SecurePlatform page 204
Standalone Upgrade on a UTM-1/Power-1 Appliance page 206
Standalone Gateway Upgrade on an IPSO Platform page 207
199
Introduction
Introduction
This chapter describes the process of upgrading a standalone deployment to R70.
A standalone deployment consists of the Security Management server and gateway
installed on the same system. Since backward compatibility is supported, a
Security Management server that has been upgraded to R70 can enforce and
manage gateways from previous versions. In some cases, however, new features
may not be available on earlier versions of the gateway.
The R70 Security Management server can manage the following gateways:
Release Version
NGX R60, R60A, R61, R62, R65
InterSpect NGX R60
Endpoint Security
Note - R70 cannot manage gateway versions NG, NG FP1, or NG FP2.
200
In This Section
Upgrading Products on a SecurePlatform Operating System page 201

Reverting to Your Previous Software Version page 201
Upgrading Products on a SecurePlatform Operating

System
Upgrading to R70 on a SecurePlatform operating system requires upgrading both
the operating system and the installed software products.
To upgrade products installed on SecurePlatform, refer to Standalone Security
Gateway Upgrade on SecurePlatform.
This process upgrades all the installed components (Operating System and software
packages) in a single upgrade process. No further upgrades are required.
Reverting to Your Previous Software Version

Before you perform an upgrade process you should back up your current
SecurePlatform configuration. The purpose of the back up process is to back up the
entire SecurePlatform configuration, and to restore it if necessary, for example, in
the event that the Upgrade process is unsuccessful.
Warning - For all operating systems except SecurePlatform, an R70 upgrade cannot be
reverted to its previous version, once it is complete.
To back up your configuration, use the SecurePlatform snapshot and revert

commands (for additional information, refer to “SecurePlatform Backup and
Restore Commands” on page 189).”
Chapter 11 Upgrading a Standalone Deployment 201

Using the Pre-Upgrade Verification Tool

Pre-upgrade verification runs automatically (or manually if desired) during the
upgrade process. Pre-upgrade verification performs a compatibility analysis of the
currently installed deployment and its current configuration. A detailed report is
provided, indicating the appropriate actions that should be taken before and after
the upgrade process. This tool can also be used manually.
Usage:
-t TargetVersion [-f FileName] [-w]
or
-i[-f FileName][-w]
-p Path of the installed SmartCenter server (FWDIR)
-c Currently installed version
-t Target version
-i Check originality of INSPECT files only
-f Output in file
-w Web format file
Where the currently installed version is one of the following:
For Release Version is:

NGX NGX_R62
NGX_R61
NGX_R60A
NGX_R60
The target version is: R70.
Action Items Before and After the Pre-Upgrade Process

• errors - Items that must be repaired before and after performing the upgrade. If
you proceed with the upgrade while errors exist, the upgrade will fail.
• warnings - Items that you should consider repairing before and after performing
the upgrade.
202
Standalone Security Gateway Upgrade on a Windows Platform
Standalone Security Gateway Upgrade on a

Windows Platform
It is recommended that before you perform an upgrade process, you should back up
your current configuration, in case the upgrade process is unsuccessful. For
additional information, refer to Backing Up Your Current Deployment page 187.
reverted to its previous version once it is complete.
To perform an upgrade on a Windows platform:

3. Agree to the EULA and verify your contract information.
For more information on contracts, “On a Windows Platform” on page 143
not the Pre-upgrade verification tool should be executed (refer to “Using the
Pre-Upgrade Verification Tool” on page 202). Pre-upgrade verification performs
a compatibility analysis of the currently installed gateway and its current
configuration. A detailed report is provided, indicating appropriate actions that
should be taken before and after the upgrade process. The tool can be used
manually as well.
7. Reboot when prompted.
Uninstall Check Point packages on the Windows platform using the Add/Remove
applet in the Control Panel. Check Point packages need to be uninstalled in the
opposite order to which they were installed. Since CPsuite is the first package
installed, it should be the last package uninstalled.

Standalone Security Gateway Upgrade on SecurePlatform
Standalone Security Gateway Upgrade on

SecurePlatform
operating system and the installed software products. The procedure in this section
applies to the following gateway versions:
• R62
• R61
• R60A
• R60
The process described in this section upgrades all of the components (Operating
System and software packages) in a single upgrade process. No further upgrades
are required. The single upgrade package contains all necessary software items.
reverted to its previous version once it is complete.
To perform an upgrade on a SecurePlatform server:

3. Select SecurePlatform R70 Upgrade Package
(CPspupgrade_<version_number>.tgz).
Note - Creating the snapshot image can take up to twenty minutes, during which time
Check Point products are stopped.

7. Accept the license agreement, and verifying your contract information.
For more information on contracts, “On SecurePlatform, and Linux” on
page 150
• Upgrade
204
Standalone Security Gateway Upgrade on SecurePlatform

license repository. Select one of the following:
User Center.
10. Select a source for the upgrade utilities
Either download the most updated files from the Check Point website for use
11. Open SmartUpdate and attach the new licenses to the gateways.
were installed. Since CPsuite is the first package installed, it should be the last

Standalone Upgrade on a UTM-1/Power-1 Appliance
Standalone Upgrade on a UTM-1/Power-1

Appliance
operating system and the installed software products using the WebUI.
To upgrade your appliance using the WebUI:
1. Download an upgrade package, as directed.
2. Select the upgrade package file.
3. Click Upload upgrade package to appliance.
The Upload Package to Appliance window opens.
4. Browse to the upgrade (tgz) file and select it.
5. Click Upload and wait until the package uploads
6. Click Start Upgrade.
7. Before the upgrade begins, an image is created of the system and is used to
revert to in the event the upgrade is not successful. The Save an Image before
Upgrade page, displays the image information.
Click Next.
8. In the Safe Upgrade section, select Safe upgrade to require a successful login
after the upgrade is complete. If no login takes place within the configured
amount of time, the system will revert to the saved image.
Click Next.
9. The Current Upgrade File on Appliance section displays the information of the
current upgrade.
10. To begin the upgrade, click Start..
were installed. For example, since CPsuite is the first package installed, it should
be the last package uninstalled.
206
Standalone Gateway Upgrade on an IPSO Platform
Standalone Gateway Upgrade on an IPSO

Platform
This section describes the upgrade process on an IPSO Platform. It is
recommended that you back up your current configuration, before you perform an
upgrade process, for example, in the event that the upgrade process is
unsuccessful. IPSO has its own back up and restore facility. For additional
information, refer to the Nokia Network Voyager Reference Guide.
If a situation arises in which a revert to your previous configuration is required refer
to “Reverting to Your Previous Deployment” on page 195 for details.
Note - For R70 you need IPSO 6.0
Before upgrading:
• From the Check Point website, download:
• IPSO 6.0
• IPSO_Wrapper_R70.tgz.
• From Nokia, download: UTM-Base
To upgrade to R70:
2. Click System Configuration > Install New IPSO Image (Upgrade).
3. Enter the following information (for IPSO 6.0):
4. Click Apply.
time.
5. Click Apply.

A message is displayed indicating that the new image installation process has
started.
6. When you receive a Success message, click UP > UP > Manage IPSO Images.
7. Under the title Select an image for next boot, select the last downloaded image:
IPSO 6.0
8. Click Test Boot.
properly.
13. In Voyager, deactivate existing packages and delete them.
Deactivate and delete the packages in the opposite order to which they were
installed and activated.
14. Access the CLI console, and log in.
15. Type newpkg, and press Enter.
16. Use the FTP menu option to transfer the UTM-Base package.
17. Install the UTM-Base package.
18. Activate the UTM-Base package.
19. In Voyager, verify that the UTM Base package is turned ON.
20. On the CLI, type newpkg, and press Enter.
21. Use the FTP menu option to transfer the IPSO_Wrapper_R70.tgz package.
22. Install the IPSO_Wrapper_70 package.
23. Type Reboot and press Enter.
208

Once Anti-virus and Web filtering is enabled, the relevant traffic is blocked from
passing through the gateway. If the relevant traffic is not blocked, run the
fwipso2linux command on the gateway to manually activate the native IPSO security
servers. (When the UTM-Base package was installed and activated, the native IPSO
security servers should have been activated as well).
Uninstalling Previous Software Packages

If you are reverting to an NG or NGX version that is compatible with your current
IPSO version, deactivate the R70 products, making sure to deactivate the previous
suite version last of all. Then, reactivate the previous product versions.
If you are reverting to an NG version that requires an earlier IPSO version:
1. From the IPSO Image Management page in the Network Voyager, select the
earlier IPSO image and reboot.
When you revert to the earlier image, IPSO automatically reverts to using the
saved configuration set associated with that image.
2. On the Manage Packages page, confirm that the previous versions of Check
Point packages are enabled and the R70 versions are disabled.
Note - On flash-based platforms, the R70 packages will no longer appear in the Manage
Packages page since they were never part of the previous configuration set.

210
Chapter 12
Advanced Upgrade of
Security Management servers
& Standalone Gateways
In This Chapter

Migrate Your Current Server Configuration and Upgrade page 213
Migrate Your Current Security Gateway Configuration & Upgrade page 228
211
Introduction
Introduction
There are a number of reasons for performing an advanced upgrade, for example if
you need to:
• Upgrade to R70 while replacing the Operating System on which the current
Security Management Server is installed.
• Upgrade to R70 while migrating to a new server.
• Upgrade to R70 while avoiding unnecessary risks to the production Security
Management server in case of failure during the upgrade process.
To avoid unnecessary risks, it is possible to migrate the current configuration of the
production Security Management server, to a new Security Management server.
Warning - When performing an advanced upgrade using the import-export tool, it is vital
that the target machine has the same exact configuration as the source machine. For
example, the same products should be installed on both. A products mismatch may result in
a corrupt database.
212
Migrate Your Current Server Configuration and Upgrade
Migrate Your Current Server Configuration

and Upgrade
In This Section

Advanced Upgrade on a Windows Platform page 214
Advanced Upgrade on a Linux Platform page 215
Advanced Upgrade on SecurePlatform page 219
Advanced Upgrade on an IPSO Platform page 221
Advanced Upgrade on a Solaris Platform page 223
Migration to a New Machine with a Different IP Address page 226
Introduction
This section describes the advanced upgrade procedure for Security Management
Server. The advanced upgrade procedure involves two machines. The first machine
is the working production machine, the source. The second machine, the
destination, is off-line, and only contains the operating system of the latest release,
in this case R70. Security Management server is installed on the second
(destination) machine and the configuration of the first machine (the source) is
imported.
Advanced upgrade on all platforms except IPSO involves:
• Performing a new installation, and manually importing a previously exported
configuration, or:
• Performing a new installation and upgradingthrough the wrapper. The wrapper
automatically performs the install, and the upgrade_import process.
When migrating to a new Security Management server, the destination server should
have the same IP configuration as the original Security Management server. If you
are migrating to a new machine with a different IP address, see: See “Migration to
a New Machine with a Different IP Address” on page 226.
Chapter 12 Advanced Upgrade of Security Management servers & Standalone Gateways 213
Warning:
An advanced upgrade of Security Management server influences the behavior of the
Eventia Reporter Server in regard to consolidation sessions. If you are deploying
Eventia Reporter, before you perform an advanced upgrade of Security Management
server, you must first remove Eventia Reporter’s consolidation session. See “Advanced
Eventia Reporter Upgrade” on page 303 for how to remove the consolidation session.
Advanced Upgrade on a Windows Platform

To perform an advanced upgrade on a Windows platform:
1. Insert the R70 CD into the production Security Management server.
2. Accept the license agreement and click next.
3. Under Upgrade Options, select Export.
If you opt to perform the Export procedure manually, make sure you are using
the R70 Export tool. The upgrade_export tool is located on the product CD
under the windows directory.
4. When prompted, download the most recently updated upgrade utilities from the
Check Point website.
If this is not possible, select Use the upgrade utilities from the CD.
5. Perform the Pre-Upgrade Verification.
6. Select the destination path for the configuration (.tgz) file.
Wait until the database files are exported.
7. Copy the exported.tgz file to the new Security Management server.
8. Insert the R70 CD into the target Security Management server.
9. Do one of the following:
• Perform a fresh install of Security Management server and import the
configuration file. When prompted, select Installation using Imported
Configuration. This option prompts you for the location of the imported .tgz
configuration file and then automatically installs the new software and
utilizes the imported .tgz configuration file.
• Perform a fresh install of Security Management server, and manually import
the configuration file using the upgrade_import tool on the R70 CD. To
manually import the Security Management Server database:
214
i. On the R70 Security Management server, locate the upgrade_export

tool in the $FWDIR/bin/upgrade_tools directory.
ii. Copy upgrade_export tool to the same directory on the source machine.
(Before doing this, it is recommended to preserve the old upgrade tools
by renaming them.)
iii. Run the upgrade_export tool:
upgrade_export <new database name>
The upgrade_export tool creates a <new database name>.tgz file.
iv. Transfer the .tgz file to the R70 $FWDIR/bin/upgrade_tools folder.
v. Run the upgrade_import tool:
upgrade_import <new database name>.tgz
The database is imported.
vi. Reboot the Security Management server.
vii. Open SmartDashboard and edit the properties of the Security
Management server network object, removing the IP address of the
source machine and replacing it with the new one.
Warning - The configuration file (.tgz) file contains your security configuration. It is highly
recommended to delete it after completing the upgrade process.
Advanced Upgrade on a Linux Platform

To perform a new installation and manually import the configuration:
3. Enter n.
4. Enter y to agree to the End-user License Agreement.
5. Select New installation as the installation option.
6. Enter n.
7. From the list of products, select Security Management.
8. Enter n.
9. Specify the Security Management Server type to install:

• Primary Security Management
• Secondary Security Management
• Log server
10. Enter n.
12. After product installation, the Check Point Configuration Program opens. Use
the Check Point Configuration program to:
a. Add licenses: The Check Point Configuration Program only manages local
licenses on this machine. The recommended way of managing licenses is
through SmartUpdate.
b. Configure GUI clients: A list of hosts which will be able to connect to this
Security Management server using SmartConsole.
c. Configure group permissions: Specifies a group name.
d. Configure a pool of characters: For use in cryptographic operations. Type
e. Configure the Certificate Authority: Saves the CA’s Fingerprint to a file.
f. Start the installed products.
13. Log in again to the root account to set the new environment variables.
14. Transfer the exported configuration to the new Solaris installation, for example
through FTP.
15. Change directory to /opt/CPsuite-R70/fw1/bin/upgrade tools
Verify that the upgrade tools in this directory are the R70 upgrade tools, taken
from the installation CD or downloaded from the Check Point website:
16. Run ./upgrade_import <name_of_exported_configuration_file.tgz>
17. Enter y to stop all Check Point services.
The license upgrade wrapper runs.
18. Enter c to continue, or q to quit.
19. Wait for the message: upgrade_import finished successfully!
20. Enter y to restart Check Point Services.
216
Performing a New Installation

To perform a new installation and upgrade using the Wrapper:
3. Enter n.
5. Select products:
• Check Point Power for headquarters and branch offices
• Check Point UTM for medium-sized businesses
6. Enter n.
7. For the installation option, select Installation Using Imported Configuration.
8. To import a Security Management Server configuration and upgrade it, enter the
path to, and name of, the compressed file that contains the exported
configuration. Enter n.
While the R65 upgrade utilities are on the R70 CD, it is recommended to
11. Enter n.
follow the recommendations.
13. Enter n.
14. Specify an upgrade option:
• Upgrade installed products
• Upgrade installed products and install new products
15. Enter n.
18. Reboot.
20. To start Check Point Services, run: cpstart.
218
Advanced Upgrade on SecurePlatform

To perform an advanced upgrade on SecurePlatform using the wrapper:
3. Select SecurePlatform R70 Upgrade Package (CPsupgrade_R70.tgz).

7. Accept the license agreement.
• Upgrade
ii. Export the configuration
iii. Upgrade the installation
User Center.
To perform an advanced upgrade on SecurePlatform by manually importing the
database:
1. On the R70 Security Management server, locate the upgrade_export tool in the
$FWDIR/bin/upgrade_tools directory.
2. Copy upgrade_export tool to the same directory on the source machine. (Before
doing this, it is recommended to preserve the old upgrade tools by renaming
them.)
3. Run the upgrade_export tool:
./upgrade_export <new database name>
4. The upgrade_export tool creates a <new database name>.tgz file.
5. Transfer the .tgz file to the R70 $FWDIR/bin/upgrade_tools folder.
6. Run the upgrade_import tool:
./upgrade_import <new database name>.tgz
7. The database is imported.
8. Reboot the Security Management server.
9. Open SmartDashboard and edit the properties of the Security Management
server network object, removing the IP address of the source machine and
replacing it with the new one.
220
Advanced Upgrade on an IPSO Platform

Advanced upgrade involves performing a new installation and manually importing a
previously exported configuration.
To perform an advanced upgrade on an IPSO platform:
1. On the production machine, download the latest R70 upgrade tools, and
transfer them to $FWDIR/bin/upgrade_tools.
(You need the latest R70 upgrade tools to perform the export operation.)
2. On the production machine, run upgrade_export.
3. Transfer the resulting .tgz file to the second, off-line machine.
4. On the second, off line machine, download from the Check Point website the
R70 upgrade package: IPSO_Wrapper_<version_number>.tgz
5. From the command prompt, run:
newpkg –S –m LOCAL –n <path_to>/IPSO_Wrapper_<version_number>.tgz>
The package and products are installed but not activated.
6. Reboot.
8. Select a product:
• Check Point Power for headquarters and branch offices
• Check Point UTM for medium-sized businesses
9. Select the installation type: Stand Alone or Distributed.
10. Select Security Management Server from the list.
11. Specify the Security Management Server type as Primary or Secondary.
12. Add Licenses.
14. Configure the GUI clients and hosts which can access the Security
Management server management component.
18. When prompted, do not start the installed products.

19. From $FWDIR/bin/upgrade_tools, run upgrade_import.
20. Reboot.
222
Advanced Upgrade on a Solaris Platform

To perform an advanced upgrade on a Solaris platform:
3. Enter n.
6. Enter n.
7. From the list of products, select Security Management.
8. Enter n.
• Log server
10. Enter n.
14. Transfer the exported configuration to the new Solaris installation, for example,
using FTP.
15. Change the directory to /opt/CPsuite-R70/fw1/bin/upgrade tools.
Verify that the upgrade tools in this directory are the R70 upgrade tools taken
from the installation CD or downloaded from the Check Point website.
Performing a Solaris Installation and Upgrade

To perform a new Solaris installation and upgrade using the wrapper:
3. Enter n.
5. For the installation option, select Installation Using Imported Configuration.
The license upgrade wrapper runs. The license upgrade process may take some
since, as all the licenses are gathered and sent in SSL-encrypted format to the
Check Point User Center.
While the upgrade utilities are on the R70 CD, it is recommended to download
the latest tools from the Check Point website.
9. Enter n.
224
11. Enter n.
13. Enter n.
16. Reboot.
Migration to a New Machine with a Different IP

Address
Due to the nature of licenses (which are associated with IP addresses), when
migrating your current Security Management Server configuration, verify that the
destination server has the same IP configuration as the original.
The following two sections explain the steps that should be performed when the
new Security Management Server has a different IP address.
Before Migrating Your Original Security Management

Server
To prepare to migrate a Security Management server to a new machine:
1. On the original Security Management server, add rules that will allow the new
Security Management Server to access the gateways it will manage. To do this
create a Security Management Server object that represents the new Security
Management Server’s IP address:
Manage > Network Objects > New… > Check Point > Host/Gateway and in the
General Properties tab select Secondary Security Management server in the
software blades section.
2. On the original Security Management server, create a firewall rule that allows
FW1 (TCP 256), CPD (TCP 18191) services, and FW1_CPRID (TCP 18208)
services to originate from the new Security Management server whose
destination is all available gateways.
3. Install the new security policy on all.
4. Perform the appropriate process to migrate your original Security Management
server.
After Migrating Your Original Security Management

Server
To complete the process of migrating a Security Management server to a new
machine:
1. Update the Security Management Server licenses with the new IP address. If
central licenses are used they should also be updated with the new IP Address.
2. Use the cpstart command to start the new Security Management Server.
3. Access the new Security Management Server using SmartDashboard.
226
4. On the new Security Management Server, remove the object you created to
represent the new Security Management Server’s IP address.
5. On the new Security Management Server update the primary Security
Management Server object so that its IP Address and topology match its new
configuration.
6. On the DNS, map the Security Management Server’s DNS to the new IP
address.
Migrate Your Current Security Gateway Configuration & Upgrade
Migrate Your Current Security Gateway

Configuration & Upgrade
In This Section:
Advanced Upgrade on a Windows Platform page 228

Advanced Upgrade on a Linux Platform page 215
Advanced Upgrade on SecurePlatform page 233
Advanced Upgrade on an IPSO Platform page 235
This section covers the advanced upgrade procedure for security gateways. The
advanced upgrade procedure involves two machines. The first machine is the
working production machine. The second machine is off-line, and only contains the
operating system. The Security Management server is freshly installed on the
second machine and the configuration of the first machine is imported.
Advanced Upgrade on a Windows Platform

To perform an advanced upgrade on a Windows platform:
1. Insert the R70 CD into the production Gateway.
2. Accept the license agreement and click Next.
3. Under Upgrade Options, select Export.
If you opt to perform the Export procedure manually, make sure that you are
using the R70 Export tool. The upgrade_export tool is located on the product
CD under the Windows directory.
4. When prompted, download the most updated upgrade utilities from the Check
Point website.
If this is not possible, select Use the upgrade utilities from the CD.
5. Perform the Pre-Upgrade Verification.
6. Select the destination path for the configuration (.tgz) file.
Wait until the database files are exported.
7. Copy the exported.tgz file to the new Security Management server.
8. Insert the R70 CD into the target Security Management server.
9. Do one of the following:
228
• Perform a fresh install of the security gateway, and import the configuration
file. When prompted, select Installation using Imported Configuration. This
option prompts you for the location of the imported .tgz configuration file
and then automatically installs the new software and utilizes the imported
.tgz configuration file.
• Perform a fresh install of security gateway, and manually import the
configuration file using the upgrade_import tool on the R70 CD.
Warning - The configuration file (.tgz) file contains your security configuration. It is highly
recommended to delete it after completing the import process.
Advanced Upgrade on a Linux Platform

Advanced upgrade involves either:
• Performing a new installation, and manually importing a previously exported
configuration, or:
• Performing a new installation and upgrade through the wrapper. The wrapper
automatically performs the install, and the upgrade_import process.
To perform a new installation and manually import the configuration:
3. Enter n.
6. Enter n.
7. From the list of products, select Security Management Server and Security
gateway.
8. Enter n.
• Log server
10. Enter n.
12. After the installation is complete, the Check Point Configuration Program
opens. Use the Check Point Configuration program to:
230

14. Transfer the exported configuration to the new solaris installation, for example
through FTP.
15. Change directory to /opt/CPsuite-R70/fw1/bin/upgrade tools
Make sure that the upgrade tools in this directory are the R70 upgrade tools,
taken from the installation CD or downloaded from the Check Point website.
To perform a new installation and upgrade using the wrapper:
3. Enter n.
5. Select Installation Using Imported Configuration, for the installation option.
While the R65 upgrade utilities are on the R70 CD, it is recommended to
9. Enter n.
11. Enter n.
13. Enter n.
15. After the installation is complete, the Check Point Configuration Program
opens. Use the Check Point Configuration program to:
16. Reboot.
232
Advanced Upgrade on SecurePlatform

To perform an advanced upgrade on SecurePlatform:
3. Select SecurePlatform R70 Upgrade Package (CPsupgrade_R70.tgz).

7. Enter y to agree to the license agreement.
• Upgrade
User Center.
234
Advanced Upgrade on an IPSO Platform

Advanced upgrade involves performing a new installation and manually importing a
previously exported configuration.
To perform an advanced upgrade on an IPSO platform:
1. On the production machine, download the latest R70 upgrade tools, and
transfer them to $FWDIR/bin/upgrade_tools.
(You need the latest R70 upgrade tools to perform the export operation.)
2. On the production machine, run upgrade_export.
3. Transfer the resulting.tgz file to the second, off-line machine.
4. On the second, off line machine, download from the Check Point website the
R70 upgrade package: IPSO_Wrapper_<version_number>.tgz
5. From the command prompt, run:
newpkg –S –m LOCAL –n <path_to>/IPSO_Wrapper_<version_number>.tgz>
The package and products are installed but not activated.
6. Reboot.
8. Select the installation type: Stand Alone.
9. Select Security Management Server Security and Security gateway from the
selection list.
10. Specify the Security Management Server type as Primary or Secondary.
11. Add Licenses.
13. Configure the GUI clients and hosts that can access the Security Management
server management component.
17. When prompted, do not start the installed products.
18. From $FWDIR/bin/upgrade_tools, run upgrade_import.
19. Reboot.
236
Chapter 13
Upgrading ClusterXL
Deployments
In This Chapter
Tools for Gateway Upgrades page 237

Planning a Cluster Upgrade page 238
Minimal Effort Upgrade on a ClusterXL Cluster page 240
Zero Downtime Upgrade on a ClusterXL Cluster page 240
Full Connectivity Upgrade on a ClusterXL Cluster page 243
Tools for Gateway Upgrades

• SmartUpdate’s Upgrade All Packages Feature: This feature allows you to
upgrade all packages installed on a gateway. For IPSO and SecurePlatform, this
feature also allows you to upgrade your Operating System as a part of your
upgrade.
• SmartUpdate’s Add Package to Repository: SmartUpdate provides three tools for
adding packages to the Package Repository:
• From CD: Adds a package from the Check Point CD.
• From File: Adds a package that you have stored locally.
• From Download Center: Adds a package from the Check Point Download
Center.
237
Planning a Cluster Upgrade
• SmartUpdate’s Get Check Point Gateway Data: This tool updates SmartUpdate
with the current Check Point or OPSEC third party packages installed on a
specific gateway or throughout your entire enterprise.

When upgrading ClusterXL, the following options are available to you:
• Minimal Effort Upgrade: Select this option if you have a period of time
during which network downtime is allowed. The minimal effort method is
much simpler because the clusters are upgraded as gateways and therefore
can be upgraded as individual gateways.
• Zero Downtime: Select this option if network activity is required during the
upgrade process. The zero downtime method assures both inbound and
outbound network connectivity at all time during the upgrade. There is
always at least one active member that handles traffic.
• Full Connectivity Upgrade: Choose this option if your gateway needs to
remain active and your connections must be maintained. Full Connectivity
Upgrade with Zero Down Time assures both inbound and outbound network
connectivity at all time during the upgrade. There is always at least one
active member that handles traffic and open connections are maintained
during the upgrade.
Note - Full Connectivity Upgrade is supported between minor versions only. For further
information, refer to “Full Connectivity Upgrade on a ClusterXL Cluster” on page 243 and
the R70 Release Notes.
Permanent Kernel Global Variables

When upgrading each cluster member, verify that changes to permanent kernel
global variables are not lost (see: sk26202). For example, if “fwha_mac_magic” and
“fwha_mac_forward_magic” were set to values other than the default values, then
verify these values remain unchanged after the upgrade.
238
Ready State During Cluster Upgrade/Rollback

Operations
When cluster members of different versions are present on the same
synchronization network, cluster members of the previous version become active
while cluster members of the new (upgraded) version remain in a special state
called Ready. In this state, the cluster members with the new version do not
process any traffic destined for the cluster IP address. This behavior is the
expected behavior during the upgrade process.
To avoid such behavior during an upgrade or rollback, physically or using ifconfig,
disconnect the cluster interfaces and the synchronization network of that cluster
member before beginning.
Upgrading OPSEC Certified Third-Party Cluster

Products
• When upgrading Nokia clustering (VRRP and IP Cluster), follow either one of
the available procedures (that is, zero downtime or minimal effort).
• When upgrading other third-party clustering products, it is recommended that
you use the minimal effort procedure.
Zero downtime upgrade is not supported using the regular procedure. The third
party may supply an alternative upgrade procedure to achieve a zero downtime
upgrade.
• For a complete understanding of the upgrade procedure, refer to the third-party
vendor documentation before performing the upgrade process.
Chapter 13 Upgrading ClusterXL Deployments 239

Minimal Effort Upgrade on a ClusterXL Cluster
Minimal Effort Upgrade on a ClusterXL

Cluster
If you choose to perform a Minimal Effort Upgrade, meaning you can afford to have
a period of time during which network downtime is allowed, each cluster member is
treated as an individual gateway. In other words, each cluster member can be
upgraded in the same way as you would upgrade an individual gateway member. For
additional instructions, refer to “Upgrading a Distributed Deployment” on
page 159.
Zero Downtime Upgrade on a ClusterXL

Cluster
Supported Modes
Zero Downtime is supported on all modes of ClusterXL, including IPSO’s IP
clustering and VRRP. For additional third-party clustering solutions, consult your
third-party solution’s guide.
To perform a zero downtime upgrade, first upgrade all but one of the cluster
members.
To upgrade all but one of the cluster members:
1. Run cphaconf set_ccp broadcast on all cluster members. This changes the
cluster control protocol to broadcast instead of multicast and ensures that
during the upgrade the new upgraded members stay in the Ready state as long
as a previous version member is active.
In previous versions, a message prompts you to reboot the cluster members in
order to fully activate the change. This message should be ignored, no reboot is
required.
2. Suppose that cluster member A is the active member, and members B and C
are standby members. In Load Sharing mode, randomly choose one of the
cluster members to upgrade last. Ensure that the previously upgraded NGX
licenses are attached to members B and C.
3. Attach the previously upgraded licenses to all cluster members (A, B and C) as
follows:
240
Zero Downtime Upgrade on a ClusterXL Cluster
• On the SmartConsole GUI machine, open SmartUpdate, and connect to the

Security Management server. The updated licenses are displayed as
Assigned.
• Use the Attach assigned licenses option to Attach the Assigned licenses to
the cluster members.
4. Upgrade cluster members B and C in one of the following ways:
• Using SmartUpdate
• In Place
When the upgrade of B and C is complete, reboot both of them.
5. Continue with the process according to one of the following scenarios:
• If you are upgrading from NG with Application Intelligence (R54 and
above), skip to step 6. When machines B and C are up again, change the
cluster version in SmartDashboard to R70.
• If you are running SmartUpdate, skip to step 8. SmartUpdate compiles and
installs an updated policy on the new member, once it is rebooted.
6. Installing the policy:
If you are upgrading from NG with Application Intelligence (R54 and above),
install the policy on the cluster. The policy will be successfully installed on
cluster members B and C, and will fail on member A.
Be aware that policy installation on the old Check Point gateway may cut
connections for services that do not survive the policy installation.
This can be avoided by configuring the Check Point Gateway > Advanced >
Connection Persistence tab to either Keep all connections or Keep data
connections. For complete instructions, click the help button in the Connection
Persistence tab.
Note - Do not change any cluster parameters from the current policy at this time. For
example, if the cluster is running in New High Availability mode, do not change it to LS.
Changes can be made after the upgrade process is complete.
7. If you are upgrading from a previous version, perform the following steps:
a. From the Policy Installation window, clear the For Gateway Clusters, install on
all the members, if it fails do not install at all option located under the Install
on each selected Module independently option.

Zero Downtime Upgrade on a ClusterXL Cluster
b. Install the security policy on the cluster.

The policy will be successfully installed on cluster members B and C, and
will fail on member A.
8. Using the cphaprob stat command (executed on a cluster member), verify that
the status of cluster member A is Active or Active Attention. The remaining
cluster members will have a Ready status. The status Active Attention is given
if member A’s synchronization interface reports that its outbound status is
down, because it is no longer communicating with other cluster members.
9. Execute the cphastop command on cluster member A. Machines B and/or C
start to process traffic (depending on whether this is a Load Sharing or High
Availability configuration).
10. It is recommended that you do not install a new policy on the cluster until the
last member has been upgraded. If you must install a new policy, perform the
following steps:
a. Run cpstop on the old Check Point gateway.
b. Run fw ctl set int fwha_conf_immediate 1 on all new Check Point
gateways.
c. Install the policy.
Note - It is recommended that you minimize the time in which cluster members are
running different versions.
To upgrade the final cluster member:

1. Upgrade cluster member A by either:
• Using SmartUpdate
• In Place
2. Reboot cluster member A.
3. Run cphaconf set_ccp multicast followed by cphastart on all cluster
members. This returns the cluster control protocol to multicast (instead of
broadcast).
This step can be skipped if you prefer to remain working with the cluster
control protocol in the broadcast mode.
242
Full Connectivity Upgrade on a ClusterXL Cluster
Full Connectivity Upgrade on a ClusterXL

Cluster
ClusterXL clusters can be upgraded while at the same time maintaining full
connectivity between the cluster members.
Understanding a Full Connectivity Upgrade

The Full Connectivity Upgrade (FCU) method assures that synchronization is
possible from old to new cluster members without losing connectivity. A full
connectivity upgrade is only supported from R70 to a future minor version that
specifically supports FCU.
Connections that have been opened on the old cluster member will continue to
“live” on the new cluster member.
In discussing connectivity, cluster members are divided into two categories:
• New Members (NMs): Cluster members that have already been upgraded. NMs
are in the “non-active” state.
• Old Members (OMs): Cluster members that have not yet been upgraded. These
cluster members are in an “active state” and carry all the traffic.

Supported Modes
FCU is supported on all modes of ClusterXL, including IPSO’s IP clustering and
VRRP. Legacy High Availability is not supported in FCU. For other third-party
support, refer to the third-party documentation.
Full Connectivity Upgrade Prerequisites

Make sure that the new member (NM) and the old member (OM) contain the same
firewall policy and product installation. During the upgrade, do not change the
policy from the last policy installed on the Check Point Gateway prior to its
upgrade. Make sure that the upgraded version is at least NGX or higher.
Full Connectivity Upgrade Limitations

• This upgrade procedure is equivalent to a failover in a cluster where both
members are of the same version. Therefore, whatever would not normally
survive failover, will not survive a Full Connectivity Upgrade. This includes:
• Security servers and services that are marked as non-synced
• Local connections
• TCP connections that are TCP streamed
• The exact same products must be installed on the OM and on the NM.
For example, it is not possible to perform an FCU from a Check Point Gateway
that has Floodgate-1 installed to a newer Check Point Gateway that does not
have Floodgate-1 installed. Verify the installed products by running the
command fw ctl conn on both cluster members.
An example output on the NM:
Registered connections modules:
No. Name Newconn Packet End Reload Dup Type Dup Handler
0: Accounting 00000000 00000000 d08ff920 00000000 Special
d08fed58
1: Authentication d0976098 00000000 00000000 00000000 Special
d0975e7c
3: NAT 00000000 00000000 d0955370 00000000 Special d0955520
4: SeqVerifier d091e670 00000000 00000000 d091e114 Special
d091e708
6: Tcpstreaming d0913da8 00000000 d09732d8 00000000 None
7: VPN 00000000 00000000 d155a8d0 00000000 Special d1553e48
Verify that the list of Check Point Gateway names is the same for both cluster
members.
244
• All the Gateway configuration parameters should have the same values on the
NM and the OM. The same rule applies to any other local configurations you
may have set.
For example, having the attribute block_new_conns with different values on the
NM and on the OM might cause the FCU to fail since gateway behavior cannot
be changed during the upgrade.
• A cluster that performs static NAT using the gateway’s automatic proxy ARP
feature requires special considerations: cpstop the old Check Point Gateway
right after running cphastop. Running cphastop is part of the upgrade
procedure described in “Zero Downtime Upgrade on a ClusterXL Cluster” on
page 240. Failure to do this may cause some of the connections that rely on
proxy ARP to fail and may cause other connections that rely on proxy ARP not
to open until the upgrade process completes. Note, however, that running
cpstop on the old Check Point Gateway rules out the option to rollback to the
OM while maintaining all live connections that were originally created on the
OM.
Performing a Full Connectivity Upgrade

The procedure for updating a cluster with full connectivity varies according to the
number of members in the cluster.
To upgrade a cluster with two members:
Follow the steps outlined in “Zero Downtime Upgrade on a ClusterXL Cluster” on
page 240. Before you get to step 9 on page 242 (executing cphastop), run the
following command on the upgraded member:
fw fcu <other member ip on sync network>(e.g. fw fcu 172.16.0.1).
Then continue with step 9 on page 242.
To upgrade a cluster with three or more members:
Choose one of the following two methods:
1. Upgrade the two NMs, following the steps outlined in “Zero Downtime Upgrade
on a ClusterXL Cluster” on page 240. Before you get to step 9 on page 242
(executing cphastop), run the following command on all the upgraded
members: fw fcu <other member ip on sync network> then continue with step
9 on page 242 on the single OM.
or

2. First upgrade only one member, following the steps outlined in “Zero Downtime
Upgrade on a ClusterXL Cluster” on page 240. Before you get to step 9 on page
242 (executing cphastop), run the following command on all the upgraded
members: fw fcu <other member ip on sync network>. Then continue with
step 9 on page 242 on all remaining OMs.
For more than three members, divide the upgrade of your members so that the
active cluster members can handle the amount of traffic during the upgrade.
Note - cphastop can also be executed from the Cluster object in the SmartConsole. Once
cphastop is executed, do not run cpstart or cphastart again or reboot the machine.
Monitoring the Full Connectivity Upgrade

Displaying Upgrade Statistics (cphaprob fcustat)
cphaprob fcustat displays statistical information regarding the upgrade process.
Run this command on the new member. Typical output looks like this:
During FCU....................... yes
Number of connection modules..... 23
Connection module map (remote -->local)
0 --> 0 (Accounting)
1 --> 1 (Authentication)
2 --> 3 (NAT)
3 --> 4 (SeqVerifier)
4 --> 5 (SynDefender)
5 --> 6 (Tcpstreaming)
6 --> 7 (VPN)
Table id map (remote->local)..... (none or a specific list,
depending on configuration)
Table handlers ..................
78 --> 0xF98EFFD0 (sip_state)
8158 --> 0xF9872070 (connections)
Global handlers ................. none
The command output includes the following parameters:

During FCU: This should be “yes” only after running the fw fcu command and
before running cphastop on the final OM. In all other cases it should be “no”.
Number of connection modules: Safe to ignore.
Connection module map: The output reveals a translation map from the OM to the
NM. For additional information, refer to “Full Connectivity Upgrade Limitations” on
page 244.
246
Table id map: This shows the mapping between the gateway’s kernel table indices
on the OM and on the NM. Having a translation is not mandatory.
Table handlers: This should include a sip_state and connection table handlers. In
a security gateway configuration, a VPN handler should also be included.
Global handlers: Reserved for future use.
Display the Connections Table (fw tab -t connections -u [-s])

This command displays the “connection” table. If everything was synchronized
correctly the number of entries in this table and the content itself should be
approximately the same in the old and new cluster members. This is an
approximation because between the time that you run the command on the old and
new members new connections may have been created or perhaps old connections
were deleted.
Note - Not all connections are synchronized. For example, local connections and services
that are marked as non-synched.
Options
-t - table
-u - unlimited entries
-s - (optional) summary of the number of connections
For further information on the fw tab -t connections command, refer to the
“Command Line Interface” Book.
Making Adjustments After Checking the Connection Table

It is safe to run the fw fcu command more than once. Be sure to run both cpstop
and cpstart on the NM before re-running the fw fcu command. The reason for
running cpstop and cpstart is that the table handlers that deal with the upgrade
are only created during policy installation (cpstart installs policy).

248
Chapter 14
Upgrading Provider-1
In This Chapter

Provider-1 Upgrade Tools page 251
Provider-1 Upgrade Practices page 264
Upgrading a Multi-MDS System page 273
Restarting CMAs page 276
Restoring Your Original Environment page 277
Renaming Customers page 278
Changing the MDS IP Address and External Interface page 282
IPS in Provider-1 page 283
249
Introduction
Introduction
This chapter describes methods and utilities for upgrading Provider-1 to the current
version.
In This Section
Supported Versions and Platforms page 250

Before You Begin page 250
Supported Versions and Platforms

The direct upgrade of the MDS to the current version is supported from the
following versions:
Release Version
NGX R65
R62
R61
R60A
R60
The latest information regarding supported platforms is always available in the

Check Point Release Notes at http://support.checkpoint.com.
Before You Begin

Before performing a Provider-1 upgrade, it is recommended that you read the
current version Release Notes at http://support.checkpoint.com.
If you are upgrading a multi-MDS environment refer, to “Upgrading a Multi-MDS
System” on page 273”.
250
Provider-1 Upgrade Tools
Provider-1 Upgrade Tools

This section describes the different upgrade and migrate utilities, and explains
when and how each of them is used.
In This Section
Pre-Upgrade Verifiers and Fixing Utilities page 251

Installation Script page 252
export_database page 253
migrate_assist page 256
cma_migrate page 257
migrate_global_policies page 262
Backup and Restore page 262
Pre-Upgrade Verifiers and Fixing Utilities

Before performing the upgrade the Provider-1 upgrade script, mds_setup, runs a list
of pre-upgrade utilities. The utilities search for well known upgrade problems that
might be present in your existing installation. The output of the utilities is also
saved to a log file. Three types of messages are generated by the pre-upgrade
utilities:
• Action items before the upgrade: These include errors and warnings. Errors
have to be repaired before the upgrade. Warnings are left for the user to check
and conclude whether they should be fixed or not. In some cases, it is
suggested that fixing utilities should be run during the pre-upgrade check, but
in most cases the fixes are done manually from SmartDashboard. An example of
an error to be fixed before the upgrade is when an invalid policy name is found
in your existing installation. In this case, you must rename the policy.
• Action items after the upgrade: These include errors and warnings, which are to
be handled after the upgrade.
• Information messages: This section includes items to be noted. For example,
when a specific object type that is no longer supported is found in your
database and is converted during the upgrade process, a message indicates that
this change is going to occur.
Chapter 14 Upgrading Provider-1 251

Installation Script
Installation Script
Use the mds_setup installation script for MDS.
Note - When installing MDS on SecurePlatform, the installation is performed using the
SecurePlatform installer on the CD. Do not run the mds_setup script directly. For
additional information, refer to “Provider-1 Upgrade Practices” on page 264.
To run mds_setup:
1. Mount the Provider-1 CD from the relevant subdirectory.
2. Change the directory to the mounted directory.
3. Browse to either the Solaris or Linux directory, depending on the operating
system of your MDS machine.
4. Run the installation script: ./mds_setup.
When mds_setup is executed, it first checks for an existing installation of MDS:
• If no such installation exists, mds_setup asks you to confirm a fresh
installation of MDS.
• If a previous version of MDS is detected, you are prompted to select one of
the following options (Pre-Upgrade Verification Only, Upgrade or Backup)
listed below.
5. Exit all shell sessions. Open a new shell in order for the new environment to be
set.
252
export_database
Pre-Upgrade Verification Only

Pre-Upgrade Verification Only enables you to run pre-upgrade verification without
upgrading your existing installation. No fixing utilities are executed. Use this option
at least once before you upgrade. It provides you with a full report on upgrade
issues, some of which should be handled before the upgrade. In a multi-MDS
environment, the pre-upgrade verification must be run on all MDSes (and MLMs)
before upgrading the first MDS.
Upgrade
When the upgrade option is used, mds_setup runs the Pre-Upgrade Verifier and if
no errors are found, the upgrade process proceeds. In case of errors, mds_setup
stops the installation until all the errors are fixed. In some cases, mds_setup
suggests automatically fixing the problem using a fixing utility. Fixing utilities that
affect the existing installation can also be run from the command line. You can
choose to stop the installation and run the fixing utility from the command line.
There are two important things to remember after changing your existing
installation:
• Verify your changes in the existing installation before you upgrade.
• Synchronize global policies. If you make changes in global policies, reassign
these global policies to customers. If you have a multi-MDS environment:
• Synchronize databases between MDSs in High Availability.
• Synchronize databases between CMAs in High Availability.
• Install the database on CLMs.
Backup
Prior to performing an upgrade, back up your MDS. The backup option from
mds_setup runs the mds_backup process (refer to mds_backup). Backup is also
used for replication of your MDS to another machine. Manual operations are
necessary if you are switching IP addresses or network interface names. For
additional information, refer to “Changing the MDS IP Address and External
Interface” on page 282.
export_database
The export_database utility allows you to export an entire database into one .tgz
file that can be imported into a different MDS machine. The following files can be
exported:

export_database
• An entire CMA database

• An entire Security Management database
• An MDS Global Policy database
This tool can be used instead of migrate_assist, which exports the database
remotely, file by file, whereas export_database creates one comprehensive file on
the source machine.
The export_database tool is supported on LInux and Solaris 2. If you are running
other platforms, use migrate_assist to export all files, including the global policy.
Before using the export_database utility, you must:
1. Copy the export tool .tgz file for your operating system to the source CMA or
Security Management server. The export tool files can be found on your
installation CD or on the Check Point support website,
2. Unntar the export tool .tgz file to some path in the source machine.
A directory called export_tools is extracted.
3. Run the export_database commands from the export_tools directory.
After exporting the databases using export_database, transfer the .tgz files to the
target machine. Import the CMA or Security Management files using cma_migrate
and import the Global Policy file using the migrate_global_policies command.
Usage
• Exporting a CMA:
./export_database.sh <path for the output file> –c <name of CMA>
• Exporting a Security Management server:
./export_database.sh <path for the output file>
• Exporting an MDS global database:
./export_database.sh <fully qualified path for the output file>
–g
254
merge_plugin_tables
Other flags:
Table 14-1 export_database flags
Flag Meaning
-h Display usage
-b Batch mode
-l Include the log database
-m Include the SmartMap database
Example
• To export the database of a CMA, CMA1, including its log database to a file path,
/var/tmp, use the following command:
./export_database.sh /var/tmp –c CMA1 -l
• To export a Security Management database, including its Smartmap database,
to a file path, /var/tmp, use the following command:
./export_database.sh /var/tmp -m
• To export an MDS’s Global Policy to a file path, /var/for_export, use the
following command:
./export_database.sh /var/for_export –g
merge_plugin_tables
The merge_plugin_tables utility is included in the export_database utility. It
searches for all CMA or Security Management Plug-ins and merges the Plug-in
tables with the CMA or Security Management tables.
In Linux and Solaris 2, the merge_plugin_tables tool runs automatically when you
run the export_database tool and its output becomes part of the CMA database
.tgz file.
If you have a Security Management server running on FreeBSD, IPSO 6, or WIN32
you can and should use merge_plugin_tables to consolidate your Plug-in
information before exporting files using migrate_assist.

migrate_assist
Before using the merge_plugin_tables utility, you must:

1. Copy the export tool .tgz file for your operating system to the source CMA or
Security Management server. The export tool files can be found on your
installation CD or on the Check Point support website,
2. Unntar the export tool .tgz file to some path in the source machine.
A directory called export_tools is extracted.
3. Run the merge_plugin_tables command from the export_tools directory.
Usage
merge_plugin_tables <-p conf_dir> [-s] [-h]
where <-p conf_dir> is the path of $FWDIR directory of the CMA/Security
Management, -s performs the utility in silent mode (default is interactive mode),
and -h displays usage.
Example
To merge the Plug-in tables of a CMA, CMA1, run the following commands:
mdsenv cma1
merge_plugin_tables -p "$FWDIR"
migrate_assist
This utility is a helper utility for cma_migrate. It can be used to pull the original
management directories to the current disk storage using FTP.
When you finish running migrate_assist, it is possible to run cma_migrate (refer to
“cma_migrate” on page 257), the input directory of which will be the output
directory of migrate_assist.
You can use export_database instead of migrate_assist to export a CMA,
Security Management, or Global Policy database if your source machine is running
on LInux 30 or Solaris 2. See “export_database” on page 253 for more
information.
Note - Before running migrate_assist, stop source management processes and merge
Plug-in tables.
256
cma_migrate
Usage
migrate_assist <source machine name/ip> <source FWDIR folder> <user name>
<password> <target folder> <source CPDIR folder>
Example
To import a Security Management server with the IP address 192.168.0.5 of
version NGX R60, use the following command:
migrate_assist 192.168.0.5 /opt/CPsuite-R60/fw1 FTP-user FTPpass /EMC1
/opt/CPshrd-R60
Where /EMC1 is the name of the directory created on the MDS server machine,
migrate_assist accesses the source machine and imports the source FWDIR and
CPDIR folders to the specified target folder according to the structure described
above. The user name and password are needed to gain access to the remote
machine via FTP.
Note - When the source management is a Security Management version R70 or higher,
running on Windows, the following procedure should be done before running
migrate_assist:
1. Run the command: cpprod_util CPPROD_GetInstalledPlugIns > plugins.txt.
2. Copy the resulting file (plugins.txt) to %FWDIR%\conf directory.
3. If you have Plug-ins installed, run merge_plugin_tables before running
migrate_assist.
cma_migrate
This utility is used to import an existing Security Management server or CMA into a
Provider-1 MDS so that it will become one of its CMAs. If the imported Security
Management or CMA is of a version earlier than the MDS to which it is being
imported, then the Upgrade process is performed as part of the import. The
available versions are listed in “Supported Versions and Platforms” on page 250.
It is recommended to run cma_migrate to import CMA or Security Management
database files created using the export_database tool.
Bear in mind that the source and target platforms may be different. The platform of
the source management to be imported can be Solaris, Linux, Windows,
SecurePlatform or IPSO.

cma_migrate
Before running cma_migrate, create a new customer and a new CMA. Do not start
the CMA, or the cma_migrate will fail.
If you are migrating a CMA to a new CMA with a different IP address, follow the
instructions in “Migration to a New Machine with a Different IP” in the Check Point
Internet Security Products Upgrade Guide.
The source database’s subdirectories to be migrated are conf, database, registry,
and log. The $CPDIR/conf directory should be named conf.cpdir and placed
inside <old source database directory path> to avoid overwriting the
$FWDIR/conf directory.
Note - The registry directory is required only if you are upgrading from version R70 or
higher.
When the source management is a Security Management version R70 or higher,

running on Windows, the following procedure should be done before creating
<source management directory path>:
1. Run: cpprod_util CPPROD_GetInstalledPlugIns > plugins.txt.
2. Copy the resulting file (plugins.txt) to %FWDIR%\conf directory.
Usage
cma_migrate <source management directory path> <target CMA FWDIR
directory>
258
cma_migrate
Example
cma_migrate /tmp/exported_smc.22Jul2007-224020.tgz
/opt/CPmds-FLO/customers/cma2/CPsuite-FLO/fw1
The first argument (<source management directory path>)specifies a path on the

local MDS machine, where the data of the source management data resides. Use
migrate_assist to build this source directory or build it manually. Set the structure
under the source management directory as described in Table 14-2.
Table 14-2 Source Management Structure

directory contents
conf This directory contains the information that
resides in $FWDIR/conf of the source
management.
database This directory contains the information that
resides in $FWDIR/database of the source
management.
log This directory contains the information that
resides in$FWDIR/log of the source management
or is empty if you do not wish to maintain the
logs.
conf.cpdir This directory contains the information that
resides in $CPDIR/conf of the source
management.
registry This directory is required only if you are
upgrading from version R70 or higher. It
contains the information that resides in
$CPDIR/registry of the source management.
The second argument (<target CMA FWDIR directory>) is the FWDIR of the newly
created CMA.
Note - To run the cma_migrate utility from the MDG, right-click a CMA and select Import
Customer Management Add-on from the menu. You can also run mdscmd migratecma to
import files to an MDS.
Additional Information
When running cma_migrate, pre-upgrade verification takes place. If no errors are
found, then the migration continues. If errors are found, changes must be
performed on the original Security Management server.

cma_migrate
Certificate Authority Information

The original Certificate Authority and putkey information is maintained when using
cma_migrate. This means that the Security Management server that was migrated
using cma_migrate should not re-generate certificates to gateways and SIC should
continue to work with gateways. However, if the IP of the CMA is different than that
of the original management, then putkey should be repeated between the CMA and
entities that connect to it using putkey information. Use putkey -n to re-establish
trust. For additional information on putkey, refer to the Check Point Command Line
Interface documentation.
If your intent is to split a CMA into two or more CMAs, reinitialize their Internal
Certificate Authority so that only one of the new CMAs employs the original ICA:
To reinitialize a CMA’s Internal Certificate Authority:
1. Run: mdsstop_customer <CMA NAME>
2. Run: mdsenv <CMA NAME>
3. Remove the current Internal Certificate Authority by executing the fwm
sic_reset command. This may require some preparation that is described in
detail from the command prompt and also in the Secure Knowledge solution
sk17197.
4. Create a new Internal Certificate Authority by executing:
mdsconfig -ca <CMA NAME> <CMA IP>
5. Run the command: mdsstart_customer <CMA NAME>
For further information, refer to SK17197 at the following link:
http://supportcontent.checkpoint.com/solutions?id=sk17197
260
cma_migrate
Resolving Issues with IKE Certificates

When migrating a management database that contains a gateway object that takes
part in a VPN tunnel with an externally managed third-party gateway, an issue with
the IKE certificates arises. After migration, when such a gateway presents its IKE
certificate to its peer, the peer gateway uses the FQDN of the certificate to retrieve
the host name and IP address of the Certificate Authority that issued the
certificate. If the IKE certificate was issued by a Check Point Internal CA, the
FQDN will contain the host name of the original management. In this case, the
peer gateway will try to contact the original management for the CRL information,
and failing to do so will not accept the certificate.
There are two ways to resolve this issue:
• Update the DNS server on the peer side to resolve the host name of the original
management to the IP address of the relevant CMA.
• Revoke the IKE certificate for the gateway(s) and create a new one. The new
certificate will contain the FQDN of the CMA.

migrate_global_policies
migrate_global_policies
The migrate_global_policies command transfers (and upgrades, if necessary) a
global policies database from one MDS to another.
If the global policies database on the target MDS has polices that are assigned to
customers, migrate_global_policies aborts. This is done to ensure that the Global
Policy used at the Customer's site is not deleted.
Note - When executing the migrate_global_policies utility, the MDS will be stopped.
The CMAs can remain up and running.
Usage
migrate_global_policies <path global policies conf database>
<path global policies conf database>: Specifies the fully qualified path to
the directory where the global policies files, originally exported from the source
MDS ($MDSDIR/conf), are located.
Note - Migrate_global_policies fails if there is a global policy assigned to a

Customer, Do not to create and assign any Global Policy to a Customer before you run
migrate_global_policies.
Backup and Restore

The purpose of the backup/restore utility is to back up an MDS as a whole,
including all the CMAs that it maintains, and to restore it when necessary. The
restoration procedure brings the MDS to the state it was when the backup
procedure was executed. The backup saves both user data and binaries. Backup
and restore cannot be used to move the MDS installation between platforms.
Restoration can be performed on the original machine or, if your intention is to
upgrade by replicating your MDS for testing purposes, to another machine. When
performing a restoration to another machine, if the machine’s IP address or
interface has changed, refer to “Changing the MDS IP Address and External
Interface” on page 282” for instructions on how to adjust the restored MDS to the
new machine.
During backup, it is okay to view data but do not write using MDGs, GUIs or other
clients. If the Provider-1 system consists of several MDSes, the backup procedure
takes place manually on all the MDSes concurrently. Likewise, when the restoration
procedure takes place, it should be performed on all MDSes concurrently.
262
Backup and Restore
mds_backup
This utility stores binaries and data from your MDS installation. Running
mds_backup requires superuser privileges. This utility runs the gtar command on
the root directories of data and binaries. Any extra information located under these
directories is backed up, except from files that are specified in mds_exclude.dat
($MDSDIR/conf) file. The collected information is wrapped in a single zipped tar file.
The name of the created backup file comprises the date and time of the backup,
followed by the extension .mdsbk.tgz. For example: 13Sep2002-141437.mdsbk.tgz.
The file is placed in the current working directory, thus it is important not to run
mds_backup from one of the directories that is to be backed up.
Usage
mds_backup
mds_restore
Restores an MDS that was previously stored with mds_backup. For correct operation,
mds_restore requires a fresh installation of an MDS from the same version of the
MDS to be restored.
Usage
mds_restore <backup file>
$MDSDIR/bin/set_mds_info -b -y

Provider-1 Upgrade Practices
Provider-1 Upgrade Practices

In This Section
In-Place Upgrade page 264

Replicate and Upgrade page 266
Gradual Upgrade to Another Machine page 267
Migrating from Security Management to a CMA page 269
In-Place Upgrade
The in-place upgrade process takes place on the existing MDS machine. The MDS
with all CMAs are upgraded during a single upgrade process.
Note - When upgrading Provider-1, all SmartUpdate packages on the MDS (excluding
SofaWare firmware packages) are deleted from the SmartUpdate Repository.
1. Run the Pre-upgrade verification only option from mds_setup. In a multi-MDS

environment, perform this step on all MDSes (refer to “Upgrading in a
Multi-MDS Environment” on page 272 for details).
2. Make the changes required by the pre-upgrade verification, and if you have
High Availability, perform the required synchronizations.
3. Test your changes as follows:
a. Assign the global policy
b. Install policies to CMAs
c. Verify logging using SmartView Tracker
d. View status using the MDG or SmartView Monitor
4. Back up your system either by selecting the backup options in mds_setup or by
running mds_backup.
5. Perform the in-place upgrade.
• For Solaris or Linux, use mds_setup (See “Installation Script” on page 252).
• For SecurePlatform, run patch add cd (See “Upgrading to R70 on
SecurePlatform” on page 265).
6. After the upgrade completes, retest using the sub-steps in step 3 above.
264
In-Place Upgrade
Upgrading to R70 on SecurePlatform

This section describes how to upgrade SecurePlatform R54 and later versions using
a CD ROM drive.
To perform an upgrade on SecurePlatform:
1. Log in to SecurePlatform (expert mode is not necessary).
2. Apply the SecurePlatform upgrade package:
# patch add cd.
3. You are prompted to verify the MD5 checksum.
4. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No
If you select Yes, a Safe Upgrade is performed.
Safe Upgrade automatically takes a snapshot of the entire system so that the
entire system (operating system and installed products) can be restored if
something goes wrong during the Upgrade process (for example, hardware
incompatibility). If the Upgrade process detects a malfunction, it automatically
reverts to the Safe Upgrade image.
When the Upgrade process is complete, upon reboot you are given the option to
start the SecurePlatform operating system using the upgraded version image or
using the image prior to the Upgrade process.

Replicate and Upgrade
Replicate and Upgrade

Choose this type of upgrade if you intend to change hardware as part of the
upgrade process or if you want to test the upgrade process first. The existing MDS
installation is copied to another machine (referred to as the target machine) by
using the mds_backup and mds_restore commands.
To perform the Replicate and Upgrade process:
1. Back up your existing MDS. This can be done by running mds_backup or by
running mds_setup and selecting the Backup option.
2. Install a fresh MDS on the target machine.
To restore your existing MDS, first install a fresh MDS on the target machine
that is the exact same version as your existing MDS.
Note - The target machine should be on an isolated network segment so that gateways
connected to the original MDS are not affected until you switch to the target machine.
3. Restore the MDS on the target machine. Copy the file created by the backup
process to the target machine and run mds_restore, or run mds_setup and
select the Restore option.
4. If your target machine and the source machine have different IP addresses,
follow the steps listed in “IP Address Change” on page 282 to adjust the
restored MDS to the new IP address. If your target machine and the source
machine have different interface names (e.g. hme0 and hme1), follow the steps
listed in “Interface Change” on page 282 to adjust the restored MDS to the
new interface name.
5. Test to confirm that the replication has been successful:
a) Start the MDS.
b) Verify that all CMAs are running and that you can connect to the MDS with
MDG and Global SmartDashboard.
c) Connect to CMAs using SmartDashboard.
6. Upgrade your MDS. Stop the MDS on the target machine and employ an
In-Place Upgrade (for additional information, refer to “In-Place Upgrade” on
page 264).
7. Copy the /opt/CPmds-R70/conf/mdsdb/cp-admins.C file to the same location
ion the destination MDS.
8. Start the MDS.
266
Gradual Upgrade to Another Machine
9.

In a gradual upgrade, CMAs are transferred to another current version MDS one
CMA at a time.
In a gradual upgrade, the following information is not retained:
• Provider-1 Administrators
To do: Redefine and reassign to customers after the upgrade.
• Provider-1 SmartConsole Clients
To do: Redefine and reassign to customers after the upgrade.
• Policy assignment to customers
To do: Assign policies to customers after the upgrade.
• Global Communities statuses.
To do: execute the command:
mdsenv; fwm mds rebuild_global_communities_status all
To perform a gradual upgrade:
1. Install MDS of the target version onto the target machine.
2. Copy the following file to the target MDS:
$CPDIR/conf/lic_cache.C
All CMA and MDS licenses reside in cp.license, and all licenses appear in the
cache.
3. On the target MDS, create a customer and CMA but do not start the CMA.
4. Use the export_database utility to export the CMA database into a .tgz file and
transfer the file from the source machine to the destination machine. For
additional information, refer to “export_database” on page 253. This process
transfers the licenses for both the CMA and the CMA repository.
5. Use cma_migrate to import the CMA. For additional information, refer to
“cma_migrate” on page 257.
6. Start the CMA and run:
mdsenv
mdsstart

7. Use migrate_global_policies to import the global policies.
Gradual Upgrade with Global VPN Considerations

A gradual upgrade process in an MDS configuration that uses the Global VPN
Communities (GVC) is not fundamentally different from the gradual upgrade
process described above, with the following exceptions:
1. Global VPN community setup involves the Global database and the CMAs that
are managing gateways participating in the global communities. When gradually
upgrading a GVC environment, split the upgrade into two parts:
• one for all the CMAs that do not participate in the GVC
• one for CMAs that do participate with the GVC
2. If some of your CMAs have already been migrated and some have not and you
would like to use the Global Policy, make sure that it does not contain gateways
of non-existing customers. To test for non-existing customers, assign this Global
Policy to a customer. If the assignment operation fails and the error message
lists problematic gateways, you have at least one non-existing customer. If this
occurs:
a. Run the where used query from the Global SmartDashboard > Manage >
Network Objects > Actions to identify where the problematic gateway(s) are
used in the Global Policy. Review the result set, and edit or delete list items
as necessary. Make sure that no problematic gateways are in use.
b. The gateways must be disabled from global use:
i. From the MDG’s General View, right-click a gateway and select Disable
Global Use.
ii. If the globally used gateway refers to a gateway of a customer that was
not migrated, you can remove the gateway from the global database by
issuing a command line command. First, make sure that the Global
SmartDashboard is not running, and then execute the command:
mdsenv; remove_globally_used_gw <Global name of the gateway>
3. When issuing the command: migrate_global_policies where the existing
Global Policy contains Global Communities, the resulting Global Policy
contains:
• the globally used gateways from the existing database
• the globally used gateways from the migrated database
As a result of the migration, the Global Communities are overridden by the
migrated database.
268
Migrating from Security Management to a CMA
4. The gradual upgrade does not restore the Global Communities statuses,
therefore, if either the existing or the migrated Global Policy contains Global
Communities, reset the statuses from the command line (with MDS live):
mdsenv; fwm mds rebuild_global_communities_status all

This section describes how to migrate the management part of a standalone
gateway to a CMA, and then manage the standalone gateway (as a gateway only)
from the CMA.
Note - If you want the option to later undo the separation process, back up the standalone
gateway before migrating.
Before migrating the management part of the standalone gateway to the target
CMA, some adjustments are required:
1. Make sure that:
• FTP access is allowed from the MDS machine (on which the target CMA is
located) and the standalone machine. (This is only necessary if you plan to
use migrate_assist.)
• The target CMA is able to communicate with and install policy on all
gateways.
2. Add an object representing the CMA (name and IP address) and define it as a
Secondary Security Management server.
3. Install policy on all managed gateways.
4. Delete all objects or access rules created in steps 1 and 2.
5. If the standalone gateway already has Check Point Security Gateway installed:
• Clear the Firewall option in the Check Point Products section of the gateway
object. You may have to first remove it from the Install On column of your
rulebase (and then add it again).
• If the standalone gateway participates in a VPN community, in the IPSec
VPN tab, remove it from the community and erase its certificate. Note these
changes in order to undo them after the migration.
6. Save and close SmartDashboard. Do not install policy.

7. To migrate the management part to the CMA, run:

migrate_assist <Standalone_GW_NAME><Standalone_GW_FWDIR><username>
<password><target_dir><Standalone_GW_CPDIR> command.
8. Create a new CMA on the MDS, but do not start it.
9. Migrate the exported database into the CMA. Use cma_migrate or the import
operation from the MDG, specifying as an argument the database location you
used as <target_dir> in the migrate_assist command.
10. To configure the CMA after migration, start the CMA and launch
SmartDashboard.
11. In SmartDashboard, under Network Objects, locate:
• An object with the Name and IP address of the CMA primary management
object (migrated). Previous references to the standalone management object
now refer to this object.
• An object for each gateway managed previously by Security Management.
12. Edit the Primary Management Object and remove all interfaces (Network Object
> Topology > Remove).
13. Create an object representing the gateway on the standalone machine (From
New > Check Point > Gateway), and:
• Assign a Name and IP address for the gateway.
• Select the appropriate Check Point version.
• Select the appropriate Check Point Products you have installed.
• If the object previously belonged to a VPN Community, add it back.
• Do not initialize communication.
14. Run Where Used on the primary management object and, in each location,
consider changing to the new gateway object.
15. Install the policy on all gateways, except for the standalone gateway. You may
see warning messages about this gateway because it is not yet configured.
These messages can be safely ignored.
16. Uninstall the standalone gateway.
17. Install a gateway only on the previous standalone machine.
18. From the CMA SmartDashboard, edit the gateway object created in step 12 and
establish trust with that gateway.
19. On the same object, define the gateway's topology.
270
20. Install the Policy on the gateway.

Upgrading in a Multi-MDS Environment
Upgrading in a Multi-MDS Environment

In This Section
Pre-Upgrade Verification and Tools page 272

Upgrading a Multi-MDS System page 273
Multi-MDS environments may contain components of High Availability in MDS or at

the CMA level. It may also contain different types of MDSes: managers, containers,
or combinations of the two. In general, High Availability helps to reduce down-time
during an upgrade.
This section provides guidelines for performing an upgrade in a multi-MDS
environment. Specifically, it explains the order of upgrade and synchronization
issues.
Pre-Upgrade Verification and Tools

Run pre-upgrade verification on all MDSes before applying the upgrade to a
specific MDS by choosing the Pre-Upgrade Verification Only option from mds_setup
(for additional information, refer to “Pre-Upgrade Verifiers and Fixing Utilities” on
page 251). Start upgrading the first MDS, only after you have fixed all the errors
and reviewed all the warnings on all your MDSes.
272
Upgrading a Multi-MDS System

In This Section
MDS High Availability page 273

Before the Upgrade page 274
After the Upgrade page 274
CMA High Availability page 275
MDS High Availability

Communication between Multi-Domain Servers can only take place when the
Multi-Domain Servers are of the same version. In a system with a single Manager
MDS, there is a period of time when the Container MDSes are not accessible. If
more than one Manager MDS exists, follow these steps:
1. Upgrade one Manager MDS. All other containers are managed from the other
Manager MDS.
2. Upgrade all container MDSes. Each Container MDS that you upgrade is
managed from the already upgraded Manager MDS.
3. Upgrade your second Manager MDS.
Following these steps promises continuous manageability of your container MDS.
While containers do not accept Security Management connections, the CMAs on
the container MDSes do. This means that even if you cannot perform global
operations on the container MDS, you can still connect to the CMAs that reside on
it.
Note - MLMs in a multi-MDS system need to be upgraded to the same version as the
Manager and Container MDSs.

Before the Upgrade

1. Perform pre-upgrade verification for all MDSes.
2. If the pre-upgrade verifier requires a modification to the global database, then,
after modifying the global database, all other MDSes should be synchronized.
3. If this modification affects a global policy that is assigned to customers, then
the global policy should be reassigned to the relevant customers, in order to
repair the error in the CMA databases.
4. If a modification is required at the CMA level, then if it exists after modifying
the CMA database, synchronize the mirror CMA. If the customer also has a CLM
(on MLM), install the database on the CLM to verify that the modification is
applied to the CLM as well.
Note - When synchronizing, make sure to have only one active MDS and one active CMA for
each customer. Modify the active MDS/CMA and synchronize to Standby.
After the Upgrade

After upgrading an MDS or an MLM in a multi MDS environment, the CMA/CLM
object versions (located in the CMA database) are not updated.
In this case, when using SmartDashboard to connect to a CMA after the upgrade,
additional CMA/CLMs are displayed with the previous version.
If the CMA identifies the CLM version as earlier then the current CLM version, the
following scenario takes place:
A complete database installation from the CMA on the CLM does not take place
and as result, IP addresses and services are not completely resolved by the
CLM.
Before updating the CLM/CMA objects to the most recent version, use the mdsstat
command to verify that all MDS processes are running and that all active CMAs are
up and running with valid licenses. Also, confirm that SmartDashboard is not
connected. Then, run the mdsenv command on each MDS after upgrading all
MLMs/MDSs to set the shell for MDS level commands.
To update all CLM/CMA objects, run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
To update CLM/CMA objects that are located on a specific MLM/MDS, (in case
other MDSs were not yet upgraded) run:
274
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <MLM/MDS name>

After running this utility, remember to synchronize all standby CMAs/Security
Management backups.
CMA High Availability

CMA High Availability can help minimize the period of management downtime
during upgrade. While upgrading one of the MDS containers in a High Availability
configuration, others MDSs can continue to manage gateways. The CMAs hosted on
these MDSs need to be synchronized and defined as Active in order to do so.
After successfully upgrading one of the MDS containers, its CMAs can become
Active management servers for the duration of time required to upgrade the others.
The synchronization between the two CMAs in a High Availability configuration
takes place only after MDS containers hosting both of them are upgraded. If policy
changes are made on both CMAs during the upgrade process, after the upgrade one
of the configurations overrides another and the collisions need to be resolved
manually.
After the upgrade is completed on all the MDS containers, the High Availability
status of the CMAs appears as Collision. To resolve this, every CMA High Availability
pair needs to be synchronized. During the synchronization process, changes from
one of the CMAs override the changes made to another.
To migrate a CMA/Security Management High Availability deployment, use the
migrate utility. (See “cma_migrate” on page 257).
Note - Before migrating, all the objects representing the secondary management should be
deleted from the primary Security Management server.
The database to import is the database belonging to the primary CMA/Security

Management Server. Before importing, verify that the database has been
synchronized.
Also perform these steps if you want to migrate your current High Availability
environment to a CMA High Availability on a different MDS. Then, continue with a
High Availability deployment (for more information, see the High Availability chapter
in the Check Point Provider-1/SiteManager-1 Administration Guide).

Restarting CMAs
Restarting CMAs
After completing the upgrade process, CMAs should be started sequentially using
the command mdsstart -s.
276
Restoring Your Original Environment

In This Section
Before the Upgrade page 277

Restoring Your Original Environment page 277
Before the Upgrade

Pre-upgrade utilities are an integral part of the upgrade process. In some cases,
you are required to change your database before the actual upgrade can take place
or the Pre-Upgrade Verifier suggests you execute utilities that perform the required
changes automatically. Even if you decide to restore your original environment,
keep the changes you made as a result of the pre-upgrade verification.
Prepare a backup of your current configuration using the mds_backup utility from
the currently installed version. Prepare a backup as the first step of the upgrade
process and prepare a second backup right after the Pre-Upgrade Verifier
successfully completes with no further suggestions.

To restore your original environment:
1. Removing the new installation:
a. If the installation finished successfully, execute the mds_remove utility from
the new version. This restores your original environment just before the
upgrade, after the pre-upgrade verification stage.
b. If the installation stopped or failed before its completion, manually remove
the new software packages. It may be easier for you to remove all Check
Point installed packages and a perform fresh installation of the original
version.
2. Perform mds_restore using the backup file.

Renaming Customers
Renaming Customers
In This Section
Identifying Non-Compliant Customer Names page 278

High Availability Environment page 278
Automatic Division of Non-Compliant Names page 278
Resolving Non-Compliance page 279
Advanced Usage page 280
Earlier Provider-1 versions allowed customer names or CMA names in to contain

illegal characters, such as spaces and certain keyword prefixes. The current version
does not permit this. It is necessary to rename customer and CMA names to comply
the current version naming restrictions.
Identifying Non-Compliant Customer Names

The mds_setup utility performs several tests on the existing installation before an
upgrade takes place. One of the tests is a test for customer names compliance with
the current naming restrictions. If all customer names comply with the restrictions,
no message is displayed. When a non-compliant customer name is detected, it is
displayed on the screen, detailing the reason why the name was rejected.
High Availability Environment

In an MDS High Availability environment, non-compliance is detected on the first
MDS you upgrade. The mds_setup utility identifies non-compliant names as more
than a single MDS. Since this is non-compliant, an error message is issued.
Automatic Division of Non-Compliant Names

If the number of customers with non-compliant names is large, the translation task
may automatically divide into several sessions. By default, all the intermediate work
is saved.
278
Resolving Non-Compliance
Resolving Non-Compliance
During the upgrade procedure, after selecting Option 2 - Upgrade to R70 on the
mds_setup menu, the resolution of compliant names is performed. The translation
prompt is only displayed if a non-compliant name is detected.
Note - Nothing is changed in the existing installation when translating customer names.
Any changes are applied only to the upgraded installation.
Translation prompt - Enter a name to replace the non-compliant name, or enter the
'-' sign to get a menu of additional options. The new name is checked for naming
restrictions compliance and is not accepted until you enter a compliant name.
Additional Options Menu Edit another name - The customer names are presented in
alphabetical order. Choose this option to edit a customer name that was already
translated, or any other customer name.
Skip this name - Choose this option if you are not sure what to do with this name
and want to come back to it later. The upgrade cannot take place until all
non-compliant customer names are translated.
Quit session and save recent translations - Choose this option if you want to save
all the work that was done in this session and resume later.
Quit session and throw away recent translations - Choose this option if you want to
abort the session and undo all the translations that you entered during this session.
Return to translation prompt - Choose this option if you want to return to the
customer name you were prompted with when you entered '-'.
Note - The pre-upgrade tool allows only non-compliant customer names to be translated.
If the session is exited before all the translations are done, the mds_setup utility
exits with an error message stating that the MDS verification failed. To return to the
tool, simply run mds_setup again and choose Option 2 - Upgrade to R70.
High Availability
After completing the translations on the first MDS, copy the following files to the
other MDSes. If the MDSes are properly synchronized, no additional work is
required.

Advanced Usage
Files to be copied:
/var/opt/CPcustomers_translated.txt
/var/opt/CPcustomers_translated.md5
When running the tool a second time, the customer names that have already been
translated are shown before the first non-compliant name is displayed. This is also
the case when running on an additional MDS.
Advanced Usage
An advanced user may choose to directly edit the translation file,
/var/opt/CPcustomers_translated.txt. In this case, all the translations are
verified when mds_setup is run again.
Translations file format - The file is structured line-wise. Each line's meaning is
indicated by its first character. An empty line is ignored. Any line that does not
obey the syntax causes the file to be rejected with an appropriate message.
Table 14-3 Line Prefixes

Line Prefix Meaning Comment
# A comment line. May be inserted anywhere.
- Existing non-compliant Must exactly match an
name. existing non-compliant
name, otherwise it will be
rejected.
+ A translation for the If the entry does not
preceding '-' line. comply with the naming
restrictions, it is ignored.
280
Advanced Usage
The '-' and '+' lines must form pairs. Otherwise, the file is rejected.
If the translations file is manually modified, the mds_setup detects it and displays
the following menu:
1. Use the translations file anyway - Choose this option only if an authorized
person modified it. This option reads the file, verifies its content and uses the
translations therein.
2. Ignore the translations file and generate a new one - Choose this option to
overwrite the contents of the file.
3. Quit and leave the translations file as it is - Choose this option to exit
mds_setup and leave the translations file as is for now. Run mds_setup again
when you are sure that option 1 or option 2 is suitable.

Changing the MDS IP Address and External Interface
Changing the MDS IP Address and External

Interface
In This Section
IP Address Change page 282

Interface Change page 282
IP Address Change
If your target machine and the source machine have different IP addresses, follow
the steps listed below it to adjust the restored MDS to the new IP address.
To change the IP address:
1. The MDS must be stopped. Stop the MDS by running mdsstop.
2. Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address.
3. Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the MDS object that has the
source MDS IP address and change its IP address to the new IP address. Do
not change the name of the MDS.
4. Install a new license on the target MDS with the new MDS IP address.
5. For multiple MDS/MLM environments, repeat steps 1 to 4 on each MDS/MLM
for the MDS/MLM for which you changed the IP.
Interface Change
If your target machine and the source machine have different interface names (e.g.,
hme0 and hme1), follow the steps listed below to adjust the restored MDS to the new
interface name.
To change the interface:
1. Change the interface name in file $MDSDIR/conf/external.if to the new
interface name.
2. For each CMA, replace the interface name in $FWDIR/conf/vip_index.conf.
282
IPS in Provider-1
IPS in Provider-1
• When upgrading to R70, the previous IPS configuration of the Customer is
overridden on the first Global Policy Assign.
It is recommended to save each Customer’s Security Policy so that the settings
can be restored after upgrade. To do so, from the MDG, go to Customer
Configuration window > Assign Global Policy tab, and enable Create database
version.
• Customers who are upgrading to Provider-1 R70 should note that the IPS
subscription has changed.
• All customers subscribed to IPS are automatically assigned to an
“Exclusive” subscription
• “Override” and “Merge” subscriptions are no longer supported.
See the Global Policy Chapter of the Provider-1 R70 Administration Guide for
detailed information.

IPS in Provider-1
284
Chapter 15
Upgrading SmartLSM ROBO
Gateways
In This Chapter
Planning the ROBO Gateway Upgrade page 286

ROBO Gateway Upgrade Package to SmartUpdate Repository page 287
License Upgrade for a VPN-1 Power/UTM ROBO Gateway page 287
Upgrading a ROBO Gateway Using SmartProvisioning page 289
Using the Command Line Interface page 293
285
Planning the ROBO Gateway Upgrade
Planning the ROBO Gateway Upgrade

When you upgrade your Security Management server, it is recommended to upgrade
the ROBO gateways managed by SmartProvisioning so that they are compatible with
the latest features and functionalities. This chapter describes how to upgrade your
ROBO gateways.
The general workflow for upgrading ROBO gateways comprises the following steps:
1. For VPN-1 Power/UTM ROBO gateways, in SmartDashboard, define new
SmartLSM Profile objects for the new version and install the respective policies
on these objects. This Install Policy operation only compiles the policy, it does
not send it to any gateway. The compiled policy is automatically fetched later
by the relevant ROBO gateways, following their upgrade.
2. Add the upgrade package to the SmartUpdate package repository.
For additional information, refer to “ROBO Gateway Upgrade Package to
SmartUpdate Repository” on page 287.
3. Upgrade your ROBO Gateways in one of the following ways:
• Using SmartProvisioning (refer to “Upgrading a ROBO Gateway Using
SmartProvisioning” on page 289)
• Using the SmartLSM Command Line Interface
(refer to “Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli” on
page 295).
When upgrading VPN-1 Power/UTM ROBO gateways, the upgrade process removes
the initial Plug & Play license from your gateway. Trying to perform a remote
upgrade on a gateway without a valid NGX license will succeed, but this gateway
will not be able to load the correct policy after the upgrade. Make sure that all
gateways have valid permanent NG and NGX licenses installed before the upgrade.
286
ROBO Gateway Upgrade Package to SmartUpdate Repository
ROBO Gateway Upgrade Package to

SmartUpdate Repository
Once you have launched SmartUpdate, add the packages needed for the upgrade to
the SmartUpdate package repository. UTM-1 Edge Firmware packages are added
the same way.
For details on how to add packages to the Package Repository, refer to the
SmartUpdate chapter of the R70 Security Management Server Administration Guide.
License Upgrade for a VPN-1 Power/UTM

ROBO Gateway
The general workflow for upgrading ROBO gateway licenses to N70 comprises the
following steps:
1. Upgrade the software on the ROBO Gateway, as described in “Upgrading a
ROBO Gateway Using SmartProvisioning” on page 289.
2. Use SmartProvisioning to Attach the upgraded licenses to each ROBO Gateway,
one ROBO at a time.
Using SmartProvisioning to Attach the Upgraded

Licenses
To attach the upgraded licenses:
1. Open SmartProvisioning.
2. For each ROBO Gateway, open the Edit VPN-1 Power/UTM ROBO Gateway window,
and select the Licenses tab. All licenses that are attached to this ROBO
gateway are shown. If the license upgrade succeeded, the window will report
that: There are un-attached licenses that are assigned to this ROBO.
3. Add those licenses that are assigned to this ROBO from the SmartLSM License
Repository to the Licenses window. You can do this by performing one of the
following two options. The first way is easier:
• Click Add these licenses to the list.
• Click Add, and then select those licenses that are assigned to this ROBO.
Chapter 15 Upgrading SmartLSM ROBO Gateways 287

License Upgrade on Multiple ROBO Gateways
The added assigned licenses are shown grayed-out because they are not yet
attached.
4. Click OK to attach the Assigned Licenses to this ROBO.
The ROBO gateway now has both NG and NGX licenses. The Licenses window
shows that the NGX license is Attached, and the NG license is Obsolete,
meaning that it is no longer needed. The NG license is useful because if you
need to downgrade the Gateway version, the Gateway will keep on working.
5. Repeat from step 2 for each ROBO gateway.
License Upgrade on Multiple ROBO Gateways

You can use scripting to upgrade licenses on multiple ROBO gateways. For
additional information, refer to “Example: License Upgrade on Multiple ROBO
Gateways” on page 298.
288
Upgrading a ROBO Gateway Using SmartProvisioning
Upgrading a ROBO Gateway Using

SmartProvisioning
In This Section
Upgrading a VPN-1 Power/UTM ROBO Gateway page 289

Upgrading a UTM-1 Edge ROBO Gateway page 291
Upgrading a VPN-1 Power/UTM ROBO Gateway In Place page 292
Upgrading a VPN-1 Power/UTM ROBO Gateway

There are two methods for upgrading a VPN-1 Power/UTM Gateway, the Full
Upgrade and the Specific Install.
Full Upgrade
This method automatically performs all the required checks and actions for you.
When it successfully completes, the upgraded ROBO Gateway is ready for use. This
is the recommended method to upgrade VPN-1 Power/UTM ROBO Gateways.
To perform a full upgrade:
1. From SmartProvisioning, select the line representing the VPN-1 Power/UTM
ROBO Gateway to be upgraded.
2. Select Actions > Packages > Upgrade All Packages. This selection can also be
done through the right-click menu, or the Upgrade All Packages icon in the
toolbar.
The upgrade process begins with a verification stage, checking which version is
currently installed on the gateway and whether the required packages exist in
your Package Repository. When it completes, a Verification Details window
opens, showing you the verification results.
3. Select Change to a new Profile after upgrade, and select the appropriate new
SmartLSM Profile from the list.
4. Select Allow reboot if required.
5. Click the Continue button.

The Upgrade process begins. Its stages and completion status can be seen in
the Action Status pane, at the bottom of SmartLSM. The entire progress report
can be seen at any time by viewing the Action History (right-click on the
respective line in the Action Status pane, and select Action History).
Specific Installation
This method can be used to install a specific product on a ROBO Gateway.
To perform a specific installation:
1. From SmartLSM, select the line representing the VPN-1 Power/UTM ROBO
gateway you want to upgrade.
2. Select Actions > Packages > Get Gateway Data to fetch information about
Packages currently installed on the VPN-1 Power/UTM ROBO gateway.
3. Select Actions > Packages > Distribute Package… or right-click menu, and
select Distribute Package…, or click the icon in the toolbar.
The Distribute Package window opens. This window displays the relevant
packages from the Package Repository that can be installed on your VPN-1
Power/UTM ROBO gateway.
4. In the Distribute Package window, select the package you want to install.
You can then select one of the following actions:
• Distribute and install packages
• Only distribute packages (install later)
• Install previously distributed packages
5. The Allow Reboot if required option should be selected only when upgrading
VPN-1. If you do not select this option, manually reboot the gateway from its
console. The gateway is rebooted after the package installation is completed.
Note - If you are doing a step-by-step upgrade, do not select Allow Reboot if required.
6. If the operating system is SecurePlatform, you can select Backup image for
automatic revert, in case the installation does not succeed.
7. The option Change to a new profile after install lets you select the SmartLSM
Profile that will be assigned to the package upon installation. When upgrading
the VPN-1 Power/UTM ROBO gateway, you must provide a suitable SmartLSM
290
Upgrading a UTM-1 Edge ROBO Gateway
Profile from the target version. If you are installing a package that does not
require changing the SmartLSM Profile of the VPN-1 Power/UTM ROBO
gateway, this field remains disabled.
8. Click the Start button.
9. The Install process begins. Its stages and completion status can be seen in the
Action Status pane, at the bottom of SmartLSM. The whole progress report can
be seen at any time by viewing the Action History (right-click on the respective
line in the Action Status pane, and select Action History).
Note - You can verify if the installation will succeed before actually upgrading the ROBO
Gateway by choosing Actions > Packages > Verify Installation.
Upgrading a UTM-1 Edge ROBO Gateway

To upgrade the gateway:
1. From SmartLSM, select the line representing the UTM-1 Edge ROBO gateway
you want to upgrade, and choose Edit > Edit ROBO gateway… This selection can
also be done through the right-click menu, or the Edit ROBO gateway icon in
the toolbar, or by double-clicking the ROBO line.
2. Select the Firmware tab.
3. Select the Use the following firmware option, select the desired firmware from
the list, and click OK. The UTM-1 Edge ROBO gateway fetches and installs the
new firmware the next time it automatically checks for updates. In order for the
firmware upgrade to take effect immediately, restart the ROBO Gateway by
selecting Actions > Restart gateway.

Upgrading a VPN-1 Power/UTM ROBO Gateway In Place
Upgrading a VPN-1 Power/UTM ROBO Gateway In

Place
You can upgrade a ROBO gateway In Place (from the ROBO gateway's console), just
like an In Place upgrade of a regular gateway. Following the upgrade, update the
new version on the SmartLSM side, and select a new SmartLSM Profile for the
gateway.
To upgrade a gateway In Place:
1. From SmartLSM, select the line representing the VPN-1 Power/UTM ROBO
gateway you just upgraded, and select Edit > Edit ROBO gateway… or right-click
the Edit ROBO gateway icon in the toolbar, or double-click the ROBO line. The
Edit window opens in the General tab.
2. From the Version menu, select the new version of the upgraded gateway.
3. From the Profile menu, select a new SmartLSM Profile for the upgraded
gateway.
4. Click OK to close the window.
5. The policy and properties of the new SmartLSM Profile are applied on the
ROBO Gateway the next time it automatically checks for updates. In order for
the SmartLSM Profile change to take effect immediately, restart the ROBO
Gateway by selecting Actions > Restart Gateway.
292
Using the Command Line Interface
Using the Command Line Interface

In This Section
SmartLSM Upgrade Tools page 293

Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli page 295
Upgrading a UTM-1 Edge ROBO Gateway Using LSMcli page 296
Using the LSMcli in Scripts page 297
SmartLSM Upgrade Tools

LSMcli
The LSM Command Line Interface (LSMcli) is an alternative to SmartLSM. LSMcli
provides the ability to perform SmartLSM operations from a command line or through
a script. It also enables you to upgrade a ROBO Gateway. When used in scripts it
allows you to perform batch upgrades.
The LSMcli tool is contained in the management installation package on the
Security Management server machine. It can be run on your Security Management
server, or it can be copied to and run on another host with the same operating
system. The host does not need to be a Check Point-installed machine, but it must
be:
• Defined on the Security Management server as a GUI Client.
• Use the same Operating System as the Security Management server.
• Reachable through the network from the Security Management server.
For general usage and help, type the command LSMcli --help.

SmartLSM Upgrade Tools
The LSMcli command line arguments are fully described in the Command Line
Reference chapter of the R70 SmartProvisioning Administration Guide. A partial list
of arguments is shown in Table 15-1, which lists only the arguments that are
important for performing upgrades.
Table 15-1 LSMcli Command line arguments for upgrades

Argument Meaning
-d (Optional) Run the command with debug output.
Server The IP or hostname of the Security Management server.
User The username and password of a Security Management
Password Server Administrator.
ROBO The name of the ROBO Gateway to be upgraded.
-F Firmware The firmware version of the UTM-1 Edge ROBO Gateway.
-P=Profile (Optional) The SmartLSM Profile name the ROBO Gateway
will be mapped to after a successful upgrade.
You must specify the new SmartLSM Profile when upgrading
the VPN-1 version. This is not necessary when installing
Hotfixes or other packages.
-boot (Optional) Use this option only when upgrading VPN-1. If
you do not use this option, manually reboot the gateway from
its console.
-DoNotDistribute (Optional) Install previously distributed packages.
Product To view the list of packages available in the repository, use
Vendor the ShowRepository LSMcli command.
Version
SP (Command usage is described in the R70 SmartProvisioning
Administration Guide).
Export
The export tool is located in your SmartLSM application, under File > Export to File.
Use this tool to export a ROBO Gateway’s properties into a text file that you can
turn into a script in order to perform batch upgrades.
294
Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli

Using LSMcli
For descriptions of the command line arguments for the following commands, refer
to Table 15-1 on page 294.
To verify that a Full Upgrade of a ROBO Gateway will succeed, execute:
LSMcli [-d] <Server> <User> <Password> VerifyUpgrade <ROBO>
To perform a Full Upgrade of a ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> Upgrade <ROBO> [-P=Profile]
[-boot]
To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository
To verify that a Specific Install on a ROBO gateway will succeed, execute:

LSMcli [-d] <Server> <User> <Password> VerifyInstall <ROBO>
<Product> <Vendor> <Version> <SP>
To perform a Specific Install on a ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> Install <ROBO> <Product>
<Vendor> <Version> <SP> [-P=Profile] [-boot] [-DoNotDistribute]
To only distribute a package, execute:

LSMcli [-d] <Server> <User> <Password> Distribute <ROBO> <Product>
<Vendor> <Version> <SP>
To view a list of packages that can be installed on a specific ROBO gateway,

execute:
LSMcli [-d] <Server> <User> <Password> GetCandidates <ROBO>
To get data about a specific ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> GetInfo <ROBO>
Note - It is recommended to use the Full Upgrade method to upgrade VPN-1 Power/UTM
ROBO Gateways.

Upgrading a UTM-1 Edge ROBO Gateway Using LSMcli
Example: Upgrading a Single VPN-1 Power/UTM ROBO

Gateway
% LSMcli MyServer John mypassword VerifyUpgrade ROBO17
% LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile
Where:
MyServer = the name of my Security Management server.
John = the administrator’s name.
mypassword = the administrator’s password.
VerifyUpgrade = the Full Upgrade verification command.
Upgrade = the Full Upgrade command.
ROBO17 = the VPN-1 Power/UTM ROBO Gateway to be upgraded.
MyNewProfile = the new SmartLSM Profile that ROBO17 will be mapped to after
the upgrade.
Upgrading a UTM-1 Edge ROBO Gateway Using

LSMcli
For descriptions of the command line arguments for the following commands, refer
to Table 15-1 on page 294.
To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository
To upgrade a UTM-1 Edge ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> ModifyROBO VPN1Edge <ROBO>
[-P=Profile] [-F=Firmwarename]
If you want the firmware update to take effect immediately, execute:

LSMcli [-d] <Server> <User> <Password> Restart <ROBO>
296
Using the LSMcli in Scripts
Example: Upgrading a Single UTM-1 Edge ROBO

Gateway
% LSMcli MyServer John mypassword ModifyROBO VPN1Edge
ROBO101-P=EdgeNewProfile -F=4.0.23
% LSMcli MyServer John mypassword Restart ROBO101
Where:
MyServer = the name of my Security Management server.
John = the administrator's name.
mypassword = the administrator's password.
ModifyROBO VPN1Edge = the command to modify a property on a UTM-1 Edge
ROBO gateway.
ROBO101 = the Edge ROBO Gateway to be upgraded.
EdgeNewProfile = the new SmartLSM Profile that ROBO101 will be mapped to
after the upgrade (optional).
4.0.23 = the name of the new Firmware package.
Restart = the command to restart the gateway.

Scripting can be very handy when you want to upgrade multiple ROBO Gateways in
batches.
Example: Using the LSM CLI to write a script to

upgrade multiple ROBO Gateways
Create the following script and run it:
LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile
LSMcli MyServer John mypassword Upgrade ROBO18 -P=MyNewProfile
LSMcli MyServer John mypassword Upgrade ROBO19 -P=MyOtherProfile

Example: License Upgrade on Multiple ROBO Gateways

To upgrade licenses on multiple ROBO Gateways, create a script that runs the
LSMcli command with the AttachAssignedLicenses option on all ROBO Gateways.
The AttachAssignedLicenses option is equivalent to doing step 3 and step 4 on
page 288 in SmartLSM.
The command is:
LSMcli [-d] <Server> <User> <Password> AttachAssignedLicenses VPN1
<ROBO>
For example:
LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO17
298
Chapter 16
Upgrading Eventia
In This Chapter
Overview page 300

Upgrading Eventia Reporter page 300
Upgrading Eventia Analyzer page 306
299
Overview
Overview
When upgrading products of the Eventia suite, note that:
• Eventia Reporter of version R56 and higher can be upgraded to R65.
• Eventia Analyzer of version 1.0 and higher can be upgraded to R65.
Upgrading Eventia Reporter

During the upgrade procedure, the MySQL4 database is upgraded to MySQL5. Due
to a more efficient way of handling the data, this upgrade results in a smaller sized
database, as shown on the management view > database maintenance > Database
capacity details.
For Standalone Deployments

A Standalone Deployment upgrade refers to a previous Eventia Reporter version
that is installed on a Security Management server.
To upgrade Eventia Reporter in a Standalone Deployment perform the following
steps:
In This Section

Solaris / Linux Platform page 301
SecurePlatform page 301
Windows Platform
1. In order to begin the installation, login as an administrator and launch the
wrapper by double-clicking on the setup executable.
2. Agree to the License Agreement and click Forward.
3. Select Upgrade and click Forward.
4. Continue following the instructions.
The instructions that appear will differ according to your deployment.
300
For Distributed Deployments
5. Indicate whether to add new products by selecting the Add new products option
and click Forward.
A list of the products that will be upgraded appears. Click Forward.
Depending on the components that you have chosen to install, you may need to
take additional steps (such as installing other components and/or license
management).
6. Verify the default directory, or browse to new location in which Eventia Reporter
will be installed.
7. Verify the default directory, or browse to new location in which the output files
created by Eventia Reporter’s output will be generated.
Click Next and reboot the machine in order to complete the installation of the
Eventia Reporter and to continue with the next phase of the installation.
9. Install the Security Policy, (Policy > Install) or install the database (Policy >
Install Database) in order to make the Eventia Reporter fully functional.
Solaris / Linux Platform

1. In order to begin the installation, mount the CD on the relevant subdirectory
and launch the wrapper as follows:
2. In the mounted directory, run the script: UnixInstallScript.
3. Read the End-User License Agreement (EULA) and if you accept click Yes.
4. Continue from step 3 on page 300 in order to complete the process.
SecurePlatform
1. After you install SecurePlatform from the CD, select the Eventia Reporter
product from cpconfig or from the SecurePlatform Web GUI.
2. Continue from step 3 on page 300 in order to complete the process.

A Distributed Deployment upgrade refers to a previous Eventia Reporter version that
is installed on a dedicated machine and an Eventia Reporter Add-on installed on a
Security Management server or MDS (for versions prior to R63).
Chapter 16 Upgrading Eventia 301

To upgrade Eventia Reporter in a distributed deployment, install R70 on the old

Reporter Server and migrate the previous add-on from the Security Management
server to the Reporter Server.
Upgrade Eventia Reporter to the new R70

1. Before upgrading, open the Eventia Reporter client.
2. Go to Management > Consolidation > Sessions and stop all consolidations
sessions by selecting Stop > Terminate. Verify that all the consolidation sessions
have a Stopped status before closing Eventia Reporter.
3. Run cpstop and wait till the mysql and log_consolidator processes stop.
4. Install R70 on the previous Reporter Server.
Migrate the Add-on to the Eventia Reporter Server

To upgrade from versions prior to R63, export and import Add-On.
Prior Eventia Reporter Add-on version that contain Eventia Reporter definitions and
statuses should be copied to the machine on which Eventia Reporter is installed.
To migrate the add-on to the Eventia Server:
1. Run cpstop on both the target machine (Eventia Reporter) and the original
machine (the Add-on machine).
2. Copy the script evr_addon_export from the directory $RTDIR/conf in the R65
Eventia Reporter Server to the Security Management Server or MDS Server.
3. Invoke evr_addon_export on the Security Management Server or MDS Server.
This generates a file called evr_addon_tables.tgz in the same location as
evr_addon_export.
4. Copy evr_addon_tables.tgz to the $RTDIR/bin directory on the target R65
Eventia Reporter Server.
5. On the Eventia Reporter Server run svr_install --import
evr_addon_tables.tgz.
6. Run cpstart on both the target and original machine.
7. Open the Eventia Reporter client and start the Consolidation Sessions if
needed.
Note - After upgrading Eventia Reporter, the GUI client must be defined on the Eventia
Reporter Server. To do this run cpconfig and select GUI Clients.
302
Advanced Eventia Reporter Upgrade
Note - After upgrading Eventia Reporter in a Provider-1 environment you should select a
customer(s) that will initiate a synchronization with the CMA of the selected customer. To
do this select Tools > Customer Activation in the Eventia Reporter client, select the relevant
customers and click OK.

On the destination machine, install the required version of Eventia Reporter.
1. On the source machine, stop all consolidation sessions:
a. Open the Eventia Reporter client.
b. In the Management view, select Consolidation.
c. Select the Consolidation session.
d. Click Stop > Terminate
e. Click Remove.
2. Perform a full export that includes all of the Eventia Reporter data:
a. On the source machine, run cpstop.
b. Save the Reporter database:
i. Using a text editor, open the mysql configuration file located in
$RTDIR/Database/conf/.
The location of the database data files is specified in the mysql
configuration file my.ini (Windows) or my.cnf (for all other platforms).
ii. Locate the values of the following strings:
innodb_log_group_home_dir=<xxx>
datadir=<xxx>
innodb_data_file_path=<xxx>
iii. Remove the contents of the directory pointed to by
innodb_log_group_home_dir
iv. Move to the directory pointed to by datadir, and create a compressed
tar file (.tgz) containing all the files in this directory using the
command: gtar -zcvf <xxxx.tgz>.

v. The innodb_data_file_path variable contains a list of files. If there is

more than one entry (separated by commas) in the
innodb_data_file_path variable, locate these files and include them in
the compressed tar file.
3. Copy the my.cnf (or my.ini) file located in $RTDIR/Database/conf to a backup
location and rename it to my.cnf.old (or my.ini.old).
Note - The .ini or .cnf suffix should be added to the file according to target platform. For
example, if the source machine is Solaris you have a my.cnf file. If the target machine is
Windows, then you backup the my.cnf file as my.ini.old. If the target machine is UNIX, the
name should be my.cnf.old.
4. Copy any company logo image file(s) in $RTDIR/bin. to a backup location.

5. Copy any custom distribution scripts in $RTDIR/DistributionScripts to a
backup location.
6. If the source Reporter resides on a management machine:
a. Export the database by running: upgrade_export <yyyy.tgz> as described
in “Advanced Upgrade of Security Management servers & Standalone
Gateways” on page 211.
b. Copy the created .tgz file <yyyy.tgz> to the target machine and save it in
$FWDIR/bin/upgrade_tools.
c. On the target machine run: upgrade_import <yyyy.tgz>.
d. When prompted to run cpstart, select: no.
7. If Reporter is installed in a distributed configuration:
a. Copy the evr_addon_export script located in $RTDIR/conf on the target
machine, and:
i. For versions prior to NGX R65, place the evr_addon_export script on
the management machine.
ii. If the upgrade is from R65, place the script on the Reporter machine.
b. Run evr_addon_export. A file named tables.tgz is created.
c. Place tables.tgz on the target machine in $RTDIR/bin.
d. From inside the $RTDIR/bin directory run: svr_install -import
tables.tgz.
8. On the target machine, run: cpstop.
9. Place the file my.cnf.old (or my.ini.old) in the $RTDIR/Database/conf/
directory of the target machine.
304
Enabling Eventia Analyzer after Upgrading Reporter
10. Copy the compressed database files <xxxx.tgz> to the target machine.
11. Enter the installation directory on the target machine:
• For Windows: C:\Program Files\CheckPoint\EventiaSuite\R70\bin
• Other platforms: /opt/CPrt-R70/bin
12. Run: EVR_DB_Upgrade -mysql "<path of <xxxx.tgz> file/<xxxx.tgz>>"
For example, if you chose to place R60_Backup.tgz in $RTDIR/tmp, run:
EVR_DB_Upgrade -mysql "$RTDIR/tmp/R60_Backup.tgz"
13. If necessary, modify the following fields in the mysql configuration file to match
the locations of the database data files:
• datadir=
• innodb_log_group_home_dir=
• innodb_data_file_path=
The locations were copied in step 2 on page 303.
14. Run cpstart.
Enabling Eventia Analyzer after Upgrading Reporter

After upgrading Eventia Reporter from a previous version, only the Eventia Reporter
components will be enabled. To enable the Eventia Analyzer components (analyzer
or correlation unit) as well, run:
1. cpstop
2. evconfig
While running evconfig, enable Analyzer Server or the Correlation Unit.
3. cpstart

Upgrading Eventia Analyzer
Upgrading Eventia Analyzer

The process consists of:
• Upgrading Eventia Analyzer to R65
• Verifying that the events database has been successfully moved to its new
location
• Enabling Eventia Reporter (optional)
Upgrading Eventia Analyzer to R70

Eventia Analyzer can be upgraded to R70:
• Directly from version NGX R63
• Indirectly from any version prior to NGX R63
a. If you wish to upgrade from version 1.0, first upgrade to version 2.0, then
upgrade to R63, and then to R65.
b. If you wish to upgrade from version 2.0, first upgrade to R63 then to R65
For more detailed information on upgrading to R63, see the
CheckPoint_R63_EventiaSuite_UpgradeGuide.pdf
Prerequisites
Before upgrading to Analyzer R70, note the path to the current database file:
$RTDIR/events_db/events.sql, where $RTDIR is a variable that contains the path
of the previous Eventia Analyzer installation.
In R63, the default path:
• For Windows is C:\Program Files\CheckPoint\EventiaSuite\R63
• For Unix platforms is /opt/CPrt-R63
This path is changed during the upgrade process.
Upgrading Analyzer on SecurePlatform

1. Insert the R65 installation CD into the disk drive and run patch add cd.
2. Confirm the MDS checksum.
3. Select whether to create a backup image for automatic revert (recommended).
4. The Welcome message is displayed.
306
Upgrading Eventia Analyzer to R70
5. Read and accept the license agreement.

6. Select the first option: upgrade.
7. Download or import a service contract file, or choose to continue without one.
8. Select a source for the R70 upgrade utilities.
9. Select Upgrade Installed Products.
10. Validate the products in the products list.
11. Reboot once the upgrade is complete.
Upgrading Analyzer on a Windows Platform

1. Insert the R70 Installation disk into the disk drive.
2. Read and Accept the license agreement.
3. Select upgrade option.
5. If necessary, upgrade your license.
7. Perform the pre-upgrade verification check.
8. Decide whether to install additional Check Point products.
10. Decide whether to copy log files now or manually copy them later.
11. Select a destination location.
12. Once the upgrade has completed, reboot.
Upgrading Analyzer on Solaris and Linux

1. Insert the R70 installation CD into the disk drive.
2. Run: UnixInstallScript.
3. Read and accept the license agreement.
4. Select the upgrade option.
7. Select to upgrade installed products.

Verifying the Events Database Has Been Moved

9. Once upgrade has completed, login again to the root account.
10. Run cpstart to activate the installed products.
Verifying the Events Database Has Been Moved

When upgrading from R63 to R65, the events database is moved (not copied) from
its R63 location to a new R65 location. This should occur automatically during the
upgrade process, so there is no need to run upgradeDB.
To verify that the database has been correctly moved:
1. Navigate to the R63 $RTDIR/events_db/. The events.sql database file should
no longer exist in this directory
2. Navigate to the R65 $RTDIR/events_db/ directory. The events.sql should be
here
If the move has failed, move the database manually
Moving the Events Database

To manually move the events database:
1. Run: cpstop.
2. Move the file events.sql manually, from R63 $RTDIR/events_db/ to R65
$RTDIR/events_db/.
3. Run: cpstart.
Enabling Eventia Reporter

After upgrading Eventia Analyzer from a previous version, only the Eventia Analyzer
components (Analyzer or correlation unit) will be enabled. To enable all
components of Eventia Reporter run:
1. cpstop
2. evconfig
3. Enable Eventia Reporter
4. cpstart
308
Chapter 17
Upgrading IPS-1
In This Chapter
IPS-1 Upgrade Paths page 310

Upgrading from R65.1 to R65.2 page 310
Upgrading IPS-1 Management Servers page 310
Upgrading IPS-1 Sensors page 311
Upgrading IPS-1 Power Sensors page 311
Upgrading Legacy Sensor Appliances page 313
309
IPS-1 Upgrade Paths
IPS-1 Upgrade Paths

IPS-1 Management Servers, including NFR Sentivist Servers and Enterprise
Servers, and IPS-1 Power 1000 and 2000 Sensors, of versions 5.x, can be
upgraded to the current version.
• For earlier versions: reinstall.
• For Non-Power Sensors installed on SecurePlatform: reinstall.
Upgrading from R65.1 to R65.2

If you are upgrading from R65.1 to R65.2, for both SecurePlatform and Solaris:
1. From the Check Point Suport Center, download ips1_r65_hfa1.tar.gz.
2. Copy the compressed tar file onto the target system.
Note - Alerts Concentrators do not require an upgrade. On a stand-alone Alerts

Concentrator, the upgrade process will fail.
3. Login root (or admin).

4. Unzip and untar the file.
For non-SPLAT systems, use the GNU tar located in:
/opt/CPips1-R65/bin/gtar.
5. Move to the resulting ips1_r65_hfa1 directory.
6. Run: ./install_ips1_r65_hfa1.sh
If IPS-1 is running the script will stop it.
7. Restart the IPS-1 application, and log in using an IPS-1 HFA1 level Dashboard.
Upgrading IPS-1 Management Servers

Upgrading IPS-1 Management is integrated into the installation process. To
upgrade IPS-1 Management from a previous version according to supported
upgrade paths, follow the relevant steps in the installation instructions. To upgrade
IPS-1 Management onto a new hardware platform, follow the instructions in the
IPS-1 Management Server Backup and Migration chapter of the IPS-1
310
Upgrading IPS-1 Sensors
Upgrading IPS-1 Sensors

The only way to upgrade a regular (non-Power) Sensor is to completely reinstall it,
including formatting the hard disk. For instructions on how to install an IPS-1
Sensor, see Installing SecurePlatform and IPS-1 Sensors.
Upgrading IPS-1 Power Sensors

There are two kinds of upgrades:
• Remote Upgrade: Performed from the Alerts Concentrator, and replaces only
changed packages.
• Full Upgrade: Formats the hard disk and completely reinstalls the operating
system and software.
For a Remote Upgrade, follow the instructions in “Remotely Upgrading an IPS-1 Power
Sensor” on page 311 .
For a Full Upgrade, follow the instructions for reinstallation in the “Reinstalling an
IPS-1 Power Sensor” on page 312, using a newer version of the installation source.
Remotely Upgrading an IPS-1 Power Sensor

For information on possible upgrade paths, see “IPS-1 Upgrade Paths” on
page 310.
The remote upgrade is performed from the IPS-1 Alerts Concentrator, as follows:
1. Mount the CD on the appropriate subdirectory on the Alerts Concentrator.
2. Switch to the ips1 user account, by running:
su - ips1
Note - If the Alerts Concentrator is running on SecurePlatform, to switch to the

ips1 user you will need to be in expert mode.
3. From the root directory of the CD, run:

./upgrade_sensor -d $IPS1DIR/alcr -u <upgrade_file.tar> <Sensor_name>
Chapter 17 Upgrading IPS-1 311

Reinstalling an IPS-1 Power Sensor
The upgrade_sensor script will verify that the given IPS-1 Sensor is upgradeable,
transfer the necessary files from the IPS-1 Sensor CD to the Sensor and tell it to
complete the upgrade. If the upgrade_sensor script finishes without any errors, the
IPS-1 Sensor will reboot itself. When it comes back up, it will be running a new
version of the IPS-1 Sensor software.
If, for some reason, the upgrade fails, you may need to do a full re-installation of
the IPS-1 Sensor.
Reinstalling an IPS-1 Power Sensor

The procedure described in this section formats the hard disk and completely
reinstalls the operating system and software.
The installation can be from one of two kinds of sources:
• A Local Distribution Partition (LDP) image on the Power Sensor’s hard disk. An
LDP image is created during installation and so should exist on your Power
Sensor. Use an LDP image to reinstall the existing version of the software.
• An IPS-1 Power Sensor installation source directory on a network server. Use
this type of installation to perform a Full Upgrade.
To reinstall (or perform a Full Upgrade):
1. If you are going to be installing from a network server (not from an LDP), obtain
a Check Point IPS-1 Power Sensor installation CD, and extract the Power-Sensor
- <version_number>.tar file to a network server accessible from the Power
Sensor’s management interface by FTP, HTTP, or NFS.
2. Connect to the IPS-1 Power Sensor with a Serial Console.
3. Boot the Power Sensor. During disk initialization, you will see the following:
Press ESC twice to enter the ROM Menu, or any other key to auto
boot....
Seconds Remaining until Auto Boot: 5
Within 5 seconds, press ESC twice.
4. When prompted for the ROM menu password, if you haven’t set one, just press
Enter.
The main ROM menu appears.
5. Select Boot in Rescue Mode.
6. When the next menu appears, select (Re)Install System (manual).
312
Upgrading Legacy Sensor Appliances
7. Set the various date and time values, as prompted. Then confirm the date and
time.
8. Available LDP images are listed, with their software version and build numbers.
Select an LDP image number, or n to install from a network source.
9. In a network installation, you will be prompted for network information to
enable the installation, as follows:
a. Set IP information for the Power Sensor’s management interface.
b. Optionally, set a host and domain name. For example:
c. mysensor.example.com
d. Type the default gateway address.
e. Type the IP address of the installation source.
f. Type the path on the installation source computer to the directory
containing NR-INSTALL-DIRECTORY . Something like:
g. /root/Power-Sensor.5.0.7/Install
h. Type the protocol to be used - ftp, nfs, or http. Depending on the selected
protocol, you may be prompted for additional information.
10. Select the installation type. There should be only one choice (1).
11. In most cases, select to install to the Multiple Disk Array.
12. Select to install to the root partition. Wait for the system to complete formatting
the partition.
In most cases, do not create a local installation image. Select n.
The system installs the packages and reboots twice. When finished, the system is
at the same state as when shipped. Continue setting up the Sensor by following the
instructions in Initial Configuration of IPS-1 Power Sensor.
Upgrading Legacy Sensor Appliances

Customers upgrading legacy hardware to this version should note that the interface
ordering may differ from previous versions of the IPS-1 Sensor software.
The illustrations below identify the names of the interfaces on each legacy
appliance.

100C and 200C
100C and 200C
200F
310C
320C
320F
500C (pre-Jan 2006)
314
500C (post-Jan 2006)
500C (post-Jan 2006)
500F (pre-Jan 2006)
500F (post-Jan 2006)

500F (post-Jan 2006)
316

CP R70 Internet Installation and UpgradeGuide

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CP R70 Internet Installation and UpgradeGuide

Diunggah oleh

Hak Cipta:

Format Tersedia

Installation and Upgrade Guide

Internet Security Product Suite

701313 March 2, 2009

RESTRICTED RIGHTS LEGEND:

Please refer to http://www.checkpoint.com/copyright.html for a list of our trademarks

For third party notices, see http://www.checkpoint.com/3rd_party_copyright.html.

Chapter 2 Getting Started

Chapter 3 Setup and Installation

Chapter 4 Installing Provider-1

Chapter 5 IPS-1 Setup and Installation

Chapter 8 Service Contract Files

Chapter 9 Upgrading a Distributed Deployment

Chapter 10 Backup and Revert for Security Gateways

Chapter 11 Upgrading a Standalone Deployment

Chapter 12 Advanced Upgrade of Security Management servers & Standalone Gate-

Chapter 13 Upgrading ClusterXL Deployments

Chapter 14 Upgrading Provider-1

Chapter 15 Upgrading SmartLSM ROBO Gateways

Chapter 16 Upgrading Eventia

Chapter 17 Upgrading IPS-1

To extend your organization’s growing security infrastructure and requirements, we

Who Should Use This Guide

Table 2: SmartDashboard Tab Titles

TABLE P-1 Check Point Documentation

TABLE P-1 Check Point Documentation (continued)

For New Check Point Customers

Endpoint Security Integration

This chapter contains information and terminology related to installing R70.

• Provider-1 Administrator: A security administrator, assigned with granular

Chapter 2 Getting Started 23

• Global Manager: A new type of administrator account in the MDG. With

Hardware and Software Requirements

Product / Management Blade Platform and Operating System

Check Point Security Gateway X X X X X

Chapter 2 Getting Started 25

Check Point Product Platform and Operating System

Notes to Supported by Platform Table

Supported Upgrade Paths and

Upgrade Paths and Interoperability page 27

Upgrade Paths and Interoperability

Upgrading Security Management Servers

Backward Compatibility For Gateways

Chapter 2 Getting Started 27

Table 2-4 Backward Compatibility for Gateways

Note - R70 cannot manage gateway versions NG, NG FP1, or NG FP2

IPS-1 Upgrade Paths and Interoperability

Obtaining a License Key

Chapter 2 Getting Started 29

Licensing Eventia Suite

Chapter 2 Getting Started 31

Installing SecurePlatform Using the CD page 35

Installing SecurePlatform Using the CD

Chapter 3 Setup and Installation 35

10. Select OK.

Installing SecurePlatform from the Network

General Workflow page 37

Chapter 3 Setup and Installation 37

Required Packages page 38

PXELINUX Configuration Files

DHCP Daemon Setup

Chapter 3 Setup and Installation 39

2. Edit the daemon’s configuration file, found at /etc/dhcpd.conf. The

# The client’s MAC address