Firewall administrators commonly have questions about upgrading to NG, such as: What versions can I upgrade from? What version should I upgrade to? Should I upgrade or rebuild? When will I have to upgrade? There are no absolute answers for every configuration. A great deal of confusion over whether or not to try and upgrade Check Point 2000 (4.x) to NG originated with NG FP0, the initial release.The initial release did not consistently upgrade to the new version cleanly, leaving a bad initial reaction to NG on the part of users.
Check Point has implemented quite a few new features in FP3, as you will see throughout this text. There are many improvements in documentation, features, flexibility, and performance.The fear over newsgroup postings or other information sources available on the Internet discussing issues with NG and the upgrade process is unfounded. Shortly, we’ll discuss the steps in the upgrade process, but there is one dominant reason Check Point administrators must consider upgrading their infrastructures: The end of life for version 4.x is scheduled to occur on June 30, 2003.
There are three paths to take for the upgrade process: upgrade your existing management server, build another server to be used for the upgrade process, or use this opportunity to rebuild from scratch.The amount of work involved increases with each of these choices. The significant advantage for the parallel server choice is the ability to roll back if you do encounter a problem.The third choice could involve a significant investment of time and will test your meticulous nature.The new rebuild option is discussed at the end of this topic. Ultimately, the choice is yours to make. Considering that your management server is the most important component of your firewall architecture, you might want to avoid a potential career-limiting move and choose the second or third options.
The quickest and easiest method to upgrade is to use a Check Point CD and select the Upgrade option directly on your live management server. This is by far the riskiest method of upgrading, because there is no quick and easy method to back out of the process.Tools are available to mitigate some of the risk in using this option.There is a Pre-Upgrade Verifier tool and a Post-Upgrade Verifier tool to assist in providing a clean upgrade. The Pre-Upgrade tool uses read-only access to analyze the database for potential issues that could interfere with a clean upgrade. It gives you an opportunity to address any necessary changes. If errors are encountered during the upgrade, the Post-Upgrade tool is designed to fix these problems or to verify the upgrade process. It is important to note that Check Point recommends that you make a backup copy of your $FWDIR\conf directory before running the Post-Upgrade tool.The reason for this is that this tool accesses the database with the ability to make changes.You can access the Pre-Upgrade an d Post-Upgrade Verifier tools by following this URL: www.checkpoint.com/techsupport/downloadsng/utilities.html (available with public access).
The most appealing option is to build a parallel system and take advantage of the upgrade utilities in a manual or automatic process.The automatic process involves making a copy of the existing management server’s contents and performing the upgrade directly from the CD.To assist in this process, you’ll find some Check Point Solutions invaluable for guidance.The first is the Check Point Knowledge Base Solution ID, sk11635: How to Upgrade from VPN-1/FireWall-1 4.1 to VPN-1/FireWall-1 NG FP1 and Above.This solution provides a step-by-step process for replicating an existing management server. Within this solution are two hyperlinks; click to get the Upgrade Verifier Utility that links to www.checkpoint.com/techsupport/ng/fp3_updates.html and the Upgrade Guide that links to https://support.checkpoint.com/public/idsearch.jsp?id=sk16625 (both available with public access). The first link is a one-stop page for FP3 documents, tools, and appli-cations.The Upgrade Guide link to Solution ID sk16625 is discussed in the next section.
The 4.x Upgrade Process
Let’s say that you have an existing 4.x installation and the time has come to upgrade to NG FP3.There is a specific order you must follow to upgrade: management server (SmartCenter Server), then graphical user interface (GUI) clients (SMART Clients), and then firewalls (enforcement points).The upgrade of the 4.1 management server to the FP3 SmartCenter Server is the most critical step, as mentioned earlier; SmartCenter Server is the new name for the management server. Once this component is upgraded, you need to upgrade the GUI clients.An NG management server can manage version 4.1 firewalls provided that you select backward compatibility during the installation.
Let’s now look at sk16625, The Ultimate Upgrade Guide: How to Upgrade a Management Server from 4.1 to NG. A hyperlink in this resolution, How to Upgrade the Management Server, links to http://support.checkpoint.com/kb/docs/public/firewall1/ng/pdf/upgrade_mgmt_srvr.pdf, a file that is indeed the ultimate upgrade guide for taking a 4.1 through NG FP2 management server to FP3.This date for this PDF file is February 2003. At the time this topic was written, this file had recently replaced a version from December 2002. This document contains detailed systematic processes to replicate your existing management server and then use automatic or manual methods to upgrade.
The main premise of this document is based on upgrading without changing the operating system, name, or IP address of the existing management station. If you are using the upgrade opportunity to migrate to a different platform, change the name or change the IP of the current management server.
When to Rebuild
You might be thinking that you would rather have a tooth pulled without Novocain than completely rebuild your management server. If your environment includes thousands of objects and dozens of rule bases, you could find an upgrade option more appealing.The main benefit of this option is to enjoy the luxury of starting with a clean slate.You can define common standards for naming and color designation. Eliminate the unused or unnecessary objects, services, and rules by not creating them. This option requires an additional server for rebuilding, so the option involves less risk. One last point to keep in mind is that naming conventions are not quite as important in NG as they are in 4.x. Using some type of naming convention such as h-hostname, net-x.x.x.x, or fw-fwname helped with using the network objects manager.This tool sorts the objects alphabetically, regardless of type, and using a naming convention means that similar types of objects are listed together. In SmartView Dashboard, the new name for the Policy Editor in FP3, the order that objects are displayed in the Objects list can be sorted by type, name, and even color. However, using a standard naming convention is still beneficial for providing a level of clarity and consistency.
The next reason that makes a rebuild the option of choice deals with Rule Base optimization.Two different Rule Base scenarios make this option more viable.The first is when you are dealing with a legacy of policy generation without maintenance. Firewall administrators often forgo deletion of old rule sets. Every single rule of every policy ever saved exists in the rulebases.fws file. When a large number of legacy Rule Bases are present, you can use the rebuild option to avoid carrying antiquated polices along for the upgrade.The other appropriate situation is when you are looking to improve performance with a more streamlined rule set; the fewer the number of rules that exist, the better the performance.You might want to recreate new policies using a more streamlined Rule Base.
The aforementioned reasons for rebuilding versus upgrading are noncritical. Eliminating unused objects and old Rule Bases helps shorten compilation and installation time.
There is a stateful relationship between the objects.C and rulebases.fws files. Performing a manual backup by copying off these configuration files requires synchronization of these files. For example, if a Rule Base contained objects that were created today and you copied a version of the objects.C from a week ago, the Rule Base would no longer be able to load. Another type of corruption occurs when a group object no longer matches traffic correctly against the objects it contains. This and other types of corruption may be related to drive or memory errors. This problem is not specific to 4.x but also occurs in NG. If you have corruption issues, it can be impossible to locate the source of the problem. In this scenario, a clean rebuild is a necessity.
Summary
This topic was designed to introduce you to Check Point Next Generation Feature Pack 3. In particular, we discussed the changes in Network Address Translation followed by the possible upgrade paths. Many enhancements are included for each FP release of the NG code. It is important to realize that the design modifications are engineered to improve the security of your VPN-1/FireWall-1 architecture. In doing so, the means by which the inspect engine makes decisions regarding packet flow have changed. Whether upgrading from the Check Point 2000 (4.1) version or within NG feature packs; a firewall administrator needs to understand the potential impact to his or her environment.
The configuration of NAT will always be one of your most important tasks. The changes in where this translation occurs on your gateway now depend on the default properties or your customization.These modifications are intended to remove complexity while providing additional flexibility.Your job is to implement these options successfully into your environment. Understanding how and why will give you the necessary tools to be successful.
An important element for packet flow with NAT is the ARP entry on the firewall. This entry is necessary for the router to forward packets to the firewall for translated addresses. Although there is an automatic option for the firewall in some configurations, it is important to know when this feature will not function. Equally important is to understand which MAC address is necessary for creating Manual ARP entries for special configurations. Ironically, you can avoid all the ARP issues by simply using static routes on the router to forward the packets to the firewall.
Upgrading the management server in your environment can be an intimidating process.The early issues of the initial NG release and the horror stories of failed upgrade attempts have made this task even more overwhelming. The functions of an NG management server are more numerous than a 4.1 management station.The underlying database structure is entirely different as well. Check Point provides utilities and documentation to guide you through the upgrade process.The recommended practice is to replicate the management server before performing the upgrade so that you have a rollback option. Additionally, you may chose the upgrade as an opportunity to rebuild the configuration from scratch. Knowing your options and selecting the best choice will depend on your specific goals and requirements.
Throughout the remainder of this text, we highlight additional changes and configuration options that will impact your Check Point solution. Although these changes are subtle in comparison with the major version changes from 4.x to NG, consider FP3 a substantial version upgrade. The topics that follow walk you through various options and changes.This guide is intended to inform you of how the environment changed and to make you comfortable with making the decisions that lie ahead of you.
