R81.10 Jumbo Hotfix Accumulator - New Ongoing take #55

[MatanYanay]

Hi All

A new Ongoing Jumbo Hotfix Accumulator take for R81.10 (take 55) was released today, and is available for download. Please refer to sk175186

Please note the following:

•        Availability:
  • Available to download the via sk175186
  • Available for download via CPUSE by using package identifier.
  • Can be provided by customer support

Content included in this take:

• List of resolved issue in this take can be found in sk175186

New: Starting from R80.40, Central Deployment allows you to perform a batch deployment of Hotfixes on your Security Gateways and clusters from SmartConsole!!

For more information, see sk168597.

Thanks,

Release Operation Group

[G_W_Albrecht]

Not true that it is

• Available to download the via sk175186
• List of resolved issue in this take can be found in sk175186

This page has moved

See https://community.checkpoint.com/t5/General-Topics/New-documentation-format-for-Jumbo-sk/m-p/147520#...

[RamGuy239]

@G_W_Albrecht 

Not a huge fan of this change. I can see the benefits of moving things to a more dynamic document style type of page. But it was much easier to get a quick overview of all the jumbo hotfix takes and their changelog when it was a flat website like sk175186 used to be.

I can see we have the same kind of change for R80.30, R80.40 ad R81 jumbo hotfix accumulators as well.

In most cases, you would jump from let's say R81.10 Take 14 to R81.10 Take 45. It's not all that common to have deployments patching to a new GA jumbo as soon as it releases as that would require patching quite frequently. So unless there is something specific that needs to get fixed by a new jumbo, or there is some known vulnerability that needs to get patched, or there is a general maintenance window where things are being patched to the latest recommended version things tend to not get touched and then you will most likely be in a situation where there are several jumbo hotfix releases between what you are currently running and what is the current GA recommended jumbo. Getting a quick overview of all fixes you'll be getting was much easier using the SK as with this new Jumbo Hotfix Accumulator document page there is no section that will list a complete changelog for all jumbo hotfix takes.

If I was to get an overview of all the changes I'll get by moving from R81.10 JHF Take 14 to R81.10 JHF Take 45 I would have to first read the changelog for Take 45 under the section "Take 45 - General Availability", then I would have to move to section "Earlier Released Takes --> Take 44", then move to Take 38, then move to Take 30, then move to Take 22 to get a complete picture.

[G_W_Albrecht]

For shure, and this is also my opinion! But the worst thing for me is that all information found inside the Jumbo HF document is not available for UserCenter support search anymore - this is a drawback that can not be valued correctly until all consequences have been realized. Germans call this procedure type verschlimmbesserung (imworseprovement).

[Magnus-Holmberg]

Agree here aswell, it changes the dynamic of the usercenter and make it harder to find.

[Arne_Boettger]

I must concur. I too was surprised by the new structure. It would be helpful to know what the driver behind this was, and if there are actual improvements we dont recognize immediately.

[the_rock]

I agree with the guys. How in the world do I download this jumbo? I cant find it anywhere...

[the_rock]

Never mind, got it, but still, this in my opinion was not necessary at all. Bad decision, just my personal take.

[MatanYanay]

Hi All 

first I will start and say that we are working to fix the specific bug search in usercenter.

This method brings a modern UI with better browsing capabilities and user experience.

We are in the process of upgrading our systems to improve the overall customer experience, a better search engine and results.

As Jumbo SKs are part of a fundamental process we decided to go ahead and start with the Jumbos.

Browsing through hundreds or more items became cumbersome and the new format makes it much easier.

Thanks 

Matan.

[the_rock]

Understood @MatanYanay . Like anything new, it takes time, but this will surprise lots of people, for sure.

[G_W_Albrecht]

Although to make things better is basically a good thing, i would have opted for not replacing the old format but supplementing it with new features as long as the shortcomings have not been eliminated ! Suddenly deleting the old format completely together with crippled search options making my work harder does not give much hope 😞

Any estimate when searching for Jumbo Take content like SK numbers and IDs will be able in UC ?

[MatanYanay]

@the_rock  and all 

just to make sure everyone know how to download the GA / Ongoing take. 

you need to click in the left panel on the relevant take you want to download

once you clicked on it you will see the download table with the links to CPUSE offline package and  SmartConsole package

Thanks 

Matan.

[MatanYanay]

@G_W_Albrecht 

The searching for Jumbo Take content like SK numbers and IDs will be resolved by tomorrow morning 

Thanks 

[G_W_Albrecht]

So why did you put it in production before resolving it if that is so easy to achieve ?

[MatanYanay]

Hi @G_W_Albrecht  and all 

It’s a fare question, this was a big change that took a lot of effort, and though it was tested extensively, this search capability did not get to the production version. We are taking this very seriously and this is why we will be able to fix this within a day.

I would like to thank you all for your feedback and if you have more please share ( please do it on the main thread I published this change ) as we would be glad to hear on the different ways you browse the SK and the different use cases, so we can keep improving.

Thanks

Matan.

[MatanYanay]

Hi All

The issue with the IDs search and the sks search resolved now.

you can search in usercenter and get the results under the documentation tab   

Thanks 

Matan.

[G_W_Albrecht]

Not for me:

[MatanYanay]

@G_W_Albrecht 

I'm checking, as I can see the issue...

will get back to your shortly  

[JohAicher]

Hi all,

has anybody made bad experience with this HFA?

Reg. Johann

[JohAicher]

Unbelieveable !!!

CP is pushing out R81.10 HFA 55 and the problem with VPN remote users  who do NOT get IP from DHCP ist sitll not solved!!!

the problem came up on HFA 45 and there was a Hotfix for this - why is that NOT fixed in HFA 55 ?????

[MatanYanay]

Hi @JohAicher  and All

We apologize for the inconvenience, the fix will be included in the next ONGOING jumbo we will release by EO May / Early June

There is a hotfix available for anyone encountering this issue (sk178767)

Matan.

[Kris_Pellens]

Does Check Point release new GA before end of may given issue mentioned above?

Can someone explain where detailed information can be found regarding PRJs?

E.g. PRJ-34712, PMTR-73184, Routing, In rare scenarios, the routed daemon may unexpectedly exit or write logs in the incorrect order.

This has been solved in Ongoing Take 55. But it's not clear what the rare scenarios are. Also Check Point TAC is not willing to share the details with us.

Thanks.

[JohAicher]

from my point of view it would be very helpful to get information about open cases for any Version/HFA like 81.10 HFA 55

- an other very big company give this info to users...

so we could decide which HFA to install at any given time and to know which problems could come up - I do not understand why this info is top secret for users paying lot of money for the products and services

like:

open cases - with detailed info about the problem

closed cases - with detailed info - not only  i. e. PRJ-34712, PMTR-73184 - from which we do not get more info's about

[MatanYanay]

Hi @JohAicher and @Kris_Pellens 

We are taking it internally to see how and what we can do to improve our Jumbo documentation. 

Be aware we have section of "Important Note", in this section we are alerting on issues that can cause an impact.

Thanks 

Matan.

[Alex_Ambrose]

Hi @JohAicher 

Regarding PRJ-34712 / PMTR-73184, the issue we found can potentially occur with a wide variety of configuration. In our internal testing, we discovered it specifically with OSPF configuration, and this seems to be the protocol most likely to trigger the issue. However, it's not limited only to OSPF and could impact a wide variety of configuration scenarios.

The issue itself is still somewhat rare (hence "in rare scenarios" in the bug description), just could be triggered by one of many potential causes.

What @MatanYanay said is also correct, that we will be discussing this internally to improve this documentation in the future.

Thanks,

Alex

[Kris_Pellens]

Thank you for your feedback Alex.

We have two VSX/VSLS clusters (running both OSPF and BGP) which we will upgrade next week.

Since we can't afford downtime in our environment, do you have a port fix for this isse (PRJ-34712 / PMTR-73184)?

Or should we go for take 55; and when does take 55 become GA?

[Linus]

Just a heads up:

Sometimes our remote access users get the following error message:

"VPN-1 server can't find any certificate to use for IKE"

Problem is solved when I install a policy even when no changes are published. I think maybe some service is being restarted .

Problem started when I installed Ongoing Take 55. 

I found sk104739 but my certificates (Subordinate and Trusted CA) are still valid.

[Alex_Ambrose]

@Kris_Pellens I don't have any information on when the JHF goes GA.

Regarding the fix itself, if you do not have routing trace logs enabled via the 'set trace' commands, then your risk is very low. If you haven't been experiencing issues thus far then I would say it's low risk and you can wait for the GA release.

Regardless, if you want a portfix for this issue prior to upgrading to JHF55, please open an SR and CFG will handle it.

[Kris_Pellens]

MVC is not working on R81.10 (VSX/VSLS): T30, T45, and T55.

Case opened in March 2022.

Check Point confirmed the issue this week; and provided non working fixes:

1. fw1_wrapper_HOTFIX_R81_10_JHF_T30_326_MAIN_GA_FULL.tar
2. fw1_wrapper_HOTFIX_R81_10_JHF_T45_359_MAIN_GA_FULL.tgz

As per the case notes:

1. Installed fix (fw1_wrapper_HOTFIX_R81_10_JHF_T45_359_MAIN_GA_FULL.tgz) on R81.10 member with T45.
2. Ran "fw ctl set int ccl_use_cluster_id_mac 1 –a" on R80.40 member.

After reboot of R81.10 member, HA module no longer starts. Not happy with the support at all.

Re-escalated the case one more time!

What's the issue?

During MVC we turn on "enable non_strict_ccl_mac_check" that makes the correction to check only the the correction bit meaning only "02" bit.
The customer have a very unique MAC that has the "02" bit on.
The New member therefore thinks that the MAC is "corrected".

Background

In R80.40 we use following for MAC for correction "02:00:00"
In R81.10 - the correction MAC is: "02:XX:XX" XXXX - is cluster_id

Next steps

Private Fix that will cause MVC not to use non_strict_ccl_mac_check (only for R81.10 member). (fwha_mvc_enable_non_strict_ccl())
The problem that the correction will not work during this period of time, so the solution will be implement sk168076 partially on the old member (R80.40) if correction is needed.
sk168076 causes the old member to use the correction mechanism similar the new R81.10 member.
Why partially? - It's enough to run on old member "fw ctl set int ccl_use_cluster_id_mac 1 –a" {}no need to update the kern file unless we need to reboot R80.40 that is shouldn't happen.

[Olegf]

@Kris_Pellens 

Hi Kris,

I’m working at Check Point as a Technology Leader.

We apologies for you experience and will investigate it. I will review the case personally. Looks like something happened during the private HF installation, and this this not connected to the original MVC issue.

I want to clarify that the MVC issue was very unique, that we saw for first time on this specific customer, because of the unique MAC address that he uses.
Beside this specific MAC issue, we are using and testing MVC frequently including VSX T30, T45, and T55 and didn’t experience issues. Sorry for the inconvenience.

Thanks,
Oleg

[Kris_Pellens]

Hi Oleg,

Thank you for you feedback.

We succesfully applied the private fix on a 16000T production appliance. Without the fix, MVC does not work correctly.

The upgrade of the cluster went smoothly, despite we had some issues with OSPF, RADIUS, ... Regarding OSPF: it looks there's a difference between R80.40 and R81.10.

Tomorrow we will repeat the exercise for our 23800 appliances.

Kind regards,
Kris