The article assumes that you have a basic expertise with:
The Google Cloud Platform and specifically Google Compute Engine.
Check Point CloudGuard IaaS Security Gateway and Security Management Server.
If deploying a Single Gateway solution doesn't fit your needs, Checkpoint offers additional cloud solutions in GCP including Managed Instance Group and High Availability.
This reference architecture illustrates how one can protect resources deployed in Google Cloud Platform using Check Point CloudGuard IaaS Security Gateway.
A common use case involves a web application environment deployed in a virtual network in Google Compute Engine.
The web application can consist of multiple tiers, such as a Web tier and an Application tier.
The traffic flows in this environment normally consist of:
Traffic arriving from the Internet to the Web tier.
Traffic between the Web tier and the Application tier.
Traffic between the environment and an on-premises network for administration and backend services.
Outgoing connections from the environment to the Internet for software updates and access to external web services.
Roaming users' remote access connections to the environment.
From a security perspective, these traffic flows should all be inspected and governed by the same security policy enforced elsewhere by the organization.
These security controls should include:
Access Control (Firewall).
Logging.
Application Control.
Intrusion Prevention (IPS).
Advanced Threat Prevention.
Site-to-Site VPN (for communication with the on-premises network).
Remote Access VPN (for communication with roaming users).
Network Address Translation (for Internet bound traffic).
Any one of the zones offered by GCP (e.g. us-east1-b, europe-west2-a etc.)
us-central1-a
Machine type
Any one of the machine types listed, depending on your needs
n1-standard-4
Network
An existing VPC
Subnetwork
An existing Subnetwork under the selected VPC
Only subnets that are in the same Zone as the machine are listed
Firewall rules
All firewall rules are checked off
By default, if no rules are created, incoming traffic will be blocked
External address type
Static/ephemeral/none
Static
Installation type
One of the following solutions:
Gateway and Management (Standalone).
Gateway only.
Management only.
Manual configuration.
R81 Gateway only
See Comment #1
Disk type
SSD
standard
SSD
The type of disk used by the Check Point instance
Disk size
At least 100 GB
100
See Comment #2
Automatically generate an administrator password
Checked
Unchecked
Unchecked
See Comment #3
Allow download from/upload to Check Point
Checked
Unchecked
Checked
Automatically download Blade Contracts and other important data. Improve product experience by sending data to Check Point
Admin shell
/etc/cli.sh
/bin/bash
/bin/csh
/bin/tcsh
/bin/bash
Select the administrator default shell
Public SSH key for the user 'admin'
None
See Comment #3
SIC key
An empty string, or at least 8 alphanumeric characters
None
See Comment #5
Allowed GUI clients
CIDR notation
None
See Comment #6
The network, in which the managed Security Gateways reside
CIDR notation
0.0.0.0/0
See Comment #7
Additional network interfaces
No additional network interface will be created
see Comment #8
Comments:
Once the instance starts, it will set itself up automatically based on the installation type you have selected. The use of the Manual configuration installation type is discouraged as it will require you to manually perform additional steps, such as:
When installing a Security Management Server, this password could be used to connect to the Security Management Server using SmartConsole GUI clients.
Note this password will not work over SSH, as SSH password authentication is disabled by default.
By default, the instance will trust all instance level and project level public keys as explained here: https://cloud.google.com/compute/docs/instances/connecting-to-instance. To lock down access to the instance even further, you can enter here a specific SSH public key. If one is given, only the owner of the corresponding private key would be able to connect over SSH to the instance.
The Secure Internal Communication (SIC) Activation key needed to establish trust between the CloudGuard IaaS Security Gateway and its Security Management Server. If not provided and needed, then a key will be automatically generated.
Only used in Gateway and Management (Standalone) and Management only installations. Access to the Security Management Server over SSH, HTTPS and SmartConsole GUI clients would only be allowed from this address range.
Only used in Management only installations. Communication from gateways to this Management Server will only be allowed from this address range.
You should select networks and sub-networks for all network interfaces even if they are not used. The unused network interfaces will be ignored and will not be deployed. Google Compute Engine supports instances with multiple network interfaces, for more information how to configure CloudGuard for GCP with multiple interfaces refer to: sk121637.
By default, every Check Point Security Gateway and Security Management Server's WebUI is accessible from the internet by browsing to http://<virtual-machine-public-ip>. Restricting access to the WebUI is possible by configuring a Firewall Rule, or by configuring the Check Point Gateway and Management Server settings.
Click Deploy to start the deployment process. The deployment time will depend on installation type and is expected to complete in less than 10 minutes.
If a public address was not allocated, then the deployment will complete once the instance has started. Note that in such a case, you should wait a few more minutes until the first time wizard completes.
If a public address was allocated, then the deployment will be pending until the first time wizard has completed running, and the product is ready for use.
Once completed, you should be presented with a page similar to this:
Note that some variations on the below are possible depending on the deployment options you have selected.
Example:
The page will contain the following items:
Attribute name
Comment
External IP address
The CloudGuard IaaS instance public address.
Will only be presented, if External IP address of the primary (first) network interface was set to Static or Ephemeral.
Additional external IP addresses
List of additional external IP addresses.
Will only be presented if any of the additional External IP addresses was set to Static or Ephemeral.
Instance
A link to the instance in the Google Compute Engine console.
Instance zone
The zone, in which the instance was deployed.
Instance machine type
The instance machine type.
Admin user
The username.
Use this username to connect to the instance using SSH and the Web portal. Also, if this instance acts as a Security Management Server, then use this username to connect using the SmartConsole GUI clients.
Admin password (Temporary)
An automatically randomly generated password.
Use this password to connect to the instance's web portal. Also, if this instance acts as a Security Management Server, then use this password to connect using the SmartConsole GUI clients. Note that this password will not work over SSH, as SSH password authentication is disabled by default. This field will only be presented, if Automatically generate an administrator password was selected. We recommend that you change this password. To change or set the SmartConsole GUI clients login password, connect over SSH to the instance and run the 'cpconfig' command. To change or set the Gaia Portal login password, connect over SSH to the instance and run the 'set user admin ...' Gaia Clish command.
Secure Internal Communication (SIC) one time secret
The one-time SIC key used to establish trust between the CloudGuard IaaS Security Gateway and its Security Management Server. Will only be presented, if this Security Gateway is managed by an external Security Management Server.
In addition to the Check Point instance, this template will perform the following:
Allocate a public address and associate it with the instance (unless None was requested).
Create the following Google Compute Engine firewall rules for each configured network interface:
For a Gateway only, or a Gateway and Management (Standalone) deployment:
A permissive Google Compute Engine firewall rule allowing all traffic. The rationale for this is that the instance already enforces a Check Point security policy, and there is no need for a second security mechanism.
For a Management only deployment:
A rule allowing connections from the Check Point CloudGuard IaaS Security Gateways to the Security Management Server.
A rule allowing connections over SSH / HTTPS, with SmartConsole GUI clients to the Security Management Server.
For a Manual configuration deployment, no firewall rules should be created.
Tag the instance:
For a Gateway only installation type, the following tag would be added:
checkpoint-gateway
For a Management only installation type, the following tag would be added:
checkpoint-management
For a Gateway and Management (Standalone) installation type, the following tags would be added:
You can connect to the Gaia Portal over HTTPS using a web browser.
Notes:
The username is 'admin'.
If you have selected Automatically generate an administrator password, then use the Admin password (Temporary) shown at the end of the deployment.
If you have not selected Automatically generate an administrator password, then first you will need to connect over SSH to the machine and set the user 'admin' password.
When you connect to the Gaia Portal, you will be presented with an SSL warning similar to the following:
Your connection is not private NET::CERT_AUTHORITY_INVALID
Example:
This is due to the fact that the certificate presented by the Gaia Portal is self-signed.
You can validate the certificate by comparing its fingerprint to the fingerprint of the certificate found on the CloudGuard IaaS Gateway. To retrieve the CloudGuard IaaS Gateway's certificate fingerprint, connect to the CloudGuard IaaS Gateway over SSH and run the following command: [Expert@HostName:0]# cpopenssl x509 -in /web/conf/server.crt -fingerprint
Alternatively, you can install your own SSL certificate. Refer to the following articles:
If you have selected Automatically generate an administrator password, then use the Admin password (Temporary) shown at the end of the deployment.
If you have not selected Automatically generate an administrator password, then first you will need to connect over SSH to the machine and set the user 'admin' password using the clish CLI command "set user admin password".
SmartConsole GUI clients (when the instance acts as Security Management Server)
If the instance acts as a Security Management Server, then you can connect to it using the SmartConsole GUI clients.
If you have selected Automatically generate an administrator password, then use the Admin password (Temporary) shown at the end of the deployment.
If you have not selected Automatically generate an administrator password, then first you will need to connect over SSH to the machine and set the Security Management password (run the 'cpconfig' command and select the relevant option).
(6) Connecting the CloudGuard IaaS Security Gateway to its Management Server
If you are deploying a centrally managed Security Gateway, then you will need to define the CloudGuard IaaS Security Gateway on the Security Management Server.
This section explains how to add a load balancer to your environment. After the the procedure described in the section has been done, the gateways will respond to GCP probes.
Note: this feature is only available to machines running a CloudGuard version of R81.10 and above.
Create a load balancer and health checks as explained in MIG admin guide.
In the management, add the following to "$FWDIR/conf/user.def.FW1":
The following diagram depicts the flow of incoming traffic arriving from the Internet and directed at the Web tier of a web application.
A user and an attacker are sending HTTP traffic to the web application on TCP port 80.
The web application is fronted by a Checkpoint CloudGuard IaaS instance.
The Check Point CloudGuard IaaS instance that receives the connection checks the connection against the current security policy and logs the traffic.
If the connection is allowed, then the instance translates the connection, so that:
The source address is changed to be the instance's private address.
The destination address is changed to the address of an internal web server.
In order to have this behavior work, an access rule and a NAT rule needs to be created.
Create a gateway object to represent the Check Point CloudGuard gateway as is described in "Connecting the CloudGuard IaaS Security Gateway to its Management Server". We will assume a host object by the name Gateway-internal-address that has the internal address of the Gateway and a host object by the name application exists.
If this instance acts as a Security Gateway, then you will need to set up routes in Google Compute Engine, so that outgoing traffic is routed through the instance.
CHECK_POINT_ADDRESS with the private IP address of the Check Point CloudGuard IaaS Security Gateway.
Comments:
The first route will be applied to the Check Point CloudGuard IaaS Security Gateway because it has the checkpoint-gateway tag and because its priority value (100) has a higher precedence over the priority value of the second route (500).
The second route will be applied to all other instances sending their Internet bound traffic to the CloudGuard IaaS Security Gateway.
Note that by default, Google Compute Engine creates a default route with a priority value of 1000. The two routes above have therefore higher precedence over it and this third route can be deleted.
Check Point Firewall and NAT rules:
In SmartConsole, set up Network Address Translation (NAT) rules, so that Internet bound traffic, originating from the Web and Application subnets, is hidden behind the CloudGuard IaaS Security Gateway's public address.
Follow the instructions in this section, if you want traffic between subnets (e.g., between the Web subnet and the Application subnet) in Google Compute Engine to be inspected by the Check Point CloudGuard IaaS Security Gateway.
(A) Inspecting traffic between subnets from different VPCs
It is recommended to use Check Point CloudGuard Security Gateway using an hub and spoke architecture to inspect traffic between subnets from different VPCs. Follow the steps in the outbound traffic section under (8) Inspecting traffic for each VPC in which the Check Point CloudGuard Security Gateway is deployed.
If the hosts you wish to protect are in a different subnet than the Check Point CloudGuard Security Gateway, for each such subnet follow these steps:
Connect to the Check Point CloudGuard Security Gateway via SSH, and create a static route using the following command: set static-route SUBNET-ADDRESS/SUBNET-MASK nexthop gateway address GCP-DEFAULT-GATEWAY on Where:
SUBNET-ADDRESS/SUBNET-MASK is the subnet address range (e.g. 10.1.2.0/24).
GCP-DEFAULT-GATEWAY is the GCP default gateway of the subnet in which the Check Point CloudGuard Security Gateway is deployed (e.g. 10.0.2.1).
For example:set static-route 10.1.2.0/24 nexthop gateway address 10.0.2.1 on
Make sure to run: save config, for the configuration to be saved after reboot.
Create a Network object as described in outbound traffic section under (8) Inspecting traffic in the sub section Check Point Firewall and NAT rules.
For each VPC that contains such subnets:
Create a Network Group object.
Name the object.
Add all the Network objects you have created that represent the subnets within the VPC.
Example:
Select OK.
Double-click the Check Point CloudGuard Security Gateway object.
In the left pane select Network Management.
Double-click the interface within the VPC.
Under General in the Topology section select Modify….
In section Leads To tick override.
Tick This Network (Internal).
Tick Specific:.
In the drop-down list select the newly created Network Group object.
Select OK 3 time in order to save the configurations.
After adding all the VPCs and subnetworks, perform install policy in order to apply the configuration.
(B) Inspecting traffic between subnets within the same VPC
Ideally, we would like traffic between the Web and Application subnets to be sent through the Check Point CloudGuard IaaS Security Gateway using Google Compute Engine routes.
That being said, currently, Google Compute Engine routes can only be applied to traffic leaving the virtual network, but cannot be applied to traffic that remains inside the virtual network.
To work around this limitation, we will use NAT to force traffic between these subnets to pass through the Check Point CloudGuard IaaS Security Gateway. To achieve this, we will use "Shadow Subnets", subnets that in fact don't exist and will be used as aliases for the desired destination subnet.
To best explain the configuration steps, we will use the following example environment.
The Web Server (10.0.1.10) is configured to connect to a Shadow App Server, whose address (172.16.2.20) is in a Shadow Application subnet, which resides outside the virtual network.
The Web Server initiates a connection to that address.
Google Compute Engine routes send this connection to the Check Point CloudGuard IaaS Security Gateway.
The CloudGuard IaaS Security Gateway inspects the traffic and if allowed, translates the source and destination addresses.
The source address is translated to an address belonging to the Shadow Web Subnet (172.16.1.10), and the destination address is translated to the App Server address (10.0.2.20).
Make sure to replace the addresses to reflect your environment when you follow these steps:
Component / Range
Address
Network name
web-application-network
Security Subnet
10.0.0.0/24
Check Point CloudGuard IaaS Security Gateway private address
10.0.0.2
Web subnet
10.0.1.0/24
Application subnet
10.0.2.0/24
NAT components
Shadow Addresses (*)
Shadow Web subnet
172.16.1.0/24
Shadow Application subnet
172.16.2.0/24
(*) NAT Shadow addresses must be outside the virtual network address space.
Add the following NAT rule to the Check Point NAT policy:
Source
Destination
Translated Source
Translated Destination
10.0.1.0/24
172.16.2.0/24
172.16.1.0/24
10.0.2.0/24
Note that this rule should be placed above the NAT rules created in the chapter "Inspecting Internet bound traffic" - section "Check Point Firewall and NAT rules" above.
Configure the Web servers to reach the Application servers through the Shadow Application addresses (172.16.2.0).
You would need to create a Google Compute Engine firewall rule to allow traffic from the Shadow Web subnet to the Application subnet.
For example, assuming the servers in the Web subnet need to open connections to servers in the Application subnet over TCP port 8080, the following Google Compute Engine firewall rule should be created:
You should review the Google Compute Engine firewall rules in your network to ensure that no other Google Compute Engine firewall rules allow direct access from the Web subnet to the Application subnet.
You can limit the scope of this firewall rule further by tagging your application instances and adding the same tag to the above Google Compute Engine firewall rules.
In this example, we assumed that the servers in the Web subnet need to initiate connections to the servers in the Application subnet. If connections need to also be initiated from the reverse direction, then repeat the steps above reversing the role of the Web and Application subnets.
Follow the instructions in this section, if you want to set up a VPN tunnel between the Check Point CloudGuard IaaS Security Gateway in Google Compute Engine and an on-premises Security Gateway.
In this section, we will setup the encryption domain of the CloudGuard IaaS Security Gateway. The encryption domain will consist of the Web and Application subnets.
Traffic from these subnets to the on-premises network will be routed to the CloudGuard IaaS Security Gateway using the Google Compute Engine route we have set up in the "Inspecting Internet bound traffic" section above.
For more information about defining VPN tunnels with Security Gateways on different sites and different servers, see the VPN Administration Guide:
In this deployment, the company's on-premises Security Management Server centrally manages the CloudGuard IaaS Security Gateway at the company's local site and the CloudGuard IaaS Security Gateway protecting the company's private subnets in Google Compute Engine.
You can encrypt the data going between the company's on-premises and the company's private subnets in Google Compute Engine by creating a VPN tunnel.
Create a Group network object for the encryption domain behind the CloudGuard IaaS Security Gateway. Add the Google Compute Engine subnets (web-subnet and app-subnet) to this Group network object.
Example:
Edit the CloudGuard IaaS Security Gateway object:
On the General Properties pane, check the IPSec VPN box.
In the left tree, click on the [+] sign to expand the Network Management pane.
Click on the VPN Domain pane - select the option Manually defined. Select the Group network object you created in Step 2.
In the left tree, click on the [+] sign to expand the IPSec VPN - go to the Link Selection pane.
Select the option Always Use this IP Address.
Select the option Statically NATed IP.
Enter the CloudGuard IaaS Security Gateway public IP address.
Click on the Source IP address settings... button.
Select the option Manual - select the option Selected address from topology table - select the private IP address of the external interface.
Ensure that the encryption domain of the on-premises gateway is configured correctly.
Add the two gateways to a VPN community (such as "MyIntranet").
If you want to disable NAT inside the VPN tunnel, then do that in the VPN community object:
On SmartConsole Navigation Toolbar, click on the GATEWAYS & SERVERS app.
On the right pane, click on the Objects tab.
Click on the VPN Communities.
Edit the relevant VPN community:
Go to the Advanced pane.
Check the box Disable NAT inside the VPN community.
Click on OK.
Install the Access Policy on the two Security Gateways.
Using this setup, it is possible to have the same set of Check Point CloudGuard IaaS Security Gateways inspect traffic belonging to multiple web applications.
We will assume a second web application named web2.
There is already a deployed external load balancer in the environment. (For instructions on adding a load balancer to your environment go to "Setting up a load balancer")
To achieve this, you need to assign an additional IP address to the load balancer.
Procedure:
While in your load balancer resource page in GCP, click on Edit.
Click on Frontend configurationsection.
Click on ADD FRONTEND IP AND PORT.
Fill in the required information relevant to your environment.
Click DONE.
Click UPDATE.
In order for the Gateway to direct the traffic to the correct application, A NAT rule needs to be created:
Create a Host object to represent the external load balancer:
Important: This article provides reference architecture only for the deployment of Check Point CloudGuard Security Gateways version R80.40 and higher. For information regarding deployment of Check Point CloudGuard Security Gateways using previous versions, contact Check Point Support.
QoS blade is not supported.
VSX mode is not supported.
For supported versions of Jumbo Hotfix Accumulator refer to sk109141.
The R77.30 Jumbo Hotfix Accumulator (all its Takes) is not supported on CloudGuard for Google Cloud Platform.
For a list of additional limitations in other related solutions visit the "Known Limitations" section in GCP HA Admin Guide and GCP MIG Admin Guide.
Gathered "Inspecting Internet bound traffic", "Inspecting incoming traffic" and "inspecting traffic between subnets" as sub-sections under one section ,"Inspecting traffic".
Moved all information about versions under R80.30 to internal comments.
Revised deployment options table.
Removed sections "A second CloudGuard IaaS Security Gateway in the same zone", "A second CloudGuard IaaS Security Gateway in a different zone" and "Multiple CloudGuard IaaS Security Gateways". Their content was moved removed due to irrelevance and redundancy.
Revised "Multiple web applications" use of load balancer to adding a additional IP to the external load balancer.
28 Oct 2017
"(4) Deployment" section - corrected the links for BYOL and PAYG deployment options.
18 Oct 2017
Added information about R80.10 CloudGuard IaaS Gateway.
Added instructions for R80.X SmartConsole.
18 Sep 2017
Spelling corrections.
05 Mar 2017
"Deployment" section - added deployment options (BYOL and PAYG).
15 Feb 2017
"Connecting to the instance" section - "Gaia Portal" subsection: added an explanation about SSL warning in web browser.
11 Jan 2017
First release of this article.
Give us Feedback
Thanks for your feedback!
Are you sure you want to rate this stars?