Reloading the OS for FortiGate Security Appliance

The OS reload process is used to rebuild a IBM Cloud® Virtual FortiGate Security Appliance (vFSA) server. This might be necessary in the case of a disk failure, bad configuration of the vFSA node requiring a rebuild, chassis swap, or any other event that requires a rebuild of the server.

The process typically performs the following actions:

• Reload the server host's operating system (OS). This generates a new host OS password.
• Install KVM in the operating system.
• Create a vFSA VM in the KVM.
• Reconfigure the vFSA with the default configuration for IBM Cloud.
• If the node is part of a cluster (HA only), then rejoin the existing cluster and automatically synchronize the configuration, session tables, and so on.

The process can take between 2 and 5 hours to complete. Stand-alone gateways are out of service during this period. For vFSA High Availability (HA) gateways, when you reload the OS on one of your servers, the vFSA fails over to another server in the cluster and continues to process data traffic. After the reload completes, the server rejoins the cluster.

For vFSA, the OS reload process cannot be used to update the vFSA version. You must use the FortiGate Fabric Upgrade tool to change the version. Details on downgrading and upgrading the vFSA version can be found in Upgrading the vFSA.

For a successful OS Reload on a vFSA, ensure the following:

• IBM Cloud allows only an OS reload of the vFSA with a certified version. Certified versions can be found in IBM Cloud Virtual FortiGate Security Appliance supported versions. When you run an OS reload readiness check, the version running on the vFSA is detected and stored. If this detected version matches a version in the supported version's list, then the OS Reload action can be run. If the node fails the readiness check with a host connectivity issue (blocking the OS reload from proceeding), open a case with IBM Support to override the readiness check to allow the process to proceed.

• Do not modify the vFSA configuration during the OS reload operation. For example, automated software agents attempting to modify one or both vFSA nodes. Configurations changes like these can corrupt the OS reload.

• For HA deployments, the admin password for the provisioned vFSA gateway must match the admin password that is defined in the vFSA portal. The password in the portal was defined when you first provisioned the gateway, and it might not match the current gateway password. If so, use SSH to connect to the vFSA gateway and change the admin password to match. You can then proceed with the OS reload operation.

• The vFSA configuration must allow admin SSH access to the vFSA private IP, before the OS reload request. This is required to rejoin the cluster. After the OS reload completes, if wanted, you can disable SSH access again.

• Do NOT perform an OS reload on both servers of the Highly Available gateway at the same time.

  Performing an OS reload on both servers of the HA gateway at the same time destroys the vFSA cluster and causes the gateway to be out of service. If the vFSA cluster is destroyed, you must use the Rebuild cluster option to reprovision the vFSA and re-create the HA cluster.

• The IPMI interface for the bare-metal server must be enabled or the following error is issued:

  You cannot toggle the IPMI interface while transactions are running.