Skip navigation
All Places > CloudGuard IaaS > Blog

CloudGuard IaaS

9 posts

We are happy to update on the availability of R80.20 Security Gateways (based on new Linux kernel) and R80.20 Security Management in GCP.

 

Both BYOL & PAYG solutions are updated with the new version and ready for deployment through the GCP marketplace:

https://console.cloud.google.com/marketplace/browse?q=cloudguard

 

As always we are here for your comments and suggestions,

CloudGuard IaaS R&D 

I've been asked several times about if CloudGuard is a WAF product (that's another discussion!) and how best can a dedicated WAF service be placed in front of CloudGuard IaaS gateways. As all the requests came from customers using Microsoft Azure, I decided to look into the Application Gateway.

 

In short, the Application Gateway is basically a "load balancer on steroids" and provides much the same functionality as a standard SKU Azure Load Balancer, but with the added benefit of WAF capabilities. As our reference architecture in Azure uses a load balancer and one or more gateways, this seemed the obvious choice for the deployment.

 

I wrote a lab guide to deploying this solution, as with most cloud topics, it will age very quickly, but hopefully give you a good starting point if you have a project that has strict requirements on having a WAF service at the Azure perimeter. It's very much a first draft, so there will be mistakes and also outdated information, please provide any feedback below.

 

Note this is not official Check Point documentation or advice, deploy this solution at your own risk. No warranties implied, may contain nuts. Check Point are not responsible for any service charges accrued by this deployment. The value of investments may go down as well as up.

Hi Everyone,

 

We are glad to announce that R80.20 Gateway with new Linux kernel is now generally available in Azure & AWS.

 

The new image offers significant improvements:

 

Important

  • R77.30 based solutions will be removed soon from the marketplace.
  • For specific exceptional cases where R77.30 is needed, please contact Check Point TAC.
  • Only standard deployment is supported for single R80.20 gateway. Standalone and custom configuration modes are not supported.
  • In order to manage R80.20 gateways using R80.10 Management Server JHF take 177 or later must be installed.
    See sk116380 for more information.

 

 

Performance

 

 

AWS

For R80.20 gateway:

 Maximum Throughput (Mbps)Maximum Throughput (Mbps)Maximum Throughput (Mbps)
AWS Instance Typec5.largec5.xlargec5.2xlarge
Number of cores248
CPEnt - NGFW260040554065
CPEnt - NGTP104018903400
  • Tested with Cloud-Certified leading testing equipment
  • Used AWS on-demand instances environment
  • Actual performance results may vary depending on cloud infrastructure resources availability, region, topology, and other factors
  • These results are based on actual performances measurements by Check Point performance lab using real-world traffic simulation with out-of-the-box configuration

 

Azure

For R80.20 gateways:

 Maximum ThroughputMaximum ThroughputMaximum Throughput
Azure VM sizeD2_v2 (2 core)D3_v2 (4 core)D4_v2 (8 core)
CPEnt - FW + IPS132025404890
CPEnt - NGFW132025354790
CPEnt - NGTP123525303985
  • Tested using default deployment and Check Point configurations.
  • Tested with Cloud-Certified leading testing equipment
  • Actual performance results may vary depending on cloud infrastructure resources availability, region, topology, and other factors
  • These results are based on actual performances measurements by Check Point performance lab using real-world traffic simulation with out-of-the-box configuration

 

Notes:

-          For different VM sizes see: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-sizes/ 

-          Performance can be limited by the network bandwidth allocated by Azure to the VM

-          NGFW:  FW + IPS (Recommended - out of the box) + APCL

-          NGTP: NGTP : FW + IPS (Recommended - out of the box) + APCL + URLF + AV + AB

 

 

AWS Solution templates update

All deployment options (Single Gateway, Cluster, Auto Scaling Group and Transit VPC) are supported and can be deployed using our CloudFormation templates.

 

 

Azure Solution templates update

 

The following marketplace offers have been renamed:

  • Check Point CloudGuard IaaS R80.10 Scale Set à Check Point CloudGuard IaaS Scale Set (as it supports both R80.10 & R80.20).
  • Check Point CloudGuard IaaS R80.10 High Availability à Check Point CloudGuard IaaS High Availability (as it supports both R80.10 & R80.20).
  • Check Point CloudGuard IaaS Cluster à Check Point CloudGuard IaaS R77.30 & R80.10 Cluster (as it supports only R77.30 & R80.10).

 

 

The new image is supported by the following solutions:

  • Check Point CloudGuard IaaS Single Gateway
  • Check Point CloudGuard IaaS High Availability
  • Check Point CloudGuard IaaS Scale Set

 

This version will be available on OCI & GCP Marketplace, soon.

 

As always we are here for your comments and suggestions.

CloudGuard IaaS R&D 

Hello Everyone,

 

We are glad to update on the release of R80.20 Service Registration bundle for CloudGuard for NSX-V.
Release highlights:

  • R80.20 Management and R80.20 M2 support in service registration and provisioning
  • R80.10 CloudGuard Gateway is now aligned to the R80.10 jumbo hotfix Take 154 with security fixes and updates
  • Improved OVF capabilities (Larger log partition size, Support of Virtual Machine Compatibility Settings…)
  • Improved automatic license distribution
  • Important bug fixes
  • NSX 6.4.x support

 

 

Stay tuned for NSX-T news and make sure to visit our tech room at CPX for more info and demos on our upcoming solutions!

 

CloudGuard IaaS R&D

Hello,

 

We are happy to update that we released R80.20 Management Server in AWS.

It can be deployed using our CloudFormation template for Security Management Server:

 

The R80.20 Management Server is available as BYOL and PAYG for managing 5 GWs and can be deployed on the AWS M5 Instance Type Family.

 

R80.20 Gateway with new Linux kernel will come soon.

 

As always we are here for your comments and suggestions.

CloudGuard IaaS R&D

Hello Everyone,

 

We are happy to update that AWS recently announced their new Security Hub (preview) service and CloudGurad for AWS was declared as one of the Launch Partners.

Customers can enable CloudGuard integration from the Security Hub Console and CloudGuard will send its findings (logs) to the new AWS service.

Detailed configuration steps available here.

 

You are welcome to watch and share the movie we created to emphasize the integration.

 

Note: The integration is currently supported only on R80.20 Management Server deployed in AWS.

 

As always we are here for your comments and suggestions.

CloudGuard IaaS R&D 

CloudGuard IaaS R&D is proud to announce our R80.10 CloudGuard Controller Hotfix 1 release over JHF take 154.

The HF is now available to install on top of JHF take 154 in addition to JHF take 70.

 

R80.10 CloudGuard Controller Hotfix 1 offers the following features on top of the CloudGuard Controller built-in to R80.10:

       Integration with Google Cloud Platform

       Integration with Cisco ISE

      Integration with Nuage Networks VSP

       Major upgrade support from R77.30 to R80.10

       Automatic license management with the CloudGuard Central Licensing utility

       Monitoring capabilities integrated into SmartView  

       CloudGuard Controller support for Bladed Systems: 64000, 61000, 44000, 41000

       SmartConsole UI improvement

 

Customers who already upgraded to R80.10 M1 / R80.20 GA can take advantage of all these features using the built-in CloudGuard controller (no HF installation required).

 

Refer to sk120464 for download and installation instructions.

 

As always we are here for your comments and suggestions.

CloudGuard IaaS R&D 

Hello Everyone,

 

In an effort to improve customer awareness and add visibility to our announcements regarding feature releases, I'll be posting blog entries whenever we have an exciting new feature.

 

Hopefully, this will both be a good source for you to find out about exciting new features, as well as a platform for you to give us some direct feedback about those new releases.

 

I'll start with a few recent announcements (and possibly repost some older ones just in case there are readers who missed them), and going forward I'll be posting about new releases as they are announced.

 

Edit: I'll publish all other posts under my personal Blog CloudGuard IaaS Announcements 

Hi, a customer challenged me to replace an ailing member of a cluster with a brand new one. here are the steps:


(This was tested on an  R77.30 cluster Afand R80.10 management server)

We assume that we have a cluster where in azure, the names of the cluster member VMs are CL1 and CL2. The name of the resource group is CLrg. We want to remove CL2 and replace it with a new member of the cluster. The steps are

 

  1. From Azure, delete all the resources in the CLrg resource group that are part of CL2, (all these resources’ names will begin with CL2. They include the VM, IP address, disks, vNICs)
  2. From the Azure portal record the ID of the availability set of the cluster (you’ll find it under “properties” of the availability set, in the CLrg resource group.)
  3. From Azure, using some new resource group, go through the motions of creating a single gateway (using the single gateway template). For all the parameter values you enter, make sure you adhere to 6.b-6.g below.
  4. After the verification, but before you deploy, you have a chance to download the template. Download it.
  5. Edit the template file you downloaded by adding the “availabilityset” key/value to the “properties” of the “virtual machine” section of the template. It should look like this:
  6. Use your favorite tool (e.g., powershell) to deploy the modified template but note the following
    1. Deploy to the same resource group as the cluster
    2. The VM name must be the exact same name as the VM you deleted (in this vase “CL2”)
    3. The version must be the same as the cluster
    4. The license must be the same as the cluster
    5. The installation type must be “gateway”
    6. The machine type must be the same as the cluster members
    7. The Vnet must be the same existinig vnet and the subnets must be the same subnets as the other cluster member
  7. Verify that the template was successfully deployed by looking, in the Azure portal, at the members of the availability set. The new member should be there
  8. Prepare the gateway to be clustered. SSH into the new gateway and
    1. cpconfig--> (6) Enable cluster membership for this gateway
    2. Reboot
    3. Copy the HA config file from the member that’s still on the cluster. In R77.30 the following command should do it (assuming the access policy allows it!) by scp from the new gateway to the existing gateway
      1. scp admin@<ipaddressofexistingmember>:/opt/CPsuite-R77/fw1/conf/azure-ha.json /opt/CPsuite-R77/fw1/conf
    4. Reconfigure the configuration using the commands
      1. azure-ha-conf --client-id <client id> --client-secret <client secret> --force
      2. $FWDIR/scripts/azure_ha_cli.py reconf
    5. Add the required routes to the new gateway (the same routes you added originally to the cluster members) 
  9. From SmartConsole
    1. Remove the old member from the cluster
    2. Publish
    3. Add the new gateway as a cluster member
    4. From network management, Get interfaces on the cluster
    5. Publish and push policy to cluster
  10. Test failover