R77.80 to R80.40 Upgrade Smart 1-225s Questions

[Dwayne_White]

Hi All,

This is my first post so forgive me if I am in the wrong area.

I help support a small data center that has a small Check Point environment.  We have 2 Smart-1 225s configured as HA managers.  They managed two 12600 Secure Gateways that are configured as a VSX cluster.  The environment is on R77.30 Take 351 and we would like to upgrade it to R80.40.  My understanding is that the 12600s only support R80.40.  Yes, this upgrade is long overdue.  This will be an in place upgrade on the existing appliances.

I would like to approach the upgrade in two phases.  The first phase being to upgrade the managers to R80.40 and leave the VSX cluster/Gateways on R77.30.  I would like to run in this configuration for a period of time to ensure that the managers are stable.

The second phase would be to upgrade the VSX Cluster/Gateways at a later time.

I was looking over the R80.40 Installation and Upgrade Guide and have some questions I would like to bounce off the community for guidance and opinion.  The revision of the guide is dated January 2022.  Some of these questions may have straightforward answers, others may be more complex.

At any rate in no particular order.

The guide mentions additional steps and considerations for dedicated End Point Servers, Smart Event Servers, Dedicated Logs servers and so forth.  I am pretty confident I do not have any dedicated servers.  Is there any configuration I can check to be sure of this?

In addition to performing snapshots and backups on each Check Point appliance, should I also perform a migrate export?  I suspect I should and if so, do I only need to do this on the Active Smart-1 225 manager or from both managers?

On page 167 of the Upgrade and Installation Guide there is a recommendation of making an explicit firewall rule for Smart Console if that traffic goes through an R77 gateway.  I am pretty confident I do not need to do this since my workstation running Smart Console does not traverse a network path that goes through a VS or Gateway.  Just looking for more insight to this action from the Guide.

On page 168, the procedure for HA Manager environment states to upgrade the primary active manager and then doing a clean install on the secondary manager and the to connect the secondary manager to the primary manager.  This particular procedure really gives me concern.  Wouldn't I just use CPUSE to upgrade the primary manager first then do the same for the secondar standby manager?  I am especially interested in feedback to this question.

On page 176, there are mobile access prerequisites listed.  I am curious if these apply to the manager or gateways or both.  We do use the SSL extender in our environment with 2FA via SMS.  I confess I am not overly familiar with how this was set up, but I do know it involves using an SMSPhones file in the $CVPNDIR/conf directory on the VS in our VSX cluster that we use for VPN access into the data center.  I believe there was also some modifications made using the DB Editor as well to create linkage between Active Directory to the SMSPhones file.  I am curious if the SMSPhones file along with the DB changes that were made will be overwritten during the upgrade and what steps I should take to protect the configuration changes that were made to make our VPN 2FA functionality work.

On page 176 there is also mention of Mobile Endpoint Compliance Security updates.  Do these apply to me or how can I tell if this applies to me and what actions do I possibly need to take?

On page 191 there is mention of a Smart Correlation Blade? I do not think I have one of these but how do I verify to be sure?

When I ran the Pre Upgrade Verification Tool on the active manager, the report produced a warning regarding DHCP Legacy vs New handling and referenced sk104114 .  After doing some research it appears that DHCP is handled differently by default if the gateways are running R77 vs R80.  R77 uses Legacy handling and R80 uses New handling.  Thee aforementioned sk details how to configure gateways on R77 to use New DHCP handling.  I have identified a custom made Service Object in my Policy we made that includes legacy DHCP services.  The aforementioned sk is fairly complex and I am curious as to what I should or should not do for the time being if I continue to run the VSX cluster on R77 and the managers on R80.40.

After both managers are upgraded to R80.40, what steps beyond what is described in the guide should I take to confirm that I can push, and mange polices on the R77.30 VSX Cluster members?

Lastly, if things go poorly when upgrading the managers from R77.30 to R80.40 and I need to fall back on one or both managers, how do I do this?  Is reverting back to the snapshot I make prior to the upgrade all I need to do or is there more involved.  The Installation and Upgrade guide does not actually have a process for fallback even though it does mention making snapshots and backups.  Also, the sk articles that are referenced at least to me do not also give a clear fallback procedure.

I appreciate any feedback that anyone has on the questions.  Also, if there is any other advice or thoughts on performing this upgrade, I would appreciate it.

Thank you.

[PhoneBoy]

Easiest way to understand what components you have is to review all the Check Point objects defined in SmartConsole.
If there isn't an object for them listed there, it doesn't exist.
The blade configuration in each object will tell you what features and functionalities are enabled.

The upgrade guide mentions needing a rule for SmartConsole if your access to the manager is through one or more gateways.
You can ignore that if it doesn't apply. 

The DHCP handling actually changed in R77.20.
See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...,
While it is recommended to change over the DHCP rules to the new method, they can remain as-is for the time being.

If you had to touch any files on the gateway itself for configuration, most likely those changes will not come across and you'll need to apply them again.
If the changes were done via SmartDashboard and/or (gui)dbedit, those should be brought forward with an upgrade.

For upgrading the HA management, you will need to follow the procedure described (clean install the secondary).
This is due to the substantial number of changes "under the hood" in R8x, including in the HA processs.
You might also fresh install the primary (from ISO) as part of following the "advanced upgrade" procedure, which will allow you to leverage the faster XFS filesystem.

Any upgrade with CPUSE will take a snapshot beforehand.
You can simply revert to the relevant snapshot and push policy to the gateways to ensure logging resumes to the management if something goes wrong with the management upgrade.
If it's the gateways

[Dwayne_White]

Hi.

Thank you for taking the time to reply.

I definitely appreciate the insight on the Secondary SMS needing to be clean installed.  I will review the guide on how to perform the clean install on the secondary manager.

Also, I do subscribe to your email list and find it handy as far as upcoming events and articles of interest.

Thank you.

[G_W_Albrecht]

- look if in SMS object SmartEvent including correlation blade or EPM are enabled (Logs should be)

- Management HA is working that way: Upgrade the primary, fresh install secondary SMS and start Sync - that is a good start. This points to the sync issues that make Management HA only a second best solution compared to a SMS VM.

- concerning SSL VPN and DHCP Legacy: that should be addressed when upgrading GWs.

- fallback to old SMS: best if you have a snapshot from R77.30

[Dwayne_White]

Hi.

Thank you for your reply.

I will look at the SMS objects in dashboard as you suggested.  I am also glad to know that the VPN, SSL and DHCP are something to address when we perform the gateway upgrade.

Thank you.

[Tal_Paz-Fridman]

To answer two specific issues you raised:

On page 176 there is also mention of Mobile Endpoint Compliance Security updates - if you use Mobile Access you should upgrade the database after the upgrade to R80.40.

On page 191 there is mention of a SmartEvent Correlation Blade - This is enabled on the Check Point object that is running the Correlation Unit (with or without the Analyzer Server):

You can also run the following command on the machine you believe is a SmartEvent Correlation Unit:

cpstat cpsead

[Dwayne_White]

Hi.

Thank you for taking the time to reply.

I appreciate the instructions on where to look for the SmartEvent Correlation Unit.

Thank you.

[Bob_Zimmerman]

You should absolutely upgrade the managements first. Only the primary management matters. Just flatten the secondary and build it like a new secondary.

Long before the management upgrade window

On the primary management, take a backup and copy it off-box. Take a migrate export and copy it off-box. Build a VM at R77.30. Give it the same hostname as your primary management, and copy the migrate export to it. Confirm that you can import it via migrate import and that all of your stuff is still there.

Look into config_system. A valid config_system file can be bundled with an installation image via ISOmorphic such that the box just comes up with the first-time wizard completed. No web browser needed.

Next, install the R80.40 upgrade tools, as described in the upgrade guide, and generate a migrate server with them. Build a new VM at R80.40. Give it the same hostname as your primary management, copy the migrate server to it, and import. Check to be sure it imports successfully.

A day before the management upgrade window

Generate a fresh backup and R77.30 migrate export. Copy them off-box.

Build a thumb drive with ISOmorphic and the R80.40 ISO image. You can include the latest CPUSE, but do not try to include a jumbo. ISOmorphic has a longstanding issue where it will let you create a thumb drive with R80.40 and a jumbo, but when you try to install, the installation runs out of drive space and fails with a really unhelpful error. I can't believe this still isn't fixed (ISOmorphic could at least refuse to let you include more than 200 MB or whatever of hotfixes), but it isn't. If you're using a config_system file, this is the time to include it on the drive.

The management upgrade window

Generate a new migrate server using the R80.40 tools and copy it off-box. Flatten the box with the thumb drive you made with ISOmorphic. Go through the first-time wizard, or let it run the config_system file. Once it comes up, copy the migrate server file to it and import.

If the import works, and all your config is present on the new version, flatten the secondary management with the ISOmorphic thumb drive and rebuild it.