Overview of CloudGuard Network for Azure VMSS

Use this guide to:

• Deploy a new Check Point VMSS When you create an Azure virtual machine (VM), you must create a virtual network (VNet) or use an existing VNet. You also need to decide how your VMs are intended to be accessed on the VNet. It is important to plan before creating resources and make sure that you understand the limits of networking resources. for Microsoft Azure.

• Configure an existing Check Point VMSS for Microsoft Azure Collection of integrated cloud services that developers and IT professionals use to build, deploy, and manage applications through a global network of data centers managed by Microsoft®., for templates 20180610 and above.

  You can locate the template version on each CloudGuard instance in this file:

  /etc/cloud-version

Introduction to Virtual Machine Scale Sets (VMSS)

Virtual Machine Scale Sets (VMSS) are an Azure compute resource you can use to deploy and manage sets of identical Virtual Machines (VMs). The Scale Sets increase or decrease the number of Virtual Machines based on the current needs.

For example, multiple web servers server a web application. The web servers are deployed across multiple fault and update domains. A Load Balancer distributes network traffic across this group of web servers as needed.

In the current cyber-landscape, it is very important that you protect these environments from attackers with a security solution that is as scalable as the resources it protects. As the number of resources you protect scales up or down, the number of Security Gateways that provide protection has to scale as well.

See Azure documentation for information on the configuration of multiple Virtual Machines - Configure multiple virtual machines in an availability set for redundancy.

Prerequisites

Make sure you are familiar with these topics

Vendor	Topics
Microsoft Azure	VMSS Autoscaling Load Balancers High Availability ports Identity and access management
Check Point	Check Point Check Point with Azure

Scale In and Scale Out Events

Each VMSS must define Scale In and Scale Out events.

You can edit or see the configuration in Azure Portal > VMSS > Scaling.

Default triggers for the firewall VMSS:

• Scale Out on more than 80% CPU usage, for an average of five minutes.

• Scale In on less than 60% CPU usage, for an average of five minutes.

Note - You can use CloudGuard Metrics as triggers for scale in and scale out events. For more information, see Additional Information.

Scale In

A scale in event occurs as a result of a decrease of the current load. When a scale in event triggers, Azure Autoscale designates one or more of the gateways as candidates for termination. The External Load Balancer stops forwarding new connections to these gateways, and Autoscale ends them. The Check Point Security Management Server detects that these CloudGuard Network Security Security Gateways are stopped and automatically deletes these gateways from its database.

Notes:

• We recommend that you have at least two Security Gateways for redundancy and availability purposes.

• To configure connection draining, where the load balancer stops assigning connections to a node, refer to sk170304.

Scale Out

A scale out event occurs, if the current load increases. When a scale out event is triggered:

• Azure Autoscale launches one or more new instances of the Check Point CloudGuard Network Security Gateways.

• The new instances of CloudGuard Network Security Gateways automatically runs the Check Point First Time Configuration Wizard and then reboot.

During the scale out, the Check Point Security Management Server detects that new instances of CloudGuard Network Security Gateways launched. The Security Management Server waits until the CloudGuard Network Security Gateways finish to deploy and then the Security Management Server automatically:

• Initializes a Secure Internal Communication (SIC Secure Internal Communication. The Check Point proprietary mechanism with which Check Point computers that run Check Point software authenticate each other over SSL, for secure communication. This authentication is based on the certificates issued by the ICA on a Check Point Management Server.) channel with these CloudGuard Network Security Gateways.

• Installs a Security Policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. on these CloudGuard Network Security Gateways.

After a Security Policy is installed, these CloudGuard Network Security Gateways start to respond to health probes. The Load Balancer then starts to forward new connections to them. The newly created CloudGuard Network Security Gateways report their status and send logs to the Check Point Security Management Server.

Notes:

1. In case of scale out event, the latest available Check Point image is used to deploy the new Virtual Machine.

2. When you use the template version 20181017 or above:

   1. Fast Deployment Images (Blink) with a pre-installed Jumbo Hotfix Accumulator Collection of hotfixes combined into a single package. Acronyms: JHA, JHF, JHFA. is used.

   2. In case of scale out event, a newer Virtual Machine uses the latest available Check Point image.

   For more information, see these SK articles:

   • CloudGuard for Azure Latest Updates - see sk132192

   • Blink - Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. Fast Deployment - see sk120193

Components of the Check Point Deployed Solution

The diagram below depicts an Azure Virtual Network Environment of logically connected Virtual Machines. (VNET) with the Check Point solution deployed.

There are two backend subnets - WebApp1 and WebApp2.

WebApp1 and WebApp2 are each a user-deployed backend subnet. Each has its own load-balanced web server.

The Check Point deployed solution has these components:

• Frontend subnet

• Virtual Machine Scale Set (VMSS)

  The number of instances that you can deploy in the Cloud is dynamic.

• Internal Load Balancer

• Backend subnet

• External Load Balancer

• Public IP address for each VMSS instance (optional)

• You cannot deploy other VMs in the VMSS subnets

Load Balancers

In the diagram below you can see Load Balancers at three levels.

Network Diagram

Note - WebAppA and WebAppB routing tables have the same VNET address, but different subnet addresses.

For Site-2-Site VPN configuration between Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. High Availability, see the Check Point CloudGuard Network High Availability for Azure Administration Guide.