Check Point Quantum Titan R81.20 has been released !

[Hen_Hertz]

We are happy to announce that Check Point Quantum Titan R81.20 has been released TODAY!

Quantum Cyber Security Platform Titan Release R81.20 delivers significant innovations in Advanced Threat Prevention, Security Management, and Security Performance.
With the release we introduce  three new software blades that leverages artificial intelligence (AI) and deep learning, to deliver advanced threat prevention against advanced domain name system exploits (DNS) and phishing, as well as autonomous IoT security.
In addition, Check Point has expanded on-premises and cloud network security through new and upcoming advanced cloud-based Check Point applications and services.
By upgrading to R81.20, these new cloud-based applications offer powerful feature upgrades on Check Point Security Gateways, without requiring an upgrade to the next software release.

With R81.20, customers immediately benefit from a wide range of new security capabilities across four major categories:

• Deep learning Threat Prevention 
• Quantum IoT Protect
• Network Security Management
• Performance Acceleration for Quantum Security Gateways

For “What’s New”, Release Notes and more information, please refer to R81.20 Home Page  [sk173903]
Check out our main product page
R81.20 webinar here!
R81.20 partner webinar here! (pass: 7G+Xzs#S)

See also the TechTalk on CheckMates: https://community.checkpoint.com/t5/General-Topics/What-s-New-in-R81-20-TechTalk-Video-Slides-and-Q-... 

This release is available for customers who are interested in implementing the new features.
We will make it the recommended version after significant adoption. It will then be available in the 'Showing Recommended Packages' section in the CPUSE tab in Gaia portal. 
Check Point will be monitoring the adoption of the release closely as well as any issues that may arise.

Please feel free to reach out to us with any feedback or questions

Best Regards
Release Operations Group

[the_rock]

Dont see iso image for R81.20 for esxi, and also, upgrade wizard does not show it anywhere.

Cheers,

Andy

[Tobias_Moritz]

The link is on the  R81.20 Home Page  [sk173903]. Here is the deep link for the iso file:

https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/m...

[the_rock]

found it tx 🙂

[PhoneBoy]

See also our recent TechTalk on CheckMates on R81.20: https://community.checkpoint.com/t5/General-Topics/What-s-New-in-R81-20-TechTalk-Video-Slides-and-Q-... 

[jdoe1979]

Does it support Gaia Fresh Install and upgrade ?
Is it recommended?

[Hen_Hertz]

Hello ! 

Of course we support Fresh Install and upgrade. 

Please follow the instructions in sk173903 , under installation section. 

We are here for any further question and feedback. 

Best Regards,

Hen. 

[_Val_]

@jdoe1979 R81.20 is not a recommended release just yet.

[RamGuy239]

Lovely. Any ETA on when the OVA images for VMware ESXi deployments are going to be released?

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

I remember back when R81.10 went GA there were links for OVA files available before sk158292 got updated. But it's difficult to find the links without them being referenced in sk158292.

I have always preferred to use VMware ESXi OVA images over ISO. Check Point has never been able to really describe the difference between using the OVA image compared to installing using ISO. But I've noticed some small differences and tweaks such as the grub configuration has been preconfigured with a small boot delay making it much easier to interrupt boot in order to access maintenance mode. When installing using ISO it set itself to 0 sec for the delay making it rather difficult to enter the boot menu unless you are smashing your keyboard like crazy when rebooting the host.

I've also been told by TAC in the past that in order for VMware installations to fully support vMotion the use of the OVA image is required. But I have yet to pinpoint anything specific that seems different when using OVA over ISO confirming this. I can find some vague references to something about this back in R77.xx documentation, but nothing on R8x.xx.

But since there are so few specifics on what the differences are, I simply opt for OVA as I suppose if there are indeed various differences between the two, like the change to the boot delay, it would make logical sense for the OVA that is made specifically for VMware ESXi deployments to offer the best optimisation for such installations compared to using the ISO.

Back in the day when I was deploying on Nutanix AHV, this was using R80.30 with 3.10 kernel, the ISO would enforce the use of legacy IDE for the disk controller, the only way for it to work with SCSI controller with better IOPS was to grab the OpenStack / Nutanix AHV / KVM qcow2 image from sk158292.

[Martin_Valenta]

will there be JHF for r81.10 management to manage r81.20 gateways or not? we do have MDS setup with 700 + gateways so upgrading MDS to r81.20 will be possible after few r81.20 JHF's..

[_Val_]

@Martin_Valenta according to sk113113, yes, there will be R81.10 JHF to manage R81.20 GWs. 

[Duane_Toler]

Congratulations to everyone in R&D, Documentation, Release Teams, and everyone else for getting this together!  I'm looking forward to rolling this out!  I know a ton of work went into this and I've been waiting patiently, albeit eagerly, for it!

Kudos to all!

[jdoe1979]

@_Val_  I meant if the new release supports Gaia Fresh Install and upgrade installation method.
The release page instructs to use Blink packages while the documentation lists both.

[PhoneBoy]

Yes @jdoe1979 both methods are supported.
The ISO is provided for a fresh install.
CPUSE methods are provided for both fresh install and upgrade.

[Hen_Hertz]

@RamGuy239  - OVA/OVF for ESX. Will be published by end of week / early next week.

Best Regards 

Hen. 

[Daniel_]

Less then two years support for a new Check Point Release?
https://www.checkpoint.com/support-services/support-life-cycle-policy/#gateway-management

We need more then one year to update all our systems. So we need R81.30 (or whatever is next) in a half year as recommended version...

[_Val_]

@Daniel_ I think this deserves a separate post, discussing this subject in this particular thread is not really handy.

[Daniel_]

I have started a new topic
https://community.checkpoint.com/t5/General-Topics/Less-then-two-year-support-for-R81-20/m-p/163138

[RamGuy239]

I did upgrade our own Check Point environment from R81.20 EA to R81.20 GA, and one of our customers to R81.20 GA (from R81.10) and it's been solid thus far. Zero curveballs are thrown our way.

Both environments are running three VMware ESXi hosts, one for management, another for logs and a third for Smart Event. All six were upgraded without any issues. In our own environment, we had to use the regular CPUSE package "Check_Point_R81.20_T627_Fresh_Install_and_Upgrade.tar" as the blink package (blink_image_1.1_Check_Point_R81.20_T627_SecurityManagement.tgz) didn't allow us to upgrade as we were already running R81.20 EA T570 so it thought we were blinking ourselves to the same version we were already running and that wasn't allowed. Installer upgrade using "Check_Point_R81.20_T627_Fresh_Install_and_Upgrade.tar" was allowed.

The customer was running R81.10, there we successfully upgraded using the "blink_image_1.1_Check_Point_R81.20_T627_SecurityManagement.tgz" package on all three management installations.


Same story for our CPAP-SG3600 HA-cluster. Wasn't allowed to use the "blink_image_1.1_Check_Point_R81.20_T627_SecurityGateway.tgz" as our gateways were already running R81.20 EA Take 570. But using the "Check_Point_R81.20_T627_Fresh_Install_and_Upgrade.tar" worked just fine.

Our customer was running CPAP-SG16200 appliances, there I used the HTML5 LOM (HTML5 LOM is a true blessing!) and did an ISO clean install in order to get the new NIC firmware for the i40e network cards on the appliances. This also worked out great and HyperFlow is enabled by default and seems to be working wonderfully thus far.

In Q1 2023 I'm going to upgrade some Maestro deployments. That is going to be interesting, the upgrade from R80.20SP to R81.10 was rough, but the documentation and process seem to be much better with R81.20. But I did noticed this in the known limitations:

Multi-Version Cluster (Zero Downtime) method does not support these operations if a Security Group has Bond interfaces in the 802.3ad (LACP) mode:

Upgrade of a Security Group from R81 to R81.20


This sounds rather unfortunate. Who doesn't utilise LACP for the TRUNK on Maestro? But it does mention R81 and not R81.10 so hopefully, this won't be an issue when moving from R81.10 to R81.20 on Maestro. Nice to have Multi-Version Clustering, making it possible to do a zero downtime upgrade. The upgrade from R80.20SP to R81.10 was certainly not zero downtime, that's for sure.


Huge thanks to RnD and everyone involved!

[jdoe1979]

For DNS security blade in the manual it mentions that it only kicks in with URL filtering.
So it doesn't apply to non-web traffic?

[genisis__]

if we have R81.10 (with JHFA78) installed and don't require new features, what would be a good reason to install R81.20?  I ask this question to understand from a technical/commercial view of what my driver would be, ie stability/fixes etc?

[Magnus-Holmberg]

Honestly I though check point would highlight skylane as it’s potentially a huge improvement of monitoring of check point products and it deserves to be highlighted in a release like this even if it’s back ported to older releases.

[PhoneBoy]

@jdoe1979 there are a couple ways DNS queries can be “blocked”

• The actual DNS request goes through the gateway (requires Anti-Bot and/or Anti-Virus)
• We can see the request in an HTTP Header (i.e. web traffic, requires either App Control or URL Fitering)

This was the case prior to R81.20, anyway. 

[linuz]

Hello,

Under the Harmony Endpoint section, it says "Exclude SaaS applications (such as Office 365) from the Remote Access VPN tunnel."

Is this feature available only on Harmony, or can we use it with the remote access VPN client as well?

Thanks.

[RamGuy239]

@Hen_Hertz Still no OVA files for R81.20 in sk158292. Eagerly awaiting those as I have a customer for whom we have to do some maintenance on their management server, and we are postponing it until OVA is ready so we can move the management from R81.10 to R81.20 while we are at it.

EDIT: I can see that the images were made available in sk158292 today! 🙂

[RamGuy239]

@Hen_Hertz Seems like there have been some fundamental changes with the R81.20 management OVA compared to the earlier versions. Normally the default login has been admin/admin. But using R81.20 OVA, I'm unable to log in using admin/admin is not working. Not entirely sure what I'm supposed to try using. The SK does not mention anything.

[RamGuy239]

@Hen_Hertz Did a test some more, and it doesn't seem like anything applies using the R81.20 MGMT OVA at all. Even if I try to pre-define IP and password, it doesn't seem to get configured. Using the R81.20 GW OVA and the IP will get configured, but seemingly not the admin password. Even when setting passwords during the OVA deployment process, I cannot log in. Normally I don't define anything and configure everything using the VMware console after deploying the host, but the usual admin/admin login is not working, so I'm not able to logon using the console. Therefore I decided to try to use the OVA template in VMware ESXi to pre-define my password, but still no dice.

I've used OVA/OVF for R80.10, R80.20, R80.30, R80.40, R81 and R81.10 for both MGMT and GW, and I have never had this issue before. Are these OVA images working as intended?

[the_rock]

Hey @RamGuy239 . Interesting you say that, because I noticed with other major vendors, those things get populated 100% of the time, but never tried it with CP though.

[RamGuy239]

@the_rock I have avoided using the template to pre-define settings as it tended to autorun the first-time-wizard on management installations and configure it as standalone (GW+management), and I don't want that. So I've just used the OVA to get the host deployed adequately on VMware ESXi and done all the Gaia configuration manually afterwards.

On GW deployments, I've used it on multiple occasions. Its quite lovely as it makes it so easy to predefine your interfaces, admin password, SIC key etc. I would use it for management deployments as well if it weren't for that strange behaviour where it automatically runs the first-time-wizard and selects the installation to be gateway + management instead of a dedicated management installation.

When not defying anything, the host usually uses 192.168.1.1/24 and admin/admin. But with the R81.20 OVA, this no longer seems to be the case. And as the SK is not mention anything regards to the default login and admin/admin is not working I'm rather confused about how I'm supposed to log in.

To bypass this issue, I tried to utilise the template for me to have a pre-defined admin password, but the admin password is certainly not being changed to whatever I define.

[RamGuy239]

With OVA images not playing along, I did some testing using R81.20 ISO on VMware ESXi. R81.20 ISO does support installation on UEFI, and it does support the use of the VMware Paravirtual controller. Can't locate anything in the documentation mentioning this. The SK for recommendations regarding VMware ESXi installation is rather old (sk104848) and doesn't mention any of this.

Do we have any official feedback from Check Point on this one? Supporting UEFI is a significant improvement for both virtual and especially open server installations. VMware Paravirtual should make noticeable improvements to IOPS with less overhead on VMware installations. I can't see any reason not to opt for VMware Paravirtual unless some unknown issues should be mentioned by Check Point on this topic.

[Amir_Senn]

Hi,

I made some emails today and it looks like sk104848 is updated.

Some preparation were started in the background but VMware Paravirtual controller and UEFI are not yet supported.

Maybe some things have worked but you might encounter operations that are not supported and could cause issues if used.

[Itay_Sharim]

@RamGuy239 - R81.20 cloud images are provided without User/Password and accept only SSH key by default. The OVA provided is required to be deployed with vSphere and not with ESXi directly.

Can you confirm which way you used to deploy the OVA?

In addition, R81.20 includes additional properties through cloud-init automation. Please see sk179752 for more info on available attributes.

[RamGuy239]

@Itay_Sharim I'm deploying it the same way I've been with R80.10, R80.20, R80.30, R80.40, R81 and R81.10. On Center, I chose Deploy OVF Template, select the OVA/OVF image and click next-next-next. The host gets created. I make changes to CPU, RAM and add an additional thick provision hard drive for expanding lv_log. Once it boots, I usually log in using the VMRC console (using admin/admin), set a different password, change the shell to bash, and set the IP address and default GW.

Jump over to SSH, and transfer a copy of the Gaia configuration of the old management host and the database. Print the Gaia config onto it, run first-time-wizard, and import the database. Mission accomplished. I, of course, have to make the additional hard drive available within LVM and expand lv_log via maintenance mode.

I'm not entirely sure what you mean by deployed with vSphere and not within ESXi directly? I'm not 100% on the terminology here, but when connecting directly to an ESXi server using WebUI, you run vSphere in HTML5. Not sure how you would deploy OVA/OVF on VMware ESXi without utilising vSphere, to be honest. When using vCenter is the same thing. You are using a centralised HTML5 WebUI, bringing together multiple ESXi servers.

Seems like my process is no longer supported as the R81.20 images any longer allowing for username+password login by default? So it forces me to use the templating to predefine my settings? What's funny is when I do apply settings, I end up with the following error, and nothing is being applied:

| Your cloud-init configuration is corrupt or contains error:

|  Provided YAML file contains one or more errors:

| Error in function _compare_to_schema:

| YAML is not compatible with provided JSON schema:

| 1: '' is too short

I suppose what I need to do for this to work is to apply my SSH key. This makes the entire process needlessly tedious. This will make me able to predefine the IP and SSH keys. Log on using SSH, restore configuration and then be able to access the VMRC console using username and password. I will give this a try to see if I'm able to do this successfully. But our primary use of the VMware ESXi images is for advanced upgrades of VMware ESXi installations. Get new hosts going using new images, and copy the Gaia configuration and database (or just the Gaia configuration when it's a gateway). Being unable to log in using the VMRC console after deploying and having to predefine various settings when all these settings are dumped onto the host by running clish -f config -i -s is just causing more friction to the entire process.

[Magnus-Holmberg]

Could you please update sk79700 so we know supported features of VSX for R81.20 if they have changed any.

[MeravAlon]

@Magnus-Holmberg  

Done. sk79700 was updated. Thanks for your feedback

Merav

[Arend]

Hi,

Aviv Abramovich mentions the percentages of zero-day attacks not being known by other players in the industry.

I like to know what sources are being used to check if a zero-day phishing or zero-day DNS signature is already being spotted by other players in the industry then Check Point?

Any idea?

[the_rock]

@Arend Thats super valid point. In all honesty, every time I attended conferences for different vendors, I always asked myself where they actually pull out info like this, but of course, they would never tell you...but I believe customers deserve to know, just my personal opinion.

Andy