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:

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

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


Download the “” installation script from CheckPoint UserCenter:

Transfer it to the management server:

Log in to the Expert mode:

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:


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



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”



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.

Using the interface eth0 from the gateways also will not work as it will cause a loop.

The only possible solution while Aviatrix engineering works to implement it properly is to pin the traffic towards a single gateway.



Pinging spoke40 vm from spoke 30 vm works:


Once egress is enabled on the FireNet, a 0/0 entry is created (on “private” subnets only) pointing to the spoke gateway:

Scale up/Scale in Scenarios

Instead of generating load I’ll “play” with the scale out parameters:

5 minutes is the minimum amount of time. Once the scale out is triggered, Azure will notify of the change:

Checking the Instances under the scale set:

Failure Scenarios


Leave a Reply