Ok, if you are reading this, you already know that it is not as simple as running CPUSE to upgrade from Checkpoint R77.30 to R80.10 in Microsoft Azure. In fact, its not even supported in Microsoft Azure (or any public cloud). Checkpoint’s preferred approach is an in-parallel upgrade and migration of services across. Wow, ok so while this reduces risk considerably it really depends how complex your Azure and Checkpoint deployment is. In the recent in-parallel upgrade we did for a client this change was almost a mini project.
Things to consider:
Azure complexities, the client had 10 VNETs with over 20 different routing tables. This meant ensuring that the Checkpoint cluster SPN had contributor rights to all resource groups containing routes to the Cluster. Checkpoint’s new test script is very useful to ensure you have all this covered
Checkpoint functionality used, in this instance, FW, VPN, URL and APP Control were used. You can clone policies, assuming your old and new cluster are managed by the same Security Manager which makes this process a lot simpler, however the VPN functionality needs to be carefully considered. When we cutover to the new firewall cluster in a change window, the VPN from On-Prem to the Azure hosted Checkpoint cluster had issues, ranging from SA’s timing out and the VPN being completely down to not all subnets being encrypted, the classic and unhelpful “no valid SA error”. Essentially after hours of troubleshooting this turned out to be issues with the interface and link selection causing IKE negotiation issues. Even though this was configured as per the Checkpoint reference architecture (i’m not mad, i’m just very disappointed). We reverted to using a link selection profile we had deployed on another R77.30 Azure deployment successfully, reset the IKE and IPSec SAs using vpn tu and hey presto a successful in-parallel upgrade.
What we took away from this experience was a very detailed runbook and test plan to ensure we captured all the VNETs and user defined routes that required changing and testing services hosted in different VNETs and subnets to ensure all subnets were routable across the VPN.
The only benefit of this saga was the ease to rollback to the original checkpoint cluster if necessary as very few changes had been performed on it during cutover.
Network Jigsaw 