Technical Tip: Recovering FortiGate from a bad OS disk after a failed upgrade in Azure

[Francesko]

Description	The article describes how to swap the OS disk of a FortiGate in Azure and restore the backup configuration file in the event of a failed upgrade or disk corruption.
Scope	FortiGate-VM in Azure.
Solution	In rare instances, the FortiGate OS (Operating System) Disk in Azure's Public Cloud may become corrupted after an upgrade. Stopping and restarting the VM from the portal does not bring the FortiGate to a working state and there is no output from the serial console. In such situations where recovery from an existing snapshot or disaster recovery plan is not possible, an alternative workaround may help restore the network to an operational state. Stop the affected FortiGate-VM from the Azure Portal. Warning: Public IP of a FortiGate VM may change in a stop/start event, if the IP is dynamically allocated. Deploy a new FortiGate VM through the marketplace with the same OS version that is shown in the latest working backup configuration file. Networking and other configuration details are not important at this point, however, remember the login information. Make sure that the new FortiGate-VM is fully licensed and shut it down through the CLI: execute shutdown Take a full snapshot of the OS (Operating System) disk on the new FortiGate-VM. Create a new disk from the taken snapshot. On the failed FortiGate VM, swap out the OS disk with the newly created disk. Warning: The old OS disk will be permanently deleted if it's decided to proceed further with this step. Connect to the serial console of the failed FortiGate with the swapped OS disk, and manually change the IPs of the interfaces to the correct IPs matching those showing in the backup configuration file. It is important to check the static routes and gateway IP configuration too. Login to the GUI and restore the backup configuration file. Note: Depending on the deployment time, the FortiGate could have been deployed as a Gen1 (Generation 1) VM. It is important to create the new FortiGate in the same VM Generation as the non-working one. Otherwise, restoring a Gen2 VM snapshot to a Gen1 deployment will not be possible. When deploying a new FortiGate from the Azure store on the v7.4 or v7.6 branch, Azure will not provide the option to select a Generation 1 VM type.  If the non-working VM is running v7.4 or v7.6 and using the Generation 1 VM type, the workaround is to deploy a FortiGate for the v7.2 branch, upgrade it to the same version as the non-working VM, and then proceed with the snapshot procedure. Detailed information regarding VM Generation support in Azure is available at the following link: https://learn.microsoft.com/en-us/azure/virtual-machines/generation-2