R81.20 New Recommended Jumbo - Take #53

[gadt]

Hi All

R81.20 Jumbo HF Take #53 is now our Recommended Jumbo take and is available for download to all via CPUSE (as recommended) and via Jumbo documentation R81.20 

Release Highlight:

A full list of resolved issues can be found in the Jumbo documentation R81.20 

Note:

• Central Deployment allows you to perform a batch deployment of Hotfixes on your Security Gateways and clusters from SmartConsole!! For more information, see sk168597.
• With Blink images, you can upgrade your environment to the required Major version including its recommended Jumbo hotfix in one Step, using a single image file.

You can install Blink images using CPUSE – More details can be found in sk120193

Thanks,

Release Operations Group

[G_W_Albrecht]

Installed well on SMS, but GW is inable to install or uninstall JT 45:

GW8120> installer uninstall
**  ************************************************************************* **
**                                 Hotfixes                                   **
**  ************************************************************************* **
Num Display name
                    Type
1   R81.20 Jumbo Hotfix Accumulator Take 45
                    Hotfix
GW8120> installer uninstall 1
The machine will automatically reboot after uninstall of Check_Point_R81_20_JUMB
O_HF_MAIN_Bundle_T45_FULL.tgz.
Do you want to continue? ([y]es / [n]o / [s]uppress reboot)  y
 
Info: Initiating uninstall of Check_Point_R81_20_JUMBO_HF_MAIN_Bundle_T45_FULL.t
gz...
Interactive mode is enabled. Press CTRL + C to exit (this will not stop the oper
ation)
Result: Uninstall_Last_Take Failed
There are hotfixes installed on top of R81.20 Jumbo Hotfix Accumulator Take 45.
Uninstall the hotfix(es) HOTFIX_TEX_ENGINE_R8120_AUTOUPDATE and try again.

[MatanYanay]

Hi @G_W_Albrecht  

We are looking into it and will update 

Thanks 

[MatanYanay · Accepted solution]

Hi @G_W_Albrecht 

We found the RC and fixed it. ( All good with the Jumbo 👍)  It related to TEX_ENGINE_R8120_AUTOUPDATE

We also will take it with you offline to verify the fix indeed worked 

Thanks for bring it to our attention  

Matan.

[G_W_Albrecht]

Yes, issue is resolved!

[the_rock]

I installed it in 2 labs, no issues at all, seems stable.

Andy

[Magnus-Holmberg]

done my part now an upgraded the first 10 mgmt machines (MDS/MLM/Event) 🙂 

[D_TK]

Had strange experience upgrading to this take.  All were previously on take 41

First upgraded on-prem management (open server) - no issues

Next, a 5200 cluster - no issues.  And then another 5200 cluster, and again no issues.  All four of these 5200s have LOM cards - no issues with them (keep reading).

Next up was a 6200 cluster.  Upgraded the standby member - finished successfully, but after the automatic reboot it didn't come back for over two hours.  When it did come back, it was upgraded to 53, sync'd fine to the active member, and was running fine.  No idea what it was doing during the two hour reboot because the LOM card wouldn't respond.  If fact, the appliance now says it doesn't have a LOM card installed...  I decided to put traffic on this member, no issues, so i went ahead and started the upgrade on the other member.  I verified that its LOM card was responding prior to starting the install.  Did the upgrade - finished successfully, and then rebooted.  What do you know, two hours later it came back, and just like the other member, all was fine.  Here's the kicker.  During the two hour reboot, the LOM card did not respond - it pinged, but no UI.  But unlike the first member, once it came back online, the LOM started working again.

I'll probably open a tac on this one, i still have five more clusters to upgrade, and three of them are 6200s.

[the_rock]

That is super odd issue, I would definitely open TAC case.

Andy

[Daniel_Karlsson]

I can confirm that HFA53 took "longer-than-usual" to install.
..about 45 minutes per node in our 7000-cluster.

No issues detected or reported so far though, just the long time to complete the udpate.

[the_rock]

Thats odd, I did not experience that issue, took about 20 mins per cluster member.

Andy

[khusant]

I am currently using 80.40 on my cluster of 6800. Do you recommend upgrading to 81.10 or 81.20?

[the_rock]

I would say 100% R81.20, I always found it very stable, even during testing, before became recommended version back in summer of last year.

[khusant]

Thanks for the info. Will upgarde to 81.20 then.

Are you using Optimized drop feature? Is it really have a performance impact on fw (less cpu usage)?

[the_rock]

I do use it, did not see any issues.

Andy

[G_W_Albrecht]

A customer found that two of his mostly used VPN clients after upgrading from JT 41 to JT 53 have issues:

- Linux CLI mode for SSLVPN / SNX build 800010003 is not working anymore, log in is no longer possible

- Win Capsule VPN seems unreliable now and clients often get logged out after 5 mins. Connecting again will also only last 5 mins; other times the connection is stable for hours

I had two tickets open (one for every client) and the result (summarized) was:

As of now, yes, I would not recommend upgrading to T53, we are in close contact with the
development team regarding this, but unfortunately there are no ETAs for the fix of this
issue.
(SR# CLI SNX)

Hopefully soon the behavior change will be reverted or fixed, and a new take will be released
for the different Jumbos.

Please rest assured that the issue is being addressed by our team, and I've been in touch
with our R&D department for additional information.
They've confirmed that they are working on a fix, but unfortunately, we don't have an ETA
for its resolution.
(SR# Capsule

So i would like to see an SK# about this issues - what CP TAC engineer could find from the documentations is that SNX's functionality is different in T41, code-wise. The behavior changes on later takes such as 53.

Still it would be good to also have some reference number (PRJ- , PMTR- ?) that helps to know if the issue is resolved in a future JT !

@MatanYanay , do you know of that issue(s)?

[MatanYanay]

Hi @G_W_Albrecht 

I'm not familiar with the second issue you described in the thread but the first one which related to 

"Linux CLI mode for SSLVPN / SNX build 800010003 is not working anymore, log in is no longer possible"

we have dedicated sk for it - https://support.checkpoint.com/results/sk/sk181805 

The fix for this issue will be part of the next Jumbo we plan to release in all our versions during May and June.

The relevant PRJs to track are PRJ-52048/PRJ-52047/PRJ-52046

Thanks

Matan. 

[G_W_Albrecht]

I think this is a different issue - all has worked still using JT 41 but after JT 53 install Linux CLI did not work anymore!

The second issue is that Windows Capsule VPN gets unreliable - clients often get logged out after 5 mins. Connecting again will also only last 5 mins; other times the connection is stable for hours. sk181805  seemed to work when no Windows Capsule VPN connection was possible directly after JT 53 install, but Windows Capsule VPN now showed as very unreliable.

[Robin_Greve]

Hi @G_W_Albrecht,

regarding the CLI SNX issue did you solve the issue with R&D or is the case still open? We have the same issue. Thanks a lot!

Best regards,

Robin Greve