CheckPoint NGX Upgrade Guide

The Upgrade Guide
NGX (R60)
For additional technical information about Check Point products, consult Check Point’s 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

August 2005
© 2003-2005 Check Point Software Technologies Ltd. NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
All rights reserved. This product and related documentation are protected by copyright TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
and distributed under licensing restricting their use, copying, distribution, and SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
decompilation. No part of this product or related documentation may be reproduced in The following statements refer to those portions of the software copyrighted by The
any form or by any means without prior written authorization of Check Point. While every OpenSSL Project. This product includes software developed by the OpenSSL Project for
precaution has been taken in the preparation of this book, Check Point assumes no use in the OpenSSL Toolkit (http://www.openssl.org/).
responsibility for errors or omissions. This publication and features described herein are THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT `ÀS IS'' AND ANY *
subject to change without notice. EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
RESTRICTED RIGHTS LEGEND: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
Use, duplication, or disclosure by the government is subject to restrictions as set forth in CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
DFARS 252.227-7013 and FAR 52.227-19. PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
TRADEMARKS: THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
©2003-2005 Check Point Software Technologies Ltd. All rights reserved. USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
Check Point, Application Intelligence, Check Point Express, the Check Point logo, DAMAGE.
AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, The following statements refer to those portions of the software copyrighted by Eric
Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX, Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS IS'' AND ANY
FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR
SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone DAMAGE. Copyright © 1998 The Open Group.
Labs logo, are trademarks or registered trademarks of Check Point Software The following statements refer to those portions of the software copyrighted by Jean-loup
Technologies Ltd. or its affiliates. All other product names mentioned herein are Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This
trademarks or registered trademarks of their respective owners. The products described software is provided 'as-is', without any express or implied warranty. In no event will the
in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and authors be held liable for any damages arising from the use of this software. Permission
6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending is granted to anyone to use this software for any purpose, including commercial
applications. 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
THIRD PARTIES: 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.
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and
other countries. Entrust’s logos and Entrust product and service names are also 2. Altered source versions must be plainly marked as such, and must not be
trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned misrepresented as being the original software.
subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate 3. This notice may not be removed or altered from any source distribution.
certificate management technology from Entrust. 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
Verisign is a trademark of Verisign Inc. 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
The following statements refer to those portions of the software copyrighted by University
program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
of Michigan. Portions of the software copyright © 1992-1996 Regents of the University of
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
Michigan. All rights reserved. Redistribution and use in source and binary forms are
PARTICULAR PURPOSE. See the GNU General Public License for more details.You
permitted provided that this notice is preserved and that due credit is given to the
should have received a copy of the GNU General Public License along with this program;
University of Michigan at Ann Arbor. The name of the University may not be used to
if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
endorse or promote products derived from this software without specific prior written
USA.
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 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
The following statements refer to those portions of the software copyrighted by Carnegie copy of this software and associated documentation files (the "Software"), to deal in the
Mellon University. Software without restriction, including without limitation the rights to use, copy, modify,
Copyright 1997 by Carnegie Mellon University. All Rights Reserved. merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit
Permission to use, copy, modify, and distribute this software and its documentation for persons to whom the Software is furnished to do so, subject to the following conditions:
any purpose and without fee is hereby granted, provided that the above copyright notice The above copyright notice and this permission notice shall be included in all copies or
appear in all copies and that both that copyright notice and this permission notice appear substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT
in supporting documentation, and that the name of CMU not be used in advertising or WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
publicity pertaining to distribution of the software without specific, written prior TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, OR OTHER DEALINGS IN THE SOFTWARE.
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. distribute or represent the code as your own. Any re-distributions of the code MUST
The following statements refer to those portions of the software copyrighted by The Open reference the author, and include any and all original documentation. Copyright. Bruce
Group. Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998,
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999,
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 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, CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
Ellson (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
(ellson@graphviz.org). Portions relating to JPEG and to color quantization copyright This software consists of voluntary contributions made by many individuals on behalf of
2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, the PHP Group. The PHP Group can be contacted via Email at group@php.net.
2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the For more information on the PHP Group and the PHP project, please see <http://
Independent JPEG Group. See the file README-JPEG.TXT for more information. www.php.net>. This product includes the Zend Engine, freely available at <http://
Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van www.zend.com>.
den Brande. Permission has been granted to copy, distribute and modify gd in any This product includes software written by Tim Hudson (tjh@cryptsoft.com).
context without fee, including a commercial application, provided that this notice is
present in user-accessible supporting documentation. This does not affect your Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il>
ownership of the derived work itself, and the intent is to assure proper credit for the All rights reserved.
authors of gd, not to interfere with your productive use of gd. If you have questions, ask. Redistribution and use in source and binary forms, with or without modification, are
"Derived works" includes all programs that utilize the library. Credit must be given in permitted provided that the following conditions are met:
user-accessible documentation. This software is provided "AS IS." The copyright holders Redistribution of source code must retain the above copyright notice, this list of
disclaim all warranties, either express or implied, including but not limited to implied conditions and the following disclaimer.
warranties of merchantability and fitness for a particular purpose, with respect to this Neither the name of Itai Tzur nor the names of other contributors may be used to
code and accompanying documentation. Although their code does not appear in gd 2.0.4, endorse or promote products derived from this software without specific prior written
the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software permission.
Corporation for their prior contributions. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
file except in compliance with the License. You may obtain a copy of the License at http:/ INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
/www.apache.org/licenses/LICENSE-2.0 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
The curl license DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
COPYRIGHT AND PERMISSION NOTICE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved. CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
Permission to use, copy, modify, and distribute this software for any purpose OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS
with or without fee is hereby granted, provided that the above copyright
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
notice and this permission notice appear in all copies. WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd
NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR Permission is hereby granted, free of charge, to any person obtaining a copy of this
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR software and associated documentation files (the "Software"), to deal in the Software
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE without restriction, including without limitation the rights to use, copy, modify, merge,
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 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
Except as contained in this notice, the name of a copyright holder shall not be used in above copyright notice and this permission notice shall be included in all copies or
advertising or otherwise to promote the sale, use or other dealings in this Software substantial portions of the Software.
without prior written authorization of the copyright holder.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
The PHP License, version 3.0 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
Redistribution and use in source and binary forms, with or without modification, is NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
permitted provided that the following conditions are met: HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
1. Redistributions of source code must retain the above copyright notice, this list of IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
conditions and the following disclaimer. IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
2. Redistributions in binary form must reproduce the above copyright notice, this list of THE SOFTWARE.
conditions and the following disclaimer in the documentation and/or other materials Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.
provided with the distribution. Confidential Copyright Notice
3. The name "PHP" must not be used to endorse or promote products derived from this Except as stated herein, none of the material provided as a part of this document may be
software without prior written permission. For written permission, please contact copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or
group@php.net. transmitted in any form or by any means, including, but not lim-ited to, electronic,
4. Products derived from this software may not be called "PHP", nor may "PHP" appear mechanical, photocopying, recording, or otherwise, without the prior written permission of
in their name, without prior written permission from group@php.net. You may indicate NextHop Technologies, Inc. Permission is granted to display, copy, distribute and
that your software works in conjunction with PHP by saying "Foo for PHP" instead of download the materials in this doc-ument for personal, non-commercial use only,
calling it "PHP Foo" or "phpfoo" provided you do not modify the materials and that you retain all copy-right and other
5. The PHP Group may publish revised and/or new versions of the license from time to proprietary notices contained in the materials unless otherwise stated. No material
time. Each version will be given a distinguishing version number. Once covered code has contained in this document may be "mirrored" on any server without written permission of
been published under a particular version of the license, you may always continue to use NextHop. Any unauthorized use of any material contained in this document may violate
it under the terms of that version. You may also choose to use such covered code under copyright laws, trademark laws, the laws of privacy and publicity, and communications
the terms of any subsequent version of the license published by the PHP Group. No one regulations and statutes. Permission terminates automatically if any of these terms or
other than the PHP Group has the right to modify the terms applicable to covered code condi-tions are breached. Upon termination, any downloaded and printed materials must
created under this License. be immediately destroyed.
6. Redistributions of any form whatsoever must retain the following acknowledgment: Trademark Notice
"This product includes PHP, freely available from <http://www.php.net/>". The trademarks, service marks, and logos (the "Trademarks") used and displayed in this
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM `ÀS IS'' AND document are registered and unregistered Trademarks of NextHop in the US and/or other
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, countries. The names of actual companies and products mentioned herein may be
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A Trademarks of their respective owners. Nothing in this document should be construed as
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP granting, by implication, estoppel, or otherwise, any license or right to use any Trademark
DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, displayed in the document. The owners aggressively enforce their intellectual property
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES rights to the fullest extent of the law. The Trademarks may not be used in any way,
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR including in advertising or publicity pertaining to distribution of, or access to, materials in
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) this document, including use, without prior, written permission. Use of Trademarks as a
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN "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 PCRE LICENCE
The material in document is provided with "RESTRICTED RIGHTS." Software and PCRE is a library of functions to support regular expressions whose syntax and
accompanying documentation are provided to the U.S. government ("Government") in a semantics are as close as possible to those of the Perl 5 language. Release 5 of PCRE
transaction subject to the Federal Acquisition Regulations with Restricted Rights. The is distributed under the terms of the "BSD" licence, as specified below. The
Government's rights to use, modify, reproduce, release, perform, display or disclose are documentation for PCRE, supplied in the "doc" directory, is distributed under the same
restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and terms as the software itself.
Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun Written by: Philip Hazel <ph10@cam.ac.uk>
1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in Data- University of Cambridge Computing Service, Cambridge, England. Phone:
General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the +44 1223 334714.
Commer-cial Copyright (c) 1997-2004 University of Cambridge All rights reserved.
Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987). Redistribution and use in source and binary forms, with or without modification, are
Use of the material in this document by the Government constitutes acknowledgment of permitted provided that the following conditions are met:
NextHop's proprietary rights in them, or that of the original creator. The Contractor/ * Redistributions of source code must retain the above copyright notice, this list of
Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. conditions and the following disclaimer.
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in
applicable laws and regulations. * 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
Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty provided with the distribution.
THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES * Neither the name of the University of Cambridge nor the names of its contributors may
OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE be used to endorse or promote products derived from this software without specific prior
PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRANTIES, written permission.
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
OF, OR OTHERWISE RESPECTING, THE MATERIAL IN THIS DOCUMENT. CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
Limitation of Liability OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING, LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
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 11
Documentation 12
NGX License Upgrade 13
Supported Upgrade Paths and Interoperability 14
Obtaining Software Installation Packages 15
Terminology 15
Upgrade Tools 17
Chapter 2 Upgrading VPN-1 Pro/Express Licenses

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

Introduction 45
Backup your Current Deployment 46
Restore a Deployment 46
Table of Contents 7
SecurePlatform Backup and Restore Commands 47
Backup 47
Restore 48
SecurePlatform Snapshot Image Management 49
Snapshot 49
Revert 50
Revert to your Previous Deployment 52
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 68
Upgrading the Enforcement Module 71
Upgrading a Clustered Deployment 71
Upgrading the Enforcement Module Using SmartUpdate 72
Enforcement Module Upgrade Process on a Windows Platform 76
Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions 77
Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 78
Enforcement Module Upgrade on a Solaris Platform 80
Enforcement Module Upgrade on an IPSO Platform 81
Chapter 5 Upgrading a Standalone VPN-1 Pro/Express Deployment

Introduction 85
Pre-Upgrade Considerations 86
License Upgrade to NGX 87
Upgrading Products on a SecurePlatform Operating System 87
Reverting to your Previous Software Version 87
Using the Pre-Upgrade Verification Tool 87
Standalone VPN-1 Gateway Upgrade on a Windows Platform 89
Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later Versions 90
Standalone VPN-1 Gateway Upgrade on SecurePlatform NG FP2, FP3, FP3 Edition 2 91
Standalone VPN-1 Gateway Upgrade on a Solaris Platform 92
Standalone VPN-1 Gateway Upgrade on an IPSO Platform 93
Migrate your Current VPN-1 Gateway Configuration and Upgrade 96
8
Chapter 6 Upgrading ClusterXL
License Upgrade to NGX 97
Tools for Gateway Upgrades 97
Planning a Cluster Upgrade 99
Permanent Kernal Global Variables 99
Ready state during Cluster Upgrade/Downgrade operations 99
Upgrading OPSEC Certified Third Party Clusters Products 101
Performing a Minimal Effort Upgrade on a ClusterXL Cluster 101
Performing a Zero Down Time Upgrade on a ClusterXL Cluster 101
Supported Modes 101
Performing a Full Connectivity Upgrade on a ClusterXL Cluster 104
Understanding a Full Connectivity Upgrade 104
Supported Modes 104
Terminology 104
Implementing a Full Connectivity Upgrade 105
Chapter 7 Upgrading Provider-1

Introduction 110
Scope 110
Before You Begin 110
Supported Platforms 111
Supported Versions for Upgrade 111
Summary of Sections in this Chapter 111
Provider-1/SiteManager-1 Upgrade Tools 113
Pre-Upgrade Verifiers and Fixing Utilities 113
Installation Script 114
pv1_license_upgrade 115
license_upgrade 116
cma_migrate 117
migrate_assist 119
migrate_global_policies 119
Backup and Restore 120
Provider-1/SiteManager-1 License Upgrade 122
Overview of NGX License Upgrade 123
Introduction to License Upgrade in Provider-1 Environments 124
Software Subscription Requirements 124
Understanding Provider-1/SiteManager-1 Licenses 124
Before License Upgrade 126
Choosing The Right License Upgrade Procedure 131
License upgrade of Entire System Before Software Upgrade 133
License Upgrade of Entire System Using Wrapper 136
License upgrade of Entire System After Software Upgrade 137
License Upgrade for a Single CMA 140
License Upgrade Using the User Center 146
SmartUpdate Considerations for License upgrade 146
Troubleshooting License Upgrade 147
Provider-1/SiteManager-1 Upgrade Practices 152
In-place Upgrade 152
Table of Contents 9
Replicate and Upgrade 154
Gradual Upgrade to Another Machine 155
Migrating from a Standalone Installation to CMA 158
MDS Post Upgrade Procedures 162
Upgrading in a Multi MDS Environment 163
Pre-Upgrade Verification and Tools 163
Upgrading an NG with Application Intelligence Multi-MDS System 163
Restoring your Original Environment 166
Before the Upgrade 166
Restoring your Original Environment 167
Renaming Customers 167
Identifying Non-Compliant Customer Names 167
High-Availability Environment 168
Automatic Division of Non-compliant Names 168
Resolving the Non-compliance 168
Advanced Usage 169
Changing MDS IP address and External Interface 171
IP Address Change 171
Interface Change 172
Chapter 8 Upgrading SmartLSM ROBO Gateways

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

Before You begin 185
License Upgrade 186
Tools for Upgrading a SmartCenter 186
Supported VSX Upgrade Paths 188
Upgrading VSX NG AI to NGX R60 SmartCenter 188
Upgrading VSX NG AI R2 to NGX R60 SmartCenter 189
Supported VSX Upgrade Procedures 190
Advanced Upgrade Procedures 190
Export and Import Commands 191
10
CHAPTER 1
Introduction to the
Upgrade Process
In This Chapter
Upgrading Successfully page 11

Documentation page 12
NGX License Upgrade page 13
Supported Upgrade Paths and Interoperability page 14
Obtaining Software Installation Packages page 15
Terminology page 15
Upgrade Tools page 17
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
11
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:
For a new features list refer to the “NGX R60 What’s New Guide”:
12
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.
2 Simulate the license upgrade process.
3 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 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 19.
• License upgrade for Provider-1 deployments is described in
“Provider-1/SiteManager-1 License Upgrade” on page 122.
• License upgrade for SmartLSM deployments is described in “License Upgrade for a
ROBO Gateway” on page 174.
• 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 13

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

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

Upgrade Tools
18
CHAPTER 2
Upgrading VPN-1
Pro/Express Licenses
In This Chapter
Overview of NGX License Upgrade page 20

Introduction to License Upgrade in VPN-1 Express/Pro Environments page 20
Software Subscription Requirements page 20
Licensing Terminology page 21
The License_Upgrade Tool page 22
Simulating the License Upgrade page 23
Performing the License Upgrade page 25
Trial Licenses page 36
Troubleshooting License Upgrade page 37
19
Overview of NGX License 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 122.
• “License Upgrade for a ROBO Gateway” on page 174.
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

accounts for which you do not have software subscription.
20
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 21

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.
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
• 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
22
Tool Options
The options are:

TABLE 2-1 license_upgrade tool options
Option Meaning
[L] View the licenses installed on your machine.
[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
[U] Sends existing licenses to the User Center Web site to perform upgrade
and (by default, in online mode) installs them on the machine.
[C] Reports whether or not there are licenses on the machine that need to be
upgraded.
[O] Perform license upgrade on a license file that was generated on a machine
with no Internet access to the User Center.
[V] View log of last license upgrade or last upgrade simulation.
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.
1 Copy the license_upgrade tool from <Specific_platform>\ on the NGX

product CD, or from the Check Point Download site at
2 Place the license_upgrade tool on the NG machine.
3 To simulate the license upgrade, run the license_upgrade tool option
[S] Simulate the license upgrade.

Simulating the License Upgrade
4 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 37.
• Refer to SecureKnowledge at https://secureknowledge.checkpoint.com.
24
License Upgrade Methods
Performing the License Upgrade

In This Section
License Upgrade Methods page 25

Deployments with Licenses Managed Centrally Using SmartUpdate page 27
Deployments with Licenses Managed Locally page 33
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.

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

Management
method
Centrally managed Entire managed System • Local machine licenses
using SmartUpdate (Run upgrade tool on (for SmartCenter)
SmartCenter Server) • License Repository
(for enforcement
modules)
Locally managed Enforcement module • Local machine licenses
SmartCenter Server • Local machine licenses
Standalone Gateway • Local machine licenses
deployment, containing both (for SmartCenter and
a SmartCenter and an enforcement module).
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 27
• “Deployments with Licenses Managed Locally” on page 33
26
Deployments with Licenses Managed Centrally Using SmartUpdate
Deployments with Licenses Managed Centrally Using

SmartUpdate
In This Section
“Introduction to Using SmartUpdate” on page 27

“1. License Upgrade for an Online SmartCenter” on page 27
“2. License Upgrade for an Offline SmartCenter” on page 30
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 37 for details.

1 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.
2 Copy the license_upgrade tool from <Specific_platform>\ on the NGX
product CD, or from the Check Point Download site at
3 Place the license_upgrade tool on the SmartCenter NG machine.
4 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.
5 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.
6 Perform the software upgrade to NGX on the SmartCenter machine and on the
SmartConsole GUI machine.
7 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.
8 Perform the software upgrade to NGX on the enforcement module machine(s).

9 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.
28
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.

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.
1 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.
2 Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD,
or from the Check Point Download site at
3 Place the license_upgrade tool on the offline SmartCenter Server NG.
4 At the offline SmartCenter, run
license_upgrade
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 don’t 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.
6 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.
7 Copy the license_upgrade tool to the online machine from the location specified
in step 2.
8 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.
30
• 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.

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.

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.
32
Deployments with Licenses Managed Locally
In This Section
“3. License Upgrade for an Online Machine” on page 33

“4. License Upgrade for an Offline Machine” on page 34
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.

2 Place the license_upgrade tool on the online NG machine.
3 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.
4 Choose the [U] option. This does the following:

• Collects all the licenses that exist on the machine.
• Installs new licenses on the local machine.
• On a SmartCenter machine, if Management High Availability licenses exist, they
are upgraded.

5 Perform the software upgrade to NGX.

6 Find out which license on the machine are obsolete. Run
cplic print
7 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.

2 Place the license_upgrade tool on the offline machine.
3 At the offline machine, run
license_upgrade
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 don’t 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.
5 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.
34
6 Copy the license_upgrade tool to the online machine. The tool is located at the
location specified in step 1.
7 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.
8 Copy the cache file (with the new licenses) to the offline machine. Copy the file to
the same directory as the license_upgrade tool.
9 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.
10 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.
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>

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.
36
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” page 37

Evaluation Licenses Created in the User Center page 38
Evaluation Licenses Not Created in the User Center page 38
Licenses of Products That Are Not Supported in NGX page 39
License Enforcement on Module is now on Management page 39
License Not in Any Of Your User Center Accounts page 40
User Does Not Have Permissions on User Center Account page 41
SKU Requires Two Licenses in NG and One License in NGX page 41
SmartDefense Licenses page 42
License Upgrade Partially Succeeds page 42
Upgraded Licenses Do Not Appear in the Repository page 43
Cannot Connect to the User Center page 43
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.

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 25 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 don’t 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
38
Licenses of Products That Are Not Supported in NGX
CK-CHECK-POINT-INTERNAL-USE-ONLY
Resolution
Evaluation licenses cannot be upgraded. If you don’t 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
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

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 Perform a license upgrade at the User Center web site to generate a new license.
2 Install the new, upgraded license on the NGX management machine (even if you
do not upgrade the gateway).
3 Upgrade the gateway.
4 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.
40
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
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

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
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 37 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>
42
Upgraded Licenses Do Not Appear in the Repository
• In the Check Point Download site at

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.
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.
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.
44
CHAPTER 3
Backup and Revert for

VPN-1 Pro/Express
In This Chapter
Introduction page 45
Backup your Current Deployment page 46
Restore a Deployment page 46
SecurePlatform Backup and Restore Commands page 47
SecurePlatform Snapshot Image Management page 49
Revert to your Previous Deployment page 52
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 tool of the version for which you
are creating a backup file (for example, if you are backing up NG with Application
Intelligence R55, use the NG with Application Intelligence Export utility tool). The
backup file 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 Insert the product CD for the version you are backing up, into the original
SmartCenter Server.
2 Use the Export tool located in the relevant operating system directory on the
product CD.
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 Copy the exported.tgz file to the target SmartCenter Server.
2 Insert the product CD for the version being restored into the SmartCenter Server.
3 Use the provided options to perform an installation using an imported
configuration file.
46
Backup
SecurePlatform Backup and Restore Commands

In This Section
Backup page 47
Restore 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.
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>]]
Chapter 3 Backup and Revert for VPN-1 Pro/Express 47

SecurePlatform Backup and Restore Commands
Parameters
TABLE 3-1 Backup Parameters
parameter meaning
-h obtain usage
-d debug flag
-l flag enables VPN-1 Pro log backup (By default,
VPN-1 Pro logs are not backed up.)
--purge DAYS delete old backups from previous backup attempts
[--sched [on hh:mm <-m schedule interval at which backup is to take place
DayOfMonth> | <-w
DaysOfWeek>] | off] • On - specify time and day of week, or day of
month
• Off - disable schedule
--tftp <ServerIP> [-path List of IP addresses of TFTP servers, on which the
<Path>][<Filename>] configuration will be backed up, and optionally the
filename.
--scp <ServerIP> List of IP addresses of SCP servers, on which the
<Username> <Password>[- configuration will be backed up, the username and
path <Path>] [<Filename>]
password used to access the SCP Server, and
optionally the filename.
--file [-path When the backup is performed locally, specify an
<Path>]<Filename> optional filename
Restore
Restore the system configuration.
Syntax
restore [-h] [-d][[--tftp <ServerIP> <Filename>] |

[--scp <ServerIP> <Username> <Password> <Filename>] |
[--file <Filename>]]
Parameters
parameter meaning
-h obtain usage
-d debug flag
48
Snapshot
--tftp <ServerIP> IP address of TFTP server, from which the

[<Filename>] configuration is restored, and the filename.
--scp <ServerIP> IP address of SCP server, from which the
<Username> <Password> configuration is restored, the username and password
[<Filename>]
used to access the SCP Server, and the filename.
--file <Filename> Specify a filename for restore operation, performed
locally.
For more information about the backup and restore utilities, see the System Commands
section in the SecurePlatform & SecurePlatform Pro guide on page 88.
SecurePlatform Snapshot Image Management

In This Section
Snapshot page 49
Revert 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>] |


SecurePlatform Snapshot Image Management
Parameters
TABLE 3-2 Snapshot Parameters
parameter meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is made, as well as the filename of the
snapshot.
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is made, the username and password used to
<Filename>
access the SCP Server, and the filename of the
snapshot.
--file <Filename> When the snapshot is made locally, specify a filename
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>] |
Parameters
TABLE 3-3 Revert Parameters
parameter meaning
-h obtain usage
-d debug flag
50
Revert
TABLE 3-3 Revert Parameters
parameter meaning
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is rebooted, as well as the filename of the
snapshot.
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is rebooted, the username and password used
<Filename>
to access the SCP Server, and the filename of the
snapshot.
--file <Filename> When the snapshot is made locally, specify a filename
The revert command functionality can also be accessed from the Snapshot image
management boot option.

Revert to your Previous Deployment

In This Section
Nokia platforms page 52

Windows Platforms page 52
Solaris page 52
SecurePlatform page 52
Linux page 52
Internal Certificate Authority Revert Considerations page 53
To revert to the software version prior to the active VPN-1 Pro/Express, perform the
following for each operating system:
Nokia platforms
1) Deactivate Check Point VPN-1 Pro/Express NGX R60.
2) Enter Delete Packages and delete Check Point VPN-1 Pro/Express NGX R60.
3) When uninstalling NGX R60 products, make sure that VPN-1 Pro/Express NGX
R60 is active.
4) Deactivate and delete the VPN-1 Pro/Express NGX R60 only after you have
deleted all other NGX R60 products.
Windows Platforms
In the Add/Remove Programs applet, select Check Point VPN-1 Pro NGX R60.
Solaris
1) Run the command: pkgrm CPsuite-R60.
SecurePlatform
1) For SecurePlatform machines enter expert mode to uninstall the package.
2) Run the command: rpm –e CPsuite-R60-00.
Linux
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.
2 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.
3 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.

54
CHAPTER 4
Upgrading a Distributed
VPN-1 Pro/Express
Deployment
In This Chapter
Upgrading the SmartCenter Server Component page 58
Upgrading the Enforcement Module page 71
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
In This Section
License Upgrade to NGX R60 page 56

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

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 19 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 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.
2 In the [Server] section, add the following:
TopologyOldFormat=1
3 Save and close the file.

The change takes effect without running the commands cpstop and cpstart.
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 52.
Chapter 4 Upgrading a Distributed VPN-1 Pro/Express Deployment 57

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 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 68) 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 page 59

Upgrading a SmartCenter High Availability Deployment page 60
SmartCenter Upgrade on a Windows Platform page 61
SmartCenter Upgrade on SecurePlatform R54, R55 and Later Versions page 62
SmartCenter Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 page 63
SmartCenter Server Upgrade on a Solaris Platform page 64
SmartCenter Upgrade on an IPSO Platform page 65
Migrate your Current SmartCenter Configuration and Upgrade page 68
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
-i[-f FileName][-w]
-p Path of the installed SmartCenter Server (FWDIR)

-c Currently installed version
-t Target version
-i Check originality of INSPECT files only
-f Output in file
-w Web format file
Where the currently installed version is one of the following:

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

Upgrading a SmartCenter High Availability Deployment

To upgrade a SmartCenter Server High Availability deployment proceed as follows:
1 Before you perform the Upgrade process, synchronize all the SmartCenter Servers
(select Policy > Management High Availability).
2 Perform the Upgrade process on both SmartCenter Servers (refer to the relevant
upgrade process below).
3 Using the SmartDashboard GUI client, connect to one of the SmartCenter Servers.
4 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.
5 Once again, synchronize all the SmartCenter Servers (select Policy > Management
High Availability).
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 52 for detailed information.
The following upgrade steps describe the upgrade process using the NGX R60 CD.
1 Access your NGX R60 CD
2 Execute the Installation package.
3 Select Upgrade from the Upgrade Options screen.
4 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.
5 Select Upgrade again, from the Upgrade Options screen.
At this point, another verification will run.
6 When prompted, reboot your SmartCenter Server.

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.
(Operating System and software packages) in a single upgrade process. No further
upgrades are required.
Refer to NGX R60 SecurePlatform Guide for additional information.
Using a CD ROM
The following steps depict how to upgrade SecurePlatform R54 and later versions using
a CD ROM drive.
1 Log into SecurePlatform (Expert mode is not necessary).
2 Apply the SecurePlatform NGX R60 upgrade package:
# patch add cd.
3 At this point you will be asked to verify the MD5 checksum.

4 Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No
If you select Yes, a Safe Upgrade 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 pre R54 versions requires an upgrade of the patch command.
1 Insert the SecurePlatform NGX R60 CD into the drive.
2 Enter the Expert mode: # expert.
3 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.
4 Apply the SecurePlatform NGX R60 upgrade package by using a CD ROM drive
with the following command:
# patch add cd.

If you chose Yes, a Safe Upgrade will be performed.
Upgrade image.

SmartCenter Server Upgrade on a Solaris Platform

This section describes the steps that should be performed when performing an upgrade
on a Solaris Platform.
1 Insert the NGX R60 CD into the CD drive.
2 Run UnixInstallScript.
3 Select Yes if you agree to the license terms.
4 A list of products appears and you are asked to select the products that you would
like to install.
5 Select Next (N) to continue.
6 At this point you are asked to reboot the machine. Select Yes (Y).
64
SmartCenter Upgrade on an IPSO Platform

on an IPSO Platform.
1 Enter Network Voyager and open a CLI console.
2 Click System Configuration > Install New IPSO Image (Upgrade).
The New Image Installation Upgrade window appears.
3 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)
4 Click Apply.
At this point you are informed that the file download and image installation can
take a long time.
5 Click Apply.
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.
7 Under the title Select an image for next boot, select the last downloaded image.
8 Click Test Boot.
9 In the window that appears select Commit testboot 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:
• 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 Applications select Off in the following line:

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

Check Point SVN Foundation NG with Application Intelligence (R55)
21 Click 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)?
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 Enter.
66
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.
Uninstalling Previous Software Packages

When trying to remove previous NG packages on Nokia platforms when VPN-1
Pro/Express NGX R60 is active, perform the following steps:
1 Deactivate VPN-1 Pro/Express NGX R60. But, if dependent packages are active,
deactivate them first.
2 Activate the previous SVN Foundation.
3 Delete the previous FireWall-1 version.
4 Deactivate the previous SVN Foundation.
5 Delete a previous SVN Foundation.
6 Activate VPN-1 Pro/Express NGX R60 and dependent products.

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

Steps Required for Migrating a SmartCenter Server to a New Machine with a Different
IP Address page 69
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 Insert the NGX R60 CD into the original SmartCenter Server.
2 Choose Export in Upgrade Options.
If you chose to perform the Export procedure manually make sure you are using
the NGX R60 Export tool.
3 Select the destination path of the configuration (.tgz) file.
Wait while exporting database files.
4 Copy the exported.tgz file to the new SmartCenter Server.
5 Insert the NGX R60 CD into the new SmartCenter Server.
68
Migrate your Current SmartCenter Configuration and Upgrade
6 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
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
1 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 Server’s 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.
2 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.
3 Install the new security policy on all Enforcement Modules.
4 Follow the Advanced Upgrade page 68 process to migrate your original SmartCenter
Server.

After migrating your original SmartCenter Server
1 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 19 for additional information.
2 Using the cpstart command start the new SmartCenter Server.
3 Access the new SmartCenter Server using SmartDashboard.
4 On the new SmartCenter Server update the primary SmartCenter object so that its
IP Address and topology match its new configuration.
5 On the new SmartCenter Server remove the object you created to represent the
new SmartCenter Server’s IP address (refer to step 1 in the previous section).
6 On the DNS Server map the Primary SmartCenter Server’s DNS to the new IP
address.
70
Upgrading a Clustered Deployment
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 page 71

Upgrading the Enforcement Module Using SmartUpdate page 72
Enforcement Module Upgrade Process on a Windows Platform page 76
Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions page 77
Enforcement Module Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 page 78
Enforcement Module Upgrade on a Solaris Platform page 80
Enforcement Module Upgrade on an IPSO Platform page 81
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
• UserAuthority Server
• PolicyServer (when it is a part of the NGX R60 software package)
• QoS
• Nokia OS
72
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 SmartUpdate’s 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.
2 SmartUpdate’s 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.
3 SmartUpdate’s Get Check Point Gateway Data - This tool updates
SmartUpdate with the current Check Point or OPSEC third party packages
installed on a specific gateway or for your entire enterprise.
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 Define the remote Check Point gateways in SmartDashboard (for a new

SmartCenter Server installation).
3 Verify that your SmartCenter Server contains the correct license to use
SmartUpdate.
4 Verify that the Administrator SmartUpdate permissions (as defined in the cpconfig
configuration tool) are Read/Write.
5 To enable SmartUpdate connections to the enforcement modules, make sure that
Policy Global Properties > FireWall-1 Implied Rules > Accept CPRID Connections
(SmartUpdate) is checked. By default, it is checked.

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.
2 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.
74
• 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 to prior NGX R60 versions using SmartUpdate NGX

R60
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 Add the corresponding packages to the Package Repository.
2 Right-click the Enforcement Module and select Distribute Package...
3 Select the relevant package from the list provided and click Distribute.
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).

Enforcement Module Upgrade Process on a Windows Platform

The following upgrade steps describe the upgrade process using the NGX R60
Installation CD.
1 Access your NGX R60 CD.
4 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.
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.
6 Select Upgrade again from the Upgrade Options screen.
7 When prompted, reboot your Enforcement Module Server.
8 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.
76
Enforcement Module Upgrade on SecurePlatform R54, R55 and Later Versions
Enforcement Module Upgrade on SecurePlatform R54, R55

and Later Versions
both the operating system and software products installed. SecurePlatform users should
Using a CD ROM
a CD ROM drive.
2 Apply the SecurePlatform NGX R60 upgrade package: # patch add cd.
Upgrade image.

Enforcement Module Upgrade on SecurePlatform NG FP2, FP3,

or FP3 Edition 2
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.
3 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 cd.

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


Enforcement Module Upgrade on a Solaris Platform

2 Run UnixInstallScript from the root directory of the NGX R60 CD.
4 A list of the existing products appears. Select Next (N) to continue.
like to install.
80
Enforcement Module Upgrade on an IPSO Platform


4 Click Apply.
take a long time.
5 Click Apply.
8 Click Test Boot.
set properly.

• CPshared
• VPN-1/FW-1


19 Click Apply.

21 Click Apply.
22 Click Save.
At this point you should receive a message that states that the process was a success.
24 Login and type CPconfig.

The following questions appears:
group]:
82



84
CHAPTER 5
Upgrading a Standalone
VPN-1 Pro/Express
Deployment
In This Chapter
Pre-Upgrade Considerations page 86
Standalone VPN-1 Gateway Upgrade on a Windows Platform page 89
Standalone VPN-1 Gateway Upgrade on SecurePlatform R54, R55 and Later
Versions page 90
Standalone VPN-1 Gateway Upgrade on SecurePlatform NG FP2, FP3, FP3
Edition 2 page 91
Standalone VPN-1 Gateway Upgrade on a Solaris Platform page 92
Standalone VPN-1 Gateway Upgrade on an IPSO Platform page 93
Migrate your Current VPN-1 Gateway Configuration and Upgrade page 96
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.
85
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
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 87).
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 89).
• 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 96) 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.
In This Section
License Upgrade to NGX page 87

Upgrading Products on a SecurePlatform Operating System page 87
Reverting to your Previous Software Version page 87
Using the Pre-Upgrade Verification Tool page 87
86
License Upgrade to NGX


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.
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 52
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 87

Usage:

or
-i[-f FileName][-w]

-t Target version
-f Output in file
-w Web format file

NG
NG_FP1
NG_FP2
NG_FP3
NG_AI
The target version is: NGX R60
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.
88
Standalone VPN-1 Gateway Upgrade on a Windows

Platform
The following upgrade steps describe the upgrade process using the NGX R60 CD.
1 Access your NGX R60 CD
the Pre upgrade verification tool should be executed (refer to the “Using the
Pre-Upgrade Verification Tool” on page 87). 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.
5 Select Upgrade again, from the Upgrade Options screen.
6 When prompted, reboot your VPN-1 Pro Server.

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

R54, R55 and Later Versions
a CD ROM.
# patch add cd.

Upgrade image.
90
Standalone VPN-1 Gateway Upgrade on SecurePlatform

NG FP2, FP3, FP3 Edition 2
Upgrading pre R54 versions requires an upgrade of the patch command.
3 Upgrade the patch command by selectingthe following option:
• Update the patch command using a CD ROM drive:
# mount /mnt/cdrom
# patch add cd.

Upgrade image.

Standalone VPN-1 Gateway Upgrade on a Solaris Platform
Standalone VPN-1 Gateway Upgrade on a Solaris Platform

2 Run UnixInstallScript.
like to install.
92
Standalone VPN-1 Gateway Upgrade on an IPSO Platform

4 Click Apply.
take a long time.
5 Click Apply.
8 Click Test Boot.
set properly.

Standalone VPN-1 Gateway Upgrade on an IPSO Platform

• CPshared
• VPN-1/FW-1
• SmartCenter
• Floodgate (Qos)
• SmartView Monitor

18 Under Applications select Off for the following:

19 Click Apply.
20 Under Applications select Off for the following:

21 Click Apply.
22 Click Save. At this point you should receive a message that states that the process
was a success.
24 Login and type CPconfig. The following questions appears:

group]:
94


Migrate your Current VPN-1 Gateway Configuration and Upgrade
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 Insert the NGX R60 CD into the original VPN-1 gateway.
2 Choose Export in Upgrade Options.
If you chose to perform the Export procedure manually make sure you are using
the NGX R60 Export tool.
3 Select the destination path of the configuration (.tgz) file.
4 Wait while exporting database files.
5 Copy the exported.tgz file to the new VPN-1 gateway server.
6 Insert the NGX R60 CD into the new VPN-1 gateway.
7 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
96
CHAPTER 6
Upgrading ClusterXL
In This Chapter
License Upgrade to NGX page 97

Tools for Gateway Upgrades page 97
Planning a Cluster Upgrade page 99
Performing a Minimal Effort Upgrade on a ClusterXL Cluster page 101
Performing a Zero Down Time Upgrade on a ClusterXL Cluster page 101
Performing a Full Connectivity Upgrade on a ClusterXL Cluster page 104

Tools for Gateway Upgrades

1 SmartUpdate’s Upgrade All Packages Feature - This feature allows you to
upgrade all packages installed on a gateway. For IPSO and SecurePlatform, this
feature also allows you to upgrade your Operating System as a part of your upgrade.
2 SmartUpdate’s 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.
97
Tools for Gateway Upgrades
3 SmartUpdate’s Get Check Point Gateway Data - This tool updates

SmartUpdate with the current Check Point or OPSEC third party packages
installed on a specific gateway or for your entire enterprise.
98
Permanent Kernal Global Variables
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 104 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.
Permanent Kernal Global Variables

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

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.
Chapter 6 Upgrading ClusterXL 99

Planning a Cluster Upgrade
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.
100
Upgrading OPSEC Certified Third Party Clusters Products
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 IPSO’s IP clustering
and VRRP. For additional third party clustering solutions please consult your third
party solution’s 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.

Performing a Zero Down Time Upgrade on a ClusterXL Cluster
2 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
3 Attach the previously upgraded licenses to all cluster members (A, 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.
4 Upgrade cluster members B and C either:
• Using SmartUpdate
• In Place
When the upgrade of B and C is complete, reboot both of them.
5 Continue with the process according to one of the following scenarios:
• 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.
6 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 Policy Installation window, deselect the For Gateway Clusters,
install on all the members, if it fails do not install at allcheckbox located
under the Install on each selected Module independently radio button.
102
Supported Modes
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 A’s synchronization interface reports that its outbound status is down,
because it is no longer communicating with other cluster members.
8 When upgrading versions prior to NGX R60, execute fw ctl setsync off on
Cluster member A.
9 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).
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 Upgrade cluster member A by either:
• Using SmartUpdate
• In Place
12 Reboot cluster member A.
13 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.

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 IPSO’s IP clustering and
VRRP. Legacy High Availability is not supported in FCU. For other third party’s
support please refer to the third party’s 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.
104
Implementing a Full Connectivity Upgrade
2 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.
4 A cluster that performs static NAT using Firewall-1’s automatic proxy ARP feature
requires special considerations: cpstop the old Check Point Gateway right after
running cphastop. Running cphastop is part of the upgrade procedure listing in
“Performing a Zero Down Time Upgrade on a ClusterXL Cluster” on page 101.
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.
Upgrading a cluster with 2 members

Follow the steps outlined in “Performing a Zero Down Time Upgrade on a ClusterXL
Cluster” on page 101. Before you get to step 9 on page 103 (executing cphastop), run
this command on the upgraded member:
fw fcu <other member ip on sync network>(e.g. fw fcu 172.16.0.1).
then continue with step 9 on page 103.

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 101. Before you get to step
9 on page 103 (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 103 on the single OM.
or
2 First upgrade one member only, by following the steps outlined in “Performing a
Zero Down Time Upgrade on a ClusterXL Cluster” on page 101. Before you get
to step 9 on page 103 (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 103 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.
106
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 104 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.

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).
108
CHAPTER 7
Upgrading Provider-1
In This Chapter

Provider-1/SiteManager-1 Upgrade Tools page 113
Provider-1/SiteManager-1 License Upgrade page 122
Provider-1/SiteManager-1 Upgrade Practices page 152
Upgrading in a Multi MDS Environment page 163
Restoring your Original Environment page 166
Renaming Customers page 167
Changing MDS IP address and External Interface page 171
109
Introduction
Introduction
In This Section
Scope page 110

Before You Begin page 110
MDS Post Upgrade Procedures page 162
Supported Platforms page 111
Supported Versions for Upgrade page 111
Summary of Sections in this Chapter page 111
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
2 If difficulties in the upgrade process require that you restore your original
environment, follow the step in “Restoring your Original Environment” on page
166. Read the restoration instructions before you begin, as several actions need to
be taken before the upgrade in order to allow the restoration.
3 If you are upgrading a multi-MDS environment refer to “Upgrading in a Multi
MDS Environment” on page 163”.
110
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 (R55W) - You can directly upgrade to
NGX.
• 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 NG with Application Intelligence and VSX NG with AI Application
Intelligence R2 - You can directly upgrade to NGX
Summary of Sections in this Chapter
Introduction page 110 This Section

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

Introduction
Restoring your Original Special considerations for restoration. How to

Environment page 166 return to the original version in the middle of the
upgrade process.
Renaming Customers page 167 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.
Changing MDS IP address and Instructions for moving MDS installation from one
External Interface page 171 machine to a second machine with another IP
address and/or an external interface name.
112
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 page 113

Installation Script page 114
pv1_license_upgrade page 115
license_upgrade page 116
cma_migrate page 117
migrate_assist page 119
migrate_global_policies page 119
Backup and Restore page 120
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

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 SmartCenter’s 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 Unzip the MDS package: gunzip <package_name>.tgz
2 Untar tar xvf <package_name>.tar
3 A new directory with the same name of the tar file has been created.
Change to it: cd <package_name>.
4 Run the installation script: ./mds_setup.
When mds_setup is executed, it first checks for an existing installation of MDS:
• If no such installation exists, mds_setup asks you to confirm a fresh
installation of MDS.
• If a previous version of MDS is detected, you are prompted to select one of
the following options (Pre-Upgrade Verification Only, Upgrade or Backup)
listed below.
5 Exit all shell sessions. Open a new shell in order for the new environment to be set.
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.
114
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
Prior to upgrading backup your MDS. This option from mds_setup, will run
mds_backup (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 171.
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/

• 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
Wizard Mode Command line Meaning

Option option
[S] license_upgrade Sends existing licenses to User Center Web
simulate 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.
[U] license_upgrade Sends existing licenses to the User Center
upgrade Web site to perform upgrade and (by default,
in online mode) installs them on the machine.
[C] license_upgrade Reports whether or not there are licenses on
status the machine that need to be upgraded.
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.
116
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 111.
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
directory contents
conf This directory contains the information that resides
under $FWDIR/conf of the source management.
database This directory contains the information that resides
under $FWDIR/database of the source
management.
log 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.
conf.cpdir 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.

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 Right click a CMA
2 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 the SmartCenter Server that was migrated using
cma_migrate should not re-generate certificates to gateways and SIC should continue
to work with gateways from version NG and later. However, if the IP of the CMA is
different from that of the original management, then putkey should be redone between
the CMA and entities that connect to it using putkey information. 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 mdsstop_customer <CMA NAME>
2 mdsenv <CMA NAME>
3 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.
4 Create new Internal Certificate Authority by executing:
mdsconfig -ca <CMA NAME> <CMA IP>
5 Run the command: mdsstart_customer <CMA NAME>
118
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 117), 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.

migrate_global_policies 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.
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.
120
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 machine’s IP address or interface has changed,
refer to “Changing MDS IP address and External Interface” on page 171” 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 you’ll
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

Provider-1/SiteManager-1 License Upgrade

In This Section
Overview of NGX License Upgrade page 123

Introduction to License Upgrade in Provider-1 Environments page 124
Software Subscription Requirements page 124
Understanding Provider-1/SiteManager-1 Licenses page 124
Before License Upgrade page 126
Choosing The Right License Upgrade Procedure page 131
License upgrade of Entire System Before Software Upgrade page 133
License Upgrade of Entire System Using Wrapper page 136
License upgrade of Entire System After Software Upgrade page 137
License Upgrade for a Single CMA page 140
License Upgrade Using the User Center page 146
SmartUpdate Considerations for License upgrade page 146
Troubleshooting License Upgrade page 147
122

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 CMA, you can also view
the licenses in the SmartUpdate license repository.
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 19.
• “License Upgrade for a ROBO Gateway” on page 174.
For the latest information and downloads regarding NGX license upgrade, check

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

Before License Upgrade

There are a number of steps you should perform before performing the license upgrade.
1 “Find out whether license upgrade is required” on page 126
2 “Simulate the License Upgrade” on page 126
3 “Provider-1 Pro Add-Ons for MDS License Upgrade” on page 127
4 “Managing VPN-1 VSX With Provider-1” on page 128
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.
126
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 Part Number
10 NG CPPR-PRO-10-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.
2 Install each generated license on its respective CMA.
3 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.
To upgrade the CMA Pro Add-on licenses
1 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.
3 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
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.
128
TABLE 7-5 Provider-1 MDS Container

Provider-1 MDS Container
25 NG CPPR-MDS-C25-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)
1 NG CPPR-CMA-1-NG
2 NG CPPR-CMA-2-NG
4 NG 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.
To upgrade the Provider-1 CMA-Bundle licenses

proxy machine.


• Log Files generated by the tool. The location of these files is printed to the
screen when running the tool.
information.
130
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.

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 133
• “When MDS is Online” on page 133
• “When MDS is Offline” on page 134
• “License Upgrade of Entire System Using Wrapper” on page 136
(applies to an online MDS version NG)
• “License upgrade of Entire System After Software Upgrade” on page 137
• “When MDS is Online” on page 137
• “When MDS is Offline” on page 138
• “License Upgrade for a Single CMA” on page 140
• “When MDS is Online, Before Software Upgrade” on page 140
• “When MDS is Offline, Before Software Upgrade” on page 141
• “When MDS is Online, After Software Upgrade” on page 143
• “When MDS is Offline, After Software Upgrade” on page 144
132
License upgrade of Entire System Before Software Upgrade
In This Section
When MDS is Online page 133

When MDS is Offline page 134
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.
1 Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy

them from the locations specified in “pv1_license_upgrade” on page 115.
2 Run the following command line tool at the MDS (On SecurePlatform, you must
be in expert mode):
proxy machine.
• Collects all the licenses that exist on the MDS machine.
• Verifies that all licenses can be upgraded, both for MDS and CMAs.
• Builds a temporary cache file containing the NGX licenses.
3 Perform the software upgrade to NGX on the MDS Manager, MDS Container, and
the MDG.
4 Start the MDS by running
mdsenv
mdsstart

5 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.
7 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.
1 Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy

them from the locations specified in “pv1_license_upgrade” on page 115.
2 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.
4 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
5 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:
134
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 Copy the cache file (with the new licenses) back to the offline MDS machine.
mdsenv
mdsstart
8 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.
the MDG.
10 Run following command line on the upgraded offline MDS:
This imports the new licenses into the CMA license repositories on the MDS.

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 At the MDS, run mds_setup and choose the Upgrade option.
2 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 The mds_setup wrapper then proceeds with the software upgrade.
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.
136
License upgrade of Entire System After Software Upgrade
In This Section
When MDS is Online page 137

When MDS is Offline page 138
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.
the MDG.
2 Run the following command line tool at the MDS (On SecurePlatform, you must
be in expert mode):
proxy machine.
• Collects all the licenses that exist on the MDS machine.
• Verifies that all licenses can be upgraded, both for MDS and CMAs.
• Builds a temporary cache file containing the NGX licenses.
• Installs upgraded licenses for the MDS and CMAs.
mdsenv
mdsstart

pv1_license_upgrade import -C <cache file>


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.
the MDG.
2 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.
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] 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.
138
7 Start the MDS services by running

mdsenv
mdsstart
8 Run the following command line on the offline MDS:

This imports the new local machine licenses to the MDS and the CMAs.
9 Restart the MDS services by running
mdsenv
mdsstart
10 Rerun the following command line on the offline MDS:

This imports the new licenses into the CMA license repositories on the MDS.

License Upgrade for a Single CMA
In This Section
When MDS is Online, Before Software Upgrade page 140

When MDS is Offline, Before Software Upgrade page 141
When MDS is Online, After Software Upgrade page 143
When MDS is Offline, After Software Upgrade page 144
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.
1 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 115 and “license_upgrade” on page 116.
2 At the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>
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:
140
license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

proxy machine.
OR:
Use the [U] Wizard mode option.
• Collects all the licenses that exist on the CMA.
• Installs an upgraded license for the CMA, and saves upgraded CMA Repository
licenses on the CMA.
4 Upgrade the software on the MDS.
mdsstart
6 Import new licenses of all CMAs into the NGX CMA Repositories.
pv1_license_upgrade import -C <cache file>
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 Copy the license_upgrade tool to the MDS version NG machine from the
locations specified in “license_upgrade” on page 116.
mdsenv <cma_name>

3 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.
5 Copy the license_upgrade tool to the online machine.
<cache_file>
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 Copy the cache file (with the new CMA licenses) to the offline target machine.
8 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
142
11 Import new licenses of all CMAs into the NGX CMA Repositories. Run the
command
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

mdsenv <cma_name>
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:
license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>
proxy machine.
OR use the [U] wizard mode option.
• Collects all the licenses that exist on the CMA.
• Install new licenses on the CMA.

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:
mdsenv <cma_name>
2 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>
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.
<cache_file>
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.
144
7 Run following command on the MDS machine:

mdsenv <cma_name>
8 EITHER run following command line on the offline target machine

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

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 page 147

Managing VPN-1 VSX With Provider-1 page 149
Provider-1 Pro Add-Ons for MDS License Upgrade

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
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
The way to generate the CMA Pro Add-on licenses in the User Center is 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.
Only this last license is upgraded by the license upgrade process.
Resolution

proxy machine.
information.
148
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
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)
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

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)
1 NG CPPR-CMA-1-NG
2 NG CPPR-CMA-2-NG
4 NG 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.
Only this last license is upgraded by the license upgrade process.
Resolution

proxy machine.
150

information.

Provider-1/SiteManager-1 Upgrade Practices

In This Section
In-place Upgrade page 152

Replicate and Upgrade page 154
Gradual Upgrade to Another Machine page 155
Migrating from a Standalone Installation to CMA page 158
MDS Post Upgrade Procedures page 162
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.
1 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 163).
2 Make the changes required by the pre-upgrade verification, and if you have High
Availability, do the required synchronizations.
3 Test your changes:
A assign global policy
B install policy
C verify logging (through SmartView Tracker)
D view status (through MDG or SmartView Monitor)
4 Backup your system either by selecting the backup options from mds_setup or by
running mds_backup.
152
In-place Upgrade
5 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 133. Follow the procedure for an online MDS or an offline
MDS, as applicable.
6 Perform the in-place upgrade using mds_setup (see “Installation Script” on
page 114).
7 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 133. Follow the procedure for an online MDS or an offline MDS, as
applicable.
8 After the upgrade completes, retest using the sub-steps in step 3 above.
Upgrading to NGX R60 on SecurePlatform

a CD ROM drive.
# patch add cd.

Upgrade image.

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 117). 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.
2 Create an additional folder for the global policy data.
3 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
4 Perform a fresh RedHat Enterprise Linux 3.0 installation.

5 Perform a fresh installation of NGX MDS on the target machine.
Refer to “Installation Script” on page 114 for detailed instructions.
6 Create customers and CMAs with the names used in the previous Provider-1 setup.
Do not start the CMAs.
7 Use migrate_global_policies to import the backed up global policies listed in
step 3 (refer to“migrate_global_policies” on page 119 for additional information).
8 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 117) 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.
154
Gradual Upgrade to Another Machine
2 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.
3 Restore the MDS on the target machine. Copy the file created by the backup
process to the target machine and run mds_restore, or run mds_setup and select
the Restore option.
4 If your target machine and the source machine have different IP addresses, follow
the steps listed in “IP Address Change” on page 171” 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 172 to adjust the restored MDS to the new interface name.
5 Test to confirm that the replication has been successful:
a) Start the MDS.
b) Verify that all CMAs are running and that you can connect to the MDS with
MDG and Global SmartDashboard.
c) Connect to CMAs using SmartDashboard.
6 Upgrade your MDS. Stop the MDS on the target machine and employ an In-Place
Upgrade (see “In-place Upgrade” on page 152 for further information).

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 Provider-1/SiteManager-1 Administrators
To do: Redefine and reassign to customers after the upgrade.
2 Provider-1/SiteManager-1 SmartConsole Clients

To do: Redefine and reassign to customers after the upgrade.
3 Policy assignment to customers

To do: Assign policies to customers after the upgrade,

4 Global Communities statuses.

To do: execute the command:
mdsenv; fwm mds rebuild_global_communities_status all
Upgrade steps
1 Install MDS of the target version onto the target machine.
2 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 133. Follow the procedure for an online MDS or an offline
MDS, as applicable.
3 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 On the target MDS, create a customer and CMA but do not start the CMA.
5 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 119. This process transfers the NGX licenses for both
the CMA and the CMA Repository.
6 Start the CMA. Run the commands
mdsenv
mdsstart
7 Import licenses that were upgraded to the CMA database from the cache file copied
from the NG version MDS. Run:
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 143, or “When MDS is Offline, After Software Upgrade” on
page 144.
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:
156
1 Global VPN community setup involves the Global database and the CMAs that are
managing gateways participating in the global communities. When gradually
upgrading a GVC environment split the upgrade into two parts:
• one for all the CMAs that do not participates in the GVC and
• one for CMAs that do.
2 If some of your CMAs have already been migrated and some have not and you
would like to use the Global Policy, make sure that it does not contain gateways of
non-existing customers. To test 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 where used query from the Global SmartDashboard > Manage >
Network Objects > Actions 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.
B The gateways must be disabled from global use:
i From the MDG’s 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>
3 When issuing the command: migrate_global_policies where the existing Global

Policy contains Global Communities, the resulting Global Policy contains:
• the globally used gateways from the existing database and
• the globally used gateways from the migrated database.
As a result of the migration, the Global Communities are overridden by the
migrated database.
4 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

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 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.
2 Uninstalling the SGW and reinstalling a module on Machine A.
3 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.
158
From NG (All Feature Pack) Installation

TABLE 7-11 Migrating from Stand Alone to CMA from NG forward
machine steps
Prepare SGW for Export
Machine A 1 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.
2 Add an object representing the CMA (name and IP
address) and define it as a Secondary SmartCenter
Server.
3 Install policy on all managed gateways.
4 Delete all objects or access rules created in steps 1
and 2.
5 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.
6 Save and close SmartDashboard. Do not install
policy.

TABLE 7-11 Migrating from Stand Alone to CMA from NG forward (Continued)
machine steps
Export the management database from Machine A and import it to CMA
on the MDS on Machine B
Machine B 1 Run the migrate_assist <SGW_NAME>
(cont...) <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 Create a new CMA on the MDS but do not start it.

3 Migrate the exported database into CMA from the
target directory of migrate_assist
(<target_dir>).
Configure CMA. Start managing all modules from CMA, except moduleA
Machine B 1 Start the CMA and on the CMA, launch
SmartDashboard. In SmartDashboard under Network
Objects find:
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).
160
TABLE 7-11 Migrating from Stand Alone to CMA from NG forward (Continued)
machine steps
3 Create an Object representing moduleA (From New
> Check Point > Gateway):
A Assign a Name 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).
5 Install Policy on all modules, except for moduleA.
You may get warning messages about moduleA
because it is not yet configured. Ignore these.
Reinstall module on Machine A and prepare for SIC with the CMA
Machine A 1 Uninstall the SGW.
2 Install the module.
Start managing moduleA from CMA
Machine B 1 Re-establish trust with moduleA.
2 Define moduleA’s topology in the CMA
SmartDashboard.
3 Install the Policy on moduleA.

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 Open a root command line on the MDS (either on a console or via ssh).
2 Set the MDS environment and stop all services by typing mdsenv;mdsstop.
3 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 Use the vi text editor to manually edit the objects_5_0.C file in the $MDSDIR/
conf/mdsdb/ directory.
5 Find the line statement :use_sites. For example:

/:use_sites
6 Edit the value and change it from true to false. For example:
:use_sites (false)
7 Save the file and exit.

8 Start the MDS services by running mdsenv;mdsstart.
162
Pre-Upgrade Verification and Tools
Upgrading in a Multi MDS Environment

In This Section
Pre-Upgrade Verification and Tools page 163

Upgrading an NG with Application Intelligence Multi-MDS System page 163
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 113).
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 page 163

Before the Upgrade page 164
After the Upgrade page 164
CMA High Availability page 165
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.

Upgrading in a Multi MDS Environment
2 Upgrade all container MDSes. Each container MDS that you upgrade is managed
from the already upgraded manager MDS.
3 Upgrade your second manager MDS.
Following these steps promises continuous manageability of your container MDS.
While containers do not accept 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 Perform pre-upgrade verification for all MDSes.
2 Perform license upgrade for all MDSes. Refer to “License upgrade of Entire System
Before Software Upgrade” on page 133, 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
3 If the pre-upgrade verifier requires a modification to the global database, then after
modifying the global database, all other MDSes should be synchronized.
4 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.
5 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 133, 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.
164
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 all CLM/CMA objects, run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
To update CLM/CMA objects that are located on a specific MLM/MDS, (in case other
MDSs were not upgraded yet), run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <MLM/MDS name>
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 117) where the imported database is the primary
CMA/SmartCenter Server, after verifying that it is synchronized.

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

In This Section
Before the Upgrade page 166

Restoring your Original Environment page 167
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.
166

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 page 167

High-Availability Environment page 168
Automatic Division of Non-compliant Names page 168
Resolving the Non-compliance page 168
Advanced Usage page 169
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.

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

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
Line Prefix Meaning Comment

# A comment line. May be inserted anywhere.
- Existing non-compliant Must exactly match an
name. existing non-compliant
name, otherwise it will be
rejected.
+ A translation for the If the entry does not
preceding '-' line. comply with the naming
restrictions, it is ignored.
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.
2 Ignore the translations file and generate a new one - Choose this option if
you want to overwrite the contents of the file.
3 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.
170
IP Address Change
Changing MDS IP address and External Interface

In This Section
IP Address Change page 171

Interface Change page 172
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 The MDS must be stopped. Stop the MDS by running mdsstop.
2 Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address.
3 Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the MDS object that has the
source MDS IP address and change its IP address to the new IP address. Do not
change the name of the MDS.
4 Due to the change of IP address install a new license on the target MDS with the
new MDS IP address.
5 For multiple MDS/MLM environments repeat steps 1 to 4 for the MDS/MLM for
which you changed the IP, on each MDS/MLM.

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 Change the interface name in file $MDSDIR/conf/external.if to the new interface
name.
2 For each CMA replace the interface name in $FWDIR/conf/vip_index.conf . 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 .
172
CHAPTER 8
Upgrading SmartLSM
ROBO Gateways
In This Chapter
Planning the ROBO Gateway Upgrade page 173

Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository page 174
Upgrading a ROBO Gateway Using SmartLSM page 175
Using the Command Line Interface page 179
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.
2 Add the upgrade package to the SmartUpdate package repository
(see “Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository” on
page 174).
3 Upgrade ROBO Gateway licenses from version NG to NGX. See “License
Upgrade for a ROBO Gateway” on page 174.
173
Adding a ROBO Gateway Upgrade Package to SmartUpdate Repository
4 Upgrade your ROBO Gateways in one of the following ways:

• using SmartLSM
(see “Upgrading a ROBO Gateway Using SmartLSM” on page 175) or
• using the SmartLSM Command Line Interface
(see “Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli” on
page 180).
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 19. Upgrading SmartCenter licenses also upgrades all ROBO
Gateway licenses.
2 Upgrade the software on the ROBO Gateway, as described in “Upgrading a
ROBO Gateway Using SmartLSM” on page 175.
3 Use SmartLSM to Attach the upgraded licenses to each ROBO Gateway, one
ROBO at a time, as follows:
Using SmartLSM to Attach the Upgraded Licenses

4 At the SmartConsole GUI client machine, open SmartLSM.
5 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.
174
License Upgrade on Multiple ROBO Gateways
6 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.
7 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.
8 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 183 for details.
Upgrading a ROBO Gateway Using SmartLSM

In This Section
Upgrading a VPN-1 Express/Pro ROBO Gateway page 175

Full Upgrade page 176
Specific Installation page 176
Upgrading a VPN-1 Edge ROBO Gateway page 177
Upgrading a VPN-1 Express/Pro ROBO Gateway In Place page 178
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 175

• The Specific Install method can be used when you want to install a specific
product on a ROBO Gateway.
Full Upgrade
1 From SmartLSM, select the line representing the VPN-1 Express/Pro ROBO
Gateway that you want to upgrade.
2 Select Actions > Packages > Upgrade All Packages. This selection can also be done
through the right-click menu, or the Upgrade All Packages icon in the toolbar.
3 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.
4 Select the Change to a new Profile after upgrade checkbox, and select the
appropriate new SmartLSM Profile from the list.
5 Check the Allow reboot if required checkbox.
6 Click the Continue button.
7 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 In SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway
you want to upgrade.
2 Select Actions > Packages > Get Gateway Data to fetch information about Packages
currently installed on the VPN-1 Express/Pro ROBO Gateway.
3 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.
4 In the Distribute Package window select the package you want to install.
You can then select one of the following actions:
• Distribute and install packages
176
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 Allow Reboot if
required checkbox.
6 If the operating system is SecurePlatform, you can select Backup image for
automatic revert, if the installation does not succeed.
7 The option Change to a new profile after install lets you select the SmartLSM
Profile that will be assigned to the Package upon installation. When upgrading the
VPN-1 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.
8 Click the Start button.
9 The Install process begins. Its stages and completion status can be seen in the Action
Status pane, at the bottom of SmartLSM. The whole progress report can be seen at
any time by viewing the Action History (right click on the respective line in the
Action Status pane, and select Action History).
Note - You can 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.
2 Select the Firmware tab.

3 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.
2 From the Version menu select the new version of the upgraded gateway.
3 From the Profile menu select a new SmartLSM Profile for the upgraded gateway.
4 Click OK to close the dialog.
5 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.
178
SmartLSM Upgrade Tools
Using the Command Line Interface

In This Section
SmartLSM Upgrade Tools page 179

Upgrading a VPN-1 Express/Pro ROBO Gateway Using LSMcli page 180
Upgrading a VPN-1 Edge ROBO Gateway Using LSMcli page 181
Using the LSMcli in Scripts page 182
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
argument meaning...
-d (Optional) Run the command with debug output.
Server The IP or hostname of the SmartCenter Server.
User The username and password of a SmartCenter Administrator.
Password
ROBO The name of the ROBO Gateway to be upgraded.
-F Firmware The firmware version of the VPN-1 Edge ROBO Gateway.

TABLE 8-1 LSMcli Command line arguments for upgrades(Continued)
argument meaning...
-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.
-DoNotDistribute (Optional) Install previously distributed packages.
Product To see the list of all packages available in the repository, use the
Vendor ShowRepository LSMcli command.
Version
SP (The usage of this command is described in the SmartLSM
User’s Guide).
Export
The export tool is located in your SmartLSM application, File > Export to File. Use
this tool to export a ROBO Gateway’s properties into a text file that you can turn into
a script in order to perform batch upgrades.
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 179.
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>
180
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 administrator’s name.
mypassword = the administrator’s 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 179.
To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository

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
182
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 175
in SmartLSM.
The command is:
LSMcli [-d] <Server> <User> <Password> AttachAssignedLicenses VPN1
<ROBO>
For example:
LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO17

184
CHAPTER 9
Upgrading VSX
SmartCenter
Management
In This Chapter
Before You begin page 185

Supported VSX Upgrade Paths page 188
Supported VSX Upgrade Procedures page 190
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.
The VSX management component can be upgraded to NGX R60 SmartCenter Server,
which can manage and enforce policies on VSX NG AI and VSX NG AI Release 2
enforcement modules.
185
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.
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

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

-t Target version
-f Output in file
-w Web format file

VSX_NG_AI
VSX_NG_AI_R2
The target version is: NGX R60
186
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

• 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.
Information Messages
Items that should be noted.
Chapter 9 Upgrading VSX SmartCenter Management 187

Supported VSX Upgrade Paths
Supported VSX Upgrade Paths

In This Section
Upgrading VSX NG AI to NGX R60 SmartCenter page 188

Upgrading VSX NG AI R2 to NGX R60 SmartCenter page 189
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 Yes

SecurePlatform Solaris Yes
SecurePlatform Windows Yes
SecurePlatform IPSO Yes
Solaris SecurePlatform
Solaris Solaris
Solaris Windows
Solaris IPSO
188
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 Yes

SecurePlatform Solaris Yes
SecurePlatform Windows Yes
SecurePlatform IPSO Yes
Solaris SecurePlatform
Solaris Solaris
Solaris Windows
Solaris IPSO

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 Download NGX R60 upgrade_export.
2 Login as admin.
3 Switch to expert mode.
4 Insert the NGX R60 CD into the system CD drive.
Mount the drive if necessary.
5 Copy upgrade_export from the NGX R60 CD to your machine using the
following command:
cp upgrade_export $FWDIR/bin/upgrade_tools/
6 Access the upgrade tools folder in the following location using the following
command:
cd $FWDIR/bin/upgrade_tools
7 Copy gtar and gzip from /bin to current the folder using the following commands:
cp /bin/gtar .
cp /bin/gzip .
8 Close all open GUI clients.

9 Run the upgrade export utility (see “Export Usage” on page 191) using the
following command:
./upgrade_export <filename>
10 Transfer the file (<file name>) to a remote location for future use.
190
Export and Import Commands
Export from Solaris

1 Login as admin.
2 Insert the NGX R60 CD into the system CD drive.
Mount the drive if necessary.
3 Copy upgrade_export from the NGX R60 CD to you machine using the
following command:
cp upgrade_export $FWDIR/bin/upgrade_tools/
4 Access the upgrade tools folder in the following location using the following
command:
cd $FWDIR/bin/upgrade_tools
5 Run the upgrade export utility (see “Export Usage” on page 191) using the
following command:
./upgrade_export <filename>
6 Transfer the file (<file name>) to a remote location for future import usage.
Import from SecurePlatform or Solaris

1 Copy the exported file from SecurePlatform or Solaris into the Spare machine.
2 Run the Import tool. (see “Import Usage” on page 192)
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> - the path to export the configuration file (default-local path)
-d - prints debug information
-h - prints this usage
-v - prints the version

Import Usage
upgrade_import [-d] [-h] <path>
Where:
<path> - The location of the exported file
-v - Prints the version
-d - Prints debug information
-h - Prints this usage
192
Index
A G mds_setup 167
migrate_assist 119
migrate_global_policies 119
Administrators 155 Global Communities 157 Migrating 158
Authentication properties 187 Global Policy 157 migration process 58
Global VPN Communities 156 Minimal Effort Upgrade 71, 99
MLM 164
Multi-MDS environments 163
B MVS 16
H
backup 47
Backup and Restore 120
backups of system settings 47
High Availability 60, 152, 163
High-Availability 169 N
backward compatibility 14
Nokia clustering 101
Nokia OS 72
I
C
Check Point Gateway 15
Import and Export tools 191
In Place Upgrade 16 O
CLM 115, 164 Internal Certificate Authority 118
Clustered deployment 71 IPSO Platform 65, 81, 93 Operation Status 74
ClusterXL 16, 99 OPSEC 72, 73, 98
CMA 115, 118, 120, 154, 155, 160,
164, 172
cma_migrate 117 L
cprid 74
CRL 118
P
License Repository 21
License Upgrade 21 Package Repository 15, 176
License_upgrade 22 patch command 63, 78, 91
E Licensing
Web Intelligence 56
Performance Pack 72
Plug & Play 174
Local Upgrade 71 PolicyServer 72
Enforcement Module 15, 55, 58 LSM 16 Pre-upgrade utilities 166
Enforcement Modules 75 LSMcli commands 179 Pre-Upgrade verification 58, 86
errors 88, 187 Pre-upgrade verification 59
Evaluation licenses 38 pre-upgrade verification 61, 76, 87,
Eventia Reporter 72 89, 114, 163, 164, 186
Expert mode 63, 77
expert mode 190
M Pre-Upgrade Verifier 114
Products 57
Provider-1/SiteManager-1
MD5 checksum 63, 78 upgrade 110
MDS 114, 115, 120, 121, 155, 160,
F 171
MDS environment 162
FQDN 118
MDS High Availability 168
MDS services 162 Q
FTP access 159 mds_backup 121
mds_remove 167 QoS 72
193
R
R V
release notes link 12 Virtual Routers 16
remote upgrade 174 Virtual System 16
restore 47 VPN distributed deployment 55
ROBO Gateway 173, 175, 177 VPN-1 distributed deployment 85
ROBO Gateways 16 VPN-1 Edge Firmware package 174
ROBO Profile 16 VPN-1 Pro Enforcement
Modules 72
VPN-1 Pro Server 89
VSX Clustering 16
S VSX Gateway 16, 185
Safe Upgrade 62, 63, 77, 78, 90, 91,

153
SCP 47 W
SecureClient 41
SecurePlatform 28, 30, 33, 34, 57, warning 88, 187
62, 63, 72, 77, 87, 90, 133, 134, Web Intelligence
137, 138, 142, 144, 191 Licensing 56
Security Policy 15 What’s New link 12
SmartCenter Server 15 Wrapper 21
SmartConsole Clients 15, 155
SmartDashboard 15
SmartLSM 173
SmartUpdate 15, 27, 73, 97, 102,
146
Z
SmartUpdate Upgrade 71
SmartView Monitor 72 Zero Downtime 71, 99
Software Upgrade 21
Solaris 191
Solaris Platform 64, 92
Spare machine 191
Standalone deployment 86
SYNDefender properties 187
T
TFTP 47, 49
The Full Upgrade method 175
The Specific Install method 176
Translation prompt 168
U
Uninstalling 158
upgrade_export 190
UserAuthority 72
UserAuthority Server 72
194

CheckPoint NGX Upgrade Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CheckPoint NGX Upgrade Guide

Uploaded by

Copyright:

Available Formats

The Upgrade Guide

Part Number 701313

Check Point Software Technologies Ltd.

Chapter 1 Introduction to the Upgrade Process

Chapter 2 Upgrading VPN-1 Pro/Express Licenses

Chapter 3 Backup and Revert for VPN-1 Pro/Express

Chapter 4 Upgrading a Distributed VPN-1 Pro/Express Deployment

Chapter 5 Upgrading a Standalone VPN-1 Pro/Express Deployment

Chapter 7 Upgrading Provider-1

Chapter 8 Upgrading SmartLSM ROBO Gateways

Chapter 9 Upgrading VSX SmartCenter Management

Upgrading Successfully page 11

Chapter 1 Introduction to the Upgrade Process 13

Supported Upgrade Paths and Interoperability

Chapter 1 Introduction to the Upgrade Process 15

Advanced Upgrade - In order to avoid unnecessary risks, it is possible to migrate the

Chapter 1 Introduction to the Upgrade Process 17

Overview of NGX License Upgrade page 20

Overview of NGX License Upgrade

Introduction to License Upgrade in VPN-1 Express/Pro

Software Subscription Requirements

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 21

The License_Upgrade Tool

The options are:

Simulating the License Upgrade

1 Copy the license_upgrade tool from <Specific_platform>\ on the NGX

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 23

Performing the License Upgrade

License Upgrade Methods page 25

License Upgrade Methods

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 25

License License Upgrade for License that are upgraded

Deployments with Licenses Managed Centrally Using

“Introduction to Using SmartUpdate” on page 27

Introduction to Using SmartUpdate

Note - SmartUpdate license management capabilities are free of charge.

1. License Upgrade for an Online SmartCenter

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 27

1 At the SmartConsole GUI machine, open SmartUpdate, connect to the

5 Choose the [U] option. This does the following:

8 Perform the software upgrade to NGX on the enforcement module machine(s).

License Statuses in SmartUpdate

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 29

2. License Upgrade for an Offline SmartCenter

1 At the SmartConsole GUI machine, open SmartUpdate and connect to the

14 Perform the software upgrade to NGX on the enforcement module machine(s).

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 31

License Statuses in SmartUpdate

Deployments with Licenses Managed Locally

“3. License Upgrade for an Online Machine” on page 33

3. License Upgrade for an Online Machine

1 Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD,

4 Choose the [U] option. This does the following:

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 33

5 Perform the software upgrade to NGX.

4. License Upgrade for an Offline Machine

1 Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD,

7 Run the license_upgrade tool at the online machine:

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 35

Troubleshooting License Upgrade

Error: “License version might be not compatible” page 37

Error: “License version might be not compatible”

Chapter 2 Upgrading VPN-1 Pro/Express Licenses 37