Technical Tip: How to configure FortiGate Active-Active cluster using autoscaling in Azure without VMSS

[lpizziniaco]

Description	This article describes FortiGate autoscaling in Azure without VMSS infrastructure.
Scope	FortiGate Azure.
Solution	In an Azure deployment, it is possible to create an active/active FortiGate cluster. The easiest way is via the Azure Marketplace, or as described in the official documentation, by the way it is possible or deploy all the needed elements one by one, and for sure some deployments even if are not officially suggested can be deployed and make them work correctly. This is the case of the topology described in this article: ELB/ILB Active-Active Cluster with auto-scale configuration without VMSS. This approach is uncommon, but it is used by some FortiGate administrators. In some cases, administrators would prefer to avoid the Azure Virtual Machine Scale Set (VMSS) infrastructure due to cost or other constraints that do not comply with certain design decisions. In such cases, a simple auto-scale configuration can be the way to go. This deployment is not typically prescribed but since it is easy to make it work is seen as a valid alternative (that is not officially supported). In this Active-Active setup, the FortiGate VMs are independent units, the configuration synchronization between units is granted by the autoscaling setup. The auto-scale grants the synchronization of all configurations except for the specific sections proper to the VM itself like hostname, routing, and others.  What is interesting about this kind of deployment is during the life of the infrastructure, administrators may need to add secondary units to the cluster to better balance the data flow and ensure optimal service. Here are the instructions. After creating the initial set of units and connecting to external and internal load balancers, it is essential to elect one FortiGate as the primary and then configure auto-scale for it: config system auto-scale    set status enable    set role primary    set sync-interface "port1"    set psksecret AVeryBigSecret end For all other devices within the cluster, the configuration should resemble the following: config system auto-scale    set status enable    set sync-interface "port1"    set primary-ip <the IP of the primary device over port1>    set psksecret AVeryBigSecret end Each time another unit is configured and attached to the cluster the above system auto-scale configuration section must be added. From a general point of view, if the configuration is correct, the HATalk process will start showing information on the secondary device's serial console, like the following: secondary's external files are not in sync with the primary's, sequence:0. (type CERT_LOCAL) secondary's external files are not in sync with the primary's, sequence:1. (type CERT_LOCAL) secondary's external files are not in sync with the primary's, sequence:2. (type CERT_LOCAL) ... secondary succeeded to sync external files with primary secondary's configuration is not in sync with the primary's, sequence:0 secondary's configuration is not in sync with the primary's, sequence:1 ... secondary starts to sync with primary logout all admin users After completion, the FortiGate GUI dashboard will display autoscaling information, below is an example of a primary unit: During its lifetime, a cluster may need an upgrade. To better achieve this, it is recommended to initiate the upgrade process from the secondary devices. Before proceeding, ensure that all units are synchronized. While upgrading a unit, if there is data flow passing through it, the connection or session (SCP or SSH) may experience a drop.

[sinanalshoker]

Good Job Luca, and many thanks