Support Center > Search Results > SecureKnowledge Details
Check Point CloudGuard IaaS reference architecture for Google Cloud Platform
Solution

  Table of Contents:

  1. Introduction
  2. Overview
  3. Management
  4. Deployment
  5. Connecting to the instance
  6. Connecting the CloudGuard IaaS Security Gateway to its Management Server
  7. Inspecting Internet bound traffic
  8. Setting up a VPN tunnel
  9. Inspecting traffic between subnets
  10. Inspecting incoming traffic
  11. Multiple CloudGuard IaaS Security Gateways
  12. A second CloudGuard IaaS Security Gateway in the same zone
  13. A second CloudGuard IaaS Security Gateway in a different zone
  14. Multiple web applications
  15. Licensing
  16. Known Limitations
  17. Revision History

 

Click Here to Show the Entire Article

 

(1) Introduction

This article provides a reference architecture for the deployment of Check Point CloudGuard IaaS Security Gateways in Google Cloud Platform.

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.

 

(2) Overview

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).

Check Point CloudGuard for Google Cloud Platform can be deployed in Google Compute Engine to provide all of the above services.

 

(3) Management

The Check Point CloudGuard IaaS Security Gateway can be managed in several ways, including:

  • A standalone configuration, in which the CloudGuard IaaS Security Gateway acts as its own Security Management Server.

  • Centrally managed, in which the Security Management Server is located on-premises.

  • Centrally managed, in which the Security Management Server is located in the same virtual network.

Notes:

 

 

(4) Deployment

Google Compute Engine supports two modes for networking:

  • Legacy (non-subnetwork) mode.

  • Subnet mode.

    Subnet mode is further divided into two:

    • Automatic

      • In this mode, a subnet is automatically created in each region.
      • In this mode, some Google Compute Engine firewall rules are automatically created for the user.
    • Custom

      • In this mode, the customer can create 0, 1 or more subnets in each region.

Check Point CloudGuard IaaS Security Gateway can be deployed in both of these modes, but for simplicity we will assume that Subnet mode is being used.

For additional information, see https://cloud.google.com/vpc/docs/vpc.

For the rest of this document, we will assume that a Custom Subnet mode environment has already been created consisting of the following:

Subnet name CIDR (example)
security 10.0.0.0/24
web 10.0.1.0/24
application 10.0.2.0/24

All of these subnets are assumed to be in the same region (e.g., us-central-1).

In addition, we will assume that an on-premises network (172.16.0.0/16) exists.

When deploying the Check Point solution, you have the option of selecting the Check Point CloudGuard IaaS installation type:

The installation type can be any of the following:

  • Gateway and Management (Standalone)
  • Gateway only
  • Management only
  • Manual configuration

A Gateway only instance can be centrally managed by a Security Management Server in your on-premises network or in the public cloud.

If your Security Management Server is on-premises, then you can manage the CloudGuard IaaS Security Gateway:

To deploy, go to one of the following:

Deployment Option Link
BYOL (Bring Your Own License) https://console.cloud.google.com/marketplace/details/checkpoint-public/check-point-cloudguard-byol
PAYG (Pay As You Go) https://console.cloud.google.com/marketplace/details/checkpoint-public/check-point-cloudguard-payg

Example:

Select:

  • A Deployment name (e.g., checkpoint-cloudguard).

  • The Zone (e.g., us-central-1a), into which the CloudGuard IaaS Security Gateway is going to be deployed.

  • The Machine type (e.g., n1-standard-2).

  • The Network (e.g., web-application-network) and Subnetwork (e.g., security), into which to deploy the solution.

  • The type of External IP address (e.g. Static) of the primary network interface of the instance.

  • The Installation Type from the following list:

    • Gateway and Management (Standalone).
    • Gateway only.
    • Management only.
    • Manual configuration.

Notes:

  • 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:

    • Set up Google Compute Engine firewall rules.
    • Run the first time wizard manually.
    • Tag the instance.

Advanced deployment options:

In addition to the above, you have the option of setting up the following advanced options:

Option Valid values Default value Comment
Disk type
  • SSD
  • standard
SSD The type of disk used by the Check Point instance
Disk size At least 100 GB 100 See Comment #1
Automatically generate
an administrator password
  • Checked
  • Unchecked
Unchecked See Comment #2
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 #4
Allowed GUI clients CIDR notation 0.0.0.0/0 See Comment #5
The network, in which the
managed Security Gateways reside
CIDR notation 0.0.0.0/0 See Comment #6

Comments:

  1. The size of the disk. If a value larger than the default is supplied, then you will need to follow sk95566 - Managing partition sizes via LVM manager on Gaia OS.

  2. If checked, a password would be automatically generated for the user 'admin'. These credentials could be used for:

    • Connecting to the Gaia Portal.
    • Connecting using a serial console (https://cloud.google.com/compute/docs/instances/interacting-with-serial-console).
    • 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.
  3. 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.

  4. 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.

  5. 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.

  6. Only used in Management only installations. Communication from gateways to this Management Server will only be allowed from this address range.

Additional network interfaces: Google Compute Engine supports instances with multiple network interfaces, for more information how to configure CloudGuard for GCP with multiple interfaces refer to: sk121637

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 would 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:

      • checkpoint-gateway
      • checkpoint-management

 

(5) Connecting to the instance

After deployment, you can connect to the instance using the following methods:

  • SSH

    You can connect to the instance using SSH as explained in https://cloud.google.com/compute/docs/instances/connecting-to-instance.

    Notes:

  • Gaia Portal

    You can connect to the Gaia Portal over HTTPS using a web browser.

    Notes:

  • Serial Console

    Follow the instructions in https://cloud.google.com/compute/docs/instances/interacting-with-serial-console.

    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.

  • 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.

    You can download and install these clients from either the Gaia Portal, or the Check Point Download Center.

    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 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.

Follow the steps described in the:

 

(7) Inspecting Internet bound traffic

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.

Additional information on routes in Google Compute Engine can be found here:
https://cloud.google.com/compute/docs/networking#routing.

You will also need to set up an appropriate security policy as well as Network Address Translation policy (NAT) for this traffic.

 

Google Compute Engine routes:

We will be creating two Google Compute Engine routes:

  • A route allowing the Check Point instance to access the Internet:

    gcloud compute routes create NETWORK_NAME-checkpoint-to-internet \
      --destination-range=0.0.0.0/0 \
      --next-hop-gateway=default-internet-gateway \
      --description="Check Point gateway to the Internet" \
      --network=NETWORK_NAME \
      --priority=100 \
      --tags=checkpoint-gateway
    
  • A route that will send the traffic of all other instances in the network through the Check Point instance:

    gcloud compute routes create NETWORK_NAME-default-to-checkpoint \
      --destination-range=0.0.0.0/0 \
      --next-hop-address=CHECK_POINT_ADDRESS \
      --description="Route all egress traffic to Check Point" \
      --network=NETWORK_NAME \
      --priority=500
    

Execute the above gcloud commands replacing:

  • NETWORK_NAME with the network name.

  • 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 R80.X SmartConsole / R77.X SmartDashboard, 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.

  • Show / Hide instructions for R80.X SmartConsole
    1. Create a network object to represent the Web subnet:

      1. On SmartConsole Navigation Toolbar, click on the GATEWAYS & SERVERS app.

      2. On the right pane, click on the Objects tab.

      3. Right-click on the Network Objects - click on the Network...:

      4. In the left tree, click on the General pane:

        1. At the top, enter the desired name

        2. On the General tab, enter the Network address and Network mask:

      5. In the left tree, click on the NAT pane:

        1. Check the box Add automatic address translation rules.

        2. Select the option Hide behind the gateway.

        3. In the Install on gateway field, select the CloudGuard IaaS Security Gateway.

        Note: Refer to the R80.10 Security Management Server Administration Guide - chapter "Creating an Access Control Policy" - section "Configuring the NAT Policy".

    2. Repeat Step 1 to create a network object to represent the Application subnet.

    3. The following Automatic NAT rules would be created:

      No. Original
      Source
      Original
      Destination
      Original
      Services
      Translated
      Source
      Translated
      Destination
      Translated
      Services
      Install On Comment
      1 application-subnet application-subnet * Any = Original = Original = Original chkp-gw  
      2 application-subnet * Any * Any H application-subnet (Hiding Address) = Original = Original chkp-gw  
      3 web-subnet web-subnet * Any = Original = Original = Original chkp-gw  
      4 web-subnet * Any * Any H web-subnet (Hiding Address) = Original = Original chkp-gw  
    4. Go to the CloudGuard IaaS Security Gateway object and enable any additional desired Network Security blades:

    5. Edit the Access Policy as required.

    6. Install the Access Policy on the CloudGuard IaaS Security Gateway.



  • Show / Hide instructions for R77.X SmartDashboard
    1. Create a network object to represent the Web subnet:

      1. Open SmartDashboard - go to the Firewall tab.

      2. Go to the Network Objects view.

      3. Right-click on the Networks category - select Network...:

      4. Go to the General tab:

        • Enter a desired name
        • Enter the subnet the Network address and Network mask

      5. Go to the NAT tab:

        • Check the box Add Automatic Address Translation.
        • Select the option Hide behind Gateway.
        • In the Install on Gateway field, select the CloudGuard IaaS Security Gateway.

        Note: Refer to the Firewall Administration Guide (R77.X) - chapter "Configuring the NAT Policy".

    2. Repeat Step 1 to create a network object to represent the Application subnet.

    3. The following Automatic NAT rules would be created:

      No. Original Packet Translated Packet Install On Comment
      Source Destination Service Source Destination Service
      1 application-subnet application-subnet Any = Original = Original = Original checkpoint-cloudguard-vm Automatic rule (see the network object data).
      2 application-subnet Any Any Happlication-subnet (Hiding Address) = Original = Original checkpoint-cloudguard-vm Automatic rule (see the network object data).
      3 web-subnet web-subnet Any = Original = Original = Original checkpoint-cloudguard-vm Automatic rule (see the network object data).
      4 web-subnet Any Any Hweb-subnet (Hiding Address) = Original = Original checkpoint-cloudguard-vm Automatic rule (see the network object data).
    4. Go to the CloudGuard IaaS Security Gateway object and enable any additional desired Network Security blades:

    5. Edit the Firewall policy as required.

    6. Install the policy on the CloudGuard IaaS Security Gateway.

 

(8) Setting up a VPN tunnel

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 (R77.X, R80, R80.10).

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.

Follow these steps to configure the VPN:

  • Show / Hide instructions for R80.X SmartConsole
    1. Open SmartConsole.

    2. 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:

    3. Edit the CloudGuard IaaS Security Gateway object:

      1. On the General Properties pane, check the IPSec VPN box.

      2. In the left tree, click on the [+] sign to expand the Network Management pane.

      3. Click on the VPN Domain pane - select the option Manually defined.
        Select the Group network object you created in Step 2.

      4. In the left tree, click on the [+] sign to expand the IPSec VPN - go to the Link Selection pane.

      5. Select the option Always Use this IP Address.

      6. Select the option Statically NATed IP.

      7. Enter the CloudGuard IaaS Security Gateway public IP address.

      8. Click on the Source IP address settings... button.

      9. Select the option Manual - select the option Selected address from topology table - select the private IP address of the external interface.

    4. Ensure that the encryption domain of the on-premises gateway is configured correctly.

    5. Add the two gateways to a VPN community (such as "MyIntranet").

    6. If you want to disable NAT inside the VPN tunnel, then do that in the VPN community object:

      1. On SmartConsole Navigation Toolbar, click on the GATEWAYS & SERVERS app.

      2. On the right pane, click on the Objects tab.

      3. Click on the VPN Communities.

      4. Edit the relevant VPN community:

        1. Go to the Advanced pane.

        2. Check the box Disable NAT inside the VPN community.

        3. Click on OK.

    7. Install the Access Policy on the two Security Gateways.



  • Show / Hide instructions for R77.X SmartDashboard
    1. Open SmartDashboard.

    2. 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:

    3. Edit the CloudGuard IaaS Security Gateway object:

      1. On the General Properties pane, check the IPSec VPN box.

      2. On the Topology pane, in the VPN Domain section, select the option Manually defined.
        Select the Group network object you created in Step 2.

      3. In the left tree, click on the [+] sign to expand the IPSec VPN - go to the Link Selection pane.

      4. Select the option Always Use this IP Address.

      5. Select the option Statically NATed IP.

      6. Enter the CloudGuard IaaS Security Gateway public IP address.

      7. Click on the Source IP address settings... button.

      8. Select the option Manual - select the option Selected address from topology table - select the private IP address of the external interface.

    4. Ensure that the encryption domain of the on-premises gateway is configured correctly.

    5. Add the two gateways to a VPN community (such as "MyIntranet").

    6. If you want to disable NAT inside the VPN tunnel, then do that in the VPN community object:

      1. In SmartDashboard, go to the IPSec VPN tab.

      2. In the left tree, click on the Communities.

      3. Edit the relevant VPN community.

      4. In the left tree, click on the [+] sign to expand the Advanced Settings - go to the Advanced VPN Properties pane.

      5. Check the box Disable NAT inside the VPN community.

      6. Click on OK.

    7. Install the policy on the two Security Gateways.

 

(9) Inspecting traffic between subnets

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.

(9.A) Inspecting traffic between subnets from different VPCs

It is recommended to use Check Point CloudGuard Security Gateway with multiple network interfaces and inspect traffic between subnets from different VPCs. Follow the steps in section (7) Inspecting Internet bound 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 section (7) Inspecting Internet bound traffic 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.

(9.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.

Additional information about Google Compute Engine routes can be found here:
https://cloud.google.com/compute/docs/networking#routing.

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:

gcloud compute firewall-rules create \
    NETWORK_NAME-allow-through-checkpoint \
    --allow "tcp:8080" \
    --network=NETWORK_NAME \
    --source-ranges=172.16.1.0/24

Notes:

  • 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.

 

(10) Inspecting incoming traffic

(10-A) Background

The following diagram depicts the flow of incoming traffic arriving from the Internet and directed at the Web tier of a web application.

  1. A user and an attacker are sending HTTP traffic to the web application on TCP port 80.

  2. The web application is fronted by a Google Compute Engine external HTTP / HTTPS load balancer.

  3. The external HTTP / HTTPS load balancer sends the traffic to one or more Check Point CloudGuard IaaS instances.

  4. The HTTP / HTTPS load balancer changes the destination port from port 80 to port 8081.

  5. The Check Point CloudGuard IaaS instance that receives the connection checks the connection against the current security policy and logs the traffic.

  6. 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 TCP load balancer.
    • The destination port is (optionally) changed back to port 80.
  7. The internal TCP load balancer selects a web server and sends the connection to it.

Below is a summary of the connection parameters in each segment of the connection:

Segment Source Destination Destination port
Client => External LB Web client Public address of the external load balancer 80
External LB => CloudGuard IaaS Security Gateway An address of the external load balancer Check Point CloudGuard IaaS instance private address 8081
CloudGuard IaaS Security Gateway => Internal LB Check Point CloudGuard IaaS Security Gateway private address Internal Load Balancer 80
Internal LB => Web instance Internal Load Balancer Web instance 80

Notes:

  • The external load balancer adds an HTTP "X-Forwarded-For" header that preserves the client's original IP address. This header is present in all segments to the right of the external load balancer.

  • In R80.10/R80.20 CloudGuard IaaS Gateway, in order to enable the "X-Forwarded-For" logging, the Identity Awareness blade must be enabled on the CloudGuard IaaS Gateway:

    1. On SmartConsole Navigation Toolbar, click on the GATEWAYS & SERVERS app.

    2. Edit the CloudGuard IaaS Security Gateway object:

      1. On the General Properties pane, check the Identity Awareness box:

      2. The Identity Awareness Configuration wizard will open.

      3. On the Methods For Acquiring Identity screen, it is recommended to check only the Terminal Servers - click on the Next button:

      4. On the Integration With Active Directory screen, check the box I do not wish to configure an Active Directory at this time - click on the Next button:

      5. On the final screen, click on the Finish button.

    3. In the left tree, click on the [+] sign to expand the Identity Awareness - click on the Proxy.

    4. Check the box Detect users located behind http proxy configured with X-Forward-For - click on OK:

    5. Install access policy on the relevant Security Gateways.

 

(10-B) Setup

This environment is more easily created from right to left, starting with the web instances.

  1. Create an instance group of web servers and an internal load balancer as explained here:
    https://cloud.google.com/compute/docs/load-balancing/internal/.

  2. Write down the private address of the internal load balancer you have created.

  3. Use the following script to create the external load balancer and have it forward traffic on its external port (80) to the Check Point CloudGuard IaaS Security Gateway on an internal port (8081). Set the variables marked in red at the beginning of the script with the values that represent your environment.

    In more detail, the script performs the following:

    • Creates an instance group.
    • Adds the Check Point CloudGuard IaaS Security Gateway into that group.
    • Assigns a named port to the Check Point instance group.
    • Creates a health check.
    • Creates a backend service that uses the named port group and the health check.
    • Adds the Check Point instance group to the backend service.
    • Creates a URL map that maps all requests by default to the backend service we created.
    • Creates a target HTTP proxy to route requests to your URL map.
    • Allocates a public address.
    • Creates a global forwarding rule to handle and route incoming requests.
  4. If the installation type is Manual configuration, and you have manually configured the machine to be a Security Gateway or StandAlone, then run the following command to add Dynamic Object named "LocalGateway" with the IP range that contains only the IP address of the CloudGuard IaaS Gateway:

    [Expert@HostName:0]# dynamic_objects -n LocalGateway -r <IP_ADDRESS> <IP_ADDRESS> -a

 

NETWORK=web-application-network
ZONE=us-central1-a
CLOUDGUARD_INSTANCE=checkpoint-cloudguard-vm
WEBAPP=web1
EXTERNAL_PORT=80
INTERNAL_PORT=8081

gcloud compute instance-groups unmanaged create "$NETWORK-$ZONE-ig-cloudguard" \
    --zone "$ZONE"

gcloud compute instance-groups unmanaged add-instances \
    "$NETWORK-$ZONE-ig-cloudguard" \
    --instances "$CLOUDGUARD_INSTANCE" --zone "$ZONE"

gcloud compute instance-groups unmanaged set-named-ports \
    "$NETWORK-$ZONE-ig-cloudguard" \
    --named-ports "$WEBAPP:$INTERNAL_PORT" \
    --zone "$ZONE"

gcloud compute http-health-checks create "$WEBAPP-basic-check" \
    --port "$INTERNAL_PORT"

gcloud compute backend-services create "$WEBAPP-backend-service" \
    --protocol HTTP --port-name "$WEBAPP" \
    --http-health-checks "$WEBAPP-basic-check" \
    --global

gcloud compute backend-services add-backend "$WEBAPP-backend-service" \
    --balancing-mode UTILIZATION --max-utilization 0.8 \
    --capacity-scaler 1 --instance-group "$NETWORK-$ZONE-ig-cloudguard" \
    --global --instance-group-zone "$ZONE"

gcloud compute url-maps create "$WEBAPP-lb" \
    --default-service "$WEBAPP-backend-service"

gcloud compute target-http-proxies create "$WEBAPP-lb-proxy" \
    --url-map "$WEBAPP-lb"

gcloud compute addresses create "$WEBAPP-lb-ip" --global
IP_ADDRESS="$(gcloud compute addresses describe "$WEBAPP-lb-ip" \
    --global | grep "^address: " | cut -d ' ' -f 2)"

gcloud compute forwarding-rules create "$WEBAPP-content-gfr" \
    --address "$IP_ADDRESS" --global \
    --target-http-proxy "$WEBAPP-lb-proxy" --ports "$EXTERNAL_PORT"

For more advanced options, refer to the https://cloud.google.com/compute/docs/load-balancing/http/content-based-example.

Follow these steps to complete this setup:

  • Show / Hide instructions for R80.X SmartConsole
    1. Open SmartConsole - click on the GATEWAYS & SERVERS app.

    2. On the right pane, click on the Objects tab.

    3. Click on the Services:

    4. Right-click on the TCP - click on the TCP...:

    5. Create an HTTP service for the port, which the external load balancer is using to forward HTTP requests to the CloudGuard IaaS Security Gateway (e.g., port 8081):

      1. Enter a representative name (e.g., HTTP-8081).

      2. On the General pane:

        1. In the Protocol field, select HTTP.

        2. In the Match by section, select the option Customize and enter the port number (e.g., 8081).

        3. Click on OK to apply the settings and close the New TCP Service window.

        Example:
    6. Create a Host object to represent the internal load balancer:

      1. On the right pane, click on the Objects tab.

      2. Right-click on the Network Objects - click on the Host...:

      3. On the General pane:

        1. Enter a representative name (e.g., web1-internal-lb).

        2. In the IPv4 Address field, enter the IP address of the internal load balancer.

        3. Click on OK to apply the settings and close the New Host window.

        Example:
    7. Create a Dynamic Object named LocalGateway, if it does not exist yet:

      1. On the right pane, click on the Objects tab.

      2. Right-click on the Network Objects - go to the menu Dynamic Objects - click on the Dynamic Object...:

      3. In the Name field, you must enter LocalGateway.

      4. Click on OK to apply the settings and close the New Dynamic Object window.

    8. Add the relevant Access rule:

      1. On SmartConsole Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the upper middle section Access Control, click on the Policy.

      3. Add the following access rule above the Cleanup rule:

        No. Source Destination VPN Services &
        Applications
        Action Track Install On Time
        1 * Any LocalGateway * Any HTTP-8081 Accept Log * Policy Targets Any
        2 * Any * Any * Any * Any Drop None * Policy Targets Any
        Example:

        Where:

        Column Value Comment
        Source Any  
        Destination LocalGateway  
        VPN Any Traffic This is the default
        Service The service you created earlier e.g., HTTP-8081
        Action Accept  
        Track Select the desired tracking option e.g., Log
    9. Add the relevant NAT rule:

      1. On SmartConsole Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the upper middle section Access Control, click on the NAT.

      3. Add the following NAT rule:

        No. Original
        Source
        Original
        Destination
        Original
        Services
        Translated
        Source
        Translated
        Destination
        Translated
        Services
        Install On Comment
        1 All_Internet LocalGateway HTTP-8081 H LocalGateway S web1-internal-lb http * Policy Targets  

        Where:

        Column Value Comment
        Original Source All_Internet Do not use "Any"
        Original Destination LocalGateway  
        Original Service The service you created earlier e.g., HTTP-8081
        Translated Source LocalGateway Select "Hide" as the translation method
        Translated Destination The internal load balancer e.g., web1-internal-lb
        Translated Service The port, on which the internal load balancer is listening e.g., http
    10. Install the Access policy on the CloudGuard IaaS Security Gateway.



  • Show / Hide instructions for R77.X SmartDashboard
    1. Open SmartDashboard - go to the Firewall tab.

    2. Create an HTTP service for the port, which the external load balancer is using to forward HTTP requests to the CloudGuard IaaS Security Gateway (e.g., port 8081):

      1. Go to the Services view.

      2. Right-click on the TCP category - select New TCP....

      3. Enter a representative name (e.g., HTTP-8081).

        Enter the port number (e.g., 8081).

        Example:

      4. Click on the Advanced... button.

      5. In the Protocol Type field, select HTTP.

      6. Click on OK to apply the settings and close the Service Properties window.

    3. Create a Host object to represent the internal load balancer:

      1. Go to the Network Objects view.

      2. Right-click on the Nodes category - go to the Node menu - select Host....

      3. Enter a representative name (e.g., web1-internal-lb).

        In the IPv4 Address field, enter the IP address of the internal load balancer.

        Example:

      4. Click on OK to apply the settings and close the Host Node properties window.

    4. Create a Dynamic Object named LocalGateway, if it does not exist yet:

      1. Right-click on the Dynamic Objects category - select Dynamic Objects....

      2. In the Name field, you must enter LocalGateway:

      3. Click on OK to apply the settings and close the Dynamic Object properties window.

    5. In the upper left tree of the Firewall tab, click on Policy and create the following Firewall rule:

      Source Destination VPN Service Action Track Install On
      Any LocalGateway Any Traffic HTTP-8081 Accept Log Policy Targets

      Example:

      Where:

      Column Value Comment
      Source Any  
      Destination LocalGateway  
      VPN Any Traffic This is the default
      Service The service you created earlier e.g., HTTP-8081
      Action Accept  
      Track Select the desired tracking option e.g., Log
    6. In the upper left tree of the Firewall tab, click on NAT and create the following NAT rule:

      Note: Refer to the Firewall Administration Guide (R77.X) - chapter "Configuring the NAT Policy".

      Original Packet Translated Packet Install On
      Source Destination Service Source Destination Service
      All_Internet LocalGateway HTTP-8081 HLocalGateway Hweb1-internal-lb Hhttp Policy Targets

      Example:

      Where:

      Column Value Comment
      Original Source All_Internet Do not use "Any"
      Original Destination LocalGateway  
      Original Service The service you created earlier e.g., HTTP-8081
      Translated Source LocalGateway Select "Hide" as the translation method
      Translated Destination The internal load balancer e.g., web1-internal-lb
      Translated Service The port, on which the internal load balancer is listening e.g., http
    7. Install the policy on the CloudGuard IaaS Security Gateway.

 

(11) Multiple CloudGuard IaaS Security Gateways

If needed, additional CloudGuard IaaS Security Gateways can be added to this setup in the same region.

Having more than one CloudGuard IaaS Security Gateway can provide a higher level of availability as well as load sharing.

In such a setup, for every connection, the external load balancer chooses a CloudGuard IaaS Security Gateway from the backend service and forwards the connection to that CloudGuard IaaS Security Gateway.

Note: There is no state synchronization between the different CloudGuard IaaS Security Gateways.

To add an additional CloudGuard IaaS Security Gateway to this environment:

  • Deploy a second CloudGuard IaaS Security Gateway.
  • Connect the second CloudGuard IaaS Security Gateway to the Security Management Server.

 

(12) A second CloudGuard IaaS Security Gateway in the same zone

If the second CloudGuard IaaS Security Gateway is in the same zone, then add the CloudGuard IaaS Security Gateway to the instance group using the following command:

gcloud compute instance-groups unmanaged add-instances "$NETWORK-ig-cloudguard" \
    --instances CLOUDGUARD2_INSTANCE --zone "$ZONE"

 

(13) A second CloudGuard IaaS Security Gateway in a different zone

If the second CloudGuard IaaS Security Gateway is in the same region, but in a different zone, then follow these steps:

  1. Use the following script to create a new instance group containing that CloudGuard IaaS Security Gateway and add it to the backend service.

    NETWORK=web-application-network
    ZONE=us-central1-b
    CLOUDGUARD_INSTANCE=checkpoint-cloudguard-2-vm
    WEBAPP=web1
    INTERNAL_PORT=8081
    
    gcloud compute instance-groups unmanaged create "$NETWORK-$ZONE-ig-cloudguard" \
        --zone "$ZONE"
    
    gcloud compute instance-groups unmanaged add-instances \
        "$NETWORK-$ZONE-ig-cloudguard" \
        --instances "$CLOUDGUARD_INSTANCE" --zone "$ZONE"
    
    gcloud compute instance-groups unmanaged set-named-ports \
        "$NETWORK-$ZONE-ig-cloudguard" \
        --named-ports "$WEBAPP:$INTERNAL_PORT" \
        --zone "$ZONE"
    
    gcloud compute backend-services add-backend "$WEBAPP-backend-service" \
        --balancing-mode UTILIZATION --max-utilization 0.8 \
        --capacity-scaler 1 --instance-group "$NETWORK-$ZONE-ig-cloudguard" \
        --global --instance-group-zone "$ZONE"
    
  2. Install the Access / Network Security policy on the new CloudGuard IaaS Security Gateway.

 

(14) Multiple web applications

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.

  • This web application will have its own external and internal load balancers.

  • The external load balancer would be listening on port 80 and will forward traffic to the Check Point CloudGuard IaaS Security Gateways on an internal port (8083).

  • Note that this internal port should be unique from the internal port used by the first web application. The following ports cannot be used: 80, 443, 444, 8082 and 8880.

To achieve this:

  • Create the internal load balancer (as described in the section "Inspecting incoming traffic" above).
  • Create the external load balancer (as described below).

Procedure:

  1. Use the following script to create a second external load balancer:

    Note: Set the variables marked in red at the beginning of the script with the values that represent your environment.

    NETWORK=web-application-network
    ZONE=us-central1-a
    WEBAPP=web2
    EXTERNAL_PORT=80
    INTERNAL_PORT=8083
    
    ports="$(gcloud compute instance-groups unmanaged get-named-ports \
        "$NETWORK-$ZONE-ig-cloudguard" \
        --zone "$ZONE" | grep -v ^NAME | sed 's/  */:/g' | tr '\n' ',')"
    
    gcloud compute instance-groups unmanaged set-named-ports \
        "$NETWORK-$ZONE-ig-cloudguard" \
        --zone "$ZONE" \
        --named-ports "${ports}${WEBAPP}:${INTERNAL_PORT}"
     
    gcloud compute http-health-checks create "$WEBAPP-basic-check" \
        --port "$INTERNAL_PORT"
    
    gcloud compute backend-services create "$WEBAPP-backend-service" \
        --protocol HTTP --port-name "$WEBAPP" \
        --http-health-checks "$WEBAPP-basic-check" \
        --global
    
    gcloud compute backend-services add-backend "$WEBAPP-backend-service" \
        --balancing-mode UTILIZATION --max-utilization 0.8 \
        --capacity-scaler 1 --instance-group "$NETWORK-$ZONE-ig-cloudguard" \
        --global --instance-group-zone "$ZONE"
    
    gcloud compute url-maps create "$WEBAPP-lb" \
        --default-service "$WEBAPP-backend-service"
    
    gcloud compute target-http-proxies create "$WEBAPP-lb-proxy" \
        --url-map "$WEBAPP-lb"
    
    gcloud compute addresses create "$WEBAPP-lb-ip" --global
    IP_ADDRESS="$(gcloud compute addresses describe "$WEBAPP-lb-ip" \
        --global | grep "^address: " | cut -d ' ' -f 2)"
    
    gcloud compute forwarding-rules create "$WEBAPP-content-gfr" \
        --address "$IP_ADDRESS" --global \
        --target-http-proxy "$WEBAPP-lb-proxy" --ports "$EXTERNAL_PORT"
    
  2. Repeat the above Step 1 for every zone, in which you have a Check Point CloudGuard IaaS Security Gateway.

  3. Create an HTTP service for the port, which the external load balancer is using to forward HTTP requests to the CloudGuard IaaS Security Gateway (e.g., port 8083):

    • Show / Hide instructions for R80.X SmartConsole
      1. Open SmartConsole - click on the GATEWAYS & SERVERS app.

      2. On the right pane, click on the Objects tab.

      3. Click on the Services:

      4. Right-click on the TCP - click on the TCP...:

      5. Create an HTTP service for the port, which the external load balancer is using to forward HTTP requests to the CloudGuard IaaS Security Gateway (e.g., port 8083):

        1. Enter a representative name (e.g., HTTP-8083).

        2. On the General pane:

          1. In the Protocol field, select HTTP.

          2. In the Match by section, select the option Customize and enter the port number (e.g., 8083).

          3. Click on OK to apply the settings and close the New TCP Service window.

          Example:


    • Show / Hide instructions for R77.X SmartDashboard
      1. Open SmartDashboard - go to the Firewall tab.
      2. Go to the Services view.

      3. Right-click on the TCP category - select New TCP....

      4. Enter a representative name (e.g., HTTP-8083).

        Enter the port number (e.g., 8083).

        Example:

      5. Click on the Advanced... button.

      6. In the Protocol Type field, select HTTP.

      7. Click on OK to apply the settings and close the Service Properties window.

  4. Create a Host object to represent the internal load balancer:

    • Show / Hide instructions for R80.X SmartConsole
      1. On the right pane, click on the Objects tab.

      2. Right-click on the Network Objects - click on the Host...:

      3. On the General pane:

        1. Enter a representative name (e.g., web2-internal-lb).

        2. In the IPv4 Address field, enter the IP address of the internal load balancer.

        3. Click on OK to apply the settings and close the New Host window.

        Example:


    • Show / Hide instructions for R77.X SmartDashboard
      1. Go to the Network Objects view.

      2. Right-click on the Nodes category - go to the Node menu - select Host....

      3. Enter a representative name (e.g., web2-internal-lb).

        In the IPv4 Address field, enter the IP address of the internal load balancer.

      4. Click on OK to apply the settings and close the Host Node properties window.

  5. Add the relevant Access / Firewall rule:

    • Show / Hide instructions for R80.X SmartConsole
      1. On SmartConsole Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the upper middle section Access Control, click on the Policy.

      3. Add the following access rule above the Cleanup rule:

        Source Destination VPN Services &
        Applications
        Action Track Install On Time
        * Any LocalGateway * Any HTTP-8083 Accept Log * Policy Targets Any

        Where:

        Column Value Comment
        Source Any  
        Destination LocalGateway  
        VPN Any Traffic This is the default
        Service The service you created earlier e.g., HTTP-8083
        Action accept  
        Track Select the desired tracking option e.g., Log


    • Show / Hide instructions for R77.X SmartDashboard

      In the upper left tree of the Firewall tab, click on Policy and create the following Firewall rule:

      Source Destination VPN Service Action Track Install On
      Any LocalGateway Any Traffic HTTP-8083 Accept Log Policy Targets

      Where:

      Column Value Comment
      Source Any  
      Destination LocalGateway  
      VPN Any Traffic This is the default
      Service The service you created earlier e.g., HTTP-8083
      Action Accept  
      Track Select the desired tracking option e.g., Log
  6. Add the relevant NAT rule:

    • Show / Hide instructions for R80.X SmartConsole
      1. On SmartConsole Navigation Toolbar, click on the SECURITY POLICIES app.

      2. In the upper middle section Access Control, click on the NAT.

      3. Add the following NAT rule:

        No. Original
        Source
        Original
        Destination
        Original
        Services
        Translated
        Source
        Translated
        Destination
        Translated
        Services
        Install On Comment
        1 All_Internet LocalGateway HTTP-8083 H LocalGateway S web2-internal-lb http * Policy Targets  

        Where:

        Column Value Comment
        Original Source All_Internet Do not use "Any"
        Original Destination LocalGateway  
        Original Service The service you created earlier e.g., HTTP-8083
        Translated Source LocalGateway Select "Hide" as the translation method
        Translated Destination The internal load balancer e.g., web2-internal-lb
        Translated Service The port, on which the internal load balancer is listening e.g., http


    • Show / Hide instructions for R77.X SmartDashboard

      In the upper left tree of the Firewall tab, click on NAT and create the following NAT rule:

      Note: Refer to the Firewall Administration Guide (R77.X) - chapter "Configuring the NAT Policy".

      Original Packet Translated Packet Install On
      Source Destination Service Source Destination Service
      All_Internet LocalGateway HTTP-8083 HLocalGateway Hweb2-internal-lb Hhttp Policy Targets

      Where:

      Column Value Comment
      Original Source All_Internet Do not use "Any"
      Original Destination LocalGateway  
      Original Service The service you created earlier e.g., HTTP-8083
      Translated Source LocalGateway Select "Hide" as the translation method
      Translated Destination The internal load balancer e.g., web2-internal-lb
      Translated Service The port, on which the internal load balancer is listening e.g., http
  7. Install the Access / Network Security policy on your CloudGuard IaaS Security Gateways.

 

(15) Licensing

When deploying a CloudGuard IaaS Security Gateway, it can be licensed using either:

  • Bring-Your-Own-License (BYOL) using the CloudGuard IaaS license.

  • Pay-As-You-Go (PAYG) - the Gateway is pre-licensed.

When deploying a Security Management Server, you will need to acquire an open server license.

 

(16) Known Limitations

Important: This article provides reference architecture only for the deployment of Check Point CloudGuard Security Gateways version R80.10 and R80.20. For information regarding deployment of Check Point CloudGuard Security Gateways version R77.30, contact Check Point Support.

  • QoS blade is not supported.

  • VSX mode is not supported.

  • Cluster (ClusterXL, VRRP) is currently 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.

 

(17) Revision History

Show / Hide the revision history
Date Description
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
Please rate this document
[1=Worst,5=Best]
Comment