- Local User Groups
R80.40 EA Program
R80.40 features centralized management control across all networks, on premise or in the cloud, lowering the complexity of managing your security and increasing operational efficiency. As part of the Check Point Infinity architecture, R80.40 provides customers with the best security management, utilizing the Industry’s largest integration of technologies from more than 160 technology partners. With Check Point R80.40 Cyber Security for Gateways and Management, businesses everywhere can easily step up to Gen V.
• We are looking for R80.X / R77.X Production environment to evaluate the new version.
• Start date: Started
Public EA (for Lab/Sandbox use) is now also available!
Additional questions? contact us@ EA_SUPPORT@checkpoint.com
A new IoT security controller to:
TLS Inspection Layer
This was formerly called HTTPS Inspection. Provides these new capabilities:
The Management & SmartConsole are developed under my ownership, so I will try to answer:
1) It is definitely not OK that SmartConsole needs to be manually installed and uninstalled for getting fixes / updates. In the past when updates were infrequent, it may have been reasonable, but not today with the jumbo updates.
2) It is not OK that preferences are lost when updating SmartConsole.
3) We had some delays with the updatable SmartConsole development (mainly due to other high priorities that came in), so we are behind schedule for sharing it with the field during 2019. However, we are not waiting for the release of R80.50. The plan is to release another flavor of SmartConsole that will be auto-updatable during Q1. We will release it to versions that are already GA (such as R80.40 and R80.30). The new package will be available in parallel to the existing one, and customer will be able to choose the new flavor early if they wish.
Will the new 3.10 kernel be required for R80.40 gateways, or will 2.6.18 still be supported?
1. Right now R80.40 comes only with kernel 3.10 which means that all modes are supported (gw, mgmt, standalone).
There should be dramatic event that will make us decide to go back to old linux flavor
2. What do you mean “no luck”? We are starting the EA deployments more extensively this week. You had no luck in getting the ea? No luck in running stand alone ? other?
I assume that the EA team can assist you if you werent able yo use it but if we miss something, we are open to get feedback and improve
We are in a process of replying to all R80.40 EA enrolments. Please reply my private message so I can have your details and check it out for you.
The Public EA program is about to start soon. Once started - you will be able to use your User Center's credentials and download R80.40 files.
You are also very welcome to join our Production EA program, which includes an EA engineer on site and full EA support. I'll be happy to introduce you with this program.
No SAML for remote access VPN yet? Any idea when integration with 3rd parties like OneLogin will be available?
The new clustering options look great for enterprises with egress points in multiple geographically disparate datacenters. I assume state-synchronization will now work via Layer 3 so packets can egress either datacenter via routed links and not get dropped as out of state?
I also though a GUI based backup solution would now in R80.40 for Provider-1 so that you can backup individual CMAs?
It would be nice to see a complete list of new features and resolved issues.
The capability to back up individual CMAs was added in R80.40.
It is easily used via CLI and we've also added REST API for it, since many customers wanted to automate it.
The UI didn't make it into this release and we'll look to add it in the next one.
Large part of the mobile access blade is part (and integrated inside) the access policy since the r80x first releases, just like data awareness is in the access policy now (while still having independent DLP policy option).
We keep also full independent policies for compatibility purposes and because some ppl want to separately edit them while the “integration” is done by running the needed functionality inside the same policy and this is available from the first R80 policy.
There is no active plan to further change the “independent policies” (they are given as they are). If there are needs on the main access policies or if the are bugs in the “independent policies”, they can be discussed with the product teams.
TLS remains separate-edit due to its nature and therefore, went thru rewrite in R80.40 to have it more integrated while still having it outside of the main policy.
Is this also applicable for VSX?
Let me be clearer on this - MVC for VSX works (and since it's planned to be enabled by default VSX customers who upgrade their environment will use MVC), however, changing the policy after the environment is already in multi-version requires the installation of the policy twice - both with the new version and the old one. While in standard cluster this is an easy operation, in VSX it requires the use of VSX util downgrade to change the VSX object to the old version before the installation, this util is not officially supported.
So the statement is that MVC for VSX has a limitation of changing the policy after the cluster runs in multi-version. We are currently working on making the VSX util downgrade to be supported officially but we cannot say if it will be available for R80.40 yet.
Guy Elyashiv | Group Manager – Clustering & Multitenancy
Do we know if support for different hardware appliances in a cluster will be supported?
VSX Cluster with x2 12400's, at some point these will be end of life, so if we want to then replace the hardware without major work it would be really good if we can as an example run a mixed set:
x1 12400, x1 15600, then to x2 15600 as an example.
At this point, its my understanding that a cluster must have the same identical hardware.
The main issue with mixed HW cluster is the difference in number of CPUs (that affects the number of FW instances).
As we already resolved the limitation of synchronizing connections from an appliance with lower number of instances towards an appliance with higher number of instances we can say that as an upgrade procedure using CU (Connectivity Upgrade) it can work and all connections will be synchronized.
This, however, will be less effective with MVC which synchronize connections both ways, so once the active member is the appliance with the higher amount of instances it will fail to synchronize some of the instances towards the standby member with the lower amount of instances.
"Support for BitLocker encryption for Full Disk Encryption."
Does anyone have any more details on exactly what Bitlocker support will be included?
I have a customer with Bitlocker on 700+ laptops and I'm trying to get them on to Check Point FDE. It's going to be a long slow migration. So what can Check Point 'do' with the existing Bitlocker laptops in the mean time?