Anatomy of a Check Point Upgrade

By | June 8, 2012

Having recently emerged relatively unscathed from a Check Point Smart Management Server upgrade, I thought I’d blog about the experience – mainly for my own future reference, but if it helps anyone else out then that’s great too!

I needed to get our SecurePlatform, Open Server based SMS from version R71.10 to R75.30, so I set about reading up on the process and planning my attack.  Here’s how I went about it….

 

Research

In order to get hold hold of the right information to plan this, I headed straight for my Check Point User Center. Although there are some superb sources of unofficial information out there (cpshared and CPUG in particular), I found that in this case the official docs were pretty much all I needed.

After studying the release notes and installation guides for the releases I was interested in (plus a quick sanity check post on the cpshared forum) I had my plan.  In a nutshell, there is no way of jumping directly from R71.10 to R75.30 – it has to be a multi-step process.

For information on the upgrade path to get me from version R71.10 to R75.30, I also checked out the Check Point R70, R71 and R75 Upgrade Map (requires a user centre account).  In my case the upgrade path was:

R71.10 –> R75  –>  R75.20 –> R75.30

The principle and process is basically the same for each step of the upgrade.  You need to export your current Check Point database using the migration tools from the release that you want to get to.  You then clean install your SMS to the next version in your migration path and import the database.  You then rinse and repeat until you get to the release you want.  Simple, right??

Actually it is pretty simple, just very time consuming!  The other step in each upgrade is to run the pre upgrade verification tool from the target version to make sure that your database is compatible before you export it.  DON’T forget to do this step as you will run into problems later if you do.  In my case the R75.20 verification tool flagged up a couple of objects that need to be renamed – a quick name change in Smart Dashboard and I was good to go after running the tool again.

 

Migration tools

A quick note on this before we plough on.  The migration tools used to perform export/import used to be called upgrade_export and upgrade_import.  The old script files still exist in the /$FWDIR/bin/upgrade_tools/ directory alongside the new migrate script.  The migrate script is exactly the same as the other two so feel free to use either.

 

Assumptions

This article assumes the reader has some knowledge of certain basics such as using SCP for file copy, extracting .tgz archives and running scripts on a Linux box.  If not then some of my other posts detail the export scripts and there’s a ton of material out there for the other bits, just a google search away.

 

What You’ll Need

Grab the following files from Smart Center:

  • Check_Point_R75.Splat.iso
  • Check_Point_migration_tools_R75.linux30.tgz
  • Check_Point_R75.20.Splat.iso
  • Check_Point_migration_tools_R75.20.linux30.tgz
  • Check_Point_R75.30_Upgrade.Splat.tgz
  • Check_Point_migration_tools_R75.30.linux30.tgz

 

Virtualize it!

Once you have the first database export taken from your management server, you can leave this box alone so it can remain on-line during the remainder of the process.  I then set up a Virtual SMS on an ESX server and carried out the rest of the upgrade steps on there until I had my final database export taken using the R75.30 migration tools.

 

Testing

I carried out a test plan after each stage of the upgrade, with most testing done in the VMWare environment and then final tests in production.  I also had the luxury of being able to build my new SMS on new hardware, meaning a roll-back to the original box was easy if required (it wasn’t!).  The tests mainly consisted of checking that SIC was maintained to all gateways and that site-to-site and remote access VPN’s were still up after the first policy push from the newer SMS.

 

The Plan

So, having done my research and set up my VM environment I was good to go.  Here are the steps I followed:

[R71.10 --> R75]

  1. copy the R75 migration tools onto the R71.10 SMS, and extract into /var/tmp
  2. run the pre_upgrade_verifier script and fix up any issues
  3. run the migrate tool to generate your database export, and copy off the box
  4. build VM SMS box as a fresh install of R75, and run a basic first time config, either through the CLI or the WebUI
  5. copy the database export file into /$FWDIR/bin/upgrade_tools
  6. run the migrate tool to import the database file
  7. TEST

[R75 --> R75.20]

  1. copy the R75.20 migration tools onto the R75 SMS, and extract into /var/tmp
  2. run the pre_upgrade_verifier script and fix up any issues
  3. run the migrate tool to generate your database export, and copy off the box
  4. build VM SMS box as a fresh install of R75.20, and run a basic first time config, either through the CLI or the WebUI
  5. copy the database export file into /$FWDIR/bin/upgrade_tools
  6. run the migrate tool to import the database file
  7. TEST

[R75.20 --> R75.30]

  1. copy the R75.30 migration tools onto the R75.20 SMS, and extract into /var/tmp
  2. run the pre_upgrade_verifier script and fix up any issues
  3. run the migrate tool to generate your database export, and copy off the box
  4. build new (non VM) SMS box as a fresh install of R75.20, and run a complete first time config either through the CLI or the WebUI.  This should include everything to match your existing SMS SPLAT config, such as reconstructing your routing table, adding administrator accounts etc, etc.
  5. upgrade to R75.30, either through the CLI or WebUI
  6. copy the database export file into /$FWDIR/bin/upgrade_tools
  7. run the migrate tool to import the database file
  8. TEST

 

Problems

The only issue I encountered was that after the final upgrade step to R75.30, the WebUI thought that my SMS was a 12000 series appliance!  Slightly concerning at first, but a quick call to my support partner revealed that this was a known bug in the WebUI code that decides whether the machine is an appliance or not.  Needless to say there was quick fix to sort this out.

 

Learnings

This was my first Check Point upgrade on a production network, and I learnt a hell of a lot during the experience.  A couple of the main things though are more practical than technical:

  • Never let your Check Point estate drop so far behind the latest release that your upgrade path ends up being as convoluted as mine was
  • Allow plenty of time. Really, plenty of it.
  • Use VMware to allow you to work on the upgrade whilst keeping your existing SMS on-line

 

I hope someone finds this stuff useful.  If you do, let me know!

Cheers

Rich

 

Follow me on Twitter

2 thoughts on “Anatomy of a Check Point Upgrade

  1. Rahul Verma

    Hey Rich,

    Would you happen to have a MDS and MLM upgrade template/plan to R77.20 that includes test, execute, validate and back-out phase?

    Your help will be greatly appreciated.

    Rahul

    Reply
    1. Rich Bibby Post author

      Hi Rahul,

      I’m afraid I don’t. I’ve always found Checkpoints own documentation to be very good, so check there.

      Rich

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *