Create a Post
Showing results for 
Search instead for 
Did you mean: 

R80.40 is now Check Point's default version widely recommended

4 15 3,043

Check Point is happy to announce that as of today, R80.40 Take 294 along with Jumbo hotfix Accumulator Take 48, is Check Point’s default version and it is considered as widely recommended for all deployments.

R80.40 is available for download via CPUSE and the R80.40 Home page.

A simple process for upgrading Security Gateways directly to the new default version is available in the CPUSE portal using Blink images.



Release Management Team


We just upgraded to r80.40 with jumbo hotfix accumulator Take 48 and have a huge memory leak with the firewall crashing every few hours. This is coming out of having memory leak issues with r80.30 and finally having those resolved after several months. Not sure whats going on but we are not very happy with Checkpoint and feel that you should not be recommending this release.


@Greg_Mandiola ,


Thank you the feedback. I will contact you offline to get more details and help!


We had many memory leaks and crashes in R80.30.  Most of these have been fixed in Jumbo 195, and things have been stable for us since we moved to 195.  We are planning on waiting to go to R80.40 until we can confirm that the leaks we had in R80.30 pre 195 have been resolved (or do not apply) in the R80.40 code train.  Hoping for a very stable R80.40 experience because it has a lot of great features we would like to use!


Hi @phlrnnr ,

If you had specific issues you are aware of, you can visit the R80.30 and R80.40 Jumbo's SK's

to check if they are already fixed in R80.40, or if they are  planned to future R80.40 Jumbo by checking the "list of upcoming resolved issues".

In general, we make sure to align the fixes to all of the Jumbo's (Assuming they are relevant)

There could be a gap due to the release date of each of them, but in general they should be there.

if there are specific fixes you inquire about and need help with, you can contact me for details.

Hello @shlomip -- thanks for your insight. 

We are very familiar with review of JFA/HFA articles for all GAIA releases. 

Similar to other posts, our customers have had some specific issues that were eventually fixed (example:  in R80.30) but the specific BUGID (or whatever code label system you use) was not publicly available.    Of course, the CP engineer viewing JFA/HFA article could search and locate BUGID.    This was source of huge confusion for a period between customer, reseller, and CP engineers.  

Can  you explain why fixes are added in JFA/HFA and not made public? 

thanks -GA

Has anyone already run the VSX on R80.40 and can talk about their experiences?

We tried to upgrade from 80.10 to 80.40 on VSX. After installing and running the vsutil upgrade on the first member, we tried to shift traffic to it so that we could continue to upgrade the other cluster member. We had significant traffic loss that we could not explain. Websites were loading slowly across multiple VS. All resource consumption looked normal. We worked with support services for a few weeks but could not get to the root cause or a fix. So we ended up rolling back to 80.10.


hi @Josh_Wilson ,


i will contact you offline for further discussion.





Hi @Greg_Mandiola ,


Thanks again for the feedback about R80.40

We would like to update that we managed to identify the issue and it is undergoing testing as we speak.

We aim to include this fix in the upcoming JHF take of R80.40


We are sorry for the inconvenience  and thank you for your patience and cooperation that helped us fix it.

The quality of our releases is very important for us and we pay extra attention in constantly improving it.

The issue you have experienced happens in R80.40 with the specific scenario of a large file passing thru multiple connections to internet (either activating ISP redundancy during policy push or remote access VPN with magic button which means that there are multiple external interfaces like ISP redundancy and VPN client tries to download large files upon connecting). This is why it was not reported by customers during the introduction of R80.40 and before we have declared it as widely recommended.


Thanks Again


Hi @Garrett_Anderso ,

Our Policy is to document every item we fix in our JHF’s.

More than that, it is part of our process for including fixes in our Jumbo’s.

It is our interest to expose those fixes and being transparent to encourage our customers to be aware of the issues

And update to the latest JHF’s.

If there are specific issues in question, you are welcome to contact me offline

Hello @shlomip -- thanks for the message and attention to details. 

We've been supporting Checkpoint customers for many years.

The intro and use of publicly documented Jumbo Hotfix concept has been fantastic (and a much needed development for CP). 

However, we continue to encounter customer issues where TAC support employs the "upgrade to latest JHA" as step #1 of troubleshooting issues.

We have many very mature CP customers where if they call TAC on something, it's likely a bug. 

The logical (and reasonable) response from our Checkpoint customers to TAC:  "tell me which bugid in the JHA issue list addresses our issue?". 

In 99% of cases, there is no specific bugID (or whatever the codes represent in JHA "fixed" table). 

I sympathize the often fixing issue "A" does necessarily affect issue "B" and it's often not apparent the relationship without R&D input.   

However,  my experience with customers and TAC "upgrade" mantra is that nothing is present in "fixed" list that represents customer issue.  This is 99.9% of time. 

Thus, I can only implore ongoing sustaining engineering to over document everything.

In addition, we have discovered on more than one case (in past year) where fixes are "inserted" into JHA without public exposure and documentation.    CP engineer could view private fixed list with associated code but this was never present on public SK JHA -- sk153152/R80.30.    That was very frustrating because R&D was referencing issue fix that only CP employee could view and customer totally in dark.  

Maybe a little off topic or more generally speaking:
We almost always have problems with so-called "portfixes", i.e. corrections that have not yet been or will never be included in the main fix (JHF) because they are custom fixes.
There are many problems with this:

1.) There is no public list, if a portfix (always depending on the installed JHF) is installed on a customer system, CP support must (!) always be asked which fix this portfix contains. Then (if you are updating - or if you have to create one through the "Update Solution" just described) you have to ask if a) the JHF target contains the portfix and if not, b) a new portfix has to be created first, which is JHF compatible on the target. This is very frustrating.

2.) It is absolutely intransparent WHEN a portfix should be implemented in a JHF. An example: There is a problem on the VSX that a daily backup via cron does not always work. The error message says that there is not enough disk space. We have been "dragging" this problem around since R80.10 (we are currently at R80.20 last release) and it has not been implemented in the main JHF. Nobody can tell us why this is the case and when it will finally be incorporated. Totally intransparent. This must be changed immediately! We as customers demand the same SK for Portfix as for the Jumbo Hotfix.

Best Regards




@Garrett_Anderso & @Rene_Moeller1 

We appreciate your feedback.


Several notes:

1. Asking to apply the latest Jumbo HFA is the best practice, to make sure your specific issue is not related to something known and fixed.  If this is the case, TAC and the customer both save time and effort to debug and analyze. If that is not the case, no harm done, and you are already on the latest code version, with potential to eliminate other issues.

2. Private fixed you receive from TAC are not compiled by R&D, as a practice, except for very limited scope of situations. Each private fix is produced for a very specific flavour of code, including specific take and libraries versions. It is crafted for your system to address your special needs, and nothing else. Applying the save code changes to other cases without careful considerations can backfire.

3. R&D is collecting informations of known bugs and fixes, but there is a much longer process of implementing fixes to the next version of the code. Since we are transitioning fixes from a limited applicable scope and specific code variants to the general availability, official hotfixes are subject of much more extensive QA processes. There is a certain time gap between the first encounter of a limited situation bug, a TAC private fix for it and inclusion of the fix to Jumbo HFA.

4. You can track your cases and private fixes by your case number. Both R&D and TAC can provide you answers about certain fixes making it to the next HFA. There is always an option to escalate your situation to your local sales representative, if you feel that a critical fix is lagging too much time before making it to Jumbo.


Tracking changes is sometimes real challenge even when they are documented. An example is sk160753 that was last updated yesterday but there is absolutely no way to know what was added or removed from it. There are quite many such SKs actually...

hello, I migrated a few days ago , but modules antibot and antivirus not working ..if I install the policy threat prevention i have error 

Policy installation failed on the gateway. If the problem persists, contact Check Point support (Info: failed to handle indicators, <csc6921a-c75f-4ef8-12f4-39aa15718ccf>).

if I uninstall   antibot and antivirus , install policy threat prevention working 

i put GA 67

thank you!