CloudGuard IaaS - Upgrade from R80.10 to R80.40

[scottikon]

Customer currently has an on premise R80.40 management server and as well as on premise gateways, they have a HA cluster in Azure UK South (primary DC) running R80.10 and they have a single gateway in Azure UK West (DR) also running R80.10.

I have read the attached guide and labbed this up and thought I was comfortable with it. However, reviewing the customer’s Azure configuration it is not deployed as per the guide. Listed below are the differences: -

• There are no frontend or backend load balancers deployed connected to the Check Point virtual machines.
• There is no cluster address configured on eth0. Both eth0 and eth1 are configured as sync interfaces and therefore just have the physical addresses.
• The load balancer the customer has configured with the Public IPs use inbound NAT rules. The target is one of the cluster members and the customer has advised that when the cluster fails over, the inbound NAT rule target is updated to target the new active cluster member. Was this a feature in R80.10? I have configured this with R80.40 to test it and it didn’t work this way.
• The routing from internal networks all use a single routing table which targets the active cluster member IP. Again the customer advises that if the cluster fails over, the routing table will update to the new active cluster member IP.

I need to determine if when we deploy the R80.40, do we deploy it and then amend the configuration to integrate with customer’s existing deployment or will the customer be required to re-configure their load balancers to  be in line with the deployment guide?

[PhoneBoy]

Sounds like they have a standard Active/Passive ClusterXL configuration in IaaS which doesn’t require front end or back end load balancers.
When a failover occurs, we change the UDR appropriately (when configured properly).

For various reasons it’s not possible to simply do an in-place upgrade, so you’ll have to install a new R80.40 cluster and integrate it into the customer’s configuration.

[scottikon]

thanks. I thought this was the case and assumed I had missed something in the configuration. Are there any configuration guides or can anyone reply with any additional config/steps required for this to work?

Additionally, if we installed the cluster side by side and then updated the UDRs to point to new cluster member 1 interface IP, will this prevent the first cluster updating the UDRs or is there something we need to do to break that link. 

im trying to put the steps together including any rollback steps. 

thanks 

[PhoneBoy]

If you deploy the clusters side by side and change the UDR to point to the new cluster, you will need to shut down the old cluster to ensure it doesn't change the UDR back 🙂

As far as documentation on upgrade steps goes, see: https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_IaaS_HighAvailability_for_.... 

[scottikon]

Thanks @PhoneBoy . Regarding the documentation, I was referring to your comment: -

"Sounds like they have a standard Active/Passive ClusterXL configuration in IaaS which doesn’t require front end or back end load balancers.
When a failover occurs, we change the UDR appropriately (when configured properly)."

Is there any guidance on how to do this configuration so we can get the cluster to update the UDRs so it can be deployed without frontend/backend loadbalancers?

Thanks

[VictorPG]

I think your customer has the first R80.10 template, which makes the UDR changes according to which Module is active in the cluster. This template is called "cluster" but the new one is cluster-ha (you can check doing a cat /etc/cloud-version in the firewall) and how clustering works its completely different. The "cluster" template is only available in version R80.10 (maybe R80.20) and it's not recommended anymore. In the Cluster-HA template you need to use the balancers (I'm pretty sure of the backend one...the frontend it's not necessary if you don't have any publications)

[scottikon]

Thanks Victor, 

I was doing some more research this afternoon and have come to the same conclusion but hadn't read anything conclusive. There are two SKs I have seen: - 

• sk122793 - Deploying a Check Point Cluster in Microsoft Azure - for templates older than 20180301
• sk110194 - Deploying a Check Point Cluster in Microsoft Azure - new deployment template version 2018...

SK122793 describes what you have stated. I had hoped SK110194 might detail the new template and load balancers etc. However, I suspect SK110194 needs updating as it doesn't include some of the details that are included in the CP_CloudGuard_IaaS_High_Availability_for_Azure_R80.10_and_Higher_Deployment_Guide.pdf.

SK110194 suggests you can still update the UDRs via API calls rather than using backend load balancer. 

I have asked our Check Point SE if there is a recommended/preferred method  (i.e., best practice) but no answer as yet. Be good if anyone from the Check Point Cloud Architecture team can advise. 

Kind Regards

Scott

[VictorPG]

I honestly  don't think is possible to update de UDRs via APPI calls in the new template, since the  cluster-ha  works completely different to the previous one. Also, the failover times are lower  in the new template, since you are using the same IP in the UDRs (the backend balancer) and no changes are done (depending of the numbers of UDRs it could time some time in the previous template)

Also for the migration keep in mind:

-Possible Changes in NAT policy Rule for the Cluster. This is because the previous template used NAT RULES in the FrontEnd Balancer, while the new one  uses Load Balancing Rules (so you have to migrate all the NAT rules configured in the FronEnd balancer to  LoadBalancing rules in azure and also make changes in the NAT policy Rule in the smartconsole. 

- Public IP addresses. I don't remember if the old template uses standard or basic Public IP address, but the balancers  in the new template are the Standard kind, which means that the Front End Balancer can only use Standard Public IP Addresses (in case you want to reuse the Public IP address from the previous cluster for publications)

-Do you have any VPN site to site? Only  in the latest R80.40 template (actually, maybe since the October R80.40 template) you can reuse the Virtual Public IP address for the VPNs site to site, but you need to make some changes. Keep in mind that this IP is different to the one used for the FrontEnd balancer. 

[scottikon]

Thanks Victor.

It would be useful if Check Point published details on the templates and a revision history. 

This gives me a few things to validate as part of planning. 

Kind Regards

Scott