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

[shlomip]

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.

Thanks,

Release Management Team

[Greg_Mandiola]

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.

[shlomip]

@Greg_Mandiola ,

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

[phlrnnr]

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!

[shlomip]

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.

[Garrett_DirSec]

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

[Rene_Moeller1]

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

[Josh_Wilson]

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.

[Ilya_Yusupov]

hi @Josh_Wilson ,

i will contact you offline for further discussion.

Thanks,

Ilya 

[shlomip]

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

[shlomip]

Hi @Garrett_DirSec ,

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

[Garrett_DirSec]

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.  

[Rene_Moeller1]

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

René

[_Val_]

@Garrett_DirSec & @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.

[HristoGrigorov]

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...

[Daniel_Toader]

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!

[Florian_Schneid]

Hey Daniel,

did you already get this issue fixed? i also tried to upgrade our management (r80.30 > R80.40) Everythins seems to have worked. I could install all Policies on all R80.30 Gateways and 14xx Appliances. However i do get the same message when i try to install the policy on our Azure Gateway which was already running R80.40. I did rollback to R80.30 for the time beeing.

regards

Florian

[Daniel_Toader]

yes..you need to reset sic in gateway with anohter password 🙂 

[Florian_Schneid]

Thanks Daniel, i will try that on the next maintenance window.

[Florian_Schneid]

Unfortunately, it did not do the trick for me, still getting the message.

[Daniel_Toader]

you need to upgrade gateway from r80.30 to r80.40 

[Florian_Schneid]

The Gateway is already 80.40 (Azure) Managed currently with R80.30. (the R80.30 Image did always cause problems with the WAAgent for me, so i choose the R80.40 Image for my Azure Gateway)

[SaffaRamma]

Issue 1:

I am experiencing the exact same issue on policy push of he Threat Prevention policy with IPS, Anti-Bot and Anti-Virus enable - "Policy installation failed on the gateway. if the problem persists, contact Check POint support (Info: failed to handle indicators, <csc6921a-c75f-4ef8-12f4-39aa15718ccf>). There are also no file indicators present in the config.

Environment:

Newly built R80.40 HA Cluster in Azure. Upgraded the management server from R80.30 to R80.40 (JHF T77). Threat Prevention wouldn't push out to either gateway. Reset SIC with gw2 and the management server and the Threat Prevention policy pushed out fine to gw2. Reset SIC with gw1 and the management server however the issue still persists on gw1.

If I disable anti-bot and antivirus, I can push the IPS to both gateways. If I re-enable either Anti-Bot or AntiVirus, the policy will push to gw2 but fail on gw1.

fw amw fetch <mgmt-ip>

[Expert@euwfirewall1:0]# fw amw fetch <mgmt-ip>
Installing Threat Prevention policy from <mgmt-ip>

Fetching Threat Prevention Security Policy From: <mgmt-ip>

Resolver Error 0 (no error)
prepare_ioc: fwobj_getobj() failed for indicators
configload_download: configload_gw_vtable_extra_data() failed
Fetching Security Policy Failed

Fetching Threat Prevention policy failed

Issue 2

I am also seeing another issue when trying to update the Azure CloudGuards to the latest JHF (T77). Verification fails with:

euwfirewall1> installer verify 1
Info: Initiating verify of Check_Point_R80_40_JUMBO_HF_Bundle_T77_sk165456_FULL.tgz...
Interactive mode is enabled. Press CTRL + C to exit (this will not stop the operation)
Result: Installation is not allowed. Reason: A fix conflict was detected during pre-install validation.
To prevent system instability, installation will not continue.
Please contact Check Point support with the following information:
Package: R80.40 Jumbo Hotfix Accumulator General Availability (Take 77)
conflicts with the following hotfixes:
accel_HOTFIX_R80_40_JHF_T48_308_MAIN_GA_FULL.tgz
For more information - see log files:
/opt/CPInstLog/CRSValidator_accel_R80_40_JUMBO_HF_MAIN.log
/opt/CPInstLog/CRSValidator_fw1_wrapper_R80_40_JUMBO_HF_MAIN.log

This is a brand new installation from the Azure Marketplace (built yesterday). Anyone seen this issue?

[Florian_Schneid]

tried to switch the azure gateway another R80.40 Management machine and the problem persists. So migt not be an upgrade issue.

i noticed the Take 77 issue as well. i think this is related to a new azure image?

my other Azure Gateway is on take 67 and it allows upgrade to 77.

tried to manually import take 67 on the new one and give the same error. Couldn't  try the Ongoing Take 78 as i can't import it right now as the deployment agent can't find it.

[Daniel_Toader]

try to put patch 78 and reset sic

[Florian_Schneid]

Daiel,

No takes are currently installable on the Azure Gateways due the error that also Dan posted

[_Val_]

@Florian_Schneid do you have a TAC case number? If yes, please PM me with it

[Florian_Schneid]

@_Val_ no TAC yet. As i reverted to R80.30.

Issue1:
From my testing’s i can say as soon as the Gateway (r80.40) has received a Policy Install from a R80.30 Management it will not allow a Threat Prevention Policy install.

Doesn't matter if is is the Upgraded Management or you switch the Gateway to a fresh R80.40 Management.

Environment:
Management (test & real) > locally installed onprem (Hyper-V)
Gateway  a Azure Gateway (cloudguard R80.40 single Gateway Image) have no spare real HW or Appliance Firewall at the moment to test those.

Issue2:
It’s simple to replicate. Just deploy a Single Cloudguard Gateway in Azure, connect to the Gaia Portal, try to install/verify any JHF. It will fail with the following message:

Verifier results
Package: R80.40 Jumbo Hotfix Accumulator General Availability (Take 77)
Installation is not allowed.

Reason:
A fix conflict was detected during pre-install validation.
To prevent system instability, installation will not continue.
Please contact Check Point support with the following information:

Package: R80.40 Jumbo Hotfix Accumulator General Availability (Take 77)
conflicts with the following hotfixes:

accel_HOTFIX_R80_40_JHF_T48_308_MAIN_GA_FULL.tgz

For more information - see log files:
/opt/CPInstLog/CRSValidator_accel_R80_40_JUMBO_HF_MAIN.log
/opt/CPInstLog/CRSValidator_fw1_wrapper_R80_40_JUMBO_HF_MAIN.log


@SaffaRamma a redeploy of the Azure Gateways did fix the Threat Prevention policy install for me.

@Daniel_Toader Did you have the issue on an appliance or also a Azure/AWS instance?

[Daniel_Toader]

i don t have azure ..i have simple gateway 3100 

[Dmitry_Gorn]

Hi,

Regarding issue #2 (JHF installation failure), please refer to https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut....

The R80.40 image in Azure currently contains two private hotfixes in order to support the newly released Azure VMSS Remote Access feature. If VMSS Remote Access is not being used, it is possible to safely uninstall the private hotfixes, and then install a new Jumbo Hotfix.

This issue will be resolved with the next image release in Azure planned in a few weeks.

Regards,

Dmitry