Model 9000 Software support

[Smorales]

Hello everyone.

For a client, we are going to perform a tech refresh of some old equipment to 9000 models.

The issue is that one of these old firewalls has version R80.30. We have tried in the past to migrate equipment from an old model with R80.30 to a new model with R81.20, but there have been many problems and the client has become mad because they are a financial institution and are quite tightly controlled.

Therefore, we are proceeding with downgrading the new equipment so that they have the same version when migrating. Yes, I know it's bad practice, but we have no other option.

I am creating this post to ask if you know whether the 9000 models still support R80.30 versions.

I would appreciate any comments.

Best regards.

[Chris_Atkinson · Accepted solution]

These EOL version (R80.x) are not supported on this hardware, please refer:

https://www.checkpoint.com/support-services/support-life-cycle-policy/

[the_rock · Accepted solution]

Hey @Smorales 

Im afraid method you want to do would never work. Now, having said that, what was the issue with the config from R80.30? 

What I always do is run show configuration from an existing fw, then save it, and copy bits and pieces to new firewall, just MAKE SURE interfaces reflect correct names.

That method never let me down.

Again, I cant comment what happened in their case, but to me, thats most logical approach.

Best,

Andy

[Don_Paterson · Accepted solution]

Hi Smorales,

This sounds like a problem that needs to be resolved with carefully planned discussions with the customer.

They are leaving themselves exposed in many ways with that solution.

If they are truly tightly controlled then they would be more open to adhering to best practices around the security solution.

They really have to appreciate the technical solutions and capitalise on the investment.

I can't see how some careful planning can't lead to a successful migration to the new hardware and a supported version.

I would not even try to use the older versions on the newer hardware because of Linux kernel versions.

There is also the possible performance issues that could be caused, IF it worked, and then the issue of being unsupported and various other issues that you might be exposed to. 

In https://support.checkpoint.com/results/sk/sk181698 (Quantum Force 9000 Appliances) you can see this note, which may be important in their case:

Important Notes:

• Effective 03 June 2024, the dedicated R81.20 image was replaced from Take 770 to Take 773 to protect against CVE-2024-24919 (see sk182336).

and also this note, which critical to be aware of:

Notes

• Quantum Force Appliances (9800, 9700, 9400, 9300, 9200, and 9100) do not support R81.20 Jumbo Hotfix Take 53 and lower.

Let us know if there is anything we can help with but Andy @the_rock is correct to point to the show configuration and interface configuration.

I would also look to document any other non-standard configurations, for example interface speeds, duplex and buffer settings, on both the appliance and switch side, and then plan the new appliance interface configuration around that.

In my experience it is better to plan as much as possible and then deal with any issues afterwards, hoping that they are minimally disruptive and with the support of the customer.

Hope that helps.

[the_rock]

You are 100% correct Don, as usual.

Here is something I always say to people, not because I dont sugar coat anything, but because I always believed and always will that honesty is the BEST policy and people desrve to know the facts.

So, first off, there is no point crying over spilled milk, as the saying goes. The fact previous attemps failed, that cant be undone. The only time machine I know in life is one I have on my Macbook air at home, sadly, that does not work in real life : - )

@Smorales , if I were you, I would talk to them, explained the situation and lay the facts. Being upset about failed attempts will just make things worse, in my opinion. If being mad was helpful, then all of us would do that lol

Lastly, all @Don_Paterson pointed out is totally accurate. Plus, put it this way...TAC will probably never even bother checking anything R80.30 related, so I would straight up tell them so and if they dont like the answer, call TAC and let them explain it to the customer.

We are here to help you, but customer should definitely be aware of all these things.

Best,

Andy

[Smorales]

Hello, everyone.

Thank you all for your suggestions and responses to the case.

Regarding downgrading new equipment.
This was because the client only gave us five minutes to get them working if something went wrong, and so as not to introduce too many variables, because at that time they were critical pieces of equipment.

The changes were between different models, and adding different versions with a failure would take us a long time to figure out what was going on, and because of the limited time the client gave us, they would ask us to cancel the activity and reschedule.

In those past situations, the equipment did support version R80.30; they were 3000 models, according to the activity documentation.

As for the downgrade on the 9000s, I just wanted additional confirmation because, as I mentioned, the customer is quite stubborn, but this time we will have to proceed with version R81.20 and not R80.30. I will take care of talking to them with documentation or, if necessary, with comments from the TAC.

I really appreciate your comments.

Best regards.

[the_rock]

Excellent! And, my honest advice is 100% do open TAC case, so if they complain about anything, its all in writting, rather then "he said, she said"

Good luck!

Andy

[Bob_Zimmerman]

All of the 3000 series boxes support up through R82. Maybe you could upgrade the software on the old gear in one window, then replace the hardware in another window?

I'll add to the chorus saying I currently work at a financial institution and wouldn't consider running anything below R81.20. We were stuck on R67 for years past its end-of-support date (long story), and that's not a position we ever want to be in again. As a result, we're extremely aggressive about software upgrades. It has taken years of work to get there, but we are now able to deploy a fix environment-wide in a matter of days when needed. Even taking things slowly by our standards, we have 16% of our environment upgraded to R82 (started after it became recommended), and we expect to get the rest there in the first six months of 2026.

I was able to get upper management buy-in by showing how about 80% of the outages attributed to the firewalls were from issues Check Point had fixed over a year before we hit them. In over half of the remaining issues, updating the firewall was the first step before we could get any troubleshooting help. Thus, by keeping the firewalls current, we have far fewer issues, and the issues we do have are dramatically faster to solve. We've had one outage attributed to software on the firewalls in all of 2025, and it was due to a patch adding better enforcement against noncompliant HTTP (i.e, the firewall did the right thing, we just didn't know the bad traffic existed in the environment).

[Vincent_Bacher]

This topic confuses me a bit.

I work for a global financial institution and so we are constantly under scrutiny. That’s why we would never consider installing any toxic versions of Checkpoint on current hardware

[the_rock]

I feel the only exception to that rule, MAYBE, would be if they had Diamond support, but even then, not positive would apply, just my educated guess.

Andy

[Vincent_Bacher]

We do have diamond support but we would not consider such a step.

[the_rock]

I dont blame you. I worked once with a hospital that also had diamond support, but TAC was on the phone and there was an unsupported version involved and we ended up upgrading that night, so that was productive.

Andy

[Smorales]

Hi Vincent,

let me share with you a bit of context:

The site where these toxic versions are installed functions as a DRP for them, so they do not prioritize upgrading a few gateways with old versions.
This is because they always have a high volume of projects, and they never prioritize these gateways because they do not run a lot of critical services as they are a DRP.
We always remind them and suggest that even though it is a DRP, they should have everything with the recommended versions, but sadly, the final decision is up to the customer and not us.

[the_rock]

Thats all you can do, really. I always personally make sure things are in the email, so no one can deny the facts later : - )

Andy

[Vincent_Bacher]

Don’t get me wrong. I understand your position well since i worked at solution providers for many years and therefore I know end customers of many industries well.

Just wanted to mention that I am now in similar situation and we would decide differently. 
Incidentally, I cannot imagine why it would not be possible to migrate an R80.30 gateway to R81.20 with new hardware.

[_Val_]

Once again, what is a "toxic version"? Are you guys sure you are using the right word?

[the_rock]

I believe Val they meant unsupported, thats the way I read it : - )

Andy

[Vincent_Bacher]

Exactly. In our organization, devices with no support on hw and/or sw are called toxic. Sorry for confusing.

[the_rock]

I knew as soon as I saw it...all good!

Andy

[Don_Paterson]

Might be some influences from Ayurvedic traditions, where “toxic” refers more to loss of vitality or digestive balance rather than literal toxicity.

For example a substance that loses nutrient or enzym potency when mixed with another substance. 

[the_rock]

I studied organic chemistry as a "young buck", I can totally relate to that 🙂

Andy

[_Val_]

I am sorry, what do you mean, "toxic"?