> Source: [sk172563](https://support.checkpoint.com/results/sk/sk172563) # sk172563 - How to perform a side-by-side upgrade of a CloudGuard Network Single Gateway for Azure | Property | Value | |----------|-------| | Solution ID | sk172563 | | Date Created | 2021-03-22 | | Last Modified | 2025-01-07 | | Technical Level | General | | Products | Cloud Firewall | | Versions | R81 (EOS), R81.10 (EOS), R81.20, R82 | | OS | Gaia | | Platform | Azure | ## Solution **Prerequisites:** * Check the Management Server's compatibility with gateway version, see [sk113113](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk113113&partition=Basic&product=Multi-Domain). * Make sure there is IP availability for deployment in the Azure account for Front-End and Back-End subnets. **To use in-place upgrade on a CloudGuard Network Single Gateway for Azure:** Refer to [sk177714 - In-Place Upgrade packages for CloudGuard Network](https://support.checkpoint.com/results/sk/sk177714) to perform an in-place upgrade from version R80.30 and above. **To use side-by-side upgrade on a CloudGuard Network Single Gateway for Azure:** 1. Log in to the Azure portal. 2. Deploy a new Check Point Single Gateway in the needed version. 3. During deployment, select the same subnets as in the existing CloudGuard IaaS Single Gateway solution. Notes: * If it is necessary to deploy the new gateway to the same Resource Group, then it is possible to deploy the new gateway to the same Resource Group that the original gateway is located in. Use the template deployment from the [Check Point official GitHub page](https://github.com/CheckPointSW/CloudGuardIaaS). * It is possible to deploy a new vNet and use vNet peering, this setup is considered a Security Spoke. 4. Define the same Static Routes as the old gateway on the newly deployed gateway: 1. Check current routes on the original gateway: `#netstat -rn` 2. Connect to SSH to the newly deployed gateway. 3. Log in to Gaia Clish, or Expert Mode. 4. Add these routes: * * In Gaia Clish: `>set static-route nexthop gateway address on` When done, save the configuration: `>save config` * In Expert mode: `>clish -c 'set static-route nexthop gateway address on' --s` Example: `set static-route 10.0.0.0/16 nexthop gateway address 10.0.2.1 on` **Parameters:** |---------------------------------------|------------------------------------------------------------------------------------------------------------| | Parameter | Definition | | `` | Specifies the prefix of the entire Virtual Network. Example: `10.0.0.0/16` | | `` | Specifies the first unicast IP address on the subnet to which the `eth1` is connected. Example: `10.0.2.1` | Notes: * * If the Virtual Network comprises several non-contiguous address prefixes, repeat the command for each prefix. * For vNET peering, add a compatible route on each peer network 5. Update the existing Gateway object in SmartConsole: **Important - Do not install policy.** 1. In SmartConsole, double-click on the current gateway object. 2. In **General Properties** do these steps: 1. In **IPv4 address**, enter the new gateway's IP address. 2. Note - Depending on how the gateway is managed or if VPN is used, this must be the main public IP address that is used. 3. Click **Communication** \> select **Reset** to reset the SIC. Enter the new **One-time** password and select **initialize**. This establishes a new SIC connection. 4. Below **Platform**, update the version to the version of the new gateway. 3. In **Network Management**, confirm that all interfaces have their correct private IP addresses. 4. For a VPN configuration in **IPsec VPN** , select **Link selection** . 1. In the **Outgoing Route Selection**: 2. Click **Source IP address settings**. 3. Select **Manual**. 4. From topology table, select **Selected addresses**. Note - For correct VPN configuration for a single gateway, see [sk109360](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk109360&partition=Basic&product=CloudGuard) **Important - Connectivity is lost during the next steps** 6. Updating Load Balancers Important - This section is only required if a Load Balancer was deployed for inbound NAT. **Note** - In Azure there are two types of Load Balancers, see . * * Basic Load Balancer - Default deployment earlier than March 2018 * Standard Load Balancer- Release date: 22 March 2018 **How to update a Basic Load Balancer:** 1. 1. In the Azure Portal, select the Azure Load Balancer used for inbound NAT to the Check Point gateway. 2. Select the Inbound NAT rules. 3. Update the Network IP Configuration for each NAT rule that points to the old gateway and update with the new Gateways `eth0` IP address. **How to update a Standard Load Balancer:** There are two methods used on the Standard Load Balancer for inbound connections: * * Inbound NAT rules * Load Balancing rules **Updating Standard Load Balancer NAT rules:** 1. 1. 1. In the Azure Portal, select the**Azure Load Balancer**used for each inbound NAT to the Check Point gateway. 2. Select the Inbound NAT rules. 3. Update the Network IP Configuration for each NAT rule that points to the old gateway and update with the new gateways `eth0` IP address. **Updating Load Balancing rules:** 1. 1. 1. In the Azure Portal, select the **Azure Standard Load Balancer** that is used for inbound NAT to the Check Point gateway 2. Create a new **Backend Pool** and add the new gateway to this backend pool. 3. Select **Load Balancing rules**. 4. Update the**Backend Pool** with the new pool created. 7. Edit any UDR to point to the new gateway. UDRs must point to the `eth1` address. 8. Install Policy onto the new gateway object. 9. Before continuing, verify that all the traffic flows work as expected. 10. Delete the original CloudGuard gateway and other redundant resources. Notes: * * If you use resources from the old resource group such as VNETs or cluster IP addresses, do not delete them. * If deployment was made into the existing Resource Group of the previous member, it is necessary to only delete these items: the original gateway, the original NICs, and storage accounts. **Routing (UDR) Troubleshooting** This step is used to identify or verify routing Azure is sending traffic to the Check Point gateway. 1. Locate the VM in question in the Azure portal. 2. Select the VM's interface. 3. Locate the Effective Route tab. 4. Review or download the effective Route Table. 5. Review the effective route and confirm that there is a UDR pointing to the new Check Point `eth1` interface. **Related Solutions:** [sk109360 - Check Point Reference Architecture for Azure](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk109360&partition=Basic&product=CloudGuard) --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content