Deploying an Aviatrix Firenet on Azure with CheckPoint CloudGuard Scale Sets (Not Officially Supported)

Thanks to Manny, Jorge, and Barry for the discussions that pushed me to test this solution.

This blog by itself does not attest the integration works

This post is a follow up on my previous blog where I went through the deployment of an AVX FireNet using CheckPoint CloudGuard Single Gateways. The blog can be found clicking on the chip below:

Deploying an Aviatrix Firenet on Azure with CheckPoint CloudGuard (Single GWs)

Scale Sets

(Azure) virtual machine scale sets (vmss) is a group of load balanced VMs. The number of VMs can automatically increase or decrease in response to demand or a defined schedule.

Allows your application to automatically scale as resource demand changes

CheckPoint offers a solution template that can be deployed directly from Marketplace. The diagram of the solution is below:

Diagram from https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_VMSS_for_Azure/Content/Topics-Azure-VMSS/Overview.htm

Scale Sets Consideration

Aviatrix at the time of this writing does not support scale sets.
manual route manipulation is required for VMSS to work with Aviatrix
East-West inspection between peered VNETs is supported only for RFC 1918 private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
It can take up to 15 min for new scale-set members start forwarding traffic

Scale Set Deployment

Tags: Each VMSS is deployed with several tags. Every tag represents configurations for the automatic management of the VMSS.

Cloud Management Extension (CME)

CME is a utility that runs on Management Server and allows the integration between CloudGuard IaaS and CSPs.

Deployment

Download the “cme_installation.sh” installation script from CheckPoint UserCenter:

https://supportcenter.checkpoint.com/supportcenter/portal?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=107571

Transfer it to the management server:

Run the script without any parameters and wait for it to finish. Installation log is located at /var/log/CPcme/cme_installation.log.

You can check if the installation was successful by starting a new SSH session and using the following command in expert mode:

Configuration

Service Principal

The first step to configure connectivity between CME and Azure is creating a service principal. Take note of the following:

Application IDclient_id
Key-valueclient_secret
Directory ID / Tenant IDtenant
Subscription ID

Grant service principal access to the subscription

Execute the command below to configure the CME on the management server (expert mode):

autoprov_cfg init Azure -mn "<Management-Name>" -tn "<Configuration-Template-Name>" -otp "<SIC-key>" -ver <Version> -po "<Policy-Name>" -cn "<Controller-Name>" -sb "<Azure-Subscription>" -at "<Active-Directory-Tenant-ID>" -aci "<Client-ID>" -acs "<Client-Secret>"

If you have done all the steps without any mistakes or typos you should now be able to see your fresh VMSS gateways in the Smart Console:

Scale out and Scale In Profile

By default, scale out is configured to trigger when the average Virtual Machine Host CPU is above 80% for more than 5 minutes and scale in is configured to trigger when the average Virtual Machine Host CPU is below 60% for more than 5 minutes. Those values can be changed:

Scale Sets and Aviatrix

Aviatrix at the time of this writing does not support scale sets.
Manual route manipulation is required for VMSS to work with Aviatrix
Attaching/Detaching spokes requires also manual route manipulation
You can ask my colleague Manny @ https://www.linkedin.com/in/emanuelsifuentes/ for a clever/automated way to manipulate routes

Manual Configuration

The following steps are required to make CloudGuard ScaleSet to work with Aviatrix:

change -dmz-firewall and -hagw-dmz-firewall route table route entries pointing from Aviatrix managed NLB to CheckPoint vmss created NLB

From:

To:

This step forwards traffic for inspection from the transit gateways towards the scale set.

Controller updates route entry every time a spoke is attached/detached but limited to the prefix of spoke being manipulated.

front end transit firenet gateways with a NLB:

change -dmz-firewall-lan route table route entry pointing towards transit gateway eth1 to “transit NLB”

From:

To:

The FireNet design after the changes is depicted below:

This solution does not work because the NLB will not get healthy as the health checks towards eth1 are replied back on transit gateway interface eth0.