Sie sind auf Seite 1von 192

The Upgrade Guide

NGX (R60)

For additional technical information about Check Point products, consult Check Points SecureKnowledge at

https://secureknowledge.checkpoint.com
See the latest version of this document in the User Center at:

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

Part Number 701313 May 2005

2003-2005 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:
2003-2005 Check Point Software Technologies Ltd. All rights reserved. Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone Labs logo, are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.

THIRD PARTIES:
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrusts logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust. Verisign is a trademark of Verisign Inc. The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided as is without express or implied warranty. Copyright Sax Software (terminal emulation only). The following statements refer to those portions of the software copyrighted by Carnegie Mellon University. Copyright 1997 by Carnegie Mellon University. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The following statements refer to those portions of the software copyrighted by The Open Group. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group. The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. GDChart is free for use in your applications and for chart generation. YOU MAY NOT redistribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999,

Check Point Software Technologies Ltd.


U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com

2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson (ellson@graphviz.org). Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http:/ /www.apache.org/licenses/LICENSE-2.0 The curl license COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. The PHP License, version 3.0 Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net. 4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo" 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License. 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes PHP, freely available from <http://www.php.net/>". THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at group@php.net. For more information on the PHP Group and the PHP project, please see <http:// www.php.net>. This product includes the Zend Engine, freely available at <http:// www.zend.com>. This product includes software written by Tim Hudson (tjh@cryptsoft.com). Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Copyright 2003, 2004 NextHop Technologies, Inc. All rights reserved. Confidential Copyright Notice Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are breached. Upon termination, any downloaded and printed materials must be immediately destroyed. Trademark Notice The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution of, or access to, materials in this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 222 1600.

U.S. Government Restricted Rights The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in DataGeneral clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987). Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of the original creator. The Contractor/ Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations. Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRAN-TIES, EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHER-WISE RESPECTING, THE MATERIAL IN THIS DOCUMENT. Limitation of Liability UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSE-QUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU. Copyright ComponentOne, LLC 1991-2002. All Rights Reserved. BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")) Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release

Table Of Contents
Chapter 1 Introduction to the Upgrade Process
Upgrading Successfully 9 Documentation 10 NGX License Upgrade 11 Supported Upgrade Paths and Interoperability 12 Obtaining Software Installation Packages 13 Terminology 13 Upgrade Tools 15

Chapter 2

Upgrading VPN-1 Pro/Express Licenses


Overview of NGX License Upgrade 18 Introduction to License Upgrade in VPN-1 Express/Pro Environments 18 Software Subscription Requirements 18 Licensing Terminology 19 The License_Upgrade Tool 20 Tool Location 20 Tool Options 20 Simulating the License Upgrade 21 Performing the License Upgrade 23 License Upgrade Methods 23 Deployments with Licenses Managed Centrally Using SmartUpdate 25 Deployments with Licenses Managed Locally 31 Trial Licenses 34 Troubleshooting License Upgrade 35 Error: License version might be not compatible 35 Evaluation Licenses Created in the User Center 36 Evaluation Licenses Not Created in the User Center 36 Licenses of Products That Are Not Supported in NGX 37 License Enforcement on Module is now on Management 37 License Not in Any Of Your User Center Accounts 38 User Does Not Have Permissions on User Center Account 39 SKU Requires Two Licenses in NG and One License in NGX 39 SmartDefense Licenses 40 License Upgrade Partially Succeeds 40 Upgraded Licenses Do Not Appear in the Repository 41 License Upgrade Status Action Reports Wrong Results 41 Cannot Connect to the User Center 42

Chapter 3

Backup and Revert for VPN-1 Pro/Express


Introduction 45 Backup your Current Deployment 46
Table of Contents 5

Restore a Deployment 46 SecurePlatform Backup and Restore Commands 46 Backup 47 Restore 48 SecurePlatform Snapshot Image Management 49 Snapshot 49 Revert 50 Revert to your Previous Deployment 50

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment


Introduction 55 Pre-Upgrade Considerations 56 License Upgrade to NGX R60 56 Web Intelligence License Enforcement 56 Upgrading Products on a SecurePlatform Operating System 57 VPN-1 Edge/Embedded Gateways Prior to Version 5.0 57 Reverting to your Previous Software Version 57 Upgrading the SmartCenter Server Component 58 Using the Pre Upgrade Verification Tool 59 Upgrading a SmartCenter High Availability Deployment 60 SmartCenter Upgrade on a Windows Platform 61 SmartCenter Upgrade on SecurePlatform R54, R55 and Later Versions 62 SmartCenter Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 63 SmartCenter Server Upgrade on a Solaris Platform 64 SmartCenter Upgrade on an IPSO Platform 65 Migrate your Current SmartCenter Configuration and Upgrade 67 Upgrading the Enforcement Module 70 Upgrading a Clustered Deployment 71 Upgrading the Enforcement Module Using SmartUpdate 71 Enforcement Module Upgrade Process on a Windows Platform 75 Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions 76 Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 77 Enforcement Module Upgrade on a Solaris Platform 79 Enforcement Module Upgrade on an IPSO Platform 80

Chapter 5

Upgrading a Standalone VPN-1 Pro/Express Deployment


Introduction 83 Pre-Upgrade Considerations 84 License Upgrade to NGX 84 Upgrading Products on a SecurePlatform Operating System 85 Reverting to your Previous Software Version 85 Using the Pre-Upgrade Verification Tool 85 Standalone VPN-1 Gateway Upgrade on a Windows Platform 87 Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions 88 Standalone VPN-1 Gateway Upgrade on SecurePlatform NG FP2, FP3, FP3 Edition 2 89 Standalone VPN-1 Gateway Upgrade on a Solaris Platform 90 Standalone VPN-1 Gateway Upgrade on an IPSO Platform 91 Migrate your Current VPN-1 Gateway Configuration and Upgrade 93

Chapter 6

Upgrading ClusterXL
License Upgrade to NGX 95 Tools for Gateway Upgrades 95 Planning a Cluster Upgrade 97 Upgrading a Clustered Deployment with Cluster Members from Different Versions 97 Upgrading OPSEC Certified Third Party Clusters Products 98 Performing a Minimal Effort Upgrade on a ClusterXL Cluster 98 Performing a Zero Down Time Upgrade on a ClusterXL Cluster 98 Supported Modes 98 Performing a Full Connectivity Upgrade on a ClusterXL Cluster 102 Understanding a Full Connectivity Upgrade 102 Supported Modes 102 Terminology 102 Implementing a Full Connectivity Upgrade 103

Chapter 7

Upgrading Provider-1
Introduction 108 Scope 108 Before You Begin 108 Supported Platforms 109 Supported Versions for Upgrade 109 Summary of Sections in this Chapter 109 Provider-1/SiteManager-1 Upgrade Tools 111 Pre-Upgrade Verifiers and Fixing Utilities 111 Installation Script 112 pv1_license_upgrade 113 license_upgrade 114 cma_migrate 115 migrate_assist 117 migrate_global_policies 117 Backup and Restore 118 Provider-1/SiteManager-1 License Upgrade 120 Overview of NGX License Upgrade 121 Introduction to License Upgrade in Provider-1 Environments 122 Software Subscription Requirements 122 Understanding Provider-1/SiteManager-1 Licenses 122 Before License Upgrade 124 Choosing The Right License Upgrade Procedure 129 License upgrade of Entire System Before Software Upgrade 131 License Upgrade of Entire System Using Wrapper 134 License upgrade of Entire System After Software Upgrade 135 License Upgrade for a Single CMA 138 License Upgrade Using the User Center 144 SmartUpdate Considerations for License upgrade 144 Troubleshooting License Upgrade 145 Provider-1/SiteManager-1 Upgrade Practices 150 In-place Upgrade 150 Replicate and Upgrade 152

Table of Contents 7

Gradual Upgrade to Another Machine 153 Migrating from a Standalone Installation to CMA 156 MDS Post Upgrade Procedures 160 Upgrading in a Multi MDS Environment 161 Pre-Upgrade Verification and Tools 161 Upgrading an NG with Application Intelligence Multi-MDS System 161 Restoring your Original Environment 164 Before the Upgrade 164 Restoring your Original Environment 165 Renaming Customers 165 Identifying Non-Compliant Customer Names 165 High-Availability Environment 166 Automatic Division of Non-compliant Names 166 Resolving the Non-compliance 166 Advanced Usage 167 Changing MDS IP address and External Interface 169 IP Address Change 169 Interface Change 170

Chapter 8

Upgrading SmartLSM ROBO Gateways


Planning the ROBO Gateway Upgrade 171 Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository 172 License Upgrade for a ROBO Gateway 172 Using SmartLSM to Attach the Upgraded Licenses 172 License Upgrade on Multiple ROBO Gateways 173 Upgrading a ROBO Gateway Using SmartLSM 173 Upgrading a VPN-1 Express/Pro ROBO Gateway 173 Full Upgrade 174 Specific Installation 174 Upgrading a VPN-1 Edge ROBO Gateway 175 Upgrading a VPN-1 Express/Pro ROBO Gateway In Place 176 Using the Command Line Interface 177 SmartLSM Upgrade Tools 177 Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli 178 Upgrading a VPN-1 Edge ROBO Gateway Using LSMcli 179 Using the LSMcli in Scripts 180

Chapter 9

Upgrading VSX SmartCenter Management


Before You begin 183 License Upgrade 184 Tools for Upgrading a SmartCenter 184 Supported VSX Upgrade Paths 186 Upgrading VSX NG AI to NGX R60 SmartCenter 186 Upgrading VSX NG AI R2 to NGX R60 SmartCenter 187 Supported VSX Upgrade Procedures 188 Advanced Upgrade Procedures 188 Export and Import Commands 189

CHAPTER

Introduction to the Upgrade Process


In This Chapter
Upgrading Successfully Documentation NGX License Upgrade Supported Upgrade Paths and Interoperability Obtaining Software Installation Packages Terminology Upgrade Tools page 9 page 10 page 11 page 12 page 13 page 13 page 15

Upgrading Successfully
All successful upgrades begin with a solid game plan and a full understanding of the steps you need to follow in order to succeed. This book provides tips and instructions to make the upgrade process as clear as possible. It is not necessary to read the entire book. In fact, there may be large portions of this guide that may not apply to you. The guide is structured to sections of typical deployments for easy navigation. We hope that your upgrade goes smoothly but in the event that you run into unexpected snags, please contact your Reseller or our SecureKnowledge support center at: https://secureknowledge.checkpoint.com

Documentation

Documentation
This guide was created to explain all available upgrade paths for Check Point products from FireWall-1 NG forward. This guide is specifically geared towards upgrading to NGX R60. Before you begin please: Make sure that you have the latest version of this document in the User Center at 0http://www.checkpoint.com/support/technical/documents/docs_r60.html It is a good idea to have the latest version of the NGX R60 Release Notes handy. Download them from: http://www.checkpoint.com/support/technical/documents/docs_r60.html For a new features list refer to the NGX R60 Whats New Guide: http://www.checkpoint.com/support/technical/documents/docs_r60.html

10

NGX License Upgrade


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. The license upgrade procedure can be performed if you have purchased any of the Enterprise Software Subscription services. License upgrade will fail for products and accounts for which you do not have software subscription. Login to http://usercenter.checkpoint.com to manage your accounts, licenses, and Enterprise Support Programs coverage (under Support Programs). License upgrade is performed by means of an easy to use tool that automatically upgrades both locally and centrally managed licenses. Using the tool you can upgrade all licenses in the entire managed system. License upgrade can also be done manually, per license, in the User Center. The automatic license upgrade tool allows you to: 1 View the status of the currently installed licenses. On a SmartCenter server (or a CMA, for Provider-1), you can also view the licenses in the SmartUpdate license repository. Simulate the license upgrade process. Perform the actual license upgrade process.

2 3

During the license upgrade, all eligible licenses are gathered and sent in SSL encrypted format to the User Center. Upgraded licenses are returned from the User center, and automatically installed. The license upgrade process adds only NGX licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses, or licenses that pertain to IP addresses no longer used) remain untouched. When running on a SmartCenter Server (or a CMA, for Provider-1), the license upgrade process also handles licenses in the SmartUpdate license repository. After the software upgrade, SmartUpdate is used to attach the new NGX licenses to the gateways. License upgrade for VPN-1 Pro/Express deployments is described in chapter 2, Upgrading VPN-1 Pro/Express Licenses on page 17. License upgrade for Provider-1 deployments is described in Provider-1/SiteManager-1 License Upgrade on page 120. License upgrade for SmartLSM deployments is described in License Upgrade for a ROBO Gateway on page 172. It is recommended to check http://www.checkpoint.com/techsupport/ngx/license_upgrade.html for up to date information and downloads regarding NGX license upgrade.

Chapter 1

Introduction to the Upgrade Process

11

Supported Upgrade Paths and Interoperability

Supported Upgrade Paths and Interoperability


Upgrading to NGX R60 is supported on the following versions: NG NG FP1 NG FP2 NG FP3 NG With Application Intelligence R54 NG With Application Intelligence R55 NG R55W GX 2.5 VSX NG AI VSX NG AI Release 2 Backward compatibility to NGX R60 is supported on the following versions: NG FP3 NG With Application Intelligence R54 NG With Application Intelligence R55 NG R55W GX 2.5 VSX NG AI VSX NG AI Release 2 Upgrading from versions prior to NG (4.0-4.1) is not supported. In order to upgrade FireWall-1 versions 4.0-4.1, upgrade the installed version to VPN-1 NG R55 (refer to the NG with Application Intelligence R55 Upgrade Guide). Once the VPN-1 NG R55 upgrade is complete, perform an upgrade to NGX R60.

12

Obtaining Software Installation Packages


NGX R60 software installation packages for Solaris, Windows, Linux and SecurePlatform are available on the product CD. NGX R60 software packages for Nokia IPSO 3.9 are available at the online download center in the following location: http://www.checkpoint.com/techsupport/downloads.jsp

Terminology
Security Policy - A Security Policy is created by the system administrator in order to regulate the incoming and outgoing flow of communication. Enforcement Module - An Enforcement module is the VPN-1 Pro engine which actively enforces the Security Policy of the organization. SmartCenter Server - The SmartCenter Server is used by the system administrator to manage the Security Policy. The databases and policies of the organization are stored on the SmartCenter Server, and are downloaded from time to time to the Enforcement modules. SmartConsole Clients - The SmartConsole Clients are GUI applications which are used to manage different aspects of the Security Policy. For instance SmartView Tracker is a GUI client used to view logs. SmartDashboard - a GUI client that is used to create Security Policies. Check Point Gateway - otherwise known as an Enforcement module or sometimes module is the VPN-1 Pro engine that actively enforces your organizations Security Policy. SmartUpdate - allows you to centrally upgrade and manage Check Point software and licenses. Package Repository - This is a SmartUpdate repository on the SmartCenter Server that stores uploaded Packages. These packages are then used by SmartUpdate to perform upgrades of Check Point Gateways. Standalone Deployment - A Standalone deployment is performed when the Check Point components that are responsible for the management of the Security Policy (the SmartCenter Server and the Enforcement Module) are installed on the same machine. Distributed Deployment - A Distributed deployment is performed when the Enforcement Module and the SmartCenter Server are deployed on different machines.

Chapter 1

Introduction to the Upgrade Process

13

Terminology

Advanced Upgrade - In order to avoid unnecessary risks, it is possible to migrate the current configuration to a spare server. Once this is completed an upgrade process should be performed on the migrated server, leaving the production server intact. In Place Upgrade - In Place upgrades are upgrades performed locally. ClusterXL - is a software-based load sharing and high availability solution for Check Point gateway deployments. It distributes traffic between clusters of redundant gateways so that the computing capacity of multiple machines may be combined to increase total throughput. In the event that any individual gateway becomes unreachable, all connections are re-directed to a designated backup without interruption. Tight integration with Check Point's SmartCenter management and enforcement point solutions ensures that ClusterXL deployment is a simple task for VPN-1 Pro administrators. ROBO Gateways - A Remote Office/Branch Office Gateway. ROBO Profile - An object that you define to represent properties of multiple ROBO Gateways. Profile objects are version dependent; therefore, when you plan to upgrade ROBO Gateways to a new version, first define new Profile objects for your new version. In general, you will want to keep the Profile objects of the previous versions until all ROBO Gateways of the previous version are upgraded to the new version. For further information about defining a ROBO Profile see the Defining Policies for the Gateway Profile Objects chapter in the SmartLSM Guide. LSM - Large Scale Manager. SmartLSM enables enterprises to easily scale, deploy and manage VPNs and security for thousands of remote locations. Management Virtual System (MVS) is a default Virtual System created by the VSX installation process during installation. The MVS: Handles provisioning and configuration of Virtual Systems and Virtual Routers. Manages Gateway State Synchronization when working with clusters. Virtual Routers are independent routing domains within a VSX Gateway that function like physical routers. VSX Clustering involves connecting two or more VSX Gateways in such a way that if one fails, another immediately takes its place. A single VSX Gateway contains multiple Virtual Routers and Virtual Systems. Virtual System is a routing and security domain featuring firewall and VPN capabilities supported by a standard Check Point Gateway. 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.

14

Upgrade Tools
Various upgrade tools are provided for migration and compatibility verification of your current deployment. These tools will help you successfully upgrade to NGX R60. The upgrade tools can be found in the following locations: in the NGX R60 $/FWDIR/bin/upgrade_tools directory. http://www.checkpoint.com/techsupport/ngx/utilities.html

Chapter 1

Introduction to the Upgrade Process

15

Upgrade Tools

16

CHAPTER

Upgrading VPN-1 Pro/Express Licenses


In This Chapter
Overview of NGX License Upgrade Introduction to License Upgrade in VPN-1 Express/Pro Environments Software Subscription Requirements Licensing Terminology The License_Upgrade Tool Simulating the License Upgrade Performing the License Upgrade Trial Licenses Troubleshooting License Upgrade page 18 page 18 page 18 page 19 page 20 page 21 page 23 page 34 page 35

17

Overview of NGX License Upgrade

Overview of NGX License Upgrade


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. The license upgrade procedure can be performed if you have purchased any of the Enterprise Software Subscription services. License upgrade will fail for products and accounts for which you do not have software subscription. Login to http://usercenter.checkpoint.com to manage your accounts, licenses, and Enterprise Support Programs coverage (under Support Programs). License upgrade is performed by means of an easy to use tool that automatically upgrades both locally and centrally managed licenses. Using the tool you can upgrade all licenses in the entire managed system. License upgrade can also be done manually, per license, in the User Center. For instructions, see the Step by Step guide to the User Center at https://usercenter.checkpoint.com/pub/usercenter/faq_us.html. For instructions on upgrading license for Provider-1 and SmartLSM deployments, see Provider-1/SiteManager-1 License Upgrade on page 120. License Upgrade for a ROBO Gateway on page 172. For the latest information and downloads regarding NGX license upgrade, check http://www.checkpoint.com/techsupport/ngx/license_upgrade.html.

Introduction to License Upgrade in VPN-1 Express/Pro Environments


Licenses are required for the SmartCenter Server and for the enforcement modules. No license is required for the SmartConsole management clients. The license upgrade procedure uses the license_upgrade command line tool that makes it simple to automatically upgrade licenses without having to do so manually through the Check Point User Center Web site https://usercenter.checkpoint.com. Version 4.1 licenses cannot be upgraded directly to NGX. You must first upgrade the license to NG and then to NGX. License upgrade from version 4.1 to NG can be done only from User Center web site. It is not supported by the upgrade tool.

Software Subscription Requirements


The license upgrade procedure can be performed if you have purchased any of the Enterprise Software Subscription services. License upgrade will fail for products and accounts for which you do not have software subscription.

18

You can see exactly the products and accounts for which you have software subscription by looking in your User Center account at https://usercenter.checkpoint.com. In the Accounts page, Enterprise Contract column, and in the Products page, Subscription and Support column, if the account or product is covered, the expiration date is shown. Otherwise, the entry says Join Now, with a link to get a quote for purchasing Enterprise Support. You can purchase an Enterprise Software Subscription for the whole account, in which case all the products in the account will be covered, or you can purchase Enterprise Software Subscription for individual products.

Licensing Terminology
The license upgrade procedures use specialized licensing terminology. It is important to understand the terminology in order to successfully perform the license upgrade. License Upgrade is the process of upgrading version NG licenses to NGX. Software Upgrade is the process of upgrading Check Point software to version NGX. License Repository is a repository on the SmartCenter Server that stores licenses for Check Point products. It is used by SmartUpdate to install and manage licenses on Check Point Gateways. Wrapper is the wizard application on the Check Point CD that allows you to install and upgrade Check Point products and upgrade licenses.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

19

The License_Upgrade Tool

The License_Upgrade Tool


The license_upgrade tool allows you to: 1 View the status of the currently installed licenses. On a SmartCenter server (or a CMA, for Provider-1), you can also view the licenses in the SmartUpdate license repository. Simulate the license upgrade process. Perform the actual license upgrade process.

2 3

During the license upgrade, all eligible licenses are gathered and sent in SSL encrypted format to the User Center. Upgraded licenses are returned from the User center, and automatically installed. The license upgrade process adds only NGX licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses, or licenses that pertain to IP addresses no longer used) remain untouched. When running on a SmartCenter Server (or a CMA, for Provider-1), the license upgrade tool also handles licenses in the SmartUpdate license repository. After using the tool, SmartUpdate is used to attach the new NGX licenses in the license repository to the gateways.

Tool Location
The license_upgrade tool can be found in one of the following locations: On the NGX product CD at <Specific_platform>\ In the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. It is also part of the NGX installation, located at $CPDIR/bin.

Tool Options
The license_upgrade command line tool has a number of options. To see all the options, run:
license_upgrade

20

Tool Options

The options are:


TABLE 2-1

license_upgrade tool options Meaning

Option [L] [S]

View the licenses installed on your machine. Sends existing licenses to User Center Web site to simulate the license upgrade in order to verify that it can be performed. No actual upgrade is done and no new licenses are returned Sends existing licenses to the User Center Web site to perform upgrade and (by default, in online mode) installs them on the machine. Reports whether or not there are licenses on the machine that need to be upgraded. Perform license upgrade on a license file that was generated on a machine with no Internet access to the User Center. View log of last license upgrade or last upgrade simulation.

[U]

[C]

[O]

[V]

Simulating the License Upgrade


Before performing the license upgrade, it is recommended to simulate the License Upgrade. Do this in order to find and solve potential problems in upgrading specific licenses. The simulation is an exact replica of the license upgrade process. It sends existing licenses to User Center Web site to verify that the upgrade is possible, however, no actual upgrade is done and no new licenses are returned. If the actual license upgrade will fail for some reason, error messages are displayed and available in a log file, which can be used for troubleshooting.
Note - License upgrade simulation can only be performed on a machine with Internet connectivity to the Check Point User Center.

Copy the license_upgrade tool from <Specific_platform>\ on the NGX product CD, or from the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. Place the license_upgrade tool on the NG machine. To simulate the license upgrade, run the license_upgrade tool option
[S] Simulate the license upgrade.

2 3

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

21

Simulating the License Upgrade

Be sure to deal with all the reported issues, so that the actual license upgrade will succeed for all licenses. For further assistance: See Troubleshooting License Upgrade on page 35. Refer to SecureKnowledge at https://secureknowledge.checkpoint.com.

22

License Upgrade Methods

Performing the License Upgrade


In This Section
License Upgrade Methods Deployments with Licenses Managed Centrally Using SmartUpdate Deployments with Licenses Managed Locally page 23 page 25 page 31

License Upgrade Methods


There are two methods of upgrading licenses to NGX in a VPN-1 Pro/Express deployment. The right method to use depends on how you manage your licenses: Centrally, from the SmartCenter Server by means of SmartUpdate, or Locally at the Check Point machine. If you use SmartUpdate to manage your licenses, you can update all licenses in your entire managed system in a single procedure. For both methods, the upgrade is performed using the license_upgrade tool. For each method the actual procedure that is used depends on whether or not the machine on which the license upgrade is to be run is online or offline. An online machine is one with Internet connectivity to the Check Point User Center. It is highly recommended to perform the license upgrade before performing any software upgrade. This ensures that the products will continue to function after the software upgrade. However, if necessary, the software upgrade can be done first.
Note - Version 4.1 licenses cannot be upgraded directly to NGX. You must first upgrade software and licenses to version NG.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

23

Performing the License Upgrade

The following table shows the Check Point licenses that are upgraded for each license upgrade method:
License Management method License Upgrade for License that are upgraded

Centrally managed using SmartUpdate

Entire managed System (Run upgrade tool on SmartCenter Server)

Local machine licenses (for SmartCenter) License Repository (for enforcement modules) Local machine licenses Local machine licenses Local machine licenses (for SmartCenter and enforcement module).

Locally managed

Enforcement module SmartCenter Server Standalone Gateway deployment, containing both a SmartCenter and an enforcement module. (that manages no remote enforcement modules)

What Next? Now choose the right procedure for you: Deployments with Licenses Managed Centrally Using SmartUpdate on page 25 Deployments with Licenses Managed Locally on page 31

24

Deployments with Licenses Managed Centrally Using SmartUpdate

Deployments with Licenses Managed Centrally Using SmartUpdate In This Section


Introduction to Using SmartUpdate on page 25 1. License Upgrade for an Online SmartCenter on page 25 2. License Upgrade for an Offline SmartCenter on page 28 Introduction to Using SmartUpdate In distributed deployments with multiple enforcement modules, SmartUpdate must be used to distribute licenses from the SmartCenter to the enforcement modules after performing the license upgrade. With SmartUpdate, you can manage all licenses for Check Point packages throughout the organization that are managed by the SmartCenter Server. SmartUpdate provides a global view of all available and installed licenses, and allows you to perform operations on Check Point Gateways such as adding new licenses, attaching licenses and deleting expired licenses.
Note - SmartUpdate license management capabilities are free of charge.

After the SmartCenter Server is upgraded, SmartUpdate must be used to complete the License Upgrade process. When SmartUpdate is opened, the upgraded licenses are imported into the license repository and are Assigned to the appropriate enforcement module. 1. License Upgrade for an Online SmartCenter Use this procedure to upgrade the licenses of the entire distributed deployment to NGX before the software upgrade, for a deployment with an online SmartCenter Server. An online SmartCenter Server is one with Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

25

Performing the License Upgrade

At the SmartConsole GUI machine, open SmartUpdate, connect to the SmartCenter Server, and select Licenses > Get all licenses. This ensures that the License Repository is updated. Copy the license_upgrade tool from <Specific_platform>\ on the NGX product CD, or from the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. Place the license_upgrade tool on the SmartCenter NG machine. On the Smartcenter Server, perform the license upgrade procedure by running license_upgrade tool (on SecurePlatform, you must be in expert mode).
Note - License upgrade using the CD Wrapper does not work for SmartCenter machines on Windows platforms with via-proxy Internet connectivity.

3 4

Choose the [U] option. This does the following: Collects all the licenses that exist on the machine. Fetches updated licenses from the User Center. Installs new licenses on the local machine. On the SmartCenter machine, if Management High Availability licenses exist, they are upgraded. Perform the software upgrade to NGX on the SmartCenter machine and on the SmartConsole GUI machine. At the SmartConsole GUI machine, open SmartUpdate, and connect to the SmartCenter Server. The updated licenses are displayed as Assigned. Use the Attach assigned licenses option to Attach the Assigned licenses to enforcement modules. Perform the software upgrade to NGX on the enforcement module machine(s). Delete obsolete licenses from NGX modules. At the SmartConsole GUI machine, open SmartUpdate and connect to the SmartCenter Server. In the License Repository, sort by the State column, select all the Obsolete licenses, Detach them, and then Delete them.

6 7

8 9

26

Deployments with Licenses Managed Centrally Using SmartUpdate

License Statuses in SmartUpdate

SmartUpdate shows whether a license is Attached or Unattached, and the license State. An: Attached license is associated with the enforcement module in License Repository, and is installed on the remote enforcement module. In order for the NGX software to work, a valid NGX license must be Attached. Unattached license is not installed on any enforcement module. A license can be in one of the following States: Assigned is an NGX license that is associated with the enforcement module in License Repository, but is not yet installed on the module as a replacement for an existing NG license. Obsolete is an NG license for which a replacement NGX license is installed on an NGX enforcement module. Requires Upgrade is an NG license that is installed on an NGX machine, and for which no replacement upgraded license exists. No NGX license is an NG license that does not need to be upgraded, or one for which the license upgrade failed.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

27

Performing the License Upgrade

2. License Upgrade for an Offline SmartCenter Use this procedure to upgrade the licenses of the entire distributed deployment before the software upgrade, where the SmartCenter Server is offline. An offline SmartCenter Server is one that does not have Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

At the SmartConsole GUI machine, open SmartUpdate and connect to the SmartCenter Server. Select Licenses > Get all licenses. This ensures that the License Repository is updated. Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD, or from the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. Place the license_upgrade tool on the offline SmartCenter Server NG. At the offline SmartCenter, run
license_upgrade

3 4

On SecurePlatform, run the option in expert mode. 5 From the menu of options choose: [U] to run the upgrade operation. [N] to specify that you dont have an internet connection. [E] to copy the licenses to a license file. Enter the name of the license package file that will be created. [Q] to quit the license upgrade tool. Copy the license package file from the offline SmartCenter to any online machine. The online machine does not need to be a Check Point-installed machine. Copy the license_upgrade tool to the online machine from the location specified in step 2. Run the license_upgrade tool at the online machine: [O] to run the upgrade operation in offline mode. Enter the name of the exported file with the location of the package file that is the result of step 5.

6 7 8

28

Deployments with Licenses Managed Centrally Using SmartUpdate

Enter the name of the file that will be created with all the upgraded licenses (output file name). Press [Y] when asked Is this machine connected to the Internet?. Press [Y] if you are connected to the internet via a proxy and supply the proxy IP port and username password. Press [N] if you are not connected via proxy and continue with the upgrade. Enter the user and password of your User Center Account. This fetches new licenses from the User Center and puts them in a cache file. 9 Copy the cache file (with the new licenses) to the offline SmartCenter. Copy the file to the same directory as the license upgrade tool.

10 Run license_upgrade tool on the offline SmartCenter. Press [U] to run the Upgrade operation. Press [N] when asked Is this machine connected to the Internet?. Press [I] to import the output file with all the upgraded licenses back to the SmartCenter. Enter the output file name with all the upgraded licenses. 11 Return to the main menu and press
[C] Check if currently installed licenses have been upgraded.

This shows the number of upgraded licenses on the machine and whether the original NG licenses have a replacement NGX license. 12 Perform the software upgrade to NGX on the SmartCenter machine and on the SmartConsole GUI machine. 13 At the SmartConsole GUI machine, open SmartUpdate and connect to the SmartCenter Server. The updated licenses are displayed as Assigned. Use the Attach assigned licenses option to Attach the Assigned licenses to enforcement modules. 14 Perform the software upgrade to NGX on the enforcement module machine(s). 15 Delete obsolete licenses from NGX modules. At the SmartConsole GUI machine, open SmartUpdate and connect to the SmartCenter Server. In the License Repository, sort by the State column, select all the Obsolete licenses, Detach them, and then Delete them.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

29

Performing the License Upgrade

License Statuses in SmartUpdate

SmartUpdate shows whether a license is Attached or Unattached, and the license State. An: Attached license is associated with the enforcement module in License Repository, and is installed on the remote enforcement module. In order for the NGX software to work, a valid NGX license must be Attached. Unattached license is not installed on any enforcement module. A license can be in one of the following States: Assigned is an NGX license that is associated with the enforcement module in License Repository, but is not yet installed on the module as a replacement for an existing NG license. Obsolete is an NG license for which a replacement NGX license is installed on an NGX enforcement module. Requires Upgrade is an NG license that is installed on an NGX machine, and for which no replacement upgraded license exists. No NGX license is an NG license that does not need to be upgraded, or one for which the license upgrade failed.

30

Deployments with Licenses Managed Locally

Deployments with Licenses Managed Locally In This Section


3. License Upgrade for an Online Machine on page 31 4. License Upgrade for an Offline Machine on page 32 3. License Upgrade for an Online Machine Use this procedure to upgrade the licenses on a single online NG machine before the software upgrade. An online machine is one with Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. The single machine can be a SmartCenter Server. Enforcement module. Standalone Gateway containing a SmartCenter Server and an enforcement module.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD, or from the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. Place the license_upgrade tool on the online NG machine. At the online machine, perform the license upgrade procedure by running license_upgrade tool (on SecurePlatform, you must be in expert mode).
Note - License upgrade using the CD Wrapper does not work for SmartCenter machines on Windows platforms with via-proxy Internet connectivity.

2 3

Choose the [U] option. This does the following: Collects all the licenses that exist on the machine. Fetches updated licenses from the User Center. Installs new licenses on the local machine. On a SmartCenter machine, if Management High Availability licenses exist, they are upgraded.
Chapter 2 Upgrading VPN-1 Pro/Express Licenses 31

Performing the License Upgrade

5 6 7

Perform the software upgrade to NGX. Find out which license on the machine are obsolete. Run
cplic print

Delete the obsolete licenses from the machine: For each obsolete license, run
cplic -del <license_signature>

4. License Upgrade for an Offline Machine Use this procedure to upgrade the licenses for a single offline machine before the software upgrade. An offline machine is one that does not have Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. The single machine can be a SmartCenter Server. Enforcement module. Standalone Gateway containing a SmartCenter Server and an enforcement module.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD, or from the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. Place the license_upgrade tool on the offline machine. At the offline machine, run
license_upgrade

2 3

On SecurePlatform, run the option in expert mode. 4 From the menu of options choose: [U] to run the upgrade operation. [N] to specify that you dont have an internet connection. [E] to copy the licenses to a license file. Enter the name of the license package file that will be created. [Q] to quit the license upgrade tool. Copy the license package file from the offline machine to any online machine. The online machine does not need to be a Check Point-installed machine.

32

Deployments with Licenses Managed Locally

6 7

Copy the license_upgrade tool to the online machine. The tool is located at the location specified in step 1. Run the license_upgrade tool at the online machine: [O] to run the upgrade operation in offline mode. Enter the name of the exported file with the location of the package file that is the result of step 5. Enter the name of the file that will be created with all the upgraded licenses (output file name). Press [Y] when asked Is this machine connected to the Internet?. Press [Y] if you are connected to the internet via a proxy and supply the proxy IP port and username password. Press [N] if you are not connected via proxy and continue with the upgrade. Enter the user and password of your User Center Account. This fetches new licenses from the User Center and puts them in a cache file. Copy the cache file (with the new licenses) to the offline machine. Copy the file to the same directory as the license_upgrade tool. Run license_upgrade tool on the offline machine. Press [U] to run the Upgrade operation. Press [N] when asked Is this machine connected to the Internet?. Press [I] to import the output file with all the upgraded licenses back to the SmartCenter. Enter the output file name with all the upgraded licenses.
Check if currently installed licenses have been upgraded.

8 9

10 Return to the main menu and press


[C]

This shows the number of upgraded licenses on the machine and whether the original NG licenses have a replacement NGX license. 11 Perform the software upgrade to NGX on the offline machine. 12 Find out which license on the machine are obsolete. Run
cplic print

13 Delete the obsolete licenses from the machine: For each obsolete license, run
cplic -del <license_signature>

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

33

Trial Licenses

Trial Licenses
Every Check Point product comes with a Trial License that allows unrestricted use of the product for 15 days. After the software upgrade, the Trial License continues to work for the remaining days of the license. There is no need to upgrade the Trial License. The Trial License does not work if you migrate your current SmartCenter configuration to a new machine, and then upgrade the new machine to NGX.

34

Error: License version might be not compatible

Troubleshooting License Upgrade


License upgrade is a smooth and easy process. There are a few predictable cases where you may come across some problems. Use this section to solve those license upgrade problems.

In This Section
Error: License version might be not compatible Evaluation Licenses Created in the User Center Evaluation Licenses Not Created in the User Center Licenses of Products That Are Not Supported in NGX License Enforcement on Module is now on Management License Not in Any Of Your User Center Accounts User Does Not Have Permissions on User Center Account SKU Requires Two Licenses in NG and One License in NGX SmartDefense Licenses License Upgrade Partially Succeeds Upgraded Licenses Do Not Appear in the Repository License Upgrade Status Action Reports Wrong Results Cannot Connect to the User Center page 35 page 36 page 36 page 37 page 37 page 38 page 39 page 39 page 40 page 40 page 41 page 41 page 42

Error: License version might be not compatible


SecureKnowledge solution sk30478 Symptoms Error: Warning: Can't find .... in cp.macro. License version might be
not compatible

Error occurs with commands such as cplic print, cpstop, cpstart, and fw ver. The error occurs when a license upgrade is performed before a software upgrade. The error appears in any situation where a licensed version is not compatible with the version installed on a machine, for example, an NGX license on an NG machine.

Cause License on the target machine was upgraded to NGX before the software was upgraded from a previous NG version to NGX.
Chapter 2 Upgrading VPN-1 Pro/Express Licenses 35

Troubleshooting License Upgrade

If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. Refer to License Upgrade Methods on page 23 to determine the upgrade path that best applies to your current configuration. Resolution Upgrade the software to version NGX. Errors will not appear after the upgrade. Note that these errors do not affect the functionality of the version NG software.

Evaluation Licenses Created in the User Center


Symptoms User Center message (Error code: 106):
No license upgrade is available for evaluation product.

Cause Evaluation licenses are not entitled to a license upgrade. Resolution Evaluation licenses cannot be upgraded. If you dont need the evaluation license, delete it. If you do need it, contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com.

Evaluation Licenses Not Created in the User Center


Symptoms User Center message (Error code: 151):
Your license contains a Certificate Key (CK) which is not found in User Center.

Cause These evaluation licenses do not exist in the User Center. Evaluation licenses are not entitled to a license upgrade. An evaluation license can be identified by examining the license string. Evaluation licenses may contain one of the following strings in the Features description:
CK-CP

or

36

Licenses of Products That Are Not Supported in NGX

CK-CHECK-POINT-INTERNAL-USE-ONLY

Resolution Evaluation licenses cannot be upgraded. If you dont need the evaluation license, delete it. If you do need it, contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com.

Licenses of Products That Are Not Supported in NGX


Symptoms User Center Message (Error code: 154):
This product is not upgradeable to NGX version and therefore a license upgrade is not needed. The product continues to be supported in its NG Release

Cause VPN-1 Net and VPN-1 SmallOffice are not supported in NGX. Therefore, if an attempt is made to upgrade the license for these products, the User Center generates an error message. The affected SKUs are: VPN-1 Net Family SKUs: CPVP-VNT and LS-CPVP-VNT families SmallOffice family SKUs: CPVP-VSO and LS- CPVP-VSO families Resolution Contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com.

License Enforcement on Module is now on Management


Symptoms User Center Message (Error code: 132):
The license enforcement of NG gateway is now performed by the NGX management server. Perform Change IP operation in User Center and install the NGX license on the management server

Cause The enforcement of NG module features is now performed by the NGX management. For example, the licensing model of QOS (formerly FloodGate-1) for VPN-1 Express was changed in NGX, and VPN-1 Express NGX modules with QoS require an

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

37

Troubleshooting License Upgrade

appropriate license to be installed on the management. License Upgrade in this scenario is not handled automatically by the license upgrade. The affected SKU family for QoS is: CPXP-QOS Resolution If you have an NG Express gateway with a QoS (FloodGate-1) license, and in any other case where this problem occurs, proceed as follows: 1 2 3 4 Perform a license upgrade at the User Center web site to generate a new license. Install the new, upgraded license on the NGX management machine (even if you do not upgrade the gateway). Upgrade the gateway. Delete the unneeded license from the gateway in one of two ways: Run the command line command at the gateway:
cplic del <license_signature>

Using SmartUpdate, select the unneeded license,

Detach

it, and then

Delete

it.

License Not in Any Of Your User Center Accounts


Symptoms User Center Message (Error Code 17):
This license is not in any of your accounts. Run the license upgrade again with the username that owns this license in the User Center.

Cause This specific license does not exist in any of the accounts that belong to this user. Resolution Run the tool again with the appropriate username. Note that each time you run the tool with a different username, upgraded licenses from the User Center are added to a cache file located on your machine. This file contains the successfully upgraded licenses from previous runs. If the partially successful license upgrade was performed via the Wrapper, then after the Wrapper has finished, run the license upgrade again via the command line, with the appropriate username.

38

User Does Not Have Permissions on User Center Account

User Does Not Have Permissions on User Center Account


Symptoms User Center Message (Error Code 19):
This license is in your account but you are not authorized to upgrade licenses in this account because you have just view-only permissions. Run license upgrade again with a username that is authorized to change the license in the User Center.

Cause This user is not authorized to change this license in the User Center. Resolution Run the tool again with the appropriate username. Note that each time you run the tool with a different username, upgraded licenses from the User Center are added to a cache file located on your machine. This file contains the successfully upgraded licenses from previous runs. If the partially successful license upgrade was performed via the Wrapper, then after the Wrapper has finished, run the license upgrade again via the command line, with the appropriate username.

SKU Requires Two Licenses in NG and One License in NGX


Symptoms User Center Message (Error code: 135):
This license is no longer needed in the version you are upgrading to. It can be safely removed from the machine after the software upgrade.

Cause The NG version of SecureClient requires two licenses: one license for the module and one for the management. In NGX only the management license is needed. The module license (CPVP-VPS-1-NG) is no longer needed because it is incorporated in the VPN-1 Pro license. The relevant SKU families are: CPVP-VSC, LS- CPVP-VSC, CPVP-VMC, LS-CPVP-VMC, CPVP-VSC-100-DES-NG
Chapter 2 Upgrading VPN-1 Pro/Express Licenses 39

Troubleshooting License Upgrade

Resolution After the software upgrade, delete the unneeded module license from the machine. Do this in one of two ways: Using the command line: Run
cplic del <license_signature>

Using SmartUpdate: Select the unneeded license,

Detach

it, and then

Delete

it.

SmartDefense Licenses
Symptoms User Center Message (Error code: 902):
SmartDefense License is not needed on the gateway.

Cause In NGX, enforcement of SmartDefense licenses is handled by the User Center. The SKU families for which this issue is relevant are SU-SMRD and SU-SMDF. Resolution Delete the unneeded license from the machine.

License Upgrade Partially Succeeds


Symptoms License upgrade fails for some of the licenses but succeeds for others. Cause License upgrade may fail for some licenses and succeed for others. A license may fail to upgrade for a number of reasons. For example, you may not have an Enterprise Subscription contract for these licensed product. See some of the other items in Troubleshooting License Upgrade on page 35 for more reasons why license upgrade may fail. Resolution After solving all or some of the licensing problems referred to in the error log, run the license_upgrade tool. This will upgrade the licenses for which the problem has been solved. The tool can be found in one of the following locations On the CD at <Specific_platform>
40

Upgraded Licenses Do Not Appear in the Repository

In the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html.

When the license_upgrade tool is run several times, the results are cumulative. This means that if the upgrade of some licenses failed and the tool is run again: Licenses that were successfully upgraded to NGX remain unchanged. Licenses that failed to upgrade in a previous run and were now successfully upgraded, are added to the machine. For example, if the upgrade of a license failed because there was no Enterprise Software Subscription contract for the licensed product, purchase Software Subscription for those products and then run the tool again to fetch the new licenses from the User Center Web site to the machine.

Upgraded Licenses Do Not Appear in the Repository


Symptoms Upgraded license does not appear in the SmartUpdate Repository. However, the license_upgrade tool log indicates that the license upgrade succeeded. The license upgrade was performed on the NGX machine, after the software upgrade to NGX. Cause The file with the upgraded licenses that was fetched from the User Center cannot be imported into the SmartUpdate Repository while SmartUpdate is open. Resolution Close any SmartUpdate GUI client that is running, and run
license_upgrade import -r

This imports the upgraded licenses into the SmartUpdate Repository.

License Upgrade Status Action Reports Wrong Results


Symptoms When running the Wrapper, Pre-Upgrade Verifier or the Upgrade Tools (Import), the relevant utility reports that there are NG licenses that needs to be upgraded. However, these NG licenses have already been upgraded to NGX, and the NGX licenses have either been installed on the machine or are in a cache file (ready to be imported into the SmartUpdate License Repository).
Chapter 2 Upgrading VPN-1 Pro/Express Licenses

41

Troubleshooting License Upgrade

Cause The Wrapper, Pre-Upgrade Verifier and the Upgrade Tools use the Status action to determine if a specific license needs to be upgraded. The determination is made by comparing the Feature string that appears in NG license to the Feature string that appears in NGX license. If the only difference between the licenses is that the Features string of the NG license end with NG, and the Features string of the NGX license end with NGX, this means that the license has been upgraded. If the license upgrade changes the Features string is some other way, the Status action mistakenly reports that a license upgrade is required. For example:
TABLE 2-2 SKU

SKUs for which the tool reports wrong results


Description NG Management Feature NGX Management Feature

CPVP-VSC-100-DES-NG VPN-1 SecureClient for 100 remote users CPVP-VMC-25-NG CPVP-VMC-250-NG CPVP-VMC-5000-NG LS-CPVP-VMC-50-NG LS-CPVP-VMC-100-NG LS-CPVP-VMC-500-NG LS-CPVP-VMC-1000-NG

CPVP-VSC-100-DES-NG CPVP-VSC-100-NGX CPVP-VMC-25-NGX CPVP-VMC-250-NGX CPVP-VMC-5000-NGX CPVP-VMC-50-NGX CPVP-VMC-100-NGX CPVP-VMC-500-NGX CPVP-VMC-1000-NGX

VPN-1 SecureClient for Macintosh CPVP-VSC-25-NG VPN-1 SecureClient for Macintosh CPVP-VSC-250-NG VPN-1 SecureClient for Macintosh CPVP-VSC-5000-NG VPN-1 Macintosh Client for 50 remote usersCPVP-VSC-50-NG VPN-1 Macintosh Client for 100 remote use CPVP-VSC-100-NG VPN-1 Macintosh Client for 500 remote use CPVP-VSC-500-NG VPN-1 Macintosh Client for 1000 remote us CPVP-VSC-1000-NG

Resolution Make sure you have an upgraded NGX license for each NG license and continue with the software upgrade.

Cannot Connect to the User Center


Symptom Failed to connect to the User Center. Cause Access to port HTTPS-443 is not allowed through the firewall. Access to the User Center requires this port to be open. Resolution Open port HTTPS-443 in the firewall.

42

Cannot Connect to the User Center

For example, in a deployment with one main firewalled gateway, and other gateways for branch offices within the organization, open HTTPS-443 in the main gateway for all the branch office gateways behind it.

Chapter 2

Upgrading VPN-1 Pro/Express Licenses

43

Troubleshooting License Upgrade

44

CHAPTER

Backup and Revert for VPN-1 Pro/Express


In This Chapter
Introduction Backup your Current Deployment Restore a Deployment SecurePlatform Backup and Restore Commands SecurePlatform Snapshot Image Management Revert to your Previous Deployment page 45 page 46 page 46 page 46 page 49 page 50

Introduction
Before you perform an Upgrade process you should backup your current configuration, in case the Upgrade process is unsuccessful. The purpose of the backup process is to backup the entire configuration, and to restore it when necessary. To backup your configuration, use the Export utility available on the NGX R60 CD. The backup file created contains your current system configuration (for example, objects, rules, users, etc.) and can be used to restore your previous configuration if the Upgrade process fails. The restoration procedure brings the configuration to the state it was at when the backup procedure was executed.
Note - Operating sytem level configurations (for example, network configuration) are not exported.

45

Backup your Current Deployment

If you are performing an Upgrade process on SecurePlatform you do not have to backup your configuration using the Export utility. SecurePlatform provides you with the option of backing up your configuration during the Upgrade process.

Backup your Current Deployment


1 2 Insert the NGX R60 CD into the original SmartCenter Server. Choose Export in Upgrade Options. Wait while exporting database files. If you chose to perform the Export procedure manually make sure you are using the NGX R60 Export tool. Once the Export utility process is complete the configuration (.tgz) file is created in the chosen destination path.
Warning - The configuration file (.tgz) file contains your product configuration. It is highly recommended to delete it after completing the import process.

Restore a Deployment
1 2 3 4 Select the destination path of the configuration (.tgz) file. Copy the exported.tgz file to the restored SmartCenter Server. Insert the NGX R60 CD into the restored SmartCenter Server. Select Installation using Imported Configuration (Windows) or (Solaris) in the Installation Options.
Advanced Upgrade

SecurePlatform Backup and Restore Commands


In This Section
Backup Restore page 47 page 48

SecurePlatform NG with Application Intelligence provides a command line, or Web GUI, capability for conducting backups of your system settings and products configuration. The backup utility can store backups either locally on the SecurePlatform machine hard drive, or remotely to a TFTP server or SCP server. The backup can be performed on request, or it can be scheduled to take place at set intervals.
46

Backup

The backup files are kept in tar gzipped format (.tgz). Backup files, saved locally, are kept in /var/CPbackup/backups. The restore command line utility is used for restoring SecurePlatform settings, and/or Product configuration from backup files. Expert permissions are required to perform the backup and restore procedures.

Backup
Backup the system configuration. You can also copy backup files to a number of scp and tftp servers for improved robustness of backup. The backup command, run by itself, without any additional flags, will use default backup settings and will perform a local backup.
Syntax
backup [-h] [-d] [-l] [--purge DAYS] [--sched [on hh:mm <-m DayOfMonth> | <-w DaysOfWeek>] | off] [[--tftp <ServerIP> [-path <Path>] [<Filename>]] | [--scp <ServerIP> <Username> <Password> [-path <Path>][<Filename>]] | [--file [-path <Path>][<Filename>]]

Parameters
TABLE 3-1

Backup Parameters meaning

parameter
-h -d -l

obtain usage debug flag flag enables VPN-1 Pro log backup (By default, VPN-1 Pro logs are not backed up.) delete old backups from previous backup attempts schedule interval at which backup is to take place On - specify time and day of week, or day of month Off - disable schedule

--purge DAYS [--sched [on hh:mm <-m DayOfMonth> | <-w DaysOfWeek>] | off]

Chapter 3

Backup and Revert for VPN-1 Pro/Express

47

SecurePlatform Backup and Restore Commands

TABLE 3-1

Backup Parameters meaning

parameter
--tftp <ServerIP> [-path <Path>][<Filename>]

List of IP addresses of TFTP servers, on which the configuration will be backed up, and optionally the filename. List of IP addresses of SCP servers, on which the configuration will be backed up, the username and password used to access the SCP Server, and optionally the filename. When the backup is performed locally, specify an optional filename

--scp <ServerIP> <Username> <Password>[path <Path>] [<Filename>]

--file [-path <Path>]<Filename>

Restore
Restore the system configuration.
Syntax
restore [-h] [-d][[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]

Parameters parameter
-h -d

meaning

obtain usage debug flag IP address of TFTP server, from which the configuration is restored, and the filename. IP address of SCP server, from which the configuration is restored, the username and password used to access the SCP Server, and the filename. Specify a filename for restore operation, performed locally.

--tftp <ServerIP> [<Filename>] --scp <ServerIP> <Username> <Password> [<Filename>] --file <Filename>

For more information about the backup and restore utilities, see the System Commands section in the SecurePlatform & SecurePlatform Pro guide on page 88.

48

Snapshot

SecurePlatform Snapshot Image Management


In This Section
Snapshot Revert page 49 page 50

SecurePlatform provides the option of backing up the entire SecurePlatform operating system and all of its products using the snapshot command. A snapshot of the system can be performed manually using the snapshot command or automatically during an upgrade procedure with the provided SafeUpgrade option. The snapshot and revert commands can use a TFTP server or a SCP Server to store snapshots. Alternatively, snapshots can be stored locally.

Snapshot
This command creates a snapshot file. The snapshot command, run by itself, without any additional flags, will use default backup settings and will create a local snapshot.
Syntax
snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]

Parameters
TABLE 3-2

Snapshot Parameters meaning

parameter
-h -d

obtain usage debug flag IP address of the TFTP server, from which the snapshot is made, as well as the filename of the snapshot. IP address of the SCP server, from which the snapshot is made, the username and password used to access the SCP Server, and the filename of the snapshot. When the snapshot is made locally, specify a filename

--tftp <ServerIP> <Filename>

--scp <ServerIP> <Username> <Password> <Filename>

--file <Filename>

Chapter 3

Backup and Revert for VPN-1 Pro/Express

49

Revert to your Previous Deployment

Revert
Reboot the system from a snapshot file. The revert command, run by itself, without any additional flags, will use default backup settings, and will reboot the system from a local snapshot.
revert [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP> <Username> <Password> <Filename>] | [--file <Filename>]]

Parameters
TABLE 3-3

Revert Parameters meaning

parameter
-h -d

obtain usage debug flag IP address of the TFTP server, from which the snapshot is rebooted, as well as the filename of the snapshot. IP address of the SCP server, from which the snapshot is rebooted, the username and password used to access the SCP Server, and the filename of the snapshot. When the snapshot is made locally, specify a filename
Snapshot image

--tftp <ServerIP> <Filename>

--scp <ServerIP> <Username> <Password> <Filename>

--file <Filename>

The revert command functionality can also be accessed from the management boot option.

Revert to your Previous Deployment


In This Section
Nokia platforms Windows Platforms Solaris SecurePlatform Linux Internal Certificate Authority Revert Considerations page 51 page 52 page 52 page 52 page 52 page 53

50

Revert

To revert to the software version prior to the active VPN-1 Pro/Express, uninstall the upgraded software version and installation packages as follows: 1 2 3 4 5 6 Deactivate VPN-1 Pro/Express NGX R60. But, if dependent packages are active, deactivate them first. Activate the previous SVN Foundation. Delete the previous FireWall-1 version. Deactivate the previous SVN Foundation. Delete a previous SVN Foundation. Activate VPN-1 Pro/Express NGX R60 and dependent products.

Nokia platforms 1 2 3 4 5 6 Verify that VPN-1 Pro/Express NGX R60 packages are active. Deactivate Enter
VPN-1 Pro/Express NGX R60.

Delete Packages

and delete

VPN-1 Pro/Express NGX R60.

Activate previous version products (for example, SVN Foundation, VPN-1, etc.). Revert to the previous compatible IPSO image. Reboot the machine.

Chapter 3

Backup and Revert for VPN-1 Pro/Express

51

Revert to your Previous Deployment

Windows Platforms In the Add/Remove Programs applet, select Solaris 1 Run the command:
pkgrm CPfw1-R60.
Check Point VPN-1 Pro NGX R60.

SecurePlatform On SecurePlatform machines, use the revert command to revert to the snapshot taken before the upgrade. Refer to the SecurePlatform/SecurePlatform Pro NGX R60 User Guide for more details about snapshot and revert operations. Linux 1 Run the command:
rpm e CPsuite-R60-00.

52

Revert

Internal Certificate Authority Revert Considerations Once the Revert process is complete, certificates issued during the use of NGX R60 remain valid. While these certificates are valid, they cannot yet be managed by the Internal CA. In order to resume management of the NGX R60 certificates after the Revert process is complete perform the following steps: 1 Backup the InternalCA.NDB and ICA.crl files (located in the $FWDIR/conf directory) and all *.crl files (located in the $FWDIR/conf/crl directory) from the version prior to NGX R60 (for example, from NG with Application Intelligence R55) to a location of your choice. Copy the NGX R60 InternalCA.NDB, ICA.crl and the *.crl files (located in the $FWDIR/conf directory) from the current NGX R60 version and use them to overwrite the files (for example, the NG with Application Intelligence R55 files) in the location from the previous step (in the $FWDIR/conf directory).
Note - If the Upgrade process was performed on a machine that runs a different operating system then the original machine, the InternalCA.NDB file must be converted after it is copied to the reverted environment. To do this run the cpca_dbutil d2u command line from the reverted environment.

Once the Revert process is complete, use the ICA Management Tool to review certificates created during the use of NGX R60 in the reverted environment (for example, the NG with Application Intelligence R55 environment). For instance, the subject to which a specific certificate was issued may no longer exist and in such a case you may want to revoke the specific certificate. For additional information refer to The Internal Certificate Authority (ICA) and the ICA Management Tool chapter in the NGX R60 SmartCenter Guide.

Chapter 3

Backup and Revert for VPN-1 Pro/Express

53

Revert to your Previous Deployment

54

CHAPTER

Upgrading a Distributed VPN-1 Pro/Express Deployment


In This Chapter
Introduction Upgrading the SmartCenter Server Component Upgrading the Enforcement Module page 55 page 58 page 70

Introduction
This chapter describes the process of upgrading a VPN-1 distributed deployment to NGX R60. A distributed deployment consists of at least one SmartCenter server and one or more Enforcement Modules. The SmartCenter component should be the first component to be upgraded. Due to backward compatibility support of previous versions, an upgraded SmartCenter can enforce and manage enforcement modules from previous versions even though some of the new features may not be available to Enforcement Modules from previous versions.

55

Pre-Upgrade Considerations

Pre-Upgrade Considerations
In This Section
License Upgrade to NGX R60 Web Intelligence License Enforcement Upgrading Products on a SecurePlatform Operating System VPN-1 Edge/Embedded Gateways Prior to Version 5.0 Reverting to your Previous Software Version page 56 page 56 page 57 page 57 page 57

License Upgrade to NGX R60


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. It is highly recommended to upgrade licenses before upgrading the software. If necessary, license upgrade can be done after the software upgrade. See Upgrading VPN-1 Pro/Express Licenses on page 17 for details.

Web Intelligence License Enforcement


A gateway or gateway cluster requires a Web Intelligence license if it enforces one or more of the following protections: Malicious Code Protector LDAP Injection SQL Injection Command Injection Directory Listing Error Concealment ASCII Only Request Header Rejection HTTP Methods The actual license required depends on the number of Web servers protected by the gateway or gateway cluster. For version R60 and higher versions, if the correct license is not installed, it is not possible to Install a Policy on any gateway. When upgrading, be aware of this change of behavior. For additional information refer to the Web Intelligence chapter in the Firewall and SmartDefense User Guide.
56

Upgrading Products on a SecurePlatform Operating System

Upgrading Products on a SecurePlatform Operating System


Upgrading to NGX R60 over a SecurePlatform operating system requires upgrading both the operating system and software products installed. To upgrade products installed on SecurePlatform, follow the SmartCenter Upgrade on SecurePlatform R54, R55 and Later Versions on page 62 section about the specific component. The process described in this section will result with an upgrade of all components installed (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to the NGX R60 SecurePlatform Guide for additional information.

VPN-1 Edge/Embedded Gateways Prior to Version 5.0


It is recommended that before you upgrade your deployment to NGX R60, VPN-1 Edge/Embedded gateways should be upgraded to version 5.0. By default, SmartCenter NGX R60 is only compatible with VPN-1 Edge/Embedded gateways 5.0. In order, to control and enforce policies on VPN-1 Edge/Embedded gateways from versions prior to 5.0 you must perform the following workaround on the upgraded SmartCenter Server. However, once the workaround is complete, new NGX R60 features may not be available to VPN-1 Edge/Embedded gateways prior to 5.0. Workaround 1 Edit the /var/opt/CPEdgecmp/conf/SofawareLoader.ini file for Unix based platforms or the %FWDIR%\FW1_EDGE_BC\conf\SofawareLoader.ini file or Windows. In the [Server] section, add the following:
TopologyOldFormat=1

2 3

Save and close the file.

The change takes effect without running the commands cpstop and cpstart.

Reverting to your Previous Software Version


To revert to the software version prior to the upgrade, uninstall the upgraded software version and installation packages and restart the system. For additional information refer to Revert to your Previous Deployment on page 50.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

57

Upgrading the SmartCenter Server Component

Upgrading the SmartCenter Server Component


This section describes how to upgrade a SmartCenter Server with Application Intelligence NGX R60. Upgrades can be performed incrementally so that you do not have to upgrade the SmartCenter Server and all of the Enforcement Modules at the same time. Once the SmartCenter Server is upgraded you can still manage Enforcement Modules from the previous SmartCenter Server version, even though the modules may not support the new (upgraded) features. You can upgrade the Enforcement Modules at your convenience. Use of the Pre-Upgrade verification tool can reduce the risk of incompatibility with the deployment to NGX R60, since it is used to test the current VPN-1 Pro gateway prior to upgrading to NGX R60. The Pre-Upgrade verification tool produces a detailed report of what should be done before performing an upgrade to NGX R60 (refer to the Using the Pre Upgrade Verification Tool on page 59). There are two upgrade methods available for the SmartCenter server: Upgrade your Production SmartCenter Server Perform the upgrade process on the production SmartCenter Server (refer to the procedures directly below). Migrate and Upgrade to a New SmartCenter Server Perform a migration process (refer to the Migrate your Current SmartCenter Configuration and Upgrade on page 67) of the currently installed version to a new server, and upgrade the migrated system. Performing the upgrade on a new machine, enables the production SmartCenter Server to remain fully operational and reduces unnecessary risks.

In This Section
Using the Pre Upgrade Verification Tool Upgrading a SmartCenter High Availability Deployment SmartCenter Upgrade on a Windows Platform SmartCenter Upgrade on SecurePlatform R54, R55 and Later Versions SmartCenter Server Upgrade on a Solaris Platform SmartCenter Upgrade on an IPSO Platform Migrate your Current SmartCenter Configuration and Upgrade page 59 page 60 page 61 page 62 page 64 page 65 page 67

SmartCenter Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 page 63

58

Using the Pre Upgrade Verification Tool

Using the Pre Upgrade Verification Tool


Automatic pre-upgrade verification runs automatically (or manually if desired) during your SmartCenter upgrade. Pre-upgrade verification performs a compatibility analysis of the currently installed SmartCenter server and its current configuration. A detailed report is provided, supplying appropriate actions that should be taken before and after the upgrade process. Usage:
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -t TargetVersion [-f FileName] [-w]

or
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -i[-f FileName][-w]

-p -c -t -i -f -w

Path of the installed SmartCenter Server (FWDIR) Currently installed version Target version Check originality of INSPECT files only Output in file Web format file

Where the currently installed version is one of the following: NG NG_FP1 NG_FP2 NG_FP3 NG_AI NG_R54 NG_R55 NG_R55W GX_2.5 VSX_NG_AI VSX_NG_AI_Release 2 The target version is: NGX_R60
-f

redirects the standard output to a file.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

59

Upgrading the SmartCenter Server Component

Upgrading a SmartCenter High Availability Deployment


To upgrade a SmartCenter Server High Availability deployment proceed as follows: 1 2 3 4 Before you perform the Upgrade process, synchronize all the SmartCenter Servers (select Policy > Management High Availability). Perform the Upgrade process on both SmartCenter Servers (refer to the relevant upgrade process below). Using the SmartDashboard GUI client, connect to one of the SmartCenter Servers. In the General page of each of the SmartCenter Server's Gateway Properties window, set the correct Check Point Products Version. This can also be done by applying Get Version button in the specific objects properties page. Once again, synchronize all the SmartCenter Servers (select
High Availability). Policy > Management

5 6

Repeat steps 3 and 4 for every additional SmartCenter Server.

60

SmartCenter Upgrade on a Windows Platform

SmartCenter Upgrade on a Windows Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. The following upgrade steps describe the upgrade process using the NGX R60 CD. 1 2 3 4 Access your NGX R60 CD Execute the Installation package. Select
Upgrade

from the

Upgrade Options

screen.

When the pre-upgrade verification recommendation appears, select whether or not the Pre upgrade verification tool should be executed (refer to the Using the Pre Upgrade Verification Tool on page 59). Pre-upgrade verification will perform a compatibility analysis of the currently installed SmartCenter server and of its current configuration. A detailed report is provided, supplying appropriate actions that should be taken before and after the upgrade process. The tool can be used manually as well. Select Upgrade again, from the Upgrade Options screen. At this point, another verification will run. When prompted, reboot your SmartCenter Server.

5 6

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

61

Upgrading the SmartCenter Server Component

SmartCenter Upgrade on SecurePlatform R54, R55 and Later Versions


Upgrading to NGX R60 over a SecurePlatform operating system requires updating both operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. Using a CD ROM The following steps depict how to upgrade SecurePlatform R54 and later versions using a CD ROM drive. 1 2 3 4 Log into SecurePlatform (Expert mode is not necessary). Apply the SecurePlatform NGX R60 upgrade package: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

If you select Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

62

SmartCenter Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2

SmartCenter Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2


Upgrading to NGX R60 over a SecurePlatform operating system requires updating both operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. Upgrading pre R54 versions requires an upgrade of the patch command. 1 2 3 Insert the SecurePlatform NGX R60 CD into the drive. Enter the
Expert

mode: # expert.

Upgrade the patch command by selecting the following option: Update the patch command using a CD ROM drive:
# mount /mnt/cdrom # patch add /mnt/cdrom/SecurePlatform/patch/CPpatch_command_*.tgz.

Apply the SecurePlatform NGX R60 upgrade package by using a CD ROM drive with the following command: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

5 6

If you chose Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

63

Upgrading the SmartCenter Server Component

SmartCenter Server Upgrade on a Solaris Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. This section describes the steps that should be performed when performing an upgrade on a Solaris Platform. 1 2 3 4 5 6 Insert the NGX R60 CD into the CD drive. Run UnixInstallScript. Select
Yes

if you agree to the license terms.

A list of products appears and you are asked to select the products that you would like to install. Select Next (N) to continue. At this point you are asked to reboot the machine. Select Yes (Y).

64

SmartCenter Upgrade on an IPSO Platform

SmartCenter Upgrade on an IPSO Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. This section describes the steps that should be performed when performing an upgrade on an IPSO Platform. 1 2 3 Enter Network Voyager and open a CLI console. Click
System Configuration > Install New IPSO Image (Upgrade). The New Image Installation Upgrade

window appears.

Enter the following information:


Enter URL to the image location Enter HTTP Realm (for HTTP URLs only) Enter Username (if applicable) Enter Password (if applicable)

Click Apply. At this point you are informed that the file download and image installation can take a long time. Click
Apply.

5 6

At this point you will receive a message that the new image installation process has started. When you receive a Success message click UP > UP > Manage IPSO Images. The IPSO Image Management window appears. Under the title Click
Select an image for next boot,

7 8 9

select the last downloaded image.

Test Boot. Commit testboot

In the window that appears select

and click

Apply.

10 Access the CLI console to see when the Reboot is complete. Once the Reboot is complete go back to Network Voyager (that is, step 10) to verify that the image was set properly. 11 In the Network Voyager, click
Refresh

and Login.

12 If you are not returned to the last window you were in click System Configuration > Manage IPSO Images. At this point, you should be able to see that the relevant IPSO Image is selected.
Chapter 4 Upgrading a Distributed VPN-1 Pro/Express Deployment 65

Upgrading the SmartCenter Server Component

13 Access the CLI console and login. 14 Perform an


FTP

using

bin

mode to transfer the package.

15 Type newpkg -S -m LOCAL -n <CPsuite package path> -o $FWDIR and press Enter. At this point the package is loaded and the following products are upgraded: CPshared VPN-1/FW-1 SmartCenter Floodgate (Qos) SmartView Monitor Once the process is complete you should receive a message that states that the process was a success. 16 Type
Reboot

and press

Enter.

17 Log into Network Voyager and select


System Configuration > Manage Install Packages.

18 Under 19 Click

Applications

select

Off

in the following line:

Check Point CPinfo NG with Application Intelligence (R55) Apply. Applications

20 Under 21 Click

select

Off

in the following line:

Check Point SVN Foundation NG with Application Intelligence (R55) Apply.

22 Click Save. At this point you should receive a message that states that the process was a success. 23 Return to the CLI console and type
Reboot.

24 Login and type CPconfig. The following questions appears: Do you want to add licenses (y/n)? If you type y answer the questions that appear. Configure Administrators: Do you want to modify this list (y/n)? If you type y answer the questions that appear. With CPconfig you can only define one administrator. Configure Group Permissions: Please specify group name [(RET) for Super-user
group]:

Enter the name and press


66

Enter.

Migrate your Current SmartCenter Configuration and Upgrade

25 Select y to reboot. The SmartCenter Server Upgrade on an IPSO Platform is complete. To manage R55W or NG modules install the Compatibility packages for these versions. These packages are located in the same place as the package installed above.

Migrate your Current SmartCenter Configuration and Upgrade


The motivations for performing an advanced upgrade are: Upgrading to NGX R60 while replacing the Operating System on which the current SmartCenter is installed on. Upgrading to NGX R60 while migrating to a new server. Upgrading to NGX R60 while avoiding unnecessary risks to the production SmartCenter server in case of failure during the upgrade process. In order to avoid unnecessary risks, it is possible to migrate the current configuration of the production SmartCenter server, to a new SmartCenter Server. Once this is completed an upgrade process should be performed on the migrated server, leaving the production SmartCenter intact. When migrating to a new SmartCenter Server the destination server should have the same IP configuration as the original SmartCenter Server. If you are migrating to a new machine with a different IP address it is important you perform a number of steps before and after the migration.

In This Section
Advanced Upgrade page 67

Steps Required for Migrating a SmartCenter Server to a New Machine with a Different IP Address page 68 Advanced Upgrade This section explains the steps that should be performed when performing an advanced upgrade on an additional SmartCenter Server via a spare machine. 1 2 Insert the NGX R60 CD into the original SmartCenter Server. Choose Export in Upgrade Options. If you chose to perform the Export procedure manually make sure you are using the NGX R60 Export tool. Select the destination path of the configuration (.tgz) file. Wait while exporting database files.
Chapter 4 Upgrading a Distributed VPN-1 Pro/Express Deployment 67

Upgrading the SmartCenter Server Component

4 5 6

Copy the exported.tgz file to the new SmartCenter Server. Insert the NGX R60 CD into the new SmartCenter Server. Select Installation using Imported Configuration (Windows) or Advanced Upgrade (Solaris) in the Installation Options. This option prompts you for the location of the imported .tgz configuration file and then automatically installs the new software and utilizes the imported .tgz configuration file.
Warning - The configuration file (.tgz) file contains your security configuration. It is highly recommended to delete it after completing the import process.

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

On the original SmartCenter Server add rules that will allow the new SmartCenter to access the modules it is managing. To do this create a SmartCenter object that represents the new SmartCenter Servers IP address: Manage > Network Objects > New > Check Point > Host/Gateway and in the General Properties tab select Secondary SmartCenter Server in the Check Point Products section. On the original SmartCenter Server, create a security rule that allows FW1 (TCP 256) and CPD (TCP 18191) services to originate from the new SmartCenter Server whose destination is all available Enforcement Modules. Install the new security policy on all Enforcement Modules. Follow the Advanced Upgrade page 67 process to migrate your original SmartCenter Server.

3 4

After migrating your original SmartCenter Server

Update the SmartCenter licenses with the new IP address. If central licenses are used for the modules, they should also be updated with the new IP Address. Refer to the Upgrading VPN-1 Pro/Express Licenses page 17 for additional information.

68

Migrate your Current SmartCenter Configuration and Upgrade

2 3 4 5 6

Using the cpstart command start the new SmartCenter Server. Access the new SmartCenter Server using SmartDashboard. On the new SmartCenter Server update the primary SmartCenter object so that its IP Address and topology match its new configuration. On the new SmartCenter Server remove the object you created to represent the new SmartCenter Servers IP address (refer to step 1 in the previous section). On the DNS Server map the Primary SmartCenter Servers DNS to the new IP address.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

69

Upgrading the Enforcement Module

Upgrading the Enforcement Module


There are two upgrade methods available: SmartUpdate Upgrade Allows you to centrally upgrade and manage Check Point software and licenses. Local Upgrade Performs a local upgrade on the Enforcement Module itself.

In This Section
Upgrading a Clustered Deployment Upgrading the Enforcement Module Using SmartUpdate Enforcement Module Upgrade Process on a Windows Platform Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions Enforcement Module Upgrade on a Solaris Platform Enforcement Module Upgrade on an IPSO Platform page 71 page 71 page 75 page 76 page 79 page 80

Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 page 77

70

Upgrading a Clustered Deployment

Upgrading a Clustered Deployment


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

Upgrading the Enforcement Module Using SmartUpdate


SmartUpdate is an optional module for VPN-1 Pro that automatically distributes software packages and remotely performs upgrades of enforcement modules and various OPSEC products. It provides a centralized means to guarantee that the latest software versions are used throughout the enterprise network. SmartUpdate turns time-consuming tasks that could otherwise be performed only by experts into simple point and click operations.
Note - When upgrading the Enforcement Module, all SmartUpdate packages (excluding SofaWare firmware packages) are deleted from the SmartUpdate Repository.

The following is a list of the products that can be upgraded to NGX R60: VPN-1 Pro Enforcement Modules SecurePlatform Performance Pack SmartView Monitor (when it is a part of the NGX R60 software package) Eventia Reporter UserAuthority PolicyServer (when it is a part of the NGX R60 software package) QoS Nokia OS

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

71

Upgrading the Enforcement Module

SmartUpdate Available Options SmartUpdate is the primary tool used for upgrading Check Point gateways. Within SmartUpdate, there are some features and tools for your convenience: 1 SmartUpdates Upgrade All Packages - This feature allows you to upgrade all packages installed on a gateway. For IPSO and SecurePlatform, this feature also allows you to upgrade your operating system as a part of your upgrade. SmartUpdates Add Package to Repository - SmartUpdate provides three tools for adding packages to the Package Repository: From CD - add a package from the Check Point CD. From File - add a package that you have stored locally. From Download Center - add a package from the Check Point Download Center. SmartUpdates Get Check Point Gateway Data - This tool updates SmartUpdate with the current Check Point or OPSEC third party packages installed on a specific gateway or for your entire enterprise.

Configuring the SmartCenter Server for SmartUpdate 1 Install the latest version of SmartConsole, including SmartUpdate.
Note - SmartUpdate is available as part of SmartCenter Pro.

2 3 4 5

Define the remote Check Point gateways in SmartDashboard (for a new SmartCenter Server installation). Verify that your SmartCenter Server contains the correct license to use SmartUpdate. Verify that the Administrator SmartUpdate permissions (as defined in the cpconfig configuration tool) are Read/Write. To enable SmartUpdate connections to the enforcement modules, make sure that
Policy Global Properties > FireWall-1 Implied Rules > Accept CPRID Connections

(SmartUpdate) is checked. By default, it is checked.

72

Upgrading the Enforcement Module Using SmartUpdate

Add Packages to the Package Repository Use SmartUpdate to add packages to and delete packages from the Package Repository: directly from the Check Point Download Center web site (Packages > Add > From Download Center...), by adding them from the Check Point CD (Packages > Add > From CD...), by importing a file (Packages > Add > From File...). When adding the package to the Package Repository, the package file is transferred to the SmartCenter Server. When the Operation Status window opens, you can verify the success of the operation. The Package Repository is then updated to show the new package object. Enforcement Module Upgrade Process Using SmartUpdate 1 From SmartUpdate > Packages > Upgrade All Packages select one or more Enforcement Modules and click Continue. At this point the Upgrade All Packages window opens in the Upgrade Verification list you can see which gateways can or cannot be upgraded. To see a list of which packages will be installed on the gateways that can be upgraded, select the gateway and click the Details button. For an explanation as to why a gateway cannot be upgraded, select the relevant gateway and click the Details button. From the list provided select the gateways that can be upgraded and click
Upgrade.

Note - the Allow reboot... option (checked by default) is required in order to activate the newly installed packages.

The Operation Status pane opens and shows the progress of the installation. Each operation is represented by a single entry. Double click the entry to open the Operation Details window, which shows the operation history. The following operations are performed during the installation process; cprid (Check Point Remote Installation Daemon) connection to the Check Point gateway. Verification for sufficient disk space. Verification of the package dependencies. The package is transferred to the gateway if it is not already there. The package is installed on the gateway. Enforcement policies are compiled for the new version.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

73

Upgrading the Enforcement Module

The gateway is rebooted if the Allow Reboot... option was selected and the package requires it. The gateway version is updated in SmartDashboard. The installed packages are updated in SmartUpdate. Upgrading a Single Product on a Check Point Node The following procedure can be used to upgrade Enforcement Modules to versions prior to NGX R60, using SmartUpdate NGX R60. Upgrading to the following versions using SmartUpdate NGX R60 is supported: R54 R55 R55W R55P R60 To upgrade an Enforcement Module to one of these versions: 1 2 3 Add the corresponding packages to the
Package Repository. Distribute Package... Distribute.

Right-click the Enforcement Module and select

Select the relevant package from the list provided and click

Repeat steps 2 to 3 for every package that should be installed on the Enforcement Module.
Note - it is also possible to use SmartUpdate to install HFAs on Enforcement Modules from previous versions (for example, R54 and later).

74

Enforcement Module Upgrade Process on a Windows Platform

Enforcement Module Upgrade Process on a Windows Platform


The following upgrade steps describe the upgrade process using the NGX R60 Installation CD. 1 2 3 4 Access your NGX R60 CD. Execute the Installation package. Select
Upgrade

from the

Upgrade Options

screen.

You are presented with three upgrade options: Download Most Updated Upgrade Utilities (recommended method) This download provides the most recent upgrade code available.
I have already downloaded and extracted the Upgrade Utilities. The files are on my local disk.

This option should be used when software packages were previously downloaded. This method is useful when internet access is not available from the SmartCenter Server machine. Use the CD version. 5 When the pre-upgrade verification recommendation appears, select whether or not the Pre upgrade verification tool should be executed (refer to the Using the Pre Upgrade Verification Tool on page 59). The Pre-upgrade verification will perform a compatibility analysis of the current installed SmartCenter Server and of its current configuration. A detailed report is provided, supplying appropriate actions that should be taken before and after the upgrade process. The tool can be used manually as well. Select Upgrade again from the Upgrade Options screen. At this point, another verification will run. When prompted, reboot your Enforcement Module Server. After you complete the upgrade process perform the following: a Using SmartDashboard login to the NGX R60 SmartCenter Server that controls the upgraded Enforcement Module. b Open the gateway object properties window that represents the upgraded Enforcement Module and change the version to NGX R60. c Perform Install Policy on the upgraded Enforcement Module. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information.

6 7 8

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

75

Upgrading the Enforcement Module

Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions


Upgrading to NGX R60 over a SecurePlatform operating system requires updating both the operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. Using a CD ROM The following steps depict how to upgrade SecurePlatform R54 and later versions using a CD ROM drive. 1 2 3 4 Log into SecurePlatform (Expert mode is not necessary). Apply the SecurePlatform NGX R60 upgrade package: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

If you select Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process. 5 After you complete the upgrade process perform the following: a Using SmartDashboard login to the NGX R60 SmartCenter Server that controls the upgraded Enforcement Module. b Open the gateway object properties window that represents the upgraded Enforcement Module and change the version to NGX R60.

76

Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2

c Perform Install Policy on the upgraded Enforcement Module.

Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2


Upgrading to NGX R60 over a SecurePlatform operating system requires updating both operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. The following steps depict how to upgrade SecurePlatform NG FP2, FP3, or FP3 Edition 2. Upgrading pre R54 versions requires an upgrade of the patch command. 1 2 3 Insert the SecurePlatform NGX R60 CD into the drive. Enter the
Expert

mode: # expert.

Upgrade the patch command by selecting the following option: Update the patch command using a CD ROM drive. Mount the CD using the following syntax:
# mount /mnt/cdrom # patch add /mnt/cdrom/SecurePlatform/patch/CPpatch_command_*.tgz.

Apply the SecurePlatform NGX R60 upgrade package by using a CD ROM drive with the following command: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

5 6

If you chose Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.
Chapter 4 Upgrading a Distributed VPN-1 Pro/Express Deployment 77

Upgrading the Enforcement Module

After you complete the upgrade process perform the following: a Using SmartDashboard login to the NGX R60 SmartCenter Server that controls the upgraded Enforcement Module. b Open the gateway object properties window that represents the upgraded Enforcement Module and change the version to NGX R60. c Perform Install Policy on the upgraded Enforcement Module.

If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information.

78

Enforcement Module Upgrade on a Solaris Platform

Enforcement Module Upgrade on a Solaris Platform


This section describes the steps that should be performed when performing an upgrade on a Solaris Platform. 1 2 3 4 5 6 7 8 Insert the NGX R60 CD into the CD drive. Run UnixInstallScript from the root directory of the NGX R60 CD. Select
Yes

if you agree to the license terms.

A list of the existing products appears. Select Next (N) to continue. A list of products appears and you are asked to select the products that you would like to install. Select Next (N) to continue. At this point you are asked to
reboot

the machine. Select Yes (Y).

After you complete the upgrade process perform the following: a Using SmartDashboard login to the NGX R60 SmartCenter Server that controls the upgraded Enforcement Module. b Open the gateway object properties window that represents the upgraded Enforcement Module and change the version to NGX R60. c Perform Install Policy on the upgraded Enforcement Module.

If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

79

Upgrading the Enforcement Module

Enforcement Module Upgrade on an IPSO Platform


This section describes the steps that should be performed when performing an upgrade on an IPSO Platform. 1 2 3 Enter Network Voyager and open a CLI console. Click
System Configuration > Install New IPSO Image (Upgrade). The New Image Installation Upgrade

window appears.

Enter the following information:


Enter URL to the image location Enter HTTP Realm (for HTTP URLs only) Enter Username (if applicable) Enter Password (if applicable)

Click Apply. At this point you are informed that the file download and image installation can take a long time. Click
Apply.

5 6

At this point you will receive a message that the new image installation process has started. When you receive a Success message click UP > UP > Manage IPSO Images. The IPSO Image Management window appears. Under the title Click
Select an image for next boot,

7 8 9

select the last downloaded image.

Test Boot. Commit testboot

In the window that appears select

and click

Apply.

10 Access the CLI console to see when the Reboot is complete. Once the Reboot is complete go back to Network Voyager (that is, step 10) to verify that the image was set properly. 11 In the Network Voyager, click
Refresh

and Login.

12 If you are not returned to the last window you were in click System Configuration > Manage IPSO Images. At this point, you should be able to see that the relevant IPSO Image is selected. 13 Access the CLI console and login. 14 Perform an
FTP

using

bin

mode to transfer the package.

15 Type newpkg -S -m LOCAL -n <CPsuite package path> -o $FWDIR and press Enter. At this point the package is loaded and the following products are upgraded:
80

Enforcement Module Upgrade on an IPSO Platform

CPshared VPN-1/FW-1 Once the process is complete you should receive a message that states that the process was a success. 16 Type
Reboot

and press

Enter.

17 Log into Network Voyager and select


System Configuration > Manage Install Packages.

18 Under 19 Click

Applications

select

Off

in the following line:

Check Point CPinfo NG with Application Intelligence (R55) Apply. Applications

20 Under 21 Click

select

Off

in the following line:

Check Point SVN Foundation NG with Application Intelligence (R55) Apply.

22 Click Save. At this point you should receive a message that states that the process was a success. 23 Return to the CLI console and type
Reboot.

24 Login and type CPconfig. The following questions appears: Do you want to add licenses (y/n)? If you type y answer the questions that appear. Configure Administrators: Do you want to modify this list (y/n)? If you type y answer the questions that appear. With CPconfig you can only define one administrator. Configure Group Permissions: Please specify group name [(RET) for Super-user
group]:

Enter the name and press 25 Select


y

Enter.

to reboot.

26 After you complete the upgrade process perform the following: a Using SmartDashboard login to the NGX R60 SmartCenter Server that controls the upgraded Enforcement Module. b Open the gateway object properties window that represents the upgraded Enforcement Module and change the version to NGX R60.

Chapter 4

Upgrading a Distributed VPN-1 Pro/Express Deployment

81

Upgrading the Enforcement Module

c Perform Install Policy on the upgraded Enforcement Module. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information.

82

CHAPTER

Upgrading a Standalone VPN-1 Pro/Express Deployment


In This Chapter
Introduction Pre-Upgrade Considerations Standalone VPN-1 Gateway Upgrade on a Windows Platform page 83 page 84 page 87

Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions page 88 Standalone VPN-1 Gateway Upgrade on SecurePlatform NG FP2, FP3, FP3 Edition 2 page 89 Standalone VPN-1 Gateway Upgrade on a Solaris Platform Standalone VPN-1 Gateway Upgrade on an IPSO Platform Migrate your Current VPN-1 Gateway Configuration and Upgrade page 90 page 91 page 93

Introduction
This chapter describes the process of upgrading a VPN-1 standalone deployment to NGX R60. A standalone deployment consists of the SmartCenter Server and enforcement module installed on the same system.

83

Pre-Upgrade Considerations

With a Standalone deployment backward compatibility is supported for previous versions. That is, a Standalone gateway can enforce and manage enforcement modules from previous versions, even though new features may not be available to enforcement modules from earlier versions. Before upgrading the software, it is highly recommended to upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. If necessary, license upgrade can be done after the software upgrade. See Upgrading VPN-1 Pro/Express Licenses on page 17 for details. Use of the Pre-Upgrade verification tool can reduce the risk of incompatibility with the deployment to NGX R60 since it is used to test the current VPN-1 Pro gateway prior to upgrading to NGX R60. The Pre-Upgrade verification tool produces a detailed report of what should be done before performing an upgrade to NGX R60 (refer to the Using the Pre-Upgrade Verification Tool on page 85). There are two upgrade methods available for a Standalone deployment: Upgrade your Current Production VPN-1 Pro Gateway Perform the upgrade process on the production VPN-1 Pro gateway (refer to the Standalone VPN-1 Gateway Upgrade on a Windows Platform on page 87). Migrate and Upgrade to a New VPN-1 Gateway Perform a migration process (refer to the Migrate your Current VPN-1 Gateway Configuration and Upgrade on page 93) of the currently installed version to a new server, and upgrade the migrated system. Performing the upgrade on a new machine, enables the production VPN-1 Pro gateway to remain fully operational and reduces unnecessary risks.

Pre-Upgrade Considerations
In This Section
License Upgrade to NGX Upgrading Products on a SecurePlatform Operating System Reverting to your Previous Software Version Using the Pre-Upgrade Verification Tool page 84 page 85 page 85 page 85

License Upgrade to NGX


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function.

84

Upgrading Products on a SecurePlatform Operating System

It is highly recommended to upgrade licenses before upgrading the software. If necessary, license upgrade can be done after the software upgrade. See Upgrading VPN-1 Pro/Express Licenses on page 17 for details.

Upgrading Products on a SecurePlatform Operating System


Upgrading to NGX R60 over a SecurePlatform operating system requires upgrading both the operating system and software products installed. To upgrade products installed on SecurePlatform, follow the Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions section about the specific component. The process described in this section will result with an upgrade of all components installed (Operating System and software packages) in a single upgrade process. No further upgrades are required.

Reverting to your Previous Software Version


To revert to the software version prior to the upgrade, uninstall the upgraded software version and installation packages and restart the system. For additional information refer to Revert to your Previous Deployment on page 50

Using the Pre-Upgrade Verification Tool


Automatic pre-upgrade verification runs automatically (or manually if desired) during your VPN-1 Pro upgrade. Pre-upgrade verification performs a compatibility analysis of the currently installed deployment and its current configuration. A detailed report is provided, supplying appropriate actions that should be taken before and after the upgrade process. This tool can also be used manually.

Chapter 5

Upgrading a Standalone VPN-1 Pro/Express Deployment

85

Pre-Upgrade Considerations

Usage:
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -t TargetVersion [-f FileName] [-w]

or
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -i[-f FileName][-w]

-p -c -t -i -f -w

Path of the installed SmartCenter Server (FWDIR) Currently installed version Target version Check originality of INSPECT files only Output in file Web format file

Where the currently installed version is one of the following: NG NG_FP1 NG_FP2 NG_FP3 NG_AI The target version is: NGX R60
-f

redirects the standard output to a file.

Action Items Before and After the Pre-Upgrade Process errors - Items that must be repaired before and after performing the upgrade. If you proceed with the upgrade while errors exist, your upgrade will fail. warning - Items that you should consider repairing before and after performing the upgrade.

86

Using the Pre-Upgrade Verification Tool

Standalone VPN-1 Gateway Upgrade on a Windows Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. The following upgrade steps describe the upgrade process using the NGX R60 CD. 1 2 3 4 Access your NGX R60 CD Execute the Installation package. Select
Upgrade

from the

Upgrade Options

screen.

When the pre-upgrade verification recommendation appears, select whether or not the Pre upgrade verification tool should be executed (refer to the Using the Pre-Upgrade Verification Tool on page 85). Pre-upgrade verification will perform a compatibility analysis of the currently installed VPN-1 gateway and of its current configuration. A detailed report is provided, supplying appropriate actions that should be taken before and after the upgrade process. The tool can be used manually as well. Select Upgrade again, from the Upgrade Options screen. At this point, another verification will run. When prompted, reboot your VPN-1 Pro Server.

5 6

Chapter 5

Upgrading a Standalone VPN-1 Pro/Express Deployment

87

Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions

Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions
Upgrading to NGX R60 over a SecurePlatform operating system requires updating both operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. The following steps depict how to upgrade SecurePlatform R54 and later versions using a CD ROM. 1 2 3 4 Log into SecurePlatform (Expert mode is not necessary). Apply the SecurePlatform NGX R60 upgrade package: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

If you select Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

88

Using the Pre-Upgrade Verification Tool

Standalone VPN-1 Gateway Upgrade on SecurePlatform NG FP2, FP3, FP3 Edition 2


Upgrading to NGX R60 over a SecurePlatform operating system requires updating both operating system and software products installed. SecurePlatform users should follow the relevant SecurePlatform upgrade process. The process described in this section will result with an upgrade of all components (Operating System and software packages) in a single upgrade process. No further upgrades are required. Refer to NGX R60 SecurePlatform Guide for additional information. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. Upgrading pre R54 versions requires an upgrade of the patch command. 1 2 3 Insert the SecurePlatform NGX R60 CD into the drive. Enter the
Expert

mode: # expert.

Upgrade the patch command by selectingthe following option: Update the patch command using a CD ROM drive:
# mount /mnt/cdrom # patch add /mnt/cdrom/SecurePlatform/patch/CPpatch_command_*.tgz.

Apply the SecurePlatform NGX R60 upgrade package by using a CD ROM drive with the following command: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

5 6

If you chose Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

Chapter 5

Upgrading a Standalone VPN-1 Pro/Express Deployment

89

Standalone VPN-1 Gateway Upgrade on a Solaris Platform

Standalone VPN-1 Gateway Upgrade on a Solaris Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. This section describes the steps that should be performed when performing an upgrade on a Solaris Platform. 1 2 3 4 5 6 Insert the NGX R60 CD into the CD drive. Run UnixInstallScript. Select
Yes

if you agree to the license terms.

A list of products appears and you are asked to select the products that you would like to install. Select Next (N) to continue. At this point you are asked to reboot the machine. Select Yes (Y).

90

Using the Pre-Upgrade Verification Tool

Standalone VPN-1 Gateway Upgrade on an IPSO Platform


It is recommended that before you perform an upgrade process, you should backup your current configuration, incase the upgrade process is unsuccessful. For additional information refer to Introduction on page 45. If a situation arises in which a revert to your previous configuration is required refer to Revert to your Previous Deployment on page 50 for detailed information. This section describes the steps that should be performed when performing an upgrade on an IPSO Platform. 1 2 3 Enter Network Voyager and open a CLI console. Click
System Configuration > Install New IPSO Image (Upgrade). The New Image Installation Upgrade

window appears.

Enter the following information:


Enter URL to the image location Enter HTTP Realm (for HTTP URLs only) Enter Username (if applicable) Enter Password (if applicable)

Click Apply. At this point you are informed that the file download and image installation can take a long time. Click
Apply.

5 6

At this point you will receive a message that the new image installation process has started. When you receive a Success message click UP > UP > Manage IPSO Images. The IPSO Image Management window appears. Under the title Click
Select an image for next boot,

7 8 9

select the last downloaded image.

Test Boot. Commit testboot

In the window that appears select

and click

Apply.

10 Access the CLI console to see when the Reboot is complete. Once the Reboot is complete go back to Network Voyager (that is, step 10) to verify that the image was set properly. 11 In the Network Voyager, click
Refresh

and Login.

12 If you are not returned to the last window you were in click System Configuration > Manage IPSO Images. At this point, you should be able to see that the relevant IPSO Image is selected.
Chapter 5 Upgrading a Standalone VPN-1 Pro/Express Deployment 91

Standalone VPN-1 Gateway Upgrade on an IPSO Platform

13 Access the CLI console and login. 14 Perform an


FTP

using

bin

mode to transfer the package.

15 Type newpkg -S -m LOCAL -n <CPsuite package path> -o $FWDIR and press Enter. At this point the package is loaded and the following products are upgraded: CPshared VPN-1/FW-1 SmartCenter Floodgate (Qos) SmartView Monitor Once the process is complete you should receive a message that states that the process was a success. 16 Type
Reboot

and press

Enter.

17 Log into Network Voyager and select


System Configuration > Manage Install Packages.

18 Under 19 Click

Applications

select

Off

for the following:

Check Point CPinfo NG with Application Intelligence (R55) Apply. Applications

20 Under 21 Click

select

Off

for the following:

Check Point SVN Foundation NG with Application Intelligence (R55) Apply.

22 Click Save. At this point you should receive a message that states that the process was a success. 23 Return to the CLI console and type
Reboot.

24 Login and type CPconfig. The following questions appears: Do you want to add licenses (y/n)? If you type y answer the questions that appear. Configure Administrators: Do you want to modify this list (y/n)? If you type y answer the questions that appear. With CPconfig you can only define one administrator. Configure Group Permissions: Please specify group name [(RET) for Super-user
group]:

Enter the name and press 25 Select


92
y

Enter.

to reboot.

Using the Pre-Upgrade Verification Tool

Migrate your Current VPN-1 Gateway Configuration and Upgrade


The motivations for performing an advanced upgrade are: Upgrading to NGX R60 while replacing the Operating System on which the current VPN-1 gateway is installed on. Upgrading to NGX R60 while migrating to a new server. Upgrading to NGX R60 while avoiding unnecessary risks to the production VPN-1 gateway in case of failure during the upgrade process. In order to avoid unnecessary risks, it is possible to migrate the current configuration of the production VPN-1 gateway, to a spare server. Once this is completed an upgrade process should be performed on the migrated server, leaving the production VPN-1 gateway intact. This section explains the steps that should be performed when performing an advanced upgrade on an additional VPN-1 gateway via a spare machine. 1 2 Insert the NGX R60 CD into the original VPN-1 gateway. Choose Export in Upgrade Options. If you chose to perform the Export procedure manually make sure you are using the NGX R60 Export tool. Select the destination path of the configuration (.tgz) file. Wait while exporting database files. Copy the exported.tgz file to the new VPN-1 gateway server. Insert the NGX R60 CD into the new VPN-1 gateway. Select Installation using Imported Configuration (Windows) or Advanced Upgrade (Solaris) in the Installation Options. This option prompts you for the location of the imported .tgz configuration file and then automatically installs the new software and utilizes the imported .tgz configuration file.
Warning - The configuration file (.tgz) file contains your security configuration. It is highly recommended to delete it after completing the import process.

3 4 5 6 7

Chapter 5

Upgrading a Standalone VPN-1 Pro/Express Deployment

93

Migrate your Current VPN-1 Gateway Configuration and Upgrade

94

CHAPTER

Upgrading ClusterXL
In This Chapter
License Upgrade to NGX Tools for Gateway Upgrades Planning a Cluster Upgrade Performing a Minimal Effort Upgrade on a ClusterXL Cluster Performing a Zero Down Time Upgrade on a ClusterXL Cluster Performing a Full Connectivity Upgrade on a ClusterXL Cluster page 95 page 95 page 97 page 98 page 98 page 102

License Upgrade to NGX


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. It is highly recommended to upgrade licenses before upgrading the software. If necessary, license upgrade can be done after the software upgrade. See Upgrading VPN-1 Pro/Express Licenses on page 17 for details.

Tools for Gateway Upgrades


1 SmartUpdates Upgrade All Packages Feature - This feature allows you to upgrade all packages installed on a gateway. For IPSO and SecurePlatform, this feature also allows you to upgrade your Operating System as a part of your upgrade. SmartUpdates Add Package to Repository - SmartUpdate provides three tools for adding packages to the Package Repository: From CD - add a package from the Check Point CD. From File - add a package that you have stored locally.

95

Tools for Gateway Upgrades

SmartUpdates Get Check Point Gateway Data - This tool updates SmartUpdate with the current Check Point or OPSEC third party packages installed on a specific gateway or for your entire enterprise.

96

Upgrading a Clustered Deployment with Cluster Members from Different Versions

Planning a Cluster Upgrade


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

When upgrading from R55W to NGX R60 refer to NGX R60 Release Notes for details about support of Web Intelligence and VoIP Application Intelligence features on Load Sharing Clusters.

Upgrading a Clustered Deployment with Cluster Members from Different Versions


When there are cluster members from different versions on the same synchronization network, the cluster members with the previous version will become active and the cluster members with the new (latest) version will remain in a special state called Ready. In this state the cluster members with the new version do not process any traffic destined for the cluster IP. During the upgrade this behavior is the expected behavior. But, if you wish to avoid such a situation (for example, during downgrade), you should physically (or using ifconfig) disconnect the cluster interfaces and the synchronization network of that cluster member prior to the downgrade process.

Chapter 6

Upgrading ClusterXL

97

Performing a Minimal Effort Upgrade on a ClusterXL Cluster

Upgrading OPSEC Certified Third Party Clusters Products


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

Performing a Minimal Effort Upgrade on a ClusterXL Cluster


If it is your intention to perform a Minimal Effort Upgrade, meaning you can afford to have a period of time during which network downtime is allowed, you will be treating cluster members as individual gateways. In other words, each cluster member can be upgraded in the same way you upgrade an individual gateway member. Please refer to Distributed deployments (refer to the Upgrading a Distributed VPN-1 Pro/Express Deployment on page 55) for additional instructions about this method.

Performing a Zero Down Time Upgrade on a ClusterXL Cluster


Supported Modes
Zero Downtime is supported on all modes of ClusterXL including IPSOs IP clustering and VRRP. For additional third party clustering solutions please consult your third party solutions guide. Upgrade All but One of the Cluster Members 1 Run cphaconf set_ccp broadcast on all cluster members. This will turn the cluster control protocol to broadcast instead of multicast and will insure that during the upgrade the new upgraded members stay in the Ready state as long as a previous version member is active. In previous versions, there was a message that told you to reboot the cluster members in order to fully activate the change. This message should be ignored, no reboot is required.

98

Supported Modes

Suppose cluster member A is the active member, and members B and C are standby members. In Load Sharing mode, randomly choose one of the cluster members to upgrade last. Ensure that the previously upgraded NGX licenses are attached to members B and C Attach the previously upgraded licenses to cluster members B and C as follows: At the SmartConsole GUI machine, open SmartUpdate, and connect to the SmartCenter Server. The updated licenses are displayed as Assigned. Use the Attach assigned licenses option to Attach the Assigned licenses to the cluster members. Upgrade cluster members B and C either: Using SmartUpdate In Place When the upgrade of B and C is complete, reboot both of them.

Continue with the process according to one of the following scenarios: Skip to step 6 if you are upgrading from NG with Application Intelligence (R54 and above). When machines B and C are up again, change the cluster version in SmartDashboard to NGX R60. Skip to step 7 if you are running SmartUpdate. SmartUpdate compiles and installs an updated policy on the new member, once it is rebooted. Installing the policy: If you are upgrading from NG with Application Intelligence (R54 and above) install the policy. Be aware that policy installation on the old Check Point gateway may cut connections for services that do not survive policy installation This can be avoided by configuring the Check Point Gateway > Advanced > Connection Persistence tab to either Keep all connections or Keep data connections. For complete instructions, when you are in the Connection Persistence tab click on the help button.
Note - Do not change any cluster parameters from the current policy in this stage. For example, if the cluster is running in New High Availability mode, do not change it to LS. Changes can be made after the upgrade process is complete.

If you are upgrading from previous versions, perform the following steps: i From the under the
Policy Installation

window, deselect the

For Gateway Clusters,

install on all the members, if it fails do not install at all Install on each selected Module independently

checkbox located radio button.

Chapter 6

Upgrading ClusterXL

99

Performing a Zero Down Time Upgrade on a ClusterXL Cluster

ii Install the security policy on the cluster. The policy will be successfully installed on cluster members B and C, and will fail on member A. 7 Using "cphaprob stat" command (executed on a cluster member) verify that the status of cluster member A is Active or Active Attention. The remaining cluster members will have a Ready status. The status Active Attention will be given if member As synchronization interface reports that its outbound status is down, because it is no longer communicating with other cluster members. When upgrading versions prior to NGX R60, execute fw ctl setsync off on Cluster member A. Execute the command cphastop on cluster member A. At this point machines B and/or C will start processing traffic (depending on whether this is a Load Sharing or High Availability configuration).

8 9

10 From this point on, it is recommended that you do not install a new policy on the cluster until the last member has been upgraded. If you must install a new policy, please perform the following steps: i Run cpstop on the old Check Point gateway.

ii Run fw ctl set int fwha_conf_immediate 1 on all new Check Point gateways. iii Install policy.
Note - It is recommended that you keep the time in which cluster members are running different versions to a minimum.

Upgrade the Final Cluster Member 11 Attach the previously upgraded licenses to cluster member A as follows: At the SmartConsole GUI machine, open SmartUpdate, and connect to the SmartCenter Server. The updated licenses are displayed as Assigned. Use the Attach assigned licenses option to Attach the Assigned licenses to the cluster member. 12 Upgrade cluster member A by either: Using SmartUpdate In Place 13 Reboot cluster member A.

100

Supported Modes

14 Run cphaconf set_ccp multicast followed by cphastart on all cluster members. This will turn the cluster control protocol back to multicast instead of broadcast. This step can be skipped if you prefer to remain working with the cluster control protocol in the broadcast mode.

Chapter 6

Upgrading ClusterXL

101

Performing a Full Connectivity Upgrade on a ClusterXL Cluster

Performing a Full Connectivity Upgrade on a ClusterXL Cluster


Understanding a Full Connectivity Upgrade
The Full Connectivity Upgrade (FCU) method assures that during an upgrade from NGX (R60) to a future NGX minor version, synchronization is possible from old to new cluster members without losing connectivity. Connections that have been opened on the old cluster member will continue to live on the new cluster member without interrupting your clients.
Note - When upgrading to NGX R60 from a version prior to NGX R60: Due to the absence of synchronization between an older version cluster member and an NGX R60 version cluster member, during upgrade, existing connections are cut when switching from an old to a new member. For additional information please refer to NGX R60 Release Notes.

Supported Modes
FCU is supported on all modes of ClusterXL including IPSOs IP clustering and VRRP. Legacy High Availability is not supported in FCU. For other third partys support please refer to the third partys documentation.

Terminology
FCU - An abbreviation for Full Connectivity Upgrade. NM - An abbreviation for the already upgraded member during the upgrade. This Check Point Gateway contains a newer version. It is in the non-active state. OM - An abbreviation for the old member that has not yet been upgraded. It carries all the traffic. It is in the active state. Pre-Requisite for using the Full Connectivity Upgrade Make sure that the NM and the OM contain the same firewall policy and product installation. Do not change the policy during the upgrade from the last policy installed on the Check Point Gateway prior to its upgrade. Make sure the upgraded version is at least NGX R60 or higher. Full Connectivity Upgrade Limitations 1 This upgrade procedure is equivalent to a failover in a cluster where both members are of the same version. Therefore, whatever would not normally survive failover also will not survive a Full Connectivity Upgrade. This includes security servers and services that are marked as non-synced or local connections.

102

Implementing a Full Connectivity Upgrade

The exact same products must be installed on the OM and on the NM. For example, it is not possible to perform FCU from a Check Point Gateway that has Floodgate-1 installed to a newer Check Point Gateway that does not have Floodgate-1 installed. Verify by running the command fw ctl conn on both cluster members. An example output on the NM:
Registered connections modules: No. Name Newconn Packet End Reload Dup Type Dup Handler 0: Accounting 00000000 00000000 d08ff920 00000000 Special d08fed58 1: Authentication d0976098 00000000 00000000 00000000 Special d0975e7c 3: NAT 00000000 00000000 d0955370 00000000 Special d0955520 4: SeqVerifier d091e670 00000000 00000000 d091e114 Special d091e708 6: Tcpstreaming d0913da8 00000000 d09732d8 00000000 None 7: VPN 00000000 00000000 d155a8d0 00000000 Special d1553e48

Verify that the list of Check Point Gateway names is the same for both cluster members. 3 Verify that all the Firewall-1 Check Point Gateway configuration parameters have the same values on the NM and the OM. The same rule applies to any other local configurations you may have set. For example having the attribute block_new_conns with different values on the NM and on the OM might fail your FCU because FireWall-1 behavior cannot be changed during the upgrade. A cluster that performs static NAT using Firewall-1s automatic proxy ARP feature requires special considerations: cpstop the old Check Point Gateway right after running cphastop. Running cphastop is part of the upgrade procedure listing in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 98. Not doing so may fail some of the connections that rely on proxy ARP and may cause other connections that rely on proxy ARP not to open, until the upgrade process completes. However note that doing cpstop on the old Check Point Gateway rules out the option to rollback to the OM while maintaining all live connections that were originally created on the OM.

Implementing a Full Connectivity Upgrade


Upgrading a cluster with 2 members Follow the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 98. Before you get to step 9 on page 100 (executing cphastop), run this command on the upgraded member: fw fcu <other member ip on sync network>(e.g. fw fcu 172.16.0.0). then continue with step 9 on page 100.
Chapter 6 Upgrading ClusterXL 103

Performing a Full Connectivity Upgrade on a ClusterXL Cluster

Upgrading a cluster with 3 or more members Choose one of the following two methods: 1 Upgrade the two NMs by following the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 98. Before you get to step 9 on page 100 (executing cphastop), run this command on all the upgraded members: fw fcu <other member ip on sync network> then continue with step 9 on page 100 on the single OM. or First upgrade one member only, by following the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 98. Before you get to step 9 on page 100 (executing cphastop), run this command on all the upgraded members: fw fcu <other member ip on sync network> then continue with step 9 on page 100 on all remaining OMs.

With more than 3 members divide the upgrade of your members so that the active cluster members can handle the amount of traffic during the upgrade.
Note - cphastop can also be performed from the Cluster object in the SmartView Monitor SmartConsole. Once cphastop is performed do not run cpstart or cphastart again or try rebooting the machine.

104

Implementing a Full Connectivity Upgrade

Monitoring the Full Connectivity Upgrade


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

During FCU This should be yes only after running the fw fcu command and before running cphastop on the final OM. In all other cases it should be no. Number of connection modules Safe to ignore. Connection module map The output reveals a translation map from the OM to the NM. See Full Connectivity Upgrade Limitations on page 102 for further information. Table id map This shows the mapping between FireWall-1 kernel table indices on the OM and on the NM. Having a translation is not mandatory. Table handlers This should include a sip_state and connection table handlers. In a VPN-1 Pro/Express configuration a VPN handler should also be included. Global handlers Reserved for future use.

Chapter 6

Upgrading ClusterXL

105

Performing a Full Connectivity Upgrade on a ClusterXL Cluster

Display the Connections Table (fw tab -t connections -u [-s])

This command displays the connection table. If everything was synchronized correctly the number of entries in this table and the content itself should be approximately the same in the old and new cluster members. This is an approximation because between the time that you run the command on the old and new members new connections may have been created or perhaps old connections were deleted.
Options

-t - table -u - unlimited entries -s - (optional) summary of the number of connections For further information on the fw tab -t connections command see the Command Line Interface Book.
Making adjustments after checking the Connection Table

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

106

CHAPTER

Upgrading Provider-1
In This Chapter
Introduction Provider-1/SiteManager-1 Upgrade Tools Provider-1/SiteManager-1 License Upgrade Provider-1/SiteManager-1 Upgrade Practices Upgrading in a Multi MDS Environment Restoring your Original Environment Renaming Customers Changing MDS IP address and External Interface page 108 page 111 page 120 page 150 page 161 page 164 page 165 page 169

107

Introduction

Introduction
In This Section
Scope Before You Begin MDS Post Upgrade Procedures Supported Platforms Supported Versions for Upgrade Summary of Sections in this Chapter page 108 page 108 page 160 page 109 page 109 page 109

Scope
This chapter describes methods and utilities for upgrading Provider-1/SiteManager-1 to NGX.

Before You Begin


1 Before performing a Provider-1/SiteManager-1 upgrade read: the latest Provider-1/SiteManager-1 release notes:
http://www.checkpoint.com/support/technical/documents/docs_prov1.html

and the latest Check Point suite release notes:


http://www.checkpoint.com/techsupport/installation/ng/release_notes.html

If difficulties in the upgrade process require that you restore your original environment, follow the step in Restoring your Original Environment on page 164. Read the restoration instructions before you begin, as several actions need to be taken before the upgrade in order to allow the restoration. If you are upgrading a multi-MDS environment refer to Upgrading in a Multi MDS Environment on page 161.

108

Supported Platforms

Supported Platforms
The latest information about supported platforms is always available in the Check Point Release Notes. Download them from:
http://www.checkpoint.com/techsupport/downloads.jsp

Supported Versions for Upgrade


Upgrade of MDS is supported from the following versions: NG with Application Intelligence (R55) - You can directly upgrade to NGX. NG with Application Intelligence (R54) - You can directly upgrade to NGX. NG FP3 HF2 - If you have NG FP3 Edition 1, NG FP3 Edition 2, NG FP3 Edition 3 or NG FP3 HF1: first install the Provider-1/SiteManager-1 NG FP3 HF2 Hotfix or the Hotfix Accumulator Build (HFA). NG FP2 - Upgrade directly to NGX. NG FP1 HF1 - If you need to upgrade from an NG FP1 installation, upgrade to NG FP1 HF1 then upgrade to NG with Application Intelligence (R55). VSX 2.0.1, VSX NG with Application Intelligence R1 and VSX NG with AI Application Intelligence R2 - You can directly upgrade to NGX

Summary of Sections in this Chapter


Introduction page 108 Provider-1/SiteManager-1 Upgrade Tools page 111 Provider-1/SiteManager-1 License Upgrade page 120 Provider-1/SiteManager-1 Upgrade Practices page 150 Upgrading in a Multi MDS Environment page 161 This Section Describes the utilities used in different stages of upgrading and migrating. Specifies the usage of each utility. Describes the various procedures available for upgrading Provider-1 licenses. Description of the upgrade practices supported in MDS. Covers when to use each upgrade practice and how it is implemented using the upgrade tools. Considerations for the multi-MDS environment. Such as the order of the upgrade, synchronization and minimizing server downtime.

Chapter 7

Upgrading Provider-1

109

Introduction

Restoring your Original Environment page 164 Renaming Customers page 165

Special considerations for restoration. How to return to the original version in the middle of the upgrade process. Starting NG with Application Intelligence, The Customer names cannot contain special characters or spaces. This section explains how to rename your Customers during the upgrade. Instructions for moving MDS installation from one machine to a second machine with another IP address and/or an external interface name.

Changing MDS IP address and External Interface page 169

110

Pre-Upgrade Verifiers and Fixing Utilities

Provider-1/SiteManager-1 Upgrade Tools


This section describes the different upgrade and migrate utilities and explains when and how each one of them is used.

In This Section
Pre-Upgrade Verifiers and Fixing Utilities Installation Script pv1_license_upgrade license_upgrade cma_migrate migrate_assist migrate_global_policies Backup and Restore page 111 page 112 page 113 page 114 page 115 page 117 page 117 page 118

Pre-Upgrade Verifiers and Fixing Utilities


Before performing the upgrade of Provider-1/SiteManager-1, Check Point verifies readiness of your current version for the upgrade. Provider-1/SiteManager-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. There are three types of messages given by the pre-upgrade utilities: 1 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 will be required to rename the policy. 2 Action Items after the upgrade Also includes errors and warnings, but to be handled after the upgrade. 3 Information Messages

Chapter 7

Upgrading Provider-1

111

Provider-1/SiteManager-1 Upgrade Tools

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, you will get a message stating that this change is going to occur. The Provider-1/SiteManager-1 Pre-Upgrade Verifier uses Provider-1/SiteManager-1 specific verifications as well as verifications checked by SmartCenters Pre-Upgrade Verifier. See Using the Pre Upgrade Verification Tool on page 59.

Installation Script
Starting from NG with Application Intelligence, the installation script to use for MDS is mds_setup. To run mds_setup: 1 2 3 4 Unzip the MDS package: gunzip <package_name>.tgz Untar tar xvf <package_name>.tar A new directory with the same name of the tar file has been created. Change to it: cd <package_name>. 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.

Pre-Upgrade Verification Only Pre-Upgrade Verification Only allows 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 of upgrade issues, some of which should be handled before the upgrade. In a multi-MDS environment it is required to run the pre-upgrade verification on all MDSes (and MLMs) before upgrading the first MDS.

112

pv1_license_upgrade

Upgrade Using this option 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 to automatically fix the problem using a fixing utility. Fixing utilities that affect your existing installation can also be executed from the command line. You can choose to stop the installation at this point and execute the fixing utility from command line. There are two important things to remember after changing your existing installation: Verify your changes in the existing installation before you upgrade. Synchronization: If you make changes in global policies, reassign these global policies to customers. If you have a multi-MDS environment: Synchronize databases between MDSs in High Availability. Synchronize databases between CMAs in High Availability. Install the database on CLMs. Backup
mds_backup

Prior to upgrading backup your MDS. This option from mds_setup, will run (see 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 more details see Changing MDS IP address and External Interface on page 169.

pv1_license_upgrade
The pv1_license_upgrade command line tool is used to perform license upgrade for Provider-1. Provider-1/SiteManager-1 NGX with licenses from previous versions will not function. It is therefore highly recommended to upgrade all Provider-1/SiteManager-1 NG licenses to NGX before upgrading software to NGX. When the tool is run on the MDS, upgraded licenses are obtained from the Check Point User Center Web site for the MDS and for all the CMAs on the MDS. The tool makes it simple to automatically upgrade licenses without having to do so manually though the User Center. The pv1_license_upgrade tool is located on the Provider-1 NGX CD at: /Tools/License Upgrade/<platform>/ NGX installation at: /opt/CPmds-R60/system/license_upgrade/

Chapter 7

Upgrading Provider-1

113

Provider-1/SiteManager-1 Upgrade Tools

Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html

license_upgrade
The license_upgrade command line tool is used to perform license upgrade for a single CMA. It is the same tool as is used to perform license upgrade in SmartCenter environments. The license_upgrade tool is located on the Provider-1 NGX CD at: /Tools/License Upgrade/<platform>/ NGX installation at: /opt/CPmds-R60/system/license_upgrade/ Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html The licence_upgrade tool can be run either as a command line with parameters, or in Wizard mode, which allows you to choose options from a menu. To run the tool in Wizard mode, run:
license_upgrade

Some of the more commonly used tool options are:


TABLE 7-1

licence_upgrade tool options Command line option license_upgrade simulate Meaning

Wizard Mode Option [S]

Sends existing licenses to User Center Web site to simulate the license upgrade in order to verify that it can be performed. No actual upgrade is done and no new licenses are returned. Sends existing licenses to the User Center Web site to perform upgrade and (by default, in online mode) installs them on the machine. Reports whether or not there are licenses on the machine that need to be upgraded.

[U]

license_upgrade upgrade

[C]

license_upgrade status

By default, on a CMA, each operation is performed on the licenses in the License Repository as well as those that belong to the local machine.

114

cma_migrate

cma_migrate
This utility is used to import an existing SmartCenter Server or CMA into a Provider-1/SiteManager-1 MDS so that it will become one of its CMAs. If the imported SmartCenter 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 list of available versions is located in Supported Versions for Upgrade on page 109. Keep in mind, the source and target platforms may be different. The platform of the source management that will be imported can be Solaris, Linux, Windows, SecurePlatform or IPSO. Before running cma_migrate create a new customer and a new CMA. Do not Start the CMA, this will cause cma_migrate to fail. Usage
cma_migrate <source management directory path> <target CMA FWDIR directory>

Example
cma_migrate /tmp/orig_mgmt_dir /opt/CPmds-R60/customers/cma2/CPfw1-R60

The first argument (<source management directory path>)specifies a path on the local MDS machine, where the data of the source management resides. Use migrate_assist to build this source directory or build it manually. Set the structure under the source management directory to:
TABLE 7-2

Source Management Structure contents

directory

conf database

This directory contains the information that resides under $FWDIR/conf of the source management. This directory contains the information that resides under $FWDIR/database of the source management. This directory contains the information that resides under $FWDIR/log of the source management or empty if you do not wish to maintain the logs. This directory is required when the source management is NG FP1 or higher. It contains the information that resides under $CPDIR/conf of the source management.
Chapter 7 Upgrading Provider-1

log

conf.cpdir

115

Provider-1/SiteManager-1 Upgrade Tools

The second argument (<target CMA FWDIR directory>) is the FWDIR of the newly created CMA. The cma_migrate utility can also be performed from the MDG: 1 2 Right click a CMA Select
Import Customer Management Add-on

from the menu.

When running cma_migrate, pre-upgrade verification takes place. If no errors are found, then the migration continues. If errors are found, changes must be performed on the original SmartCenter Server. The original Certificate Authority and putkey information is maintained when using cma_migrate. This means that SmartCenter Server that was migrated using cma_migrate should not re-generate certificates to gateways and SIC should continue to work with NG gateways. If the IP of the CMA is different from that of the original management, then putkey should be redone. Use putkey -n to reestablish trust. For further information on putkey see the Check Point Command Line Interface documentation. If you have VPN with externally managed gateways (or Global VPN-1 Communities) maintain the original FQDN of the management, so that the CRL server location is not changed. This is not a requirement for a VPN between Check Point internal gateways. The default FQDN of a CMA is its IP address, so if you migrated from CMA and changing its IP address, you should change its FQDN to the new IP address by executing:
mdsenv <CMA>, cpconfig, option 4 - Certificate Authority

If your purpose is to split a management or CMA into two or more CMAs, reinitialize their Internal Certificate Authority so only one of the new CMAs will employ the original ICA: 1 2 3
mdsstop_customer <CMA NAME> mdsenv <CMA NAME>

Remove 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. Create new Internal Certificate Authority by executing:
mdsconfig -ca <CMA NAME> <CMA IP>

4 5

Run the command: mdsstart_customer <CMA NAME>

116

migrate_assist

migrate_assist
This utility is a helper utility for cma_migrate. It can be used to pull the original management directories to the current disk storage using FTP. Once you finish running migrate_assist, it is possible to run cma_migrate (see cma_migrate on page 115), whose input directory will be the output directory of migrate_assist. Usage
migrate_assist <source machine name/ip> <source FWDIR folder> <user name> <password> <target folder>[<source CPDIR folder>]

Example If you want to import a SmartCenter server with the IP address 192.168.0.5 of version NG FP3 you will use the following command:
migrate_assist 192.168.0.5 /opt/CPfw1-53 FTP-user FTPpass/EMC1/opt/CPshared/5.0

Where /EMC1 is the name of the directory you have created on the MDS server machine migrate_assist will access the source machine and import the source FWDIR and CPDIR folders to the specified target folder according to the structure described above. User name and password are needed to gain access to the remote machine via FTP. The source CPDIR parameter is required in case that the original management is NG FP3 and higher.
Note - migrate_assist does not affect the source database, however it is highly recommended to stop it before running migrate_assist so that no SmartConsole Clients accidentally edit the database during migration.

migrate_global_policies
The migrate_global_policies utility is available starting with NG FP3. This utility transfers (and upgrades, if necessary) a global policies database from one MDS to another.

Chapter 7

Upgrading Provider-1

117

Provider-1/SiteManager-1 Upgrade Tools

replaces all existing global policies and Global Objects. Each of the existing global policies is saved under the name *.pre_migrate. 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.
migrate_global_policies
Note - When executing the migrate_global_policies utility, the MDS should be stopped. This can be done by calling the mdsstop utility (if required with a -m argument to only stop the MDS and leave the CMAs running).

Usage
migrate_global_policies <path to original global policies files> <original files version>

The original files version should be one of the following taken from the $MDSDIR/conf folder of the originating MDS: FP1 FP2 FP3 R54 - for NG with Application Intelligence R55 - for NG with Application Intelligence NGX The original file names depend on the version used:
Version NG (all Feature Packs) - requires the following files: objects_5_0.C rulebases_5_0.fws fwauth.NDB
Note - migrate_global_policies fails if there is a global policy assigned to a Customer, Do not to create and assign any Global Policy to a Customer before you run migrate_global_policies.

Backup and Restore


The purpose of the backup/restore utility is to backup 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 at 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.

118

Backup and Restore

Restoration can be done 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 machines IP address or interface has changed, refer to Changing MDS IP address and External Interface on page 169 for instructions on how to adjust the restored MDS to the new machine. During backup, it is okay to view but do not write using MDGs, GUIs or other clients. If the Provider-1/SiteManager-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. mds_backup This utility stores binaries and data from your MDS installation. Running mds_backup requires super-user privileges. This is done by running 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 is constructed by the date and time of the backup, followed by the extension .mdsbk.tgz. For example: 13Sep2002-141437.mdsbk.tgz. The file is put in the current working directory, thus it is important not to run mds_backup from one of the directories that will be backed up. For example, when backing up a NG FP3 MDS, do not run mds_backup from /opt/CPmds-53 since you cannot zip the directory youll need to write into.
Usage mds_backup

mds_restore Restores a 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

Chapter 7

Upgrading Provider-1

119

Provider-1/SiteManager-1 License Upgrade

Provider-1/SiteManager-1 License Upgrade


In This Section
Overview of NGX License Upgrade Introduction to License Upgrade in Provider-1 Environments Software Subscription Requirements Understanding Provider-1/SiteManager-1 Licenses Before License Upgrade Choosing The Right License Upgrade Procedure License upgrade of Entire System Before Software Upgrade License Upgrade of Entire System Using Wrapper License upgrade of Entire System After Software Upgrade License Upgrade for a Single CMA License Upgrade Using the User Center SmartUpdate Considerations for License upgrade Troubleshooting License Upgrade page 121 page 122 page 122 page 122 page 124 page 129 page 131 page 134 page 135 page 138 page 144 page 144 page 145

120

Overview of NGX License Upgrade

Overview of NGX License Upgrade


To upgrade to NGX R60, you must first upgrade licenses for all NG products. NGX R60 with licenses from previous versions will not function. The license upgrade procedure can be performed if you have purchased any of the Enterprise Software Subscription services. License upgrade will fail for products and accounts for which you do not have software subscription. Login to http://usercenter.checkpoint.com to manage your accounts, licenses, and Enterprise Support Programs coverage (under Support Programs). License upgrade is performed by means of an easy to use tool that automatically upgrades both locally and centrally managed licenses. Using the tool you can upgrade all licenses in the entire managed system. License upgrade can also be done manually, per license, in the User Center. The automatic license upgrade tool allows you to: 1 2 3 View the status of the currently installed licenses. On a CMA, you can also view the licenses in the SmartUpdate license repository. Simulate the license upgrade process. Perform the actual license upgrade process.

During the license upgrade, all eligible licenses are gathered and sent in SSL encrypted format to the User Center. Upgraded licenses are returned from the User center, and automatically installed. The license upgrade process adds only NGX licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses, or licenses that pertain to IP addresses no longer used) remain untouched. When running on a CMA, the license upgrade process also handles licenses in the SmartUpdate license repository. After the software upgrade, SmartUpdate is used to attach the new NGX licenses to the gateways. For instructions on upgrading license for VPN-1 Pro/Express and SmartLSM deployments, see Upgrading VPN-1 Pro/Express Licenses on page 17. License Upgrade for a ROBO Gateway on page 172. For the latest information and downloads regarding NGX license upgrade, check http://www.checkpoint.com/techsupport/ngx/license_upgrade.html.

Chapter 7

Upgrading Provider-1

121

Provider-1/SiteManager-1 License Upgrade

Introduction to License Upgrade in Provider-1 Environments


Provider-1/SiteManager-1 NGX with licenses from previous versions will not function. It is therefore highly recommended to upgrade all Provider-1/SiteManager-1 NG licenses to NGX before upgrading the software to NGX. The license upgrade procedure for Provider-1/SiteManager-1 uses the pv1_license_upgrade command line tool or the MDS Wrapper, both run on the MDS. These make it simple to automatically upgrade licenses without having to do so manually through the Check Point User Center Web site https://usercenter.checkpoint.com. Licenses for versions prior to NG cannot be upgraded directly to NGX. You must first upgrade to NG and then upgrade the licenses from NG to NGX.

Software Subscription Requirements


The license upgrade procedure is available to purchasers of any of the Enterprise Software Subscription services. License upgrade will fail for products and accounts for which you do not have software subscription. You can see exactly the products and accounts for which you have software subscription by looking in your User Center account. In the Accounts page, Enterprise Contract column, and in the Products page, Subscription and Support column, if the account or product is covered, the expiration date is shown. Otherwise, the entry says Join Now, with a link to get a quote for purchasing Enterprise Support. You can purchase Enterprise Software Subscription for the whole account, in which case all the products in the account will be covered, or you can purchase Enterprise Software Subscription for individual products.

Understanding Provider-1/SiteManager-1 Licenses


Some Important Provider-1/SiteManager-1 Terms Before explaining Provider-1/SiteManager-1 licensing, it is worth reviewing some important Provider-1/SiteManager-1 terms. The Multi-Domain Server (MDS) houses Provider-1 system information. It contains details of the Provider-1 deployment, its administrators, and Customer management information. The MDS has two flavors. The Manager, which runs the Provider-1 deployment, and the Container, which holds the Customer Managements Add-Ons (CMA). The Manager and Container can be installed on the same server, or separately.

122

Understanding Provider-1/SiteManager-1 Licenses

A Customer Management Add-On (CMA) is the Provider-1 equivalent of the SmartCenter Server for a single Customer. Through the CMA, an administrator creates Security Policies and manages the Customer modules.

Provider-1/SiteManager-1 Licensing The MDS Manager has Licenses for the MDS itself (MDS licenses), in the cp.license file. An example of an MDS license is one that specifies how many CMAs may be configured. MDS License Repository (MDS Repository). This is a mirror (that is, a read-only copy) of the CMA license repositories. All CMA license actions are reflected in the MDS License Repository. The MDS Container has: Licenses for the MDS Container itself, in the cp.license file. This license specifies, among other things, how many CMAs may be configured in the Container. For each CMA, licenses for the CMA itself (CMA licenses), in the cp.license file. An example of a CMA license is one that specifies how many Gateways the CMA can manage. For each CMA, the CMA license repository (CMA Repository) in the licenses.C file. This is a repository of Gateway licenses. To manage the licenses in the CMA Repository, use the SmartUpdate component of the Multi-Domain GUI (MDG). SmartUpdate is used to connect to the MDS Manager and manage the MDS Repository. License Upgrade Example License upgrade works per machine. During the license upgrade process, all license on a machine are upgraded. On an MDS computer with a combined Manager and Container, the following are upgraded: MDS licenses for both the manager and Container. For each CMA, the CMA licenses. For each CMA, the CMA Repository.

Chapter 7

Upgrading Provider-1

123

Provider-1/SiteManager-1 License Upgrade

Before License Upgrade


There are a number of steps you should perform before performing the license upgrade. 1 2 3 4 Find out whether license upgrade is required on page 124 Simulate the License Upgrade on page 124 Provider-1 Pro Add-Ons for MDS License Upgrade on page 125 Managing VPN-1 VSX With Provider-1 on page 126

For further assistance: Refer to SecureKnowledge at https://secureknowledge.checkpoint.com. contact the Check Point Reseller that provided your licenses. Find out whether license upgrade is required On the MDS machine, check whether or not the MDS licenses and the licenses in the MDS Repository need to be upgraded, without making any modifications. Do this in one of the following ways: Run the console command pv1_license_upgrade status. The pv1_license_upgrade tool is located on the Provider-1 NGX CD at:
/Tools/License Upgrade/<platform>/

Run the mds_setup wrapper, and then choose the pre-upgrade verification option.

This does the following: For each license, checks whether or not a license upgrade is required. Produces a report that contains action items to be done before the upgrade, action items after the upgrade, and general information. The Action items can be informational, warnings, or errors. If license upgrade is required, error messages are generated. It is highly recommended to deal with all the reported issues, so that the license upgrade will proceed smoothly. Simulate the License Upgrade On the MDS machine, simulate the license upgrade in order to find and solve potential problems in upgrading specific licenses. The simulation does not make any modifications. Run the console command pv1_license_upgrade simulate.

124

Before License Upgrade

Provider-1 Pro Add-Ons for MDS License Upgrade


Note - This section only applies if the Provider-1Pro Add-Ons for MDS are installed.

License Upgrade for the Pro Add-Ons for MDS must be performed either manually via the User Center, or via the Check Point Account Services department. To understand this issue, some background information is needed. Pro Add-Ons for MDS is a bundled product that extends the SMART management capabilities of multiple CMAs by adding SmartUpdate, SmartDirectory, and SmartView Monitor. TABLE 7-3 shows the part numbers of Pro Add-ons for MDS.
TABLE 7-3

Part numbers of Pro Add-ons for MDS

Pro Add-ons for MDS Customer Version NG 10 NG 25 NG 50 NG 100 NG 200 NG 250

Part Number CPPR-PRO-10-NG CPPR-PRO-25-NG CPPR-PRO-50-NG CPPR-PRO-100-NG CPPR-PRO-200-NG CPPR-PRO-250-NG

Licenses for the CMA Pro Add-on for MDS are generated in the User Center as follows: 1 Perform the Activate License operation on the Pro bundled product, using the IP address of the first CMA, to generate the license for this CMA. For each additional CMA, perform the Change IP operation on the bundled product, and change to the IP address of this CMA. Install each generated license on its respective CMA. At the end of the license generation process, the User Center shows a license with the IP address of the last CMA for which the Change IP operation was performed.

2 3

To upgrade the CMA Pro Add-on licenses

On the MDS machine, run the following console command If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

Chapter 7

Upgrading Provider-1

125

Provider-1/SiteManager-1 License Upgrade

The proxy port number is optional. Username and password (if any) are for the proxy machine. 2 Save the following information: Log Files generated by the tool. The location of the files is printed to the screen when running the tool. The cache file generated when running the tool, $CPDIR/conf/lic_cache.C. Contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com, and provide them with the above information.

Managing VPN-1 VSX With Provider-1


Note - This section only applies if the Virtual Systems Extension - CMA Bundle is installed.

To allow Provider-1 to manage VPN-1 VSX, the Virtual Systems Extension - CMA Bundle product is required. If the Virtual Systems Extension - CMA Bundle is older than VSX NG AI Release 2, automatic license upgrade is not available. License upgrade must be performed manually via the User Center, or via the Check Point Account Services department. To understand this issue, some background information is needed. Customers purchase multiple CMAs in order to manage either one VSX Virtual System (VS) with each CMA, or manage a VS cluster with each CMA. The purchased part numbers are shown in TABLE 7-4.
TABLE 7-4

Virtual Systems Extension - CMA Bundles

Virtual Systems Extension - CMA Bundles (Primary VSX-CMA) Gateways Version Part Number C10 NG CPPR-VSX-CMA-C10-NG C25 NG CPPR-VSX-CMA-C25-NG C50 NG CPPR-VSX-CMA-C50-NG C100 NG CPPR-VSX-CMA-C100-NG C250 NG CPPR-VSX-CMA-C250-NG

The customer receives two licenses: One license for the Provider-1 MDS Container product in TABLE 7-5 (depending on the number of VSs in TABLE 7-6). This license allows you to define the purchased number of CMAs.

126

Before License Upgrade

TABLE 7-5

Provider-1 MDS Container

Provider-1 MDS Container Customer Version Part Number NG 25 CPPR-MDS-C25-NG NG 50 CPPR-MDS-C50-NG NG 100 CPPR-MDS-C100-NG NG 200 CPPR-MDS-C200-NG NG 250 CPPR-MDS-C250-NG

One license for the Provider-1 CMA product in TABLE 7-10 (to be installed on the CMA), that specifies the size of the VS cluster that the CMAs are allowed to manage. A license for a VS cluster of 1 Gateway allows the CMA to manage one VS, A license for a VS cluster of 2 Gateways allows the CMA to manage a cluster of two VSs, and so on.
TABLE 7-6

Provider-1 CMA

Provider-1 CMA (Primary CMA) Gateways Version Part Number NG 1 CPPR-CMA-1-NG NG 2 CPPR-CMA-2-NG NG 4 CPPR-CMA-4-NG

Licenses for the Provider-1 CMA product are generated in the User Center as follows: 1 Perform the Activate License operation on the Provider-1 CMA product, using the IP address of the first CMA, to generate the license for this CMA. For each additional CMA, perform the Change IP operation on the bundled product, and change to the IP address of this CMA. Install each generated license on its respective CMA. At the end of the license generation process, the User Center shows a license with the IP address of the last CMA for which the Change IP operation was performed.

2 3

To upgrade the Provider-1 CMA-Bundle licenses

On the MDS machine, run the following console command If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine.

Chapter 7

Upgrading Provider-1

127

Provider-1/SiteManager-1 License Upgrade

Save the following information: Log Files generated by the tool. The location of these files is printed to the screen when running the tool. The cache file generated when running the tool, $CPDIR/conf/lic_cache.C. Contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com, and provide them with the above information.

128

Choosing The Right License Upgrade Procedure

Choosing The Right License Upgrade Procedure


There are various ways to upgrade licenses in a Provider-1/SiteManager-1 environment. The following sections explain the considerations that you should take into account before deciding which procedure is right for you. Decision #1: License Upgrade Before or After Software Upgrade It is highly recommended to perform the license upgrade before performing any software upgrade. This ensures that the software will continue to function after the software upgrade. However, if necessary, the software upgrade can be done first. Decision #2: License Upgrade for Entire System (Single or Multi-MDS) or Single CMA It is possible to upgrade licenses for either The entire Provider-1/SiteManager-1 environment (all MDS licenses, CMA licenses, and CMA Repository licenses), or A single CMA (CMA licenses and CMA Repository licenses). Upgrading the entire Provider-1/SiteManager-1 environment is the recommended way to upgrade licenses. The procedure uses the SmartUpdate license management capabilities, which are free of charge. Upgrading licenses for a single CMA may be required if you do not wish to upgrade the licenses on other CMAs at this time, for example if license for other CMAs were already upgraded. Note however that the software upgrade occurs for all CMAs at the same time, when the MDS is upgraded. Decision #3: License Upgrade for an Online or Offline Machine The license upgrade procedure depends on how the machine on which the procedure is to be performed, is connected to the Check Point User Center Web site. The possibilities are: Direct Internet connectivity (online). Via-proxy Internet connectivity (online via proxy). No Internet connectivity (offline). License upgrade using the mds_setup wrapper only works for online machines with Direct Internet connectivity to the Check Point User Center.

Chapter 7

Upgrading Provider-1

129

Provider-1/SiteManager-1 License Upgrade

What Next? Once you have made the above three decisions, you can then decide which of the following procedures is the right one for you. License upgrade of Entire System Before Software Upgrade on page 131 When MDS is Online on page 131 When MDS is Offline on page 132 License Upgrade of Entire System Using Wrapper on page 134 (applies to an online MDS version NG) License upgrade of Entire System After Software Upgrade on page 135 When MDS is Online on page 135 When MDS is Offline on page 136 License Upgrade for a Single CMA on page 138 When MDS is Online, Before Software Upgrade on page 138 When MDS is Offline, Before Software Upgrade on page 139 When MDS is Online, After Software Upgrade on page 141 When MDS is Offline, After Software Upgrade on page 142

130

License upgrade of Entire System Before Software Upgrade

License upgrade of Entire System Before Software Upgrade In This Section


When MDS is Online When MDS is Offline When MDS is Online Use this procedure for an online MDS of version NG. An online machine is one with Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

page 131 page 132

1 2

Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy them from the locations specified in pv1_license_upgrade on page 113. Run the following command line tool at the MDS (On SecurePlatform, you must be in expert mode): If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. This does the following: Collects all the licenses that exist on the MDS machine. Verifies that all licenses can be upgraded, both for MDS and CMAs. Fetches updated licenses from the User Center. Builds a temporary cache file containing the NGX licenses. 3 4 Perform the software upgrade to NGX on the MDS Manager, MDS Container, and the MDG. Start the MDS by running
mdsenv mdsstart

Chapter 7

Upgrading Provider-1

131

Provider-1/SiteManager-1 License Upgrade

Run the following command line tool at the MDS


pv1_license_upgrade import -c <cache file name>

The default cache file location is $CPDIR/conf/lic_cache.C. This imports the NGX licenses from the cache file to the CMA Repositories of every CMA. 6 7 Perform the software upgrade to NGX on the enforcement module machine(s). Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

When MDS is Offline This procedure upgrades licenses in the entire system, and applies to an offline MDS of version NG. An offline MDS is one with no Internet connectivity to the Check Point User Center Web site.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

1 2

Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy them from the locations specified in pv1_license_upgrade on page 113. On the offline MDS, run the following command line tool:
pv1_license_upgrade export -z <package_file>

On SecurePlatform, run the command in expert mode. The export command packs all licenses on the machine, for all CMAs and the MDS into a single package file. 3 Copy the package file (containing the licenses) from the offline MDS to the online machine. The online machine does not need to be a Check Point-installed machine. Copy the license_upgrade tool to the online machine. The tool is located at <Specific_platform> on the NGX CD, and in the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. EITHER run the command line tool at the online machine: If the online machine is directly connected to the User Center, run: license_upgrade upgrade -i <input_file> -c <cache_file> If the online machine is connected to the User Center via a proxy:

132

License upgrade of Entire System Before Software Upgrade

license_upgrade upgrade -y <proxy:port> -i <input_file> -c <cache_file> Where <input_file> is the package file that is the result of step 2. This fetches new licenses from the User Center and puts them in a cache file. OR: Use the [O] Wizard mode option. Specify the package file that is the result of step 2 and the requested cache file. This fetches new licenses from the User Center and puts them in a cache file. 6 7 Copy the cache file (with the new licenses) back to the offline MDS machine. Start the MDS by running
mdsenv mdsstart

Run following command line on the offline MDS:


pv1_license_upgrade import -c <cache_file>

The default cache file location is $CPDIR/conf/lic_cache.C. This imports the new CMA and MDS licenses to the MDS. 9 Perform the software upgrade to NGX on the MDS Manager, MDS Container, and the MDG.
pv1_license_upgrade import -c <cache_file>

10 Run following command line on the upgraded offline MDS: This imports the new licenses into the CMA license repositories on the MDS. 11 Perform the software upgrade to NGX on the enforcement module machine(s). 12 Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

Chapter 7

Upgrading Provider-1

133

Provider-1/SiteManager-1 License Upgrade

License Upgrade of Entire System Using Wrapper


This license upgrade procedure applies to an online MDS version NG. An online machine is one that has a direct Internet connection to the Check Point User Center Web site. 1 2 At the MDS, run mds_setup and choose the Upgrade option. The pre-upgrade verification begins. Note the location of the messages generated by the verification tool:
/opt/CPInstLog/verification_tools_report

The license upgrade status on the MDS and the CMAs is checked. Details are published in log files as to whether or not the license upgrade is needed for each CMA. If a license upgrade is required, you are given the choice to upgrade licenses via the User Center before the software upgrade. To do so, you are required to supply your User Center account credentials. If the online machine is connected to the User Center via a proxy, provide the proxy details. The new licenses are fetched from the User Center and installed. 3 4 The mds_setup wrapper then proceeds with the software upgrade. Run the following command line tool at the MDS
pv1_license_upgrade import -c <cache_file>

The default cache file is $CPDIR/conf/lic_cache.C. This imports the NGX licenses from the cache file to the CMA Repositories of every CMA. 5 6 Perform the software upgrade to NGX on the enforcement module machine(s). Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

134

License upgrade of Entire System After Software Upgrade

License upgrade of Entire System After Software Upgrade In This Section


When MDS is Online When MDS is Offline When MDS is Online This procedure is not recommended. NGX software with NG licenses will not function. Use this procedure for an online MDS of version NG. An online machine is one with Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. 1 2 Perform the software upgrade to NGX on the MDS Manager, MDS Container, and the MDG. Run the following command line tool at the MDS (On SecurePlatform, you must be in expert mode): If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

page 135 page 136

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. This does the following: Collects all the licenses that exist on the MDS machine. Verifies that all licenses can be upgraded, both for MDS and CMAs. Fetches updated licenses from the User Center. Builds a temporary cache file containing the NGX licenses. Installs upgraded licenses for the MDS and CMAs. 3 Start the MDS by running
mdsenv mdsstart

Run the following command line tool at the MDS


pv1_license_upgrade import -C <cache file>

The default cache file is $CPDIR/conf/lic_cache.C. This imports the NGX licenses from the cache file to the CMA Repositories of every CMA.

Chapter 7

Upgrading Provider-1

135

Provider-1/SiteManager-1 License Upgrade

5 6

Perform the software upgrade to NGX on the enforcement module machine(s). Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

When MDS is Offline This procedure is not recommended. NGX software with NG licenses will not function. This license upgrade procedure applies to an MDS version NG, with no Internet connectivity to the Check Point User Center Web site. 1 2 Perform the software upgrade to NGX on the MDS Manager, MDS Container, and the MDG. On the offline MDS, run the following command line tool:
pv1_license_upgrade export -z <package_file>

On SecurePlatform, run the command in expert mode. The export command packs all licenses on the machine, for all CMAs and the MDS into a single package file. 3 Copy the output file package (containing the licenses) from the offline MDS to an online machine. The online machine does not need to be a Check Point-installed machine. Copy the license_upgrade tool to the online machine. The tool is located at <Specific_platform> on the NGX CD, and in the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. EITHER run the command line tool at the online machine: If the online machine is directly connected to the User Center, run:
license_upgrade upgrade -i <input_file> -c <cache_file>

If the online machine is connected to the User Center via a proxy:


license_upgrade upgrade -y <proxy:port> -i <cache_file> <input_file> -c

Where <input_file> is the package file that is the result of step 2. This fetches new licenses from the User Center and puts them in a cache file. OR Use the [O] option of the Wizard mode, and specify the package file that is the result of step 2, and the requested cache file. This fetches new licenses from the User Center and puts them in a cache file. 6 Copy the cache file (with the new licenses) back to the offline MDS machine.

136

License upgrade of Entire System After Software Upgrade

Start the MDS services by running


mdsenv mdsstart

Run following command line on the offline MDS:


pv1_license_upgrade import -c <cache_file>

This imports the new licenses into the CMA license repositories on the MDS. 9 Perform the software upgrade to NGX on the enforcement module machine(s).

10 Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

Chapter 7

Upgrading Provider-1

137

Provider-1/SiteManager-1 License Upgrade

License Upgrade for a Single CMA In This Section


When MDS is Online, Before Software Upgrade When MDS is Offline, Before Software Upgrade When MDS is Online, After Software Upgrade When MDS is Offline, After Software Upgrade When MDS is Online, Before Software Upgrade Use this procedure to upgrade licenses for a single CMA on an online MDS version NG machine. An online machine is one that has Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. License upgrade operations occur both before and after the software upgrade. The license upgrade for the single CMA occurs before the software upgrade. After the software upgrade, licenses for all CMAs are imported into the NGX CMA Repositories. The software upgrade occurs for all CMAs at the same time, when the MDS is upgraded.
Note - If the license upgrade is performed before the software upgrade, Check Point products will generate warning messages until all the software on the machine has been upgraded. See Error: License version might be not compatible on page 35 for details.

page 138 page 139 page 141 page 142

Copy the pv1_license_upgrade and the license_upgrade tools to the MDS version NG machine. Copy them from the locations specified in pv1_license_upgrade on page 113 and license_upgrade on page 114. At the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>

2 3

EITHER run the following command at the MDS: If the MDS machine is directly connected to the User Center:
license_upgrade upgrade

If the MDS machine is connected to the User Center via a proxy:

138

License Upgrade for a Single CMA

license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. OR: Use the [U] Wizard mode option. This does the following: Collects all the licenses that exist on the CMA. Fetches updated licenses from the User Center. Installs an upgraded license for the CMA, and saves upgraded CMA Repository licenses on the CMA. 4 5 6 Upgrade the software on the MDS. Start the MDS services by running
mdsstart

Import new licenses of all CMAs into the NGX CMA Repositories.
pv1_license_upgrade import -C <cache file>

The default cache file is $CPDIR/conf/lic_cache.C. This imports the NGX licenses from the cache file to the CMA Repositories of every CMA. 7 8 Perform the software upgrade to NGX on the enforcement module machine(s). Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

When MDS is Offline, Before Software Upgrade This procedure explains how to upgrade licenses for a single CMA on an offline MDS version NG machine, that is, one that does not have Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. License upgrade operations occur both before and after the software upgrade. The license upgrade for the single CMA occurs before the software upgrade. After the software upgrade, licenses for all CMAs are imported into the NGX CMA Repositories. 1 2 Copy the license_upgrade tool to the MDS version NG machine from the locations specified in license_upgrade on page 114. At the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>

Chapter 7

Upgrading Provider-1

139

Provider-1/SiteManager-1 License Upgrade

Copy the licenses from this machine to a file using one of the following methods. On SecurePlatform, run the command in expert mode: EITHER run the following command line tool at the offline target machine:
license_upgrade export -z <package_file>

The export command packs all licenses on the machine into a single package file. OR Use the [U] wizard mode option. 4 Copy the output file package (containing the licenses) from the offline target machine to any online machine. The online machine does not need to be a Check Point-installed machine. Copy the license_upgrade tool to the online machine. EITHER run the command line tool at the online machine: If the online machine is directly connected to the User Center, run:
license_upgrade upgrade -i <input_file> -c <cache_file>

5 6

If the online machine is connected to the User Center via a proxy:


license_upgrade upgrade -y <proxy:port> -i <cache_file> <input_file> -c

Where <input_file> is the package file that is the result of step 3. This fetches new CMA licenses from the User Center and puts them in a cache file. OR Use the [O] wizard mode option. Specify the package file package that is the result of step 3 and the requested cache file. This fetches new licenses from the User Center and puts them in a cache file. 7 8 Copy the cache file (with the new CMA licenses) to the offline target machine. EITHER run following command line on the offline target machine:
license_upgrade import -c <cache_file>

OR Use the [U] wizard mode option. 9 Upgrade the software on the MDS.
mdsstart

10 Start the MDS services by running

140

License Upgrade for a Single CMA

11 Import new licenses of all CMAs into the NGX CMA Repositories. Run the command
pv1_license_upgrade import -c <cache file name>

12 Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

When MDS is Online, After Software Upgrade


Use this procedure if The MDS software (including all CMAs) is already upgraded. MDS licenses are already upgraded to NGX, while the single CMA licenses and CMA Repository licenses remain to be upgraded. The MDS machine has Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. Proceed as follows: 1 Make sure that the CMA is running. The following command will show the status of all CMAs:
mdsstat

2 3

At the MDS machine, enter the environment of the single CMA


mdsenv <cma_name>

EITHER run the following command at the MDS: If the MDS machine is directly connected to the User Center:
license_upgrade upgrade

If the MDS machine is connected to the User Center via a proxy:


license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. OR use the [U] wizard mode option. This does the following: Collects all the licenses that exist on the CMA. Fetches updated licenses from the User Center. Install new licenses on the CMA.

Chapter 7

Upgrading Provider-1

141

Provider-1/SiteManager-1 License Upgrade

When MDS is Offline, After Software Upgrade


This procedure assumes that The MDS software (including all CMAs) is already upgraded. MDS licenses are already upgraded to NGX, while the single CMA licenses and CMA Repository licenses remain to be upgraded. The MDS machine does not have Internet connectivity to the Check Point User Center Web site https://usercenter.checkpoint.com. Proceed as follows: 1 2 At the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>

Copy the licenses from this machine to a file using one of the following command. On SecurePlatform, run the following command in expert mode. EITHER run the following command line tool at the offline MDS:
license_upgrade export -z <package_file>

OR use the [U] wizard mode option. The export command packs all licenses on the machine into a single package file. 3 Copy the output file package (containing the licenses) from the offline MDS to any online machine. The online machine does not need to be a Check Point-installed machine. Copy the license_upgrade tool to the online machine. The tool is located at <Specific_platform> on the NGX CD, and in the Check Point Download site at http://www.checkpoint.com/techsupport/ngx/license_upgrade.html. EITHER run the command line tool at the online machine: If the online machine is directly connected to the User Center, run:
license_upgrade upgrade -i <input_file> -c <cache_file>

If the online machine is connected to the User Center via a proxy:


license_upgrade upgrade -y <proxy:port> -i <cache_file> <input_file> -c

Where <input_file> is the package file that is the result of step 2. This fetches new CMA licenses from the User Center and puts them in a cache file. OR use the [O] wizard mode option. Specify the output file package that is the result of step 2. This fetches new CMA licenses from the User Center and puts them in a cache file. 6 Copy the cache file (with the new CMA licenses) to the MDS machine.

142

License Upgrade for a Single CMA

7 8

Run following command on the MDS machine:


mdsenv <cma_name>

EITHER run following command line on the offline target machine


license_upgrade import -c <cache_file>

OR use the [U] wizard mode option. This Installs new CMA licenses on the CMA. 9 Start the CMA services by running
mdsstart_customer <cma name>

10 Import new licenses of this CMA into the NGX CMA Repositories. Run
mdsenv <cma name>)

Then, EITHER run following command line on the offline target machine
license_upgrade import -c <cache_file>

OR use the [U] wizard mode option. 11 Perform the software upgrade to NGX on the enforcement module machine(s). 12 Connect to the MDS using the SmartUpdate component of the MDG, and for each CMA, delete all obsolete licenses from NGX gateways.

Chapter 7

Upgrading Provider-1

143

Provider-1/SiteManager-1 License Upgrade

License Upgrade Using the User Center


License upgrade can be done manually in the User Center. For instructions, see the Step by Step guide to the User Center at https://usercenter.checkpoint.com/pub/usercenter/faq_us.html Licenses that are manually upgraded to NGX in the User Center, and are then manually added to the license Repository, will not be Assigned to any Gateway. This means that the license must be manually attached to the Gateway using SmartUpdate.

SmartUpdate Considerations for License upgrade


In SmartUpdate NG, the Licenses > Upgrade menu item is intended for license upgrades from version 4.1 to NG. Do not use it to upgrade NG licenses to NGX.

144

Troubleshooting License Upgrade

Troubleshooting License Upgrade


License upgrade is a smooth and easy process. There are a few predictable cases where you may come across some problems. Use this section to solve those license upgrade problems.

In This Section
Provider-1 Pro Add-Ons for MDS License Upgrade Managing VPN-1 VSX With Provider-1 Provider-1 Pro Add-Ons for MDS License Upgrade
Symptoms

page 145 page 147

Automatic license upgrade only succeeds for the license with the IP address of the last CMA for which the Change IP operation was performed. License upgrade fails on all other licenses User Center Message (Error Code 118):
The IP in the license string does not match the license IP in User Center. Perform Change IP operation in User Center or contact Customer Advocacy at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com.

Cause

In order to understand this issue, some background information is needed: Pro Add-Ons for MDS is a bundled product that extends the SMART management capabilities of multiple CMAs by adding SmartUpdate, SmartDirectory, and SmartView Monitor.
TABLE 7-7

Part numbers of Pro Add-ons for MDS

Pro Add-ons for MDS Customer Version NG 10 NG 25 NG 50 NG 100 NG 200 NG 250

Part Number CPPR-PRO-10-NG CPPR-PRO-25-NG CPPR-PRO-50-NG CPPR-PRO-100-NG CPPR-PRO-200-NG CPPR-PRO-250-NG

The way to generate the CMA Pro Add-on licenses in the User Center is as follows:

Chapter 7

Upgrading Provider-1

145

Provider-1/SiteManager-1 License Upgrade

Perform the Activate License operation on the Pro bundled product, using the IP address of the first CMA, to generate the license for this CMA. For each additional CMA, perform the Change IP operation on the bundled product, and change to the IP address of this CMA. Install each generated license on its respective CMA. At the end of the license generation process, the User Center shows a license with the IP address of the last CMA for which the Change IP operation was performed.

2 3

Only this last license is upgraded by the license upgrade process.


Resolution

On the MDS machine, run the following console command If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. 2 Save the following information: Log Files generated by the tool. The location of the files is printed to the screen when running the tool. The cache file generated when running the tool, $CPDIR/conf/lic_cache.C. Contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com, and provide them with the above information.

146

Troubleshooting License Upgrade

Managing VPN-1 VSX With Provider-1


Symptoms

Automatic license upgrade only succeeds for the license with the IP address of the last CMA for which the Change IP operation was performed. License upgrade fails on all other licenses User Center Message (Error Code 118):
The IP in the license string does not match the license IP in User Center. Perform Change IP operation in User Center or contact Customer Advocacy at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com.

Cause

In order to understand this issue, some background information is needed: Customer purchases multiple CMAs in order to manage either one VSX Virtual System (VS) with each CMA, or manage a VS cluster with each CMA. The purchased VSX part numbers are shown in TABLE 7-8.
TABLE 7-8

Virtual Systems Extension - CMA Bundles

Virtual Systems Extension - CMA Bundles (Primary VSX-CMA) Gateways Version Part Number C10 NG CPPR-VSX-CMA-C10-NG C25 NG CPPR-VSX-CMA-C25-NG C50 NG CPPR-VSX-CMA-C50-NG C100 NG CPPR-VSX-CMA-C100-NG C250 NG CPPR-VSX-CMA-C250-NG

The customer receives two licenses: One license for the Provider-1 MDS Container product in TABLE 7-9 (depending on the number of VSs in TABLE 7-8). This license allows you to define the purchased number of CMAs.
TABLE 7-9

Provider-1 MDS Container

Provider-1 MDS Container Customer Version Part Number NG 25 CPPR-MDS-C25-NG NG 50 CPPR-MDS-C50-NG NG 100 CPPR-MDS-C100-NG NG 200 CPPR-MDS-C200-NG NG 250 CPPR-MDS-C250-NG

Chapter 7

Upgrading Provider-1

147

Provider-1/SiteManager-1 License Upgrade

One license for the Provider-1 CMA product in TABLE 7-10 (to be installed on the CMA), that specifies the size of the VS cluster that the CMAs are allowed to manage. A license for a VS cluster of 1 Gateway allows the CMA to manage one VS, A license for a VS cluster of 2 Gateways allows the CMA to manage a cluster of two VSs, and so on.
TABLE 7-10

Provider-1 CMA

Provider-1 CMA (Primary CMA) Gateways Version Part Number NG 1 CPPR-CMA-1-NG NG 2 CPPR-CMA-2-NG NG 4 CPPR-CMA-4-NG

The way to generate the Provider-1 CMA product licenses in the User Center is as follows: 1 Perform the Activate License operation on the Provider-1 CMA product, using the IP address of the first CMA, to generate the license for this CMA. For each additional CMA, perform the Change IP operation on the bundled product, and change to the IP address of this CMA. Install each generated license on its respective CMA. At the end of the license generation process, the User Center shows a license with the IP address of the last CMA for which the Change IP operation was performed.

2 3

Only this last license is upgraded by the license upgrade process.


Resolution

On the MDS machine, run the following console command If the MDS is directly connected to the User Center:
pv1_license_upgrade upgrade

If the MDS is connected to the User Center via a proxy:


pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the proxy machine. 2 Save the following information: Log Files generated by the tool. The location of the files is printed to the screen when running the tool. The cache file generated when running the tool, $CPDIR/conf/lic_cache.C.

148

Troubleshooting License Upgrade

Contact Account Services at US +1 817 606 6600, option 7 or e-mail AccountServices@ts.checkpoint.com, and provide them with the above information.

Chapter 7

Upgrading Provider-1

149

Provider-1/SiteManager-1 Upgrade Practices

Provider-1/SiteManager-1 Upgrade Practices


In This Section
In-place Upgrade Replicate and Upgrade Gradual Upgrade to Another Machine Migrating from a Standalone Installation to CMA MDS Post Upgrade Procedures page 150 page 152 page 153 page 156 page 160

In-place Upgrade
The in-place upgrade process takes place on the existing MDS machine. The MDS with all CMAs are upgraded during a single upgrade process. License upgrade is also required. Provider-1/SiteManager-1 NGX with licenses from previous versions will not function. It is therefore highly recommended to upgrade all Provider-1/SiteManager-1 NG licenses to NGX before upgrading software to NGX.
Note - When upgrading Provider-1 to NGX R60, all SmartUpdate packages on the MDS (excluding SofaWare firmware packages) are deleted from the SmartUpdate Repository.

Run the Pre-upgrade verification only option from mds_setup. In a multi-MDS environment, perform this step on all MDSes (see Upgrading in a Multi MDS Environment on page 161). Make the changes required by the pre-upgrade verification, and if you have High Availability, do the required synchronizations. Test your changes: A assign global policy B install policy C verify logging (through SmartView Tracker) D view status (through MDG or SmartView Monitor)

2 3

Backup your system either by selecting the backup options from mds_setup or by running mds_backup.

150

In-place Upgrade

Follow the steps of the license upgrade procedure prior to the MDS software upgrade that are detailed in License upgrade of Entire System Before Software Upgrade on page 131. Follow the procedure for an online MDS or an offline MDS, as applicable. Perform the in-place upgrade using mds_setup (see Installation Script on page 112). Follow the steps of the license upgrade procedure after the MDS software upgrade that are detailed in License upgrade of Entire System Before Software Upgrade on page 131. Follow the procedure for an online MDS or an offline MDS, as applicable. After the upgrade completes, retest using the sub-steps in step 3 above.

6 7

Upgrading to NGX R60 on SecurePlatform The following steps depict how to upgrade SecurePlatform R54 and later versions using a CD ROM drive. 1 2 3 4 Log into SecurePlatform (Expert mode is not necessary). Apply the SecurePlatform NGX R60 upgrade package: # patch add cd. At this point you will be asked to verify the MD5 checksum. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No

If you select Yes, a Safe Upgrade will be performed. Safe Upgrade automatically takes a snapshot of the entire system so that the entire system (operating system and installed products) can be restored if something goes wrong during the Upgrade process (for example, hardware incompatibility). If the Upgrade process detects a malfunction, it will automatically revert to the Safe Upgrade image. When the Upgrade process is complete, upon reboot you will be given the option to manually choose to start the SecurePlatform operating system using the upgraded version image or using the image prior to the Upgrade process.

Chapter 7

Upgrading Provider-1

151

Provider-1/SiteManager-1 Upgrade Practices

Upgrade to NGX on a Fresh RedHat Enterprise Linux 3.0 Platform using the Same Machine 1 For each CMA create a backup folder that contains subfolders (as described in Table 7-2 on page 115). These folders will be used for backing up data files from a previously installed MDS version. These folders and their content must be accessible from the NGX machine after the operating system upgrade. Create an additional folder for the global policy data. Backup the following files from $MDSDIR/conf to the folder created in step 2:
objects_5_0.C rulebases_5_0.fws fwauth.NDB exported.C exported_domains.C

2 3

4 5 6 7 8

Perform a fresh RedHat Enterprise Linux 3.0 installation. Perform a fresh installation of NGX MDS on the target machine. Refer to Installation Script on page 112 for detailed instructions. Create customers and CMAs with the names used in the previous Provider-1 setup. Do not start the CMAs. Use migrate_global_policies to import the backed up global policies listed in step 3 (refer tomigrate_global_policies on page 117 for additional information). Migrate all the original CMAs data into the newly created CMAs (from the backup folders created in step 1), either by using Import Customer Management Add-on from the MDG or cma_migrate (refer to cma_migrate on page 115) for each CMA.

Replicate and Upgrade


Choose this type of upgrade if you intend to change hardware as part of the upgrade process or if you wish 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. Steps for employing Replicate and Upgrade: 1 Backup your existing MDS. This can be done by running mds_backup or by running mds_setup and selecting the Backup option.

152

Gradual Upgrade to Another Machine

Install a fresh MDS on the target machine. In order to restore your existing MDS, first install a fresh MDS on the target machine that is the exact same version as your existing MDS.
Note - The target machine should be on an isolated network segment so that modules connected to the original MDS are not affected until you switch to the target machine.

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. If your target machine and the source machine have different IP addresses, follow the steps listed in IP Address Change on page 169 to adjust the restored MDS to the new IP address. If your target machine and the source machine have different interface name (e.g. hme0 and hme1), follow the steps listed in Interface Change on page 170 to adjust the restored MDS to the new interface name. 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. Upgrade your MDS. Stop the MDS on the target machine and employ an In-Place Upgrade (see In-place Upgrade on page 150 for further information).

Gradual Upgrade to Another Machine


In a gradual upgrade, CMAs are transferred to another MDS machine of version NGX, one CMA at a time.
Information that is not retained

In a gradual upgrade, the following information is not retained: 1 2 3 Provider-1/SiteManager-1 Administrators To do: Redefine and reassign to customers after the upgrade. Provider-1/SiteManager-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,
Chapter 7 Upgrading Provider-1

153

Provider-1/SiteManager-1 Upgrade Practices

Global Communities statuses. To do: execute the command:


mdsenv; fwm mds rebuild_global_communities_status all

Upgrade steps 1 2 Install MDS of the target version onto the target machine. Follow the steps of the license upgrade procedure prior to the software upgrade of the MDS that are detailed in License upgrade of Entire System Before Software Upgrade on page 131. Follow the procedure for an online MDS or an offline MDS, as applicable. Copy the following file to the target MDS:
$CPDIR/conf/lic_cache.C

At this point all NGX version CMA and MDS licenses reside in cp.license, and all licenses appear in the cache. 4 5 On the target MDS, create a customer and CMA but do not start the CMA. Use the migrate_assist utility to copy the CMA directories and files for each CMA from the source machine to the destination machine. For further information see migrate_assist on page 117. This process transfers the NGX licenses for both the CMA and the CMA Repository. Start the CMA. Run the commands
mdsenv mdsstart

Import licenses that were upgraded to the CMA database from the cache file copied from the NG version MDS. Run:
pv1_license_upgrade import -c <cache file name>

If not all licenses were successfully upgraded on the version NG MDS, perform the license upgrade for a single CMA, either When MDS is Online, After Software Upgrade on page 141, or When MDS is Offline, After Software Upgrade on page 142. 8 Use migrate_global_policies to import the global policies.

Gradual Upgrade with Global VPN Considerations A gradual upgrade process in an MDS configuration that uses the Global VPN Communities (GVC) is not fundamentally different from the gradual upgrade process described above, with a few exceptions:

154

Gradual Upgrade to Another Machine

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 participates in the GVC and one for CMAs that do. 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 whether you have 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
Network Objects > Actions

query from the Global SmartDashboard > Manage > to figure out 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.
where used

B The gateways must be disabled from global use: i From the MDGs
General View,

Right Click on 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, then execute the command:
mdsenv; remove_globally_used_gw <Global name of the gateway>

When issuing the command: migrating_global_policy where the existing Global Policy contains Global Communities, the resulting Global Policy contains: the globally used gateways from the existing database and the globally used gateways from the migrated database. As a result of the migration, the Global Communities are overridden by the migrated database.

The gradual upgrade does not restore the Global Communities statuses; therefore, if: the existing Global Policy contains Global Communities 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

Chapter 7

Upgrading Provider-1

155

Provider-1/SiteManager-1 Upgrade Practices

Migrating from a Standalone Installation to CMA


This section describes how to migrate the management part of a Stand Alone Gateway to a CMA, and then manage the Stand Alone Gateway (as a module only) from the CMA. Terminology Stand Alone Gateway (SGW) - management and module installed on the same host. ModuleA - the module on Machine A during and after the separation procedure. Machine A - the machine on which the SGW is installed. Machine B - the machine on which the MDS is installed (with the target CMA).
Note - If you want the option to later undo the separation process, backup your SGW before migrating.

An Overview of the Stand Alone Installation to CMA Migration Procedure Here is a broad overview of the steps performed in TABLE 7-11 for an NG Stand-alone Station: 1 2 3 Migrating the Management part of the SGW into the target CMA. This requires some adjustments to the SGW before export and to the CMA after migration. Uninstalling the SGW and reinstalling a module on Machine A. Maintaining trust between the CMA and all the modules previously managed by the SGW: For NG modules, SIC is automatically maintained.
Note - This procedure also covers cases where the SGW manages additional modules other than itself.

156

Migrating from a Standalone Installation to CMA

From NG (All Feature Pack) Installation


TABLE 7-11

Migrating from Stand Alone to CMA from NG forward steps

machine

Prepare SGW for Export


Machine A

Make sure that: AFTP access is allowed from Machine B (machine on which the MDS is installed with the target CMA) to Machine A (machine on which SGW is installed). This is only necessary if you plan to use migrate_assist. B CMA (On Machine B) will be able to communicate with and install policy on all managed modules.

Add an object representing the CMA (name and IP address) and define it as a Secondary SmartCenter Server. Install policy on all managed gateways. Delete all objects or access rules created in steps 1 and 2. If the SGW has VPN-1 installed: A Uncheck VPN-1 from the Check Point Products section of the SGW object. You may have to first remove it from the Install On column of your rulebase (and then add it again). B If the SGW participates in a VPN-1 community: in the VPN tab, remove it from the community and erase its certificate. Note these changes in order to undo them after the migration.

3 4 5

Save and close SmartDashboard. Do not install policy.

Chapter 7

Upgrading Provider-1

157

Provider-1/SiteManager-1 Upgrade Practices

TABLE 7-11

Migrating from Stand Alone to CMA from NG forward (Continued) steps

machine

Export the management database from Machine A and import it to CMA on the MDS on Machine B
Machine B (cont...)

Run the migrate_assist <SGW_NAME>


<SGW_FWDIR> <username> <password> <target_dir> <SGW_CPDIR> command. Do not forget to supply the last parameter <SGW_CPDIR>,

this parameter is mandatory when running migrate_assist on NG. 2 3 Create a new CMA on the MDS but do not start it. Migrate the exported database into CMA from the target directory of migrate_assist (<target_dir>). Start the CMA and on the CMA, launch SmartDashboard. In SmartDashboard under Objects find:

Configure CMA. Start managing all modules from CMA, except moduleA
Machine B

Network

A An object with the Name and IP address of the CMA which is the primary management object (migrated). Previous references to the SGW management object now refer to this object. B An object for each module managed by the SGW (except for moduleA). 2 Edit the Primary Management Object and remove all interfaces (Network Object >Topology > Remove).

158

Migrating from a Standalone Installation to CMA

TABLE 7-11

Migrating from Stand Alone to CMA from NG forward (Continued) steps

machine

Create an Object representing moduleA (From > Check Point > Gateway): A Assign a
Name

New

and

IP address

for moduleA.

B Select the appropriate Check Point version. C Check the appropriate Check Point Products you have installed. D If the Object previously belonged to a VPN-1 Community, add it back. E Do not initialize communication. 4 Run Where Used on the primary Management Object and in each location, consider changing to the gateway object (moduleA). Install Policy on all modules, except for moduleA. You may get warning messages about moduleA because it is not yet configured. Ignore these. Uninstall the SGW. Install the module. Re-establish trust with moduleA. Define moduleAs topology in the CMA SmartDashboard. Install the Policy on moduleA.

Reinstall module on Machine A and prepare for SIC with the CMA
Machine A

1 2

Start managing moduleA from CMA


Machine B

1 2 3

Chapter 7

Upgrading Provider-1

159

Provider-1/SiteManager-1 Upgrade Practices

MDS Post Upgrade Procedures


When upgrading an MDS machine from one of the supported versions, please perform the following procedure immediately after completing the upgrade: 1 2 3 Open a root command line on the MDS (either on a console or via ssh). Set the MDS environment and stop all services by typing mdsenv;mdsstop. Go to the $MDSDIR/conf/mdsdb/ directory and make a backup of the objects_5_0.C file before it is changed. For example:
#cd $MDSDIR/conf/mdsdb/ #cp objects_5_0.C /tmp

4 5 6 7 8

Use the vi text editor to manually edit the objects_5_0.C file in the $MDSDIR/ conf/mdsdb/ directory. Find the line statement :use_sites. For example:
/:use_sites

Edit the value and change it from true to false. For example:
:use_sites (false)

Save the file and exit. Start the MDS services by running mdsenv;mdsstart.

160

Pre-Upgrade Verification and Tools

Upgrading in a Multi MDS Environment


In This Section
Pre-Upgrade Verification and Tools Upgrading an NG with Application Intelligence Multi-MDS System page 161 page 161

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 the down-time during the upgrade. This section explains guideline for performing an upgrade in a multi-MDS environment. Specifically, it explains the order of upgrade and synchronization issues.

Pre-Upgrade Verification and Tools


Run pre-upgrade verification on all MDSes before applying the upgrade to a specific MDS by choosing the Pre-Upgrade Verification Only option from mds_setup (for further information see Pre-Upgrade Verifiers and Fixing Utilities on page 111). Only start upgrading the first MDS after you have fixed all the errors and reviewed all the warnings on all your MDSes.

Upgrading an NG with Application Intelligence Multi-MDS System In This Section


MDS High Availability Before the Upgrade After the Upgrade CMA High Availability MDS High Availability Communication between MDSes can take place only for MDSes 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. At this point all other containers are managed from the other manager MDS. page 161 page 162 page 162 page 163

Chapter 7

Upgrading Provider-1

161

Upgrading in a Multi MDS Environment

2 3

Upgrade all container MDSes. Each container MDS that you upgrade is managed from the already upgraded manager MDS. Upgrade your second manager MDS.

Following these steps promises continuous manageability of your container MDS. While containers do not accept SmartCenter 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. Before the Upgrade 1 2 Perform pre-upgrade verification for all MDSes. Perform license upgrade for all MDSes. Refer to License upgrade of Entire System Before Software Upgrade on page 131, up to and including step 5. Note that as an alternative to running pv1_license_upgrade upgrade on all MDSs, you can use the cache file generated on one MDS, on other MDSs, by copying it to the other MDSs and running
pv1_license_upgrade import -c <cache file name>

3 4

If the pre-upgrade verifier requires a modification to the global database, then after modifying the global database, all other MDSes should be synchronized. 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. 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) then install the database on the CLM to verify that the modification is applied to the CLM as well.
Note - When synchronizing, make sure to have only one active MDS and one active CMA for each customer. Modify the active MDS/CMA and synchronize to Standby.

After the Upgrade Complete the License upgrade. Continue with License upgrade of Entire System Before Software Upgrade on page 131, from step 7. After upgrading an MDS or an MLM in a multi MDS environment, the CMA/CLM object versions (located in the CMA database) are not updated. In this case, when using SmartDashboard to connect to a CMA after the upgrade, additional CMA/CLMs will be displayed with the previous version.
162

Upgrading an NG with Application Intelligence Multi-MDS System

If the CMA identifies the CLM version as earlier then the current CLM version, the following scenario will take place: A complete database installation from the CMA on the CLM will not take place and as result, resolving IP addresses and services by the CLM will not be executed completely. In order to update the CLM/CMA objects to the most recent version, please verify that all active CMAs are up and running with valid licenses and that SmartDashboard is not connected. At this time, the following should be run on each MDS after upgrading all MLMs/MDSs: mdsenv To update CLM/CMA objects that are located on a specific MLM/MDS, run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <MLM/MDS name>

To update all CLM/CMA objects, run:


$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL

After running this utility, remember to synchronize all standby CMAs/SmartCenter backups. CMA High Availability CMA High Availability can help you minimize the period of management downtime during upgrade. While upgrading one of the MDS containers in the High Availability configuration, others can be used for managing enforcement points. The CMAs hosted on these MDSs will need to be synchronized and defined as Active in order to be able 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 High Availability configuration will take place only after MDS containers hosting both of them are upgraded. If policy changes were made on both CMAs during the upgrade process, after the upgrade one of the configurations will have to override another and the collisions will have to be resolved manually. After the upgrade is completed on all the MDS containers, the High Availability status of the CMAs will appear as Collision. To resolve this, every CMA High Availability pair needs to be synchronized. During the synchronization process changes from one of the CMAs will override the changes made to another. In order to migrate CMA/SmartCenter High Availability deployment, use the migrate utility (refer to cma_migrate page 115) where the imported database is the primary CMA/SmartCenter Server, after verifying that it is synchronized.

Chapter 7

Upgrading Provider-1

163

Restoring your Original Environment

Likewise, perform these steps if you want to migrate your current High Availability environment to a CMA High Availability on a different MDS. At this point, continue with a High Availability deployment (refer to the High Availability chapter in the Check Point Provider-1/SiteManager-1 User Guide).

Restoring your Original Environment


In This Section
Before the Upgrade Restoring your Original Environment page 164 page 165

Before the Upgrade


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

164

Restoring your Original Environment

Restoring your Original Environment


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

Renaming Customers
In This Section
Identifying Non-Compliant Customer Names High-Availability Environment Automatic Division of Non-compliant Names Resolving the Non-compliance Advanced Usage page 165 page 166 page 166 page 166 page 167

Previous Provider-1 versions allowed customer names or CMA names in Check Point 2000 to contain illegal characters, such as spaces and certain keyword prefixes. In NG with Application Intelligence, all customer names must adhere to the same restrictions as CMA names or any other network objects.

Identifying Non-Compliant Customer Names


The mds_setup utility performs several tests on the existing installation before an upgrade takes place. One of the tests is a test for customer names compliance with the new 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.

Chapter 7

Upgrading Provider-1

165

Renaming Customers

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

Automatic Division of Non-compliant Names


If the number of customers with non-compliant names is large, the translation task may automatically divide into several sessions. By default, all the intermediate work is saved.

Resolving the Non-compliance


During the upgrade procedure, after selecting Option 2 - Upgrade to NGX on the mds_setup menu, the resolution to compliant names is performed. The translation prompt is only displayed if a non-compliant name is detected.
Note - Nothing will be changed in the existing installation when translating customer names. Any changes are applied only to the upgraded installation.

Translation prompt - Enter a name to replace the non-compliant name, or enter the '-' sign to get a menu of additional options. The new name is checked for naming restrictions compliance and is not accepted until you enter a compliant name. Additional Options Menu Both CMAs in Check Point 2000 and customers in NGX are referred to as customers in this section. Edit another name - The customer names are presented in alphabetic 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 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.

166

Advanced Usage

Return to translation prompt - Choose this option if you want to return to the customer name you were prompted with when you entered '-'.
Note - The pre-upgrade tool allows only non-compliant customer names to be translated.

If the session is exited before all the translations are done, the mds_setup utility exits with an error message stating that the MDS verification failed. To return to the tool, simply run mds_setup again and choose Option 2 - Upgrade to NGX. High-Availability After completing the translations on the first MDS, copy the following files to the other MDSes. If the MDSes are properly synchronized, no additional work will be required on them. 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 were already translated will be shown before the first non-compliant name is displayed. This will also be the case when running on an additional MDS.

Advanced Usage
An advanced user may choose to directly edit the translation file, /var/opt/CPcustomers_translated.txt. In this case, all the translations will be verified when mds_setup is run again.

Chapter 7

Upgrading Provider-1

167

Renaming Customers

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

Line Prefixes Meaning Comment

Line Prefix

# -

A comment line. Existing non-compliant name.

May be inserted anywhere. Must exactly match an existing non-compliant name, otherwise it will be rejected. If the entry does not comply with the naming restrictions, it is ignored.

A translation for the preceding '-' line.

The '-' and '+' lines must form pairs. Otherwise, the file is rejected. If the translations file is manually modified, the mds_setup will detect it and will display the following menu: 1 Use the translations file anyway - Choose this option only if an authorized person modified it. This option will read the file, verify its content and use the translations therein. Ignore the translations file and generate a new one - Choose this option if you want to overwrite the contents of the file. Quit and leave the translations file as it is - Choose this option if you wish 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.

2 3

168

IP Address Change

Changing MDS IP address and External Interface


In This Section
IP Address Change Interface Change page 169 page 170

IP Address Change
If your target machine and the source machine have different IP addresses, please follow the steps listed below in order to adjust the restored MDS to the new IP address: 1 2 3 The MDS must be stopped. Stop the MDS by running mdsstop. Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address. 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. Due to the change of IP address install a new license on the target MDS with the new MDS IP address. For multiple MDS/MLM environments repeat steps 1 to 4 for the MDS/MLM for which you changed the IP, on each MDS/MLM.

4 5

Chapter 7

Upgrading Provider-1

169

Changing MDS IP address and External Interface

Interface Change
If your target machine and the source machine have different interface name (e.g. hme0 and hme1), follow the steps listed below in order to adjust the restored MDS to the new interface name: 1 2 Change the interface name in file $MDSDIR/conf/external.if to the new interface name. For each CMA replace the interface name in $FWDIR/conf/vip_index.conf . For example if this is an NG FP3 installation and you have a CMA named cma1, edit /opt/CPmds-53/customers/cma1/CPfw1-53/conf/vip_index.conf .

170

CHAPTER

Upgrading SmartLSM ROBO Gateways


In This Chapter
Planning the ROBO Gateway Upgrade Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository Upgrading a ROBO Gateway Using SmartLSM Using the Command Line Interface page 171 page 172 page 173 page 177

Planning the ROBO Gateway Upgrade


When you upgrade your SmartCenter Server, it is recommended to upgrade the ROBO Gateways managed by SmartLSM so that they are compatible with the latest features and functionalities. This chapter describes how to upgrade your ROBO Gateways. The general upgrade flow for upgrading your ROBO Gateways is: 1 In SmartDashboard, define new SmartLSM Profile objects for the new version and install the respective policies on these objects. This Install Policy operation only compiles the policy, it does not send it to any Gateway. The compiled policy is automatically fetched later by the relevant ROBO Gateways, following their upgrade. Add the upgrade package to the SmartUpdate package repository (see Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository on page 172). Upgrade ROBO Gateway licenses from version NG to NGX. See License Upgrade for a ROBO Gateway on page 172.

171

Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository

Upgrade your ROBO Gateways in one of the following ways: using SmartLSM (see Upgrading a ROBO Gateway Using SmartLSM on page 173) or using the SmartLSM Command Line Interface (see Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli on page 178).

The upgrade process removes the initial Plug & Play license from your gateway. Trying to perform a remote upgrade on a gateway without a valid NGX license will succeed, but this gateway will not be able to load the correct policy after the upgrade. Make sure that all gateways have valid permanent NG and NGX licenses installed before the upgrade.

Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository


Once you have launched SmartUpdate, add the packages needed for the upgrade to the SmartUpdate package repository. VPN-1 Edge Firmware packages are added the same way. For details of how to add packages to the Package Repository, see the SmartUpdate chapter of the SmartCenter user guide.

License Upgrade for a ROBO Gateway


To upgrade ROBO Gateway licenses to NGX: 1 Use any of the procedures described in chapter 2, Upgrading VPN-1 Pro/Express Licenses on page 17. Upgrading SmartCenter licenses also upgrades all ROBO Gateway licenses. Upgrade the software on the ROBO Gateway, as described in Upgrading a ROBO Gateway Using SmartLSM on page 173. Use SmartLSM to Attach the upgraded licenses to each ROBO Gateway, one ROBO at a time, as follows:

2 3

Using SmartLSM to Attach the Upgraded Licenses


4 5 At the SmartConsole GUI client machine, open SmartLSM. For each ROBO Gateway, open the Edit VPN-1 Express/Pro ROBO Gateway window, and select the Licenses tab. All licenses that are Attached to this ROBO Gateway are shown. If the license upgrade succeeded, the window will report that: There are un-attached licenses that are assigned to this ROBO.

172

License Upgrade on Multiple ROBO Gateways

Add those licenses that are Assigned to this ROBO from the SmartLSM License Repository to the Licenses window. You can do this by performing one of the following two options. The first way is easier: Click Add these licenses to the list. Click Add, and then select those licenses that are Assigned to this ROBO. The added Assigned licenses are shown grayed-out because they are not yet Attached. Click OK to Attach the Assigned Licenses to this ROBO. At this point the ROBO Gateway will have both NG and NGX licenses. The Licenses window shows that the NGX license is Attached, and the NG license is Obsolete, which means that it is no longer needed. The NG license is useful because if you need to downgrade the Gateway version, the Gateway will keep on working. Repeat from step 5 for each ROBO Gateway.

License Upgrade on Multiple ROBO Gateways


It is possible to use scripting to upgrade licenses on multiple ROBO Gateways. See Example: License Upgrade on Multiple ROBO Gateways on page 181 for details.

Upgrading a ROBO Gateway Using SmartLSM


In This Section
Upgrading a VPN-1 Express/Pro ROBO Gateway Full Upgrade Specific Installation Upgrading a VPN-1 Edge ROBO Gateway Upgrading a VPN-1 Express/Pro ROBO Gateway In Place page 173 page 174 page 174 page 175 page 176

Upgrading a VPN-1 Express/Pro ROBO Gateway


There are two methods for upgrading a VPN-1 Express/Pro Gateway, Full Upgrade and Specific Install: The Full Upgrade method automatically performs all the required checks and actions for you. When it successfully completes, the upgraded ROBO Gateway is ready for use. This is the recommended method to upgrade VPN-1 Express/Pro ROBO Gateways.

Chapter 8

Upgrading SmartLSM ROBO Gateways

173

Upgrading a ROBO Gateway Using SmartLSM

The Specific Install method can be used when you want to install a specific product on a ROBO Gateway.

Full Upgrade
1 2 3 From SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway that you want to upgrade. Select Actions > Packages > Upgrade All Packages. This selection can also be done through the right-click menu, or the Upgrade All Packages icon in the toolbar. The Upgrade process begins with a verification stage, checking which version is currently installed on the gateway, and whether the required packages exist in your Package Repository. When it completes, a Verification Details dialog box opens, showing you the verification results. Select the Change to a new Profile after upgrade checkbox, and select the appropriate new SmartLSM Profile from the list. Check the Click the
Allow reboot if required

4 5 6 7

checkbox.

Continue

button.

The Upgrade process begins. Its stages and completion status can be seen in the Action Status pane, at the bottom of SmartLSM. The entire progress report can be seen at any time by viewing the Action History (right-click on the respective line in the Action Status pane, and select Action History).

Specific Installation
1 2 3 In SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway you want to upgrade. Select Actions > Packages > Get Gateway Data to fetch information about Packages currently installed on the VPN-1 Express/Pro ROBO Gateway. Select Actions > Packages > Distribute Package This selection can also be done through the right-click menu, or the Distribute Package icon in the toolbar. The Distribute Package window appears. This window displays the relevant packages from the Package Repository that can be installed on your VPN-1 Express/Pro ROBO Gateway. In the Distribute Package window select the package you want to install. You can then select one of the following actions: Distribute and install packages

174

Upgrading a VPN-1 Edge ROBO Gateway

Only distribute packages (install later) Install previously distributed packages 5 The Allow Reboot if required checkbox should be checked only when upgrading VPN-1. If you do not select this checkbox, manually reboot the gateway from its console. The Gateway is rebooted after Package installation is completed.
Note -

If you are doing a step-by-step upgrade, do not check the required checkbox. If the operating system is SecurePlatform, you can select if the installation does not succeed.

Allow Reboot if

6 7

Backup image for

automatic revert,

The option Change to a new profile after install lets you select the SmartLSM Profile that will be assigned to the Package upon installation. When upgrading the VPN-1 Express/Pro ROBO Gateway, you must provide a suitable SmartLSM Profile from the target version. If you are installing a package that does not require changing the SmartLSM Profile of the VPN-1 Express/Pro ROBO Gateway, this field will remain disabled. Click the
Start

8 9

button.

The Install process begins. Its stages and completion status can be seen in the Action Status pane, at the bottom of SmartLSM. The whole progress report can be seen at any time by viewing the Action History (right click on the respective line in the Action Status pane, and select Action History).
Note - You can always verify if the installation will succeed before actually upgrading the ROBO Gateway by choosing Actions > Packages > Verify Installation.

Upgrading a VPN-1 Edge ROBO Gateway


1 In SmartLSM, select the line representing the VPN-1 Edge ROBO Gateway you want to upgrade, and choose Edit > Edit ROBO gateway This selection can also be done through the right-click menu, or the Edit ROBO gateway icon in the toolbar, or by double-clicking the ROBO line. Select the
Firmware

tab.

Chapter 8

Upgrading SmartLSM ROBO Gateways

175

Upgrading a ROBO Gateway Using SmartLSM

Select the Use the following firmware option, select the desired firmware from the list, and Click OK. The VPN-1 Edge ROBO Gateway will fetch and install the new firmware the next time it automatically checks for updates. In order for the firmware upgrade to take effect immediately, please restart the ROBO Gateway by selecting Actions > Restart gateway

Upgrading a VPN-1 Express/Pro ROBO Gateway In Place


It is possible to upgrade a ROBO gateway In Place (from the ROBO Gateway's console), just like an In Place upgrade of a regular gateway. Following the upgrade, update the new version on the SmartLSM side, and select a new SmartLSM Profile for the gateway. 1 In SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway you just upgraded, and choose Edit > Edit ROBO gateway This selection can also be performed through the right-click menu, the Edit ROBO gateway icon in the toolbar, or by double-clicking the ROBO line. The Edit dialog box opens in the General tab. From the From the Click
OK Version Profile

2 3 4 5

menu select the new version of the upgraded gateway.

menu select a new SmartLSM Profile for the upgraded gateway.

to close the dialog.

The policy and properties of the new SmartLSM Profile will be applied on the ROBO Gateway the next time it automatically checks for updates. In order for the SmartLSM Profile change to take effect immediately, please restart the ROBO Gateway by selecting Actions > Restart Gateway.

176

SmartLSM Upgrade Tools

Using the Command Line Interface


In This Section
SmartLSM Upgrade Tools Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli Upgrading a VPN-1 Edge ROBO Gateway Using LSMcli Using the LSMcli in Scripts page 177 page 178 page 179 page 180

SmartLSM Upgrade Tools


LSMcli The LSM Command Line Interface (LSMcli) is an alternative to SmartLSM. LSMcli provides the ability to perform SmartLSM operations from a command line or through a script. It also allows you to upgrade a ROBO Gateway. When used in scripts it allows you to perform batch upgrades. The LSMcli tool is contained in the SmartCenter installation package on the SmartCenter Server machine. It can be run either on your SmartCenter Server, or it can be copied to and run on another host with the same operating system. The host does not need to be a Check Point-installed machine, but it must be: Defined on the SmartCenter Server as a GUI Client. Of the same Operating System as the SmartCenter Server. Reachable through the network from the SmartCenter Server. For general usage and help, type the command LSMcli --help. The LSMcli command line arguments are fully described in the Command Line Reference chapter of the SmartLSM Guide. A partial list of arguments is shown in TABLE 8-1, which lists only the arguments that are important for performing upgrades.
TABLE 8-1

LSMcli Command line arguments for upgrades meaning...

argument -d Server User Password ROBO -F Firmware

(Optional) Run the command with debug output. The IP or hostname of the SmartCenter Server. The username and password of a SmartCenter Administrator. The name of the ROBO Gateway to be upgraded. The firmware version of the VPN-1 Edge ROBO Gateway.

Chapter 8

Upgrading SmartLSM ROBO Gateways

177

Using the Command Line Interface

TABLE 8-1

LSMcli Command line arguments for upgrades(Continued) meaning...

argument -P=Profile

(Optional) The SmartLSM Profile name the ROBO Gateway will be mapped to after a successful upgrade. You must specify the new SmartLSM Profile when upgrading the VPN-1 version. This is not necessary when installing Hotfixes or other packages.

-boot

(Optional) Use this option only when upgrading VPN-1 Pro. If you do not use this option, manually reboot the gateway from its console. (Optional) Install previously distributed packages. To see the list of all packages available in the repository, use the ShowRepository LSMcli command. (The usage of this command is described in the SmartLSM Users Guide).

-DoNotDistribute Product Vendor Version SP

Export The export tool is located in your SmartLSM application, File > Export to File. Use this tool to export a ROBO Gateways properties into a text file that you can turn into a script in order to perform batch upgrades.

Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli


For descriptions of the command line arguments for the following commands, see TABLE 8-1 on page 177. To verify that a Full Upgrade of a ROBO Gateway will succeed, execute:
LSMcli [-d] <Server> <User> <Password> VerifyUpgrade <ROBO>

To perform a Full Upgrade of a ROBO gateway, execute:


LSMcli [-d] <Server> <User> <Password> Upgrade <ROBO> [-P=Profile] [-boot]

To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository

To verify that a Specific Install on a ROBO gateway will succeed, execute:


LSMcli [-d] <Server> <User> <Password> VerifyInstall <ROBO> <Product> <Vendor> <Version> <SP>

178

Upgrading a VPN-1 Edge ROBO Gateway Using LSMcli

To perform a Specific Install on a ROBO gateway, execute:


LSMcli [-d] <Server> <User> <Password> Install <ROBO> <Product> <Vendor> <Version> <SP> [-P=Profile] [-boot] [-DoNotDistribute]

To only distribute a package, execute:


LSMcli [-d] <Server> <User> <Password> Distribute <ROBO> <Product> <Vendor> <Version> <SP>

To view a list of packages that can be installed on a specific ROBO gateway, execute:
LSMcli [-d] <Server> <User> <Password> GetCandidates <ROBO>

To get data about a specific ROBO gateway, execute:


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

Example: Upgrading a single VPN-1 Express/Pro ROBO Gateway


% LSMcli MyServer John mypassword VerifyUpgrade ROBO17 % LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile

Where: MyServer = the name of my SmartCenter Server. John = the administrators name. mypassword = the administrators password. VerifyUpgrade = the Full Upgrade verification command. Upgrade = the Full Upgrade command. ROBO17 = the VPN-1 Express/Pro ROBO Gateway to be upgraded. MyNewProfile = the new SmartLSM Profile that ROBO17 will be mapped to after the upgrade.

Upgrading a VPN-1 Edge ROBO Gateway Using LSMcli


For descriptions of the command line arguments for the following commands, see TABLE 8-1 on page 177. To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository

Chapter 8

Upgrading SmartLSM ROBO Gateways

179

Using the Command Line Interface

To upgrade a VPN-1 Edge ROBO gateway, execute:


LSMcli [-d] <Server> <User> <Password> ModifyROBO VPN1Edge <ROBO> [-P=Profile] [-F=Firmwarename]

If you want the firmware update to take effect immediately, execute:


LSMcli [-d] <Server> <User> <Password> Restart <ROBO>

Example: Upgrading a single VPN-1 Edge ROBO Gateway


% LSMcli MyServer John mypassword ModifyROBO VPN1Edge ROBO101-P=EdgeNewProfile -F=4.0.23 % LSMcli MyServer John mypassword Restart ROBO101

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

Using the LSMcli in Scripts


Scripting can be very handy when you want to upgrade multiple ROBO Gateways in batches. Example: Using the LSM CLI to write a script to upgrade multiple ROBO Gateways Create the following script and run it:
LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile LSMcli MyServer John mypassword Upgrade ROBO18 -P=MyNewProfile LSMcli MyServer John mypassword Upgrade ROBO19 -P=MyOtherProfile

180

Using the LSMcli in Scripts

Example: License Upgrade on Multiple ROBO Gateways To upgrade licenses on multiple ROBO Gateways, create a script that runs the LSMcli command with the AttachAssignedLicenses option on all ROBO Gateways. The AttachAssignedLicenses option is equivalent to doing step 6 and step 7 on page 173 in SmartLSM. The command is:
LSMcli [-d] <Server> <User> <Password> AttachAssignedLicenses VPN1 <ROBO>

For example:
LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO17 LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO18 LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO19

Chapter 8

Upgrading SmartLSM ROBO Gateways

181

Using the Command Line Interface

182

CHAPTER

Upgrading VSX SmartCenter Management


In This Chapter
Before You begin Supported VSX Upgrade Paths Supported VSX Upgrade Procedures page 183 page 186 page 188

Before You begin


VSX is a high-speed, multi-policy security solution designed for large enterprises, data centers and service provider POPs. By aggregating multiple security domains on a single platform, VPN-1 VSX minimizes hardware investment. The VSX Gateway, a single hardware device, allows replacement of complex network topologies consisting of several physical routers and VPN-1 gateways. It allows multiple networks to be protected, connected to shared resources such as the Internet and DMZs and interact with each other safely, while providing simplified and unified management, increased flexibility and cost savings.

183

Before You begin

License Upgrade
To upgrade the SmartCenter to NGX R60, you must first upgrade licenses for all NG products. a SmartCenter of version NGX R60 with licenses from previous versions will not function. It is highly recommended to upgrade licenses before upgrading the software. If necessary, license upgrade can be done after the software upgrade. See Upgrading VPN-1 Pro/Express Licenses on page 17 for details.

Tools for Upgrading a SmartCenter


Pre-Upgrade Verification During basic or either of the two phases of advanced upgrades, a pre-upgrade verification is automatically performed. If you prefer, you can run the pre-upgrade verification from the CD separately from the upgrade in order to prepare yourself for your upgrade. Pre-upgrade verification provides you with a report. Three types of results can be displayed in the report and are listed below.
Pre Upgrade-Verifier CLI Commands

Usage:
pre_upgrade_verifier -p SmartCenterPath -c CurrentVersion -t TargetVersion [-f FileName] [-w]

or
pre_upgrade_verifier -p SmartCenterPath -c CurrentVersion -i[-f FileName][-w]

-p -c -t -i -f -w

Path of the installed SmartCenter Server (FWDIR) Currently installed version Target version Check originality of INSPECT files only Output in file Web format file

Where the currently installed version is one of the following: VSX_NG_AI VSX_NG_AI_R2 The target version is: NGX R60 -f redirects the standard output to a file.
184

Tools for Upgrading a SmartCenter

Sample of Pre-Upgrade Verifier Output Action items before the upgrade


Errors: Correct the following problems in order to have a working environment. Duplicated Objects

Description: The object appears more than once in the database. Impacts: Using duplicate objects will cause problems in the SmartDashboard. To do: Rename one of the objects before starting the upgrade process. This problem will occur in the following objects
"shilog" appears twice under network_objects and services.

-------------------------------------------------------------------------------Warnings: It is recommended to resolve the following problems. Cluster New Module

Description: From FP3 we have centralized the cluster data. Many attributes that were taken from the members are now taken from the cluster object. Impacts: In the upgrade process the cluster data will be taken from one of the cluster members, if the data is not similar on all members it can lead to problems. To do: Make sure that all members of a cluster are identical. Make sure the following attributes appear: SYNDefender properties, Authentication properties (next http proxy configuration), SAM properties, NAT IP Pools properties, SMTP properties. Action Items before and after the Upgrade errorsItems that must be repaired before and after performing the upgrade. If you proceed with the upgrade while errors exist, your upgrade will fail. warningItems that you should consider repairing before and after performing the upgrade. Information Messages Items that should be noted.

Chapter 9

Upgrading VSX SmartCenter Management

185

Supported VSX Upgrade Paths

Supported VSX Upgrade Paths


In This Section
Upgrading VSX NG AI to NGX R60 SmartCenter Upgrading VSX NG AI R2 to NGX R60 SmartCenter page 186 page 187

VSX deployments have a management component and module component. The management component can be upgraded to NGX R60. NGX R60 SmartCenter Server can manage and enforce policies on VSX NG AI enforcement modules and the VSX NG AI management component can be upgraded to NGX R60. The following tables represent the available paths for VSX Management upgrade to NGX R60 SmartCenter:

Upgrading VSX NG AI to NGX R60 SmartCenter


Upgrade from Upgrade to Package Wrapper Advanced Upgrade

SecurePlatform SecurePlatform SecurePlatform SecurePlatform Solaris Solaris Solaris Solaris

SecurePlatform Solaris Windows IPSO SecurePlatform Solaris Windows IPSO

Yes Yes Yes Yes

186

Upgrading VSX NG AI R2 to NGX R60 SmartCenter

Upgrading VSX NG AI R2 to NGX R60 SmartCenter


Upgrade from Upgrade to Package Wrapper Advanced Upgrade

SecurePlatform SecurePlatform SecurePlatform SecurePlatform Solaris Solaris Solaris Solaris

SecurePlatform Solaris Windows IPSO SecurePlatform Solaris Windows IPSO

Yes Yes Yes Yes

Chapter 9

Upgrading VSX SmartCenter Management

187

Supported VSX Upgrade Procedures

Supported VSX Upgrade Procedures


Advanced Upgrade Procedures
In order to perform an Advanced Upgrade (that is, export/import) from VSX SmartCenter NG AI or NGAI R2 to NGX R60, NGX R60 export utilities must be used. Export from SecurePlatform Upgrading Smart Center Management VSX NGAI or VSX NGAI R2 to NGX R60 must be performed using NGX R60 upgrade tools (OS specific), download from Check Point's website (http://www.checkpoint.com/downloads/index.jsp). 1 2 3 4 5 Download NGX R60 upgrade_export. Login as admin. Switch to
expert

mode.

Insert the NGX R60 CD into the system CD drive. Mount the drive if necessary. Copy upgrade_export from the NGX R60 CD to your machine using the following command:
cp upgrade_export $FWDIR/bin/upgrade_tools/

Access the command: Copy


gtar

upgrade tools

folder in the following location using the following

cd $FWDIR/bin/upgrade_tools

and

gzip

from /bin to current the folder using the following commands:

. cp /bin/gzip .
cp /bin/gtar

8 9

Close all open GUI clients. Run the upgrade export utility (see Export Usage on page 189) using the following command:
./upgrade_export <filename>

10 Transfer the file (<file name>) to a remote location for future use.

188

Export and Import Commands

Export from Solaris 1 2 3 Login as admin. Insert the NGX R60 CD into the system CD drive. Mount the drive if necessary. Copy upgrade_export from the NGX R60 CD to you machine using the following command:
cp upgrade_export $FWDIR/bin/upgrade_tools/

Access the command:

upgrade tools

folder in the following location using the following

cd $FWDIR/bin/upgrade_tools

Run the upgrade export utility (see Export Usage on page 189) using the following command:
./upgrade_export <filename>

Transfer the file (<file name>) to a remote location for future import usage.

Import from SecurePlatform or Solaris 1 2 Copy the exported file from SecurePlatform or Solaris into the Spare machine. Run the
Import

tool. (see Import Usage on page 190)

Export and Import Commands


Import and Export tools are located under $FWDIR/bin/upgrade_tools. Export Usage
upgrade_export [-d] [-h] [-v] <exported file path>

Where:
<exported file path> -d -h -v

- the path to export the configuration file (default-local path)

- prints debug information - prints this usage - prints the version

Chapter 9

Upgrading VSX SmartCenter Management

189

Supported VSX Upgrade Procedures

Import Usage
upgrade_import [-d] [-h] <path>

Where:
<path> - The location of the exported file -v -d -h

- Prints the version - Prints debug information - Prints this usage

190

Index

A
Administrators 153 Authentication properties 185

G
Global Communities 155 Global Policy 155 Global VPN Communities 154

B
backup 47 Backup and Restore 118 backups of system settings 46 backward compatibility 12

H
High Availability 60, 150, 161 High-Availability 167

mds_setup 165 migrate_assist 117 migrate_global_policies 117 Migrating 156 migration process 58 Minimal Effort Upgrade 71, 97 MLM 162 Multi-MDS environments 161 MVS 14

N
Nokia clustering 98 Nokia OS 71

C
Check Point Gateway 13 CLM 113, 162 Clustered deployment 71 ClusterXL 14, 97 CMA 113, 116, 118, 152, 153, 158, 162, 170 cma_migrate 115 cprid 73 CRL 116

I
Import and Export tools 189 In Place Upgrade 14 Internal Certificate Authority 116 IPSO Platform 65, 80, 91

O
Operation Status 73 OPSEC 71, 72, 96

L
License Repository 19 License Upgrade 19 License_upgrade 20 Licensing Web Intelligence 56 Local Upgrade 70 LSM 14 LSMcli commands 177

P
Package Repository 13, 174 patch command 63, 77, 89 Performance Pack 71 Plug & Play 172 PolicyServer 71 Pre-upgrade utilities 164 Pre-Upgrade verification 58, 84 Pre-upgrade verification 59 pre-upgrade verification 61, 75, 85, 87, 112, 161, 162, 184 Pre-Upgrade Verifier 112 Products 57 products 51 Provider-1/SiteManager-1 upgrade 108

E
Enforcement Module 13, 55, 58 Enforcement Modules 74 errors 86, 185 Evaluation licenses 36 Eventia Reporter 71 Expert mode 63, 76 expert mode 188

M
MD5 checksum 63, 77 MDS 112, 113, 118, 119, 153, 158, 169 MDS environment 160 MDS High Availability 166 MDS services 160 mds_backup 119 mds_remove 165

F
FQDN 116 FTP access 157

191

Q
QoS 71

V
Virtual Routers 14 Virtual System 14 VPN distributed deployment 55 VPN-1 distributed deployment 83 VPN-1 Edge Firmware package 172 VPN-1 Pro Enforcement Modules 71 VPN-1 Pro Server 87 VSX Clustering 14 VSX Gateway 14, 183

R
release notes link 10 remote upgrade 172 restore 47 ROBO Gateway 171, 173, 175 ROBO Gateways 14 ROBO Profile 14

W
warning 86, 185 Web Intelligence Licensing 56 Whats New link 10 Wrapper 19

S
Safe Upgrade 62, 63, 76, 77, 88, 89, 151 SCP 46 SecureClient 39 SecurePlatform 26, 28, 31, 32, 57, 62, 63, 71, 76, 85, 88, 131, 132, 135, 136, 140, 142, 189 Security Policy 13 SmartCenter Server 13 SmartConsole Clients 13, 153 SmartDashboard 13 SmartLSM 171 SmartUpdate 13, 25, 72, 95, 99, 144 SmartUpdate Upgrade 70 SmartView Monitor 71 Software Upgrade 19 Solaris 189 Solaris Platform 64, 90 Spare machine 189 Standalone deployment 84 SYNDefender properties 185

Z
Zero Downtime 71, 97

T
TFTP 46, 49 The Full Upgrade method 173 The Specific Install method 174 Translation prompt 166

U
Uninstalling 156 upgrade_export 188 UserAuthority 71 192