- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: Checkpoint gateway failover with service princ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Checkpoint gateway failover with service principal
Currently we have 2 checkpoint gateways R80.40 deployed on Azure. UDR changes during failover is happening automatically using Azure service principal.
UDR changes to current active firewall is taking least 15 mins and causing a huge downtime/outage.
Can we set the Front end LB ip and cluster VIP as the next hop is route table instead of using active firewall ip’s. We think the outage will be minimal with this.
Also need to understand what api's will be executed during failover?
Can you please confirm if this setup is possible. Also need some highlight on this approach.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
with the latest HA template, I would expect no UDR modification at all. There should be a internal LB with a VIP. This VIP is the next hop for your UDRs and will not change. Only the Master/Active FW will answer the LB health checks, so the traffic is forwarded to the Master only. After failover, the Backup FW will answer the LB Health Checks and will get the traffic. This failover should happen within seconds.
On the external side, the Public/Private Cluster IP will move via Azure API calls from the Master to the Backup which could take a while
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can set up the firewall using a VMSS.
https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_VMSS_for_Azure/Default.htm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We don't want to use VMSS, we have already deployed cloud guard high availability R 8.40 in azure. We want to utilize the same.
Can you please confirm what will be the next hop in route table. Is it backend ILB and Cluster VIP or is it gateway eth0 and eth1 interface IP?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The HA works as you describe: by changing UDR routes.
The fact it can take some time for Azure to process the relevant API calls is one of the limitations of this approach.
The canonical (supported) approach to resolve this is to deploy with VMSS.
You might be able to change how the HA works by modifying the azure_ha_test.py script, but I assume this won't survive an upgrade...or be supported.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the explanation, One last question.
If I use backend ILB and Cluster VIP as a next hop in the azure route table, during failover will checkpoint API calls modify the next hop in the azure route table?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pretty sure it's supposed to go to the ILB.
Refer to the documentation: https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_IaaS_HighAvailability_for_...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
with the latest HA template, I would expect no UDR modification at all. There should be a internal LB with a VIP. This VIP is the next hop for your UDRs and will not change. Only the Master/Active FW will answer the LB health checks, so the traffic is forwarded to the Master only. After failover, the Backup FW will answer the LB Health Checks and will get the traffic. This failover should happen within seconds.
On the external side, the Public/Private Cluster IP will move via Azure API calls from the Master to the Backup which could take a while
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the solution. This was the exact answer I was looking for.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for your answer. How many SPN we need in case we had two members ?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You only need one SPN with contributor rights for the resource group, the cluster is deployed in. If, during deployment, you decide checkpoint to create the SPN, they will create two, one for each GW. See for example
CP_CloudGuard_IaaS_High_Availability_for_Azure_R80.10_and_Higher_Deployment_Guide.pdf