How to Upgrade Checkpoint GW (CloudGuard) in Azure Environement
I have a Cluster GWs running on R80.10 in Azure and i want to upgrade it to R80.40, i did not see any link where Upgrade/Migrate process explained, I checked below mentioned link which looks like a new deployment guide.
But my Question is, once I setup a new cluster in Azure with R80.40 template then what all changes do i need to do in my MGMT server to bring new Cluster into the MGMT... i want to use the same IPs (of Eth0/Eth1 and VIP) on New cluster (R80.40) as I am using with current GWs (R80.10) cause i dont want to touch the Routing (UDRs) in Azure.
Is there any upgrade/Migrate guide available from Checkpoint side to do this activity without any issue..
I upgraded CP firewalls in Azure via web UI like a regular onprem gateway and did not have any issues. I can logically only assume that process would be exactly the same for cluster (you can do either zero downtime upgrade or MVC (multi version cluster upgrade) as well, but I will let other people confirm for you.
I dont think so as we can upgrade the GW cluster or MGMT server in Azure as we do in traditional hardware box via WebUI or CLI.. as per my knowledge, there is no upgrade.. there should only be a migrate .. means we need to choose the desired template solution available in Azure Market place and install the cluster as a new GWs which comes along with 2 LBs (Internal and External).
but i want to be double sure on my knowledge as we have to proceed with this activity very soon.
hence waiting for others to reply on this matter please.
I could be mistaken, but Im pretty sure the ones I upgraded were actually deployed by Azure script/template. Anyway, lets see what other guys have to say, agreed.
Per sk173635, you need to deploy a new GW cluster and move routes/change IPs. It IS possible to use the same public IPs, but it's a little more involved.
If you can wait a bit, the ability to do in-place upgrades just like our hardware appliances is coming. I can't comment on exact timing, though.
In general, I encourage you to check out CloudGuard Network for Public Cloud - Frequently Asked Questions page, as it contains valuable information that may be useful.
Regarding the upgrade procedure, the correct way to do that so far is side-by-side as clearly documented in Azure HA admin guide, in the upgrading section.
Please note that since R80.30, the cluster solution has been changed to the High Availability solution that improves performance, and reduces failover time.
To keep the existing Cluster VIP, you can follow sk173632 to convert the cluster VIP from Basic SKU to Standard SKU, and update the solution.
We are checking internally on the feasibility for an in-place upgrade solution for Azure starting R80.30 version. If relevant, we'll update Azure latest updates sk with a link to the instruction guide.
Not sure, but it was someone from DTAC I was working with and they mentioned they consulted with Escalations and said they also confirmed it was perfectly fine to do upgrade like regular firewall via web UI, which is exactly what I ended up doing and it worked like a charm.
The likely reason is quite simple: from R80.20 we were using the Linux 3.10 kernel in Public Cloud images as it was necessary to support the newer virtual hardware types.
R80.20/.30 3.10 images were not exactly maintrain, though I believe you can CPUSE upgrade them to R80.40+.
However, don’t believe this was tested in the cloud.
Also, if the upgrade fails, your recovery options are limited since you don’t have console access.
Like @Mark_Halsall said, formal support for in-place upgrades in the cloud are planned.
Can’t see it being supported from R80.10.
Thanks D. Thats definitely good to know! But, just curious, isnt this same method as regular physical device where if upgrade was to fail, it would simply go back to current version or does Azure instance work differently?
Theoretically it should work the same.
However, there may be some differences.
Certainly if the supported underlying hardware changes from version to version (also the case coming from R80.10), you may also have to make some other changes to affect a successful upgrade.
The upgrade might have succeeded due to a gap in the deployment rules logic (something we will check and block if indeed permitted). CPUSE upgrades are not supported as the upgrading images do not contain all the necessary content for cloud (python scripts, drivers etc.). Therefore, forcing an upgrade may cause unexpected behavior and may also fail the rollback.
As Ariel wrote above, this capability is on our short-term roadmap for AWS & Azure Gateways and Cluster. Once available we will publish it on our Latest Updates SK articles for AWS & Azure accordingly. We plan to support upgrades from R80.30 to later versions. Upgrading from versions R80.20 and below will not be supported as in-place, rather as side-by-side upgrade as documented in the solution's admin guides.