Things you shouldn't do on a midnight upgrade

[Hugo_vd_Kooij]

In the list of things you shouldn't do in a midnight upgrade here is another one.

Starting point:

SmartCenter R80.20.M1 on an isolated subnet

Single Gateway R80.10

Objective:

Upgrade the gateway to R80.20

As you might know this will fail on multiple levels. And is most definitly not supported.

I did an in-place upgrade of R80.20 and that seemed to kick of easily but after reboot I had .... an InitialPolicy installed.

Great. So I locked myself out of my SmartCenter 😉

As this is running completely in ESX I have sort of an outbound management. The console. So time to get to the CLI (and mgmt_cli).

There you can try to push a policy but it fails because the versions don't match.

mgmt_cli --port 4434 install-policy policy-package 'standard' targets 'fw01'

(My system has been pushed to port 4434 when I installed EndPoint.)

You can correct this version from the CLI by upgrading the version in the object.

mgmt_cli --port 4434 set simple-gateway name 'fw01' version 'R80.20'

Now repeat the policy install and it works.

However this will be the only policy install that will work. So you end up with a firewall you can access again but can't realy manage as R80.20.M1 can't manage a R80.20 gateway.

So I will do an export of objects and reïnstall the SmartCenter to R80.20 and build a new policy and test sk86521 (Reset SIC without restarting the firewall process ) once again.

In case you didn't yet get the general idea of this post ....

Keep away from R80.10.M1

(Unless you know what you do and know why you wanted it for that very, very important business deal that will pay for the extra days you will have to spend on compex updates later.)

[PhoneBoy]

If you're still on R80.10 and want to upgrade, there is no reason to upgrade to R80.20.M1, go straight to R80.20.

If you are on R80.20.M1 and want to upgrade to R80.20...you'll need to involve the TAC currently.

See: Security Management upgrade from R80.20.M1 to R80.20 

The reason is that there is a new upgrade process that we are in the process of rolling out--one that is different from the one currently used upgrading from R80.10 and earlier releases.

At the moment, it requires TAC/R&D involvement to ensure the process goes smoothly.

Once the rollout is complete, you'll be able to upgrade without TAC/R&D involvement using a similar upgrade process as with previous releases.

The good news is that that the same mechanism we are rolling out now will also (hopefully) enable migrating domains between MDS, something that has been a limitation since R80.

[Dorit_Dor]

Thank you - i appreciate the open dialog and want to convey what is the universal plan here and how will it be different in the future. 

To start, R80.20M1 is the first management feature release and in order to support its upgrade, we have signifincantly revised and simplified the upgrade because we knew that its important ... but the new upgrade is still in Early availability (since we added updateability to that code, we will role it out as its ready). So R80.20 release notes points to sk137677 for upgrade from R80.20M1. This SK recommends to 

1. Join the new upgrade code EA 

2. Wait until the upgrade is ready and released (will be published in this SK) 

3. If #1&2 are not good enough, you can also get manual process instructions (and dont do it at midnight) - this option was added to help time-critical users but is clearly not the desired route. 

I recommend to join the EA or to wait for the upgrade. I am confident that in the future this willl no longer be issue for management feature releases. 

Still, feature releases are targetted to ppl that need the features and dont want to wait for next version. Otherwise, we have formal GA main train releases and you should use them 

[_Val_]

You are correct, you cannot manage R80.20 GA GW with R80.20.M1 management. R80.20.M1 was released before R80.20 GA cycle. In your specific case, to lift up your system onto R80.20 GA, you could benefit from R&D assistance on your MGMT part. 

On another subject, I would not advise any upgrade, however safe and tested, to be performed remotely in case you do not have out of band access to on site management tools. 

[JozkoMrkvicka]

Lession learned:

NEVER upgrade gateway without working console connection.

Lession learned vol. 2:

NEVER EVER upgrade gateway when console connection is behind gateway you are going to upgrade.

Lession learned vol. 3:

Be paranoid, always. NEVER trust following statement:"Do it, nothing will happen." It is lie, ALWAYS.

[SantiagoPlatero]

Hi all, I know the following doesn't quite apply for this discussion (I didn't found a similar discussion of the issue on the board). Also, I really don't know if the R80.20.M1 Migration Tools are available for download at this time (crucial for this), and the procedure that I explain below where tested only for the upgrade procedure from R80.20 Public EA to R80.20 GA (I try to do first using CPUSE, but it failed and asked me to contact TAC -then you will find out why I couldn't contact TAC for this-). 

Also, I think this could be an interesting starting point to think the better way to do a secure upgrade from R80.20.M1 to GA, at least until Check Point improves the upgrade path for R80.20.M1. 

Cautions first:

- We have the R80.20 Public EA management in our VMWare Datacenter, so we've do the proper snapshots prior to do the following, and also we had full replicas of the working VM.

- We didn't have any R80.20 GW in our production environment. Only a R80.20 Public EA GW for lab and testing purposes, so if we lost it, it wouldn't be an issue.

- Like Jozko said above, be paranoid. This worked for me. Maybe it won't work for you. Have your backups/snapshots/replicas prepared if you choose to do it. Do it for testing, or for fun, or for knowledge. Don't do it in your production environment, unless you have no chance at all and you feel adventurous and lucky (although if you follow the instructions and read the many, many cautions and warnings you should have the chance to do a rollback). 

Ok, enough warnings, let's go:

I found an interesting workaround talking about this issue with a regional Check Point engineer regarding the upgrade process from R80.20 EA to R80.20 GA management. I have to do this because I have the collaborative support contract, so if I've to open a case to TAC, first I've to go through our local partner, which as far as I know they aren't very well trained in R80.x. (for instance the last week they've to do the annual preventive maintenance tasks and they didn't even have downloaded the R80.20 SmartConsole).

The procedure goes as follows:

1. Download the R80.20 GA Migration Tools.

2. Export the DB from R80.20 EA using those Tools.

3. Deploy a plain new R80.20 GA installation.

4. Follow the web wizard to the end and, then, import the DB exported from step 2.

5. ?????

6. PROFIT!

I would like to give the credit for that awesome engineer who saved me, but he doesn't have an active user in the community.

And, as for a final warning and as the sk137677 clearly states: customers are advised not to upgrade from R80.20.M1 to R80.20 without consulting Check Point Support.

And I also want to clearly state: I really don't know if you could do this for R80.20.M1. Maybe you can. Maybe you not.

Although the so logical caution stated above, I think is a very interesting approach and it worked smoothly on our deployment, and maybe others find interesting to do in lab environments and such.

Sorry if this wall of text were offtopic, or were talked about in another discussion.

[PhoneBoy]

When I tried doing a migrate export/import from R80.20.M1 to R80.20 shortly after GA, the result was...not usable.

The supported process will come shortly, meanwhile please join the EA for the tool to migrate in this case 

[Tomer_Sole]

Dameon Welch-Abernathy wrote:

When I tried doing a migrate export/import from R80.20.M1 to R80.20 shortly after GA, the result was...not usable.

I want to clarify why: We changed the command-line names for it, and forgot to block the old ones. So you ended up calling an old executable. We updated the agent since then.

Guys there's a reason why we're currently limiting R80.20.M1 to R80.20 upgrades "only with active assistance by Check Point" (specifically just the upgrades from R80.20.M1 though).

Once we have enough cooperation from customers that we assisted, an update to the CPUSE Agent will remove that blockage.

We are planning to release self-help instructions for non-production environments, but currently we are delaying those until we reach to a point of actively assisting enough customer production environments.

[PhoneBoy]

While the R80.20.M1 > R80.20 upgrade process is still publicly blocked, I've managed to do it successfully using a process we will make available publicly in the near future.

TAC can walk you through the process in the meantime.

[Hugo_vd_Kooij]

The whole issue was mainly to show some workarounds in fixing version info without SmartConsole and doing a policy install from CLI. It might save your skin one day (propably night actually) if you get locked out from SmartConsole.