CP R70 High-End Installation and UpgradeGuide

Installation and Upgrade GuideHigh-End Security Product Suite

Version R70

701313 February 25, 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.

http://www.checkpoint.com/copyright.html

http://www.checkpoint.com/3rd_party_copyright.html

Table of Contents 5

Contents

Chapter 1 Introduction Welcome........................................................................................................... 8For New Check Point Customers.......................................................................... 8Who Should Use This Guide................................................................................ 9Documentation ................................................................................................ 10Terminology .................................................................................................... 12

Product and Feature Nomenclature............................................................... 12Provider-1 Terminology................................................................................ 13VSX Terminology......................................................................................... 15

Supported Upgrade Paths................................................................................. 16Upgrading Management Servers ................................................................... 16Backward Compatibility For Gateways ........................................................... 16

Licensing ........................................................................................................ 17Licensing Provider-1 ................................................................................... 17Licensing VSX ............................................................................................ 18VSX/CMA Bundle Licenses........................................................................... 19The Trial Period .......................................................................................... 20License Violations ....................................................................................... 21

More Information ............................................................................................. 21Feedback ........................................................................................................ 21

Chapter 2 Installing Provider-1 Overview ......................................................................................................... 24Creating the Provider-1 Environment ................................................................. 25

Setting Up Provider-1 Networking................................................................. 25Install the Gateways .................................................................................... 26Installing and Configuring the Primary MDS .................................................. 26Installing SmartConsole and MDG Clients...................................................... 34

Using the MDG for the First Time ...................................................................... 35Launching the MDG .................................................................................... 35Adding Licenses using the MDG ................................................................... 36

Where To From Here?....................................................................................... 39

Chapter 3 Installing VSX Installing VPN-1 Power VSX.............................................................................. 42

Installing VPN-1 Power VSX on SecurePlatform ............................................. 42First Time Login ......................................................................................... 47Initial Configuration ................................................................................... 47

Where To From Here?....................................................................................... 48

6

Chapter 4 Upgrading Provider-1 Introduction .................................................................................................... 50

Supported Versions and Platforms ................................................................ 50Before You Begin ........................................................................................ 50

Provider-1 Upgrade Tools ................................................................................. 51Pre-Upgrade Verifiers and Fixing Utilities ...................................................... 51Installation Script ....................................................................................... 52export_database.......................................................................................... 53merge_plugin_tables ................................................................................... 55migrate_assist ............................................................................................ 56cma_migrate .............................................................................................. 57migrate_global_policies ............................................................................... 62Backup and Restore .................................................................................... 62

Provider-1 Upgrade Practices............................................................................ 64In-Place Upgrade........................................................................................ 64Replicate and Upgrade................................................................................ 66Gradual Upgrade to Another Machine ........................................................... 67Migrating from Security Management to a CMA ............................................. 69

Upgrading in a Multi-MDS Environment ............................................................. 72Pre-Upgrade Verification and Tools............................................................... 72Upgrading a Multi-MDS System ................................................................... 73

Restarting CMAs.............................................................................................. 76Restoring Your Original Environment.................................................................. 77

Before the Upgrade..................................................................................... 77Restoring Your Original Environment............................................................. 77

Renaming Customers ....................................................................................... 78Identifying Non-Compliant Customer Names.................................................. 78High Availability Environment ...................................................................... 78Automatic Division of Non-Compliant Names................................................. 78Resolving Non-Compliance .......................................................................... 79Advanced Usage ......................................................................................... 80

Changing the MDS IP Address and External Interface.......................................... 82IP Address Change...................................................................................... 82Interface Change ........................................................................................ 82

IPS in Provider-1 ............................................................................................. 83

Chapter 5 Upgrading VSX Upgrade Overview ............................................................................................ 86Upgrading the Management Server .................................................................... 87

Before Upgrading........................................................................................ 87The Upgrade Process .................................................................................. 87

Upgrading VSX Gateways .................................................................................. 88Before Upgrading........................................................................................ 88Installing SecurePlatform ............................................................................ 88Performing the Upgrade .............................................................................. 89

Upgrading VSX Clusters.................................................................................... 91Before Upgrading........................................................................................ 91Performing the Upgrade .............................................................................. 92

7

Chapter 1Introduction

In This Chapter:

Welcome page 8

Who Should Use This Guide page 9

Documentation page 10

Terminology page 12

Supported Upgrade Paths page 16

Licensing page 17

More Information page 21

Feedback page 21

Welcome

8

WelcomeThank you for choosing the Check Point R70 High-End Security Suite. We hope that you will be satisfied with this security solution and the service that Check Point provides. Check Point delivers Worldwide Technical Services including educational, professional and support services, through a network of authorized training centers, certified support partners, and a variety of Check Point resources.

To obtain more information about this and other security solutions, refer to: http://www.checkpoint.com or call us at 1(800) 429-4391. For additional technical information, refer to: http://support.checkpoint.com.

Welcome to the Check Point family. We look forward to meeting all of your current and future network and application security and management needs.

For New Check Point CustomersFor new Check Point customers, the Check Point User Center can help you:

• Manage Users & 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.

https://usercenter.checkpoint.com/pub/usercenter/get_started.html

https://usercenter.checkpoint.com/pub/usercenter/get_started.html

http://www.checkpoint.com

http://www.checkpoint.com

http://support.checkpoint.com


Who Should Use This Guide

Chapter 1 Introduction 9

Who Should Use This GuideThis guide is intended for administrators responsible for installing and maintaining network security within an enterprise, including policy management and user support.

This guide assumes a basic understanding of

• System and network administration

• The underlying operating system

• Internet protocols (IP, TCP, UDP etc.)

Documentation

10

DocumentationTechnical documentation is available on your distribution High End Security Products Suite CD2 in the CD2\Docs\CheckPoint_Suite. folder. Documentation for Provider-1 also available on C6 in the Internet Security Products Suite.

These documents can also be found at: http://www.checkpoint.com/support/technical/documents.

TABLE P-1 Check Point Documentation

Title Description

Internet Security

Installation and Upgrade

Guide

Contains detailed installation instructions for Check Point network security products. Explains the available upgrade paths from versions R60 to the current version.

High-End Installation and

Upgrade Guide

Contains detailed installation instructions for the 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

Administration Guide

Explains Security Management solutions. This guide provides solutions for control over configuring, managing, and monitoring security deployments.

Firewall Administration

Guide

Describes how to control and secure network access 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.

http://www.checkpoint.com/support/technical/documents


Documentation


Eventia Reporter


Explains how to monitor and audit traffic, and 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/

SecurePlatform Pro


Explains how to install and configure SecurePlatform. This guide will also teach you how to manage your SecurePlatform machine and explains Dynamic Routing (Unicast and Multicast) protocols.

Provider-1/SiteManager-1


Explains the Provider-1 security management 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.

TABLE P-1 Check Point Documentation (continued)

Title Description

Terminology

12

Terminology

Product and Feature NomenclatureThis product version incorporates updated names of some Check Point products and features. These changes are intended to emphasize the enhanced functionality and new features included.

In order to enhance the readability of this guide, we frequently use shortened product names and features in place of the formal name.

Table 1-1

Current Product/Feature Name Previous Name(s)

Check Point Security Gateway VPN-1, VPN-1 Power, VPN-1UTM, FireWall-1

UTM-1 Edge VPN-1 UTM-1 Edge

SmartProvisioning SmartLSM

Endpoint Security Integrity

IPS SmartDefense

Web IPS Web Intelligence

Table 1-2

Short Name Refers to

Provider-1 Both Provider-1 and SiteManager-1 Used in place of ‘Provider-1

SiteManager-1 Text pertaining only to SiteManager-1

Security Gateway Check Point Security Gateway

Provider-1 Terminology


Provider-1 TerminologyThe following Provider-1 terms are used throughout this guide:

Multi-Domain Server (MDS): Contains Provider-1 system information including details of the Provider-1 deployment, its administrators and customer management information. The 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.

Multi Domain GUI (MDG): A computer running one or more of the SmartConsole applications, for example, the Provider-1 MDG.

Multi-Domain Log Module (MLM): A special MDS container that collects and stores logs. It contains multiple Customer Log Modules (CLMs).

Customer Log Module (CLM): A log server for a single customer.

Customer: A distinct network entity managed Provider-1. A customer network is physically separate from other customer networks. Each customer has its own security policy and administrators.

The term ‘customer’ may refer to the following:

• An individual business network administered by a management service provider (a customer of the MSP)

• A branch, department, subsidiary or other subdivision of a large enterprise that manages its own separate network

• Individual network entities in an enterprise data center or individual clients of a data service provider.

Customer Management Add-On (CMA): The Provider-1 equivalent of the Security Management server for a single customer. Through the CMA, an administrator creates security policies and manages the customer gateways.

Provider-1 Terminology

14

Internal Certificate Authority (ICA): The component that creates and manages X.509 compliant certificates for Secure Internal Communication (SIC), site-to-site VPN communication (between Security Gateways), and the authentication of administrators and users.

• The MDS has an ICA that secures the Multiple Domain Server (MDS) domain.

• Each CMA has its own ICA to secure its customer’s management domain.

Provider-1 Administrators: Security administrators assigned granular permissions to manage specific parts of the Provider-1 system. The following permission levels can be assigned:

• Provider-1 Superuser: Manages the entire Provider-1 system, which includes the management of all MDS servers, all administrators (with all permission levels), all customers, and all customer networks.

• Customer Superuser: Manages all administrators (with lower permission levels), all customers, and all customer networks.

• 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 also use the MDG application, however, they can view and manage only those customers that have been specifically assigned to them.

• None: Manages customer networks for specific customers, but cannot access the MDG application.

VSX Terminology


VSX TerminologyThe following terms are used throughout this manual:

Virtual Router: An independent routing domain within a VSX gateway that functions like a physical router. It is used to direct packets arriving at the VSX gateway through a shared interface to the relevant Virtual System or to direct traffic arriving from Virtual Systems to a shared interface or other Virtual Systems.

Virtual Switch: A virtual entity that provides layer-2 connectivity between Virtual Systems and connectivity to a shared interface. As with a physical switch, each Virtual Switch maintains a forwarding table with a list of MAC addresses and their associated ports.

Virtual System: A routing and security domain featuring firewall and VPN capabilities. Multiple Virtual Systems can run concurrently on a single VSX gateway, isolated from one another by their use of separate system resources and data storage.

Supported Upgrade Paths

16

Supported Upgrade PathsManagement servers and gateways exist in a wide variety of deployments. Consult the following tables to determine which versions of your management server and gateways can be upgraded to the current version.

Upgrading Management ServersThe current version supports backward compatibility for the following Security Management Server versions.

Backward Compatibility For GatewaysThe current version supports backward compatibility for the following gateway versions:

CODE EXAMPLE 1-1

Release Version

NGX R65R62R61R60AR60

CODE EXAMPLE 1-2

Release Version


Licensing


LicensingIn This Section

Check Point software is activated with a license key. To obtain a license key, register the certificate key (that appears on the back of the software media pack) with the Check Point User Center. The certificate key is used to generate a license key for the products that you are either evaluating or purchasing.

To purchase the required Check Point products, contact your reseller. Check Point software that has not yet been purchased functions for 15 days only.

Licensing Provider-1Provider-1 licenses are associated with the IP address of the licensed entity. Multi-Domain Server (MDS) licenses are based on the MDS type.

• MDS Manager License: This license covers the administrator access point to the Provider-1 environment and is bound to the MDS manager IP address. The Multi-Domain GUI (MDG) and the Global SmartDashboard tools can connect only to MDS servers having a valid manager license.

• MDS Container License: This license covers the container hosting CMAs running on an MDS machine. A container license is bound to the MDS container IP address and covers a specified maximum number of CMAs. Multiple container licenses can be combined on a given MDS container to cover up to a maximum of 250 CMAs.

• CMA License: Each CMA requires its own license that is bound the its IP address. CMA Pro Add-on licenses, which enable additional management features at the CMA level, can be purchased in bulk and are called Pro Add-ons for MDS.

• MDS Combined Manager and Container License: This license covers an MDS that functions as both a container and manager.

Licensing Provider-1 page 17

Licensing VSX page 18

VSX/CMA Bundle Licenses page 19

The Trial Period page 20

License Violations page 21

Licensing VSX

18

• Customer Log Module License: This license enables real-time logging, tracking and log management for an individual customer and is bound the IP address of to the MDS containing the customer log files.

• Multi-Domain Log Manager (MLM): This is a comprehensive license that covers up to 250 individual Customer Log Modules (CLMs) hosted on a dedicated log server. The license is bound to the log server IP address. There is no need for a separate CLM license if they are hosted on an MLM. A CLM hosted on an MDS server requires its own CLM license.

You can import Provider-1 licenses can using the Check Point command line licensing tool or the MDG. For additional information, refer to the R70 Provider-1/SiteManager-1 Administration Guide.

Licensing VSX

VSX Virtual System LicensesLike physical gateways, VSX Virtual Systems require licenses. Virtual System licenses are associated with VSX Gateway or cluster member IP addresses and are available in packs of 10, 25, 50, 100 and 250 Virtual Systems. You must install one license for the appropriate number of Virtual Systems on each VSX gateway or cluster member. License packs are cumulative up to 250 Virtual Systems.

Virtual Routers and Virtual Switches do not require licenses, and are not counted against the number of permitted Virtual Systems.

Cluster Member Licenses

In a cluster environment, you must install one Virtual System license pack on each member. However, you are only required to install a full license on one member. The second and all subsequent cluster members require a High Availability/Load Sharing license, which is available at a significantly reduced cost. You must, however, have the same number of Virtual System licenses installed on each member.

Management LicenseAppropriate licenses are required for all Security Management servers or for Provider-1 as described in “Licensing Provider-1” on page 17. Management high availability licenses are available for both Security Management and Provider-1.

VSX/CMA Bundle Licenses


IPS License for VSXIPS services provide ongoing, real-time updates and configuration advisories for defenses and security policies. Like Virtual System licenses, IPS services are licensed on a per Virtual System basis. Licenses are renewable annually and are available in packs of 10,25,50,100 and 250 Virtual Systems.

VSX/CMA Bundle LicensesVSX/CMA bundle licenses function as cost-effective combination of Provider-1 CMA licenses and Virtual System licenses. Bundle licenses cover a predefined number of CMAs and Virtual Systems and are available in packs of 10, 25, 50, 100 and 250 CMAs and Virtual Systems.

Each license bundle allows you to define the following, according to its scope:

• Up to (10, 25, 50, 100 or 250) customer CMAs

• Up to (10, 25, 50, 100 or 250) Virtual Systems

The bundle license allows you to define any combination of CMAs and Virtual Systems, providing that the sum total of either does not exceed the maximum. A single CMA can host any number of Virtual Systems up to the license limit. For example, you can define any of the following combinations with a single 10 pack bundle license:

• 10 customer CMAs containing one Virtual System each

• One customer CMA containing 10 Virtual systems

• One CMA containing four Virtual Systems and three CMAs, each containing two Virtual Systems

Note that in each case, you cannot have more than 10 Virtual Systems or 10 CMAs.

You must have the appropriate MDS licenses and customer log module licenses installed in addition to the bundle license. Furthermore, you must have the appropriate licenses installed for each VSX gateway and/or cluster member.

Bundle License Packs are CumulativeThe maximum number of CMAs and Virtual Systems covered by your license is equal to the sum of all bundle license packs installed. For example, if you purchase two 10 license packs and one 50 license pack, you can define up to three CMAs and 70 Virtual Systems. As with individual license packs, you can distribute the Virtual Systems amongst CMAs so long as the cumulative total of CMAs and Virtual Systems does not exceed the maximum.

The Trial Period

20

Limitations of VSX/CMA Bundle Licenses• Bundle licenses only support VSX Virtual Systems. If you wish to mix physical

devices and Virtual Systems on one CMA, you must also add the appropriate regular CMA license as well as the appropriate gateway license for the physical devices.

• Physical devices managed by a mixed CMAs do not use any Virtual System license “slots”. Likewise, Virtual Systems do not use any regular license “slots”.

• In order to use the MDG and global SmartDashboard, you must install a separate Provider-1 manager license.

• You cannot install a bundle license on a system using Provider-1 Enterprise Edition CMAs.

High Availability LicensesProvider-1 supports high availability and Virtual System load sharing. By installing a High Availability VSX-CMA bundle license on a second MDS machine, the specified number of Virtual Systems can be hosted by secondary CMAs. The capabilities and limitations of this license are similar to those of the regular VSX/CMA bundle.

The Trial PeriodWhen installing a Check Point product for the first time, users receive a 15 day trial period, during which the product is fully functional. Once the trial period expires, you must purchase and install the appropriate permanent product licenses. During the trial period, you can define up to 200 CMAs and up to five Virtual Systems per CMA.

To install a VSX bundle license before the trial license expires, you must first disable the trial license. To do so, execute the following command: cpprod_util CPPROD_SetPnPDisable 1.

License Violations


License ViolationsIn the event of a license violation, the following may occur:

• Syslog messages are sent

• Depending on the type of license violation, you may not be able to connect to the MDS using the MDG

• Alerts appear in the MDG. (An indication regarding the nature of the license violation also appears on the MDG status bar)

• Audit entries are generated in SmartView Tracker stating the nature of the violation

• If an MDS is in a license violation state, you cannot define new CMAs, VSX gateways, clusters, or virtual devices

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.

FeedbackCheck Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to:

[email protected]

mailto:[email protected]?subject=Check Point documentation feedback

http://support.checkpoint.com.

http://support.checkpoint.com.

Feedback

22

23

Chapter 2Installing Provider-1

In This Chapter:

Overview page 24

Creating the Provider-1 Environment page 25

Where To From Here? page 39

Overview

24

OverviewA 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 2-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.

Creating the Provider-1 Environment

Chapter 2 Installing Provider-1 25

Creating the Provider-1 EnvironmentIn This Section

This section describes the process for provisioning a Provider-1 environment. The following is a typical workflow:Figure 2-2 Workflow

Setting Up Provider-1 NetworkingThe 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.

Overview page 24

Creating the Provider-1 Environment page 25


Install the Gateways

26

Install the GatewaysInstall 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.

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:

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.

http://supportcontent.checkpoint.com/documentation_download?ID=8753


Installing and Configuring the Primary MDS


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/index.html

Adjust your hardware accordingly.



28

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 VSX gateway for accessing the management server and then OK. The Network Interface Configuration window opens.



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


30

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.



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 34

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

Installing Provider-1 on an MDSTo complete installing Provider-1 on the MDS:

1. On the Provider-1 Welcome screen, enter ‘n’.


32

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?”.

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.

Note - Any information that you enter after this stage can be modified later using the mdsconfig utility.



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

34

Installing SmartConsole and MDG Clients The following instructions are used when installing SmartConsole applications on Windows platforms.

Installing SmartConsoleTo 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 MDGTo 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 MDGTo uninstall an MDS on Linux and Solaris, execute the mds_remove command.

To uninstall the MDG and SmartConsole applications:

From the Windows Start menu, select Settings > Control Panel > Add/Remove Programs.

Note - This command is not available on SecurePlatform.

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 MDGTo 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 2-3 MDG before Customers are added

Adding Licenses using the MDG

36

Demo ModeWhen 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.

Adding Licenses using the MDGTo add a license to an MDS or MLM using the MDG:

1. In the MDG, Select the General View and the MDS Contents page.



2. Double-click on an MDS or MLM. The MDS Configuration window opens.

3. Select the License tab.


38

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.

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 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?

40

41

Chapter 3Installing VSX

In This Chapter:

Installing VPN-1 Power VSX page 42


Installing VPN-1 Power VSX

42

Installing VPN-1 Power VSX In This Section:

This section describes how to install the VPN-1 Power VSX R65 on SecurePlatform.

Installing VPN-1 Power VSX on SecurePlatformTo install VPN-1 Power VSX on SecurePlatform:

1. Insert the SecurePlatform VSX distribution CD into the CD-ROM drive and reboot the computer. The following welcome message appears:

2. Press Enter to start the installation. If you choose not to continue, you are asked to remove the CD and to reboot.

Installing VPN-1 Power VSX on SecurePlatform page 42

First Time Login page 47

Initial Configuration page 47

Installing VPN-1 Power VSX on SecurePlatform

Chapter 3 Installing VSX 43

3.

4. After the computer has been scanned for hardware compatibility, the main Welcome window appears.


44

If hardware incompatibilities are detected, the details are displayed as part of the welcome message, as in the following example:

If a hardware device on the target computer is unsuitable, select Device List to display the list of discovered hardware. Compare this list against the Hardware Compatibility list at:


Upgrade your hardware as required.

If your hardware is suitable proceed to the next step.

5. In the Keyboard Selection window, select the keyboard language.

6. In the Networking Device window, select an interface to be the management interface.




7. In the Network Interface Configuration window, enter the IP address, net mask, and optionally, the default gateway in the designated fields.

8. In the Host Name Configuration window, enter a host name for your VSX gateway.


46

9. In the Confirmation window, select OK to proceed or Cancel to abort the installation process. This procedure can last 10-12 minutes.

10. When the Installation Complete window opens, select OK to complete the installation. The system reboots automatically. Remove the CD-ROM used during the installation process.

First Time Login


First Time LoginTo log in for the first time:

1. Log in and start the configuration in one of the following ways:

• Using a keyboard and monitor directly attached to the SecurePlatform machine.

• Using a serial console and a remote terminal.

• Using an SSH Client connected to the interface and IP address,

2. Log in using the following first time default login parameters:

• Login: type admin.

• Password: type admin again as your password.

3. Change the default password in the Enter New Password and Enter New Password (again) fields to a password of your own.

4. Once the password has been changed, the SecurePlatform interactive shell prompt is displayed.

5. Use the sysconfig command to set the local time and the correct time zone.

Initial Configuration You use the cpconfig command to perform the initial VSX configuration.

To perform the initial configuration:

1. Run the cpconfig command at the VSX gateway command prompt.

2. Read and accept the license agreement.

3. Indicate whether you want to install a Check Point clustering product.

4. Indicate whether you want to enable the SecureXL acceleration feature.

5. Indicate whether you want to enable Check Point Per Virtual System State (Required for Virtual System Load Sharing).

6. Optionally, add a license manually or by retrieving a license file. You may find it easier to skip this step and add licenses later using the GUI client.

7. Configure Secure Internal Communication (SIC) by entering an activation key. Enter any series of numbers and characters. You will need this key in order to establish trust between the VSX gateway and the management server.

8. Reboot the gateway.

Where To From Here?

48

Where To From Here?You can be manage a VSX gateway using a Security Management server or a Provider-1 CMA.

You have now performed the basic steps that you need to get started. The next step is to perform the following operations on the management server:

• Create VSX gateway and/or VSX cluster objects using the management server.

• Create Virtual Systems and other virtual network devices on the management server.

• Create and install security policies on your gateways, clusters, Virtual Systems and other virtual network objects.

49

Chapter 4Upgrading Provider-1

In This Chapter

Introduction page 50

Provider-1 Upgrade Tools page 51

Provider-1 Upgrade Practices page 64

Upgrading a Multi-MDS System page 73

Restarting CMAs page 76

Restoring Your Original Environment page 77

Renaming Customers page 78

Changing the MDS IP Address and External Interface page 82

IPS in Provider-1 page 83

Introduction

50

IntroductionThis chapter describes methods and utilities for upgrading Provider-1 to the current version.

In This Section

Supported Versions and PlatformsThe direct upgrade of the MDS to the current version is supported from the following versions:

The latest information regarding supported platforms is always available in the Check Point Release Notes at http://support.checkpoint.com.

Before You BeginBefore 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 73”.

Supported Versions and Platforms page 50

Before You Begin page 50

Release Version





Provider-1 Upgrade Tools

Chapter 4 Upgrading Provider-1 51

Provider-1 Upgrade ToolsThis 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 UtilitiesBefore 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.

Pre-Upgrade Verifiers and Fixing Utilities page 51

Installation Script page 52

export_database page 53

migrate_assist page 56

cma_migrate page 57

migrate_global_policies page 62

Backup and Restore page 62

Installation Script

52

Installation ScriptUse the mds_setup installation script for MDS.

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.

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

export_database


Pre-Upgrade Verification OnlyPre-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.

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

BackupPrior 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 82.

export_databaseThe 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

54

• 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, http://support.checkpoint.com.

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:

• Exporting a Security Management server:

• Exporting an MDS global database:

./export_database.sh <path for the output file> –c <name of CMA>

./export_database.sh <path for the output file>

./export_database.sh <fully qualified path for the output file> –g


merge_plugin_tables


Other flags:

Example• To export the database of a CMA, CMA1, including its log database to a file path,

/var/tmp, use the following command:

• To export a Security Management database, including its Smartmap database, to a file path, /var/tmp, use the following command:

• To export an MDS’s Global Policy to a file path, /var/for_export, use the following command:

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

Table 4-1 export_database flags

Flag Meaning

-h Display usage

-b Batch mode

-l Include the log database

-m Include the SmartMap database

./export_database.sh /var/tmp –c CMA1 -l

./export_database.sh /var/tmp -m

./export_database.sh /var/for_export –g

migrate_assist

56

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, http://support.checkpoint.com.

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.

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

ExampleTo merge the plug-in tables of a CMA, CMA1, run the following commands:

migrate_assistThis 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 57), 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 53 for more information.

mdsenv cma1merge_plugin_tables -p "$FWDIR"

Note - Before running migrate_assist, stop source management processes and merge plug-in tables.


cma_migrate


Usagemigrate_assist <source machine name/ip> <source FWDIR folder> <user name> <password> <target folder> <source CPDIR folder>

ExampleTo import a Security Management server with the IP address 192.168.0.5 of version NGX R60, use the following command:

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.

cma_migrateThis 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 50.

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.

migrate_assist 192.168.0.5 /opt/CPsuite-R60/fw1 FTP-user FTPpass /EMC1 /opt/CPshrd-R60

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

58

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.

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.

Usagecma_migrate <source management directory path> <target CMA FWDIR directory>

Note - The registry directory is required only if you are upgrading from version R70 or higher.

cma_migrate


Example

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 4-2.

The second argument (<target CMA FWDIR directory>) is the FWDIR of the newly created CMA.

Additional InformationWhen 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 /tmp/exported_smc.22Jul2007-224020.tgz /opt/CPmds-FLO/customers/cma2/CPsuite-FLO/fw1

Table 4-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.

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.

cma_migrate

60

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

message URL http://supportcontent.checkpoint.com/solutions?id=sk17197

message URL http://supportcontent.checkpoint.com/solutions?id=sk17197

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

62

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

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

Backup and RestoreThe 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 82” 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.

Note - When executing the migrate_global_policies utility, the MDS will be stopped. The CMAs can remain up and running.

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


mds_backupThis 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_restoreRestores 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

64

Provider-1 Upgrade PracticesIn This Section

In-Place UpgradeThe in-place upgrade process takes place on the existing MDS machine. The MDS with all CMAs are upgraded during a single upgrade process.

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 72 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 52).

• For SecurePlatform, run patch add cd (See “Upgrading to R70 on SecurePlatform” on page 65).

6. After the upgrade completes, retest using the sub-steps in step 3 above.

In-Place Upgrade page 64

Replicate and Upgrade page 66

Gradual Upgrade to Another Machine page 67

Migrating from Security Management to a CMA page 69

Note - When upgrading Provider-1, all SmartUpdate packages on the MDS (excluding SofaWare firmware packages) are deleted from the SmartUpdate Repository.

In-Place Upgrade


Upgrading to R70 on SecurePlatformThis 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

66

Replicate and UpgradeChoose 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.

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 82 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 82 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 64).

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.

Gradual Upgrade to Another Machine


Gradual Upgrade to Another MachineIn 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 53. 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 57.

6. Start the CMA and run:

mdsenvmdsstart

7. Use migrate_global_policies to import the global policies.

Gradual Upgrade to Another Machine

68

Gradual Upgrade with Global VPN ConsiderationsA 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.

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

Migrating from Security Management to a CMAThis 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.

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.

Note - If you want the option to later undo the separation process, back up the standalone gateway before migrating.


70

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.



20. Install the Policy on the gateway.

Upgrading in a Multi-MDS Environment

72

Upgrading in a Multi-MDS EnvironmentIn This Section

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 ToolsRun 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 51). Start upgrading the first MDS, only after you have fixed all the errors and reviewed all the warnings on all your MDSes.

Pre-Upgrade Verification and Tools page 72

Upgrading a Multi-MDS System page 73

Upgrading a Multi-MDS System



In This Section

MDS High AvailabilityCommunication 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.

MDS High Availability page 73

Before the Upgrade page 74

After the Upgrade page 74

CMA High Availability page 75

Note - MLMs in a multi-MDS system need to be upgraded to the same version as the Manager and Container MDSs.


74

Before the Upgrade1. 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.

After the UpgradeAfter 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:

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.



$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 AvailabilityCMA 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 57).

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

Note - Before migrating, all the objects representing the secondary management should be deleted from the primary Security Management server.

Restarting CMAs

76

Restarting CMAs After completing the upgrade process, CMAs should be started sequentially using the command mdsstart -s.

Restoring Your Original Environment


Restoring Your Original EnvironmentIn This Section

Before the UpgradePre-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.

Restoring Your Original EnvironmentTo 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.

Before the Upgrade page 77

Restoring Your Original Environment page 77

Renaming Customers

78

Renaming CustomersIn This Section

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 NamesThe 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 EnvironmentIn 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 NamesIf 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.

Identifying Non-Compliant Customer Names page 78

High Availability Environment page 78

Automatic Division of Non-Compliant Names page 78

Resolving Non-Compliance page 79

Advanced Usage page 80

Resolving Non-Compliance


Resolving Non-ComplianceDuring 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.

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

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

Note - Nothing is changed in the existing installation when translating customer names. Any changes are applied only to the upgraded installation.

Note - The pre-upgrade tool allows only non-compliant customer names to be translated.

Advanced Usage

80

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 UsageAn 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 4-3 Line Prefixes

Line Prefix Meaning Comment

# A comment line. May be inserted anywhere.

- Existing non-compliant name.

Must exactly match an existing non-compliant name, otherwise it will be rejected.

+ A translation for the preceding '-' line.

If the entry does not comply with the naming restrictions, it is ignored.

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

82

Changing the MDS IP Address and External Interface

In This Section

IP Address ChangeIf 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 ChangeIf 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.

IP Address Change page 82

Interface Change page 82

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

84

85

Chapter 5Upgrading VSX

In This Chapter

Upgrade Overview page 86

Upgrading the Management Server page 87

Upgrading VSX Gateways page 88

Upgrading VSX Clusters page 91

Upgrade Overview

86

Upgrade OverviewThis guide describes the upgrade path to VPN-1 Power VSX NGX R65 for both Security Management server and Provider-1 environments. The upgrade process consists of several procedures which must be performed in sequence:

1. Upgrading the management server (Security Management or Provider-1) to R70

2. Installing the GUI Clients

3. Upgrading the VSX gateway and/or cluster

Each procedure is described in its own section.

Upgrading the Management Server

Chapter 5 Upgrading VSX 87

Upgrading the Management ServerThis section presents procedures for upgrading your Security Management servers to version VSX. You can upgrade R60, R60A, R61 and R62 management servers to the current version.

Before UpgradingBackup your existing SmartCenter servers (known Management Security servers in R70) before starting the upgrade process. This will allow you to restore your servers to their pre-installation state in the event that you encounter problems.

The Upgrade ProcessThe procedures for upgrading to the current Security Management or Provider-1 version are specific for your platform and your version.

- To upgrade your current SmartCenter server to Security Management Server version R70, please follow the instructions presented in the Internet Security Products Installation and Upgrade guide

- To upgrade your Provider-1 system, follow the instructions presented in Chapter 4, “Upgrading Provider-1”.



Upgrading VSX Gateways

88

Upgrading VSX GatewaysThe process for upgrading VSX gateways to VSX involves two procedures:

1. Creating a fresh installation of the current SecurePlatform version on a new or existing VSX gateway computer.

2. Transferring the configuration settings and security policies from the management database to the upgraded gateway.

Use the vsx_util upgrade command to upgrade VSX gateways. The vsx_util command applies settings stored in the existing management database (Security Management server or Provider-1 MDS) to newly created gateways.

Before UpgradingBefore upgrading the VSX gateway, perform the following steps:

1. Upgrade your management server to the current version.

2. If you intend to use a different computer for the upgraded gateway:

- Make sure the new machine meets the minimum hardware requirements as defined in the Check Point R70 Release Notes.

- Make sure that the new computer contains at least the same number of interfaces as the old computer, and that the VSX gateway is accessible from the management server.

3. If you intend to use the same machine, backup the current gateway database to a safe location on another computer. For detailed information on backing up a VSX gateway, see the backup and restore section of the SecurePlatform Administration Guide.

Installing SecurePlatformTo perform a fresh installation of the current Secure platform version on a new or existing computer. Follow the procedures outlined in Chapter 3, “Installing VSX”.



Performing the Upgrade


Performing the UpgradeThis section describes the procedures for upgrading VSX gateways from earlier versions. using the vsx_util upgrade command. Afterwards, use the vsx_util reconfigure command to apply settings stored in the management database to the newly upgraded gateway.

Upgrading VSX Gateways

Performing the following steps to upgrade the VSX gateway:

1. Close SmartDashboard. Close all Provider-1 CMAs containing Virtual Systems or other VSX virtual objects.

2. Execute the vsx_util upgrade command from the management server command line.

Enter the following information when prompted:

a. Security Management server or CMA IP address

b. Administrator name and password

c. VSX Gateway name

3. When prompted, select the version to which you wish to upgrade.

4. Wait until the Finished upgrading/database saved successfully message appears, indicating that the database has been updated and saved.

5. Open SmartDashboard and verify that new gateway object appears.

6. Execute the vsx_util reconfigure command from the management server command line. Enter the following information when prompted:

a. Management server or CMA IP address


c. VSX Gateway name

d. SIC activation key for the upgraded gateway

Warning - Verify that no other administrators are connected to the management server before proceeding. The vsx_util command cannot modify the management database if the database is locked.

Note - In a Provider-1 environment, the operation will skip any CMAs locked by an administrator. If this should occur, run the operation again for the relevant CMAs when they become available.


90

This action installs the existing security policy and configuration on to the newly upgraded gateway.

7. Wait until the Finished upgrading/database saved successfully message appears.

8. Reboot the new or upgraded VSX gateway.

Resume OperationIf the upgrade operation fails to complete during the reconfigure stage, you have the option to resume the process from the point at which if failed. For example, if the user is reconfiguring a gateway, and a policy installation is also taking place simultaneously, the operation will not complete, and needs to be resumed later.

• Resume is available only for the reconfigure option.

• If the upgrade operation still cannot complete successfully, execute the vsx_util upgrade command again.

Notes to the Upgrade Process• Use the fw vsx stat -v command to verify that the upgraded gateway

is operational before upgrading any other gateways.

• All operations performed using vsx_util are logged to vsx_util.log. This file is located in the same directory from which you ran the vsx_util command. The previous log file in this location will be overwritten.


Upgrading VSX Clusters


Upgrading VSX ClustersThe process for upgrading VSX clusters to VSX involves two primary procedures:

1. Creating a fresh installation of VSX SecurePlatform on each member machine.

2. Transferring configuration settings and security policies from the management database to the cluster members.

You use the vsx_util upgrade command to upgrade VSX cluster objects to the current version. The vsx_util reconfigure command applies settings stored in the existing management database (Security Management server or Provider-1 MDS) to newly created clusters and members.

Before UpgradingBefore upgrading the VSX cluster, perform the following:

1. Make sure that you have successfully upgraded you management server to the current version.

2. Upgrade your licenses from previous VSX versions as required.

3. If you intend to use a different machine for the upgraded gateway:

- Make sure the new machine meets the minimum hardware requirements as defined in the Check Point Suite Release Notes.

- Make sure the new machine contains at least the same number of interfaces as the old machine, and that the VSX gateway is accessible from the management server.

4. If you intend to use the same computer, backup the current VSX gateway, and save the configuration file to a safe location. For detailed information on backing up a VSX gateway, see the backup and restore section of the SecurePlatform Administration Guide.

5. Perform a fresh install of VSX on each gateway or cluster member and then perform the initial configuration steps as described in “Installing VPN-1 Power VSX” on page 42.



92

Performing the UpgradeThis section describes the procedures for upgrading clusters from an earlier VSX version to the current version. You perform the upgrade process using the vsx_util upgrade command. Afterwards, you use the vsx_util reconfigure command to apply settings stored in the management database to the newly upgraded member.

Upgrading to VSX

Performing the following steps to upgrade the cluster and its members:

1. Close SmartDashboard.

2. Upgrade the cluster object to the current version. To do so, run the vsx_util upgrade command from the management server command line.

Enter the following information when prompted:

a. Security Management server or CMA IP address


c. Cluster name

3. When prompted, select the version to which you plan to upgrade.

4. Wait until the Finished upgrading/database saved successfully message appears, indicating that the database has been updated and saved.

5. Open SmartDashboard and verify that an object representing the new cluster now appears in the specified cluster.

Warning - Make sure that no other administrators are connected to the management server before proceeding. The vsx_util command cannot modify the management database if the database is locked.




6. Run the vsx_util reconfigure command from the management server command line for each member. Enter the following information when prompted:

a. Management server or CMA IP address


c. Member object name

d. SIC activation key for the upgraded member

This action installs the existing security policy and configuration on the newly upgraded members.

7. Wait until the Finished upgrading/database saved successfully message appears.

8. Reboot the member.

9. Repeat steps 6 through 8 for each member.

Resume OperationIf the upgrade operation fails to complete during the reconfigure stage, you have the option to resume the process from the point at which if failed. For example, if the user is reconfiguring the gateway of a cluster, and a policy installation is also taking place on one of the gateway, the operation will not complete, and needs to be resumed later.

• Resume is available only for the reconfigure option.

• If the upgrade operation does not complete, the user must run the upgrade option of the vsx_util command again.



94

Notes to the Upgrade Process• You only need to run the vsx_util upgrade command once for each VSX

cluster. You must, however, run the vsx_util reconfigure command for each cluster member.

• For example, for a deployment with two clusters, each cluster having three members, run vsx_util upgrade twice, once for each cluster object, and the vsx_util reconfigure six times, once for each cluster member.

• To ensure the stability of the VSX deployment, it is recommended that you upgrade one cluster object and all of its members before attempting to upgrade another cluster. Execute vsx_util upgrade for one cluster object and then immediately execute vsx_util reconfigure for its members.

• Verify that each upgraded member is fully operational before upgrading the remaining members.

• All operations performed using vsx_util are logged to: vsx_util.log. This file is created in the same directory from which you ran the vsx_util command. The previous log file in this location will be overwritten.

Documents

CP R70 High-End Installation and UpgradeGuide