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:
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:
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:
Configuration
Service Principal
The first step to configure connectivity between CME and Azure is creating a service principal. Take note of the following:
- Application ID
client_id - Key-value
client_secret - Directory ID / Tenant ID
tenant - 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.
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.
Testing
East-West
Pinging spoke40 vm from spoke 30 vm works:
Egress
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
References
https://securethecloud.pl/2019/10/08/ultimate-guide-to-azure-vmss-cloudguard/
