R82 Jumbo Hotfix Accumulator take #25 has been released today

[eranzo]

Hi All,

R82 Jumbo Hotfix Accumulator take #25 has been released today, and is available for download.

Please note the following:

•        Availability:

o   Available to download the via Jumbo documentation (R82) 

o   Available for download via CPUSE by using package identifier.

o   Can be provided by customer support

Content included in this take:

• List of resolved issues in this take can be found in the Jumbo documentation (R82) 

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.

Thanks,

Release Operations Group

[the_rock]

Installed it already in my lab, will report tomorrow if any issues.

Andy

[the_rock]

@eranzo One odd thing I noticed was when I installed jumbo on my vsnext lab, rebooted, all good, showed jumbo 25 when doing cpinfo -yfw1, but in web UI and smart console, still showed jumbo 19. I installed database, pushed policy, but nothing changed. Once I rebooted it again, all was showing correct. All other lab instances (single gw, another mgmt and smart event were okay).

Andy

[Boaz_Orshav]

@the_rock Smart Console might take several minutes until it is updated but no need for reboot.

When you say "web UI" do you mean the GAIA web UI (locally on the GW)?

Do you happen to have a screenshot as well as logs (run da_cli collect_logs on the GW - it creates a tgz)?

If so - will appreciate if you can send me boazo@checkpoint.com

[the_rock]

Hey @Boaz_Orshav 

Thats my experience as well...usually, web UI and smart console may take few mins to show correct info, but in my case, even after 1 hour, it did not. Since its a lab, thats why I simply rebooted it again. I will, however, collect da_cli_logs and send over, appreciate the help.

Andy

[the_rock]

Hey @Boaz_Orshav 

Just emailed you the logs.

Cheers,

Andy

[Steffen_Appel]

After upgrading to T25, we had drops from PSL:WS :

@;26670169.44;[vs_0];[tid_1];[fw4_1];fw_log_drop_ex: Packet proto=6 10.x.x.x -> 10.x.x.x:8403 dropped by fwmultik_process_f2p_packet_inner Reason: PSL Drop: WS

Downgrading to T19 resolved it again.

[HadiFrohar]

@Steffen_Appel what kind of traffic is this? this is most likely because of

PRJ-58460, PRHF-37149

Application Control

Web protections may not properly block HTTP requests without a Host header.

Feel free to email me at hadif@checkpoint.com and I’ll be happy to take a closer look.

[the_rock]

@Steffen_Appel ...I had 2 customers install that jumbo, no issues in 2 days. Not sure if problem you are facing could be random one, maybe?

Andy

[Steffen_Appel]

@HadiFrohar It was backup traffic.

[Wolfgang]

@Steffen_Appel we see the same behavior after installing R81.20 and Jumbo take 99. All backup jobs (Commvault) did not run after this Jumbo. We added an exception in the "Inspection Settings" of the policy for all Backupservers to get it working.

[Steffen_Appel]

@Wolfgang Which exception did you set? I managed to get it working with mo protecction rules for teh backup server under R82, but the same rules do not work under R81.20

[Steffen_Appel]

@Wolfgang r81.20 required exceptions in the inspection settiongs

[Wolfgang]

@Steffen_Appel we made it simple. Adding an exception for all protection with our backupservers as destination like shown here.

[the_rock]

@Wolfgang That seems like a totally logical approach to me.

Andy

[Chris_Atkinson]

PRJ-57317, PMTR-108735

Threat Prevention

UPDATE: Improved Threat Prevention Blades performance by 15%-25% on Quantum Force 9000, 19000 and 29000 appliances.

See also: https://community.checkpoint.com/t5/General-Topics/Quantum-Force-performance-boost-is-available-post...

[genisis__]

Andy,

Just rebuilt by VSNext lab and installed JHFA25, heres what I get:

# cpinfo -y fw1

This is Check Point CPinfo Build 914000250 for GAIA
[FW1]
HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_R82_JUMBO_HF_MAIN Take: 25
HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE
HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE
HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_AUTOUPDATE
HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
HOTFIX_INEXT_NANO_EGG_AUTOUPDATE
HOTFIX_GOT_TPCONF_AUTOUPDATE

FW1 build number:
This is Check Point's software version R82 - Build 005
kernel: R82 - Build 005

[the_rock]

@genisis__ 

Mine looks more less the same, except public_cloud line.

Andy

[Expert@VSNEXT-s01-01:0]# cpinfo -yfw1

This is Check Point CPinfo Build 914000250 for GAIA
[FW1]
HOTFIX_R80_40_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_R82_JUMBO_HF_MAIN Take: 25
HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE
HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE
HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE
HOTFIX_UCA_INFRA_AUTOUPDATE
HOTFIX_INEXT_NANO_EGG_AUTOUPDATE
HOTFIX_GOT_TPCONF_AUTOUPDATE

FW1 build number:
This is Check Point's software version R82 - Build 005
kernel: R82 - Build 005

[Expert@VSNEXT-s01-01:0]#

[genisis__]

I just did something by mistake and it concerns me,  I just managed to delete VS0 from the GUI after installing a policy, and the policy giving it the wrong name. Seems to have come back after a reboot but still with the wrong name.

Can you try deleting ID0 which I assume is VS0? and its annoying that I cannot push a policy to the VS0 unless I define more then one interface.

[the_rock]

What is fw stat showing? I could try that in the lab, but I really prefer not to, as lot of people use my CP labs...sorry mate : - (

Andy

[genisis__]

Here what I see in the GUI:

CLI reports correctly:

[Expert@FW-s01-01:0]# fw stat
HOST POLICY DATE
localhost FW 21Jun2025 19:49:33 : [<Sync] [>wrp0] [<wrp0]

[genisis__]

so my big concern is that I was even allowed to delete ID0/VS0, surely you should not be able to do this?

[the_rock]

Will check tomorrow.

[genisis__]

I managed to screw up the magg1 interface, again does not seem to be any protection.  I'm rebuilding the firewall now.

[the_rock]

I did that once, had to rebuild.

[genisis__]

So if I'm correct its possible to delete VS0 and break magg1,  I think Checkpoint need to look into this and ensure protection is in place so that these elements cannot be deleted or moved, unless there is a SK to recover?

[the_rock]

Thats exactly what happened to me before in the lab.

[the_rock]

@genisis__ 

Since this was really bugging me and I wanted to verify it for myself, I did more less same setup like what you sent in the screenshot and yes, had to do the rebuild as well. Not sure if there is any way around it, but maybe someone from CP can confirm.

Best,

Andy

[genisis__]

I'm glad it was an issue that could be replicated, and I'm of course concerned that something like this could be done.  Checkpoint please take a look and resolve.

- Should not be able to delete ID0 > VS0

- Should not be able to assign magg1 to another virtual device as this should be fixed to mgmt-switch (vs500).

- Deleted virtual-gateway from GUI in my lab, after creating this through gclish. Node crashed and created crash files (ticket raised with TAC for this)
Note:  I've experienced these issues in a VM build off Proxmox.  I cannot say the issues observed happen on appliances.

[the_rock]

@genisis__ 

I totally agree with first 2 points. 

Andy

[Chris_Atkinson]

@genisis__ I would recommend starting a new thread for this line of discussion for proper visibility and please flag with your local SE, PS/ATAM or Diamond engineer for follow-up. 

[genisis__]

Is there a specific R82 ElasticXL/VSNext thread?