You can configure synchronization from one standalone FortiGate to another standalone FortiGate (
standalone-config-sync). With the exception of some configurations that do not sync (settings that identify the FortiGate to the network), the rest of the configurations are synced, such as firewall policies, firewall addresses, and UTM profiles.
This option is useful in situations when you need to set up FGSP peers, or when you want to quickly deploy several FortiGates with the same configurations. You can set up
standalone-config-sync for multiple members.
When standalone configuration synchronization is enabled, there are some limitations, including but not limited to the following:
- Network interruptions occur during firmware upgrades: when upgrading the firmware, all members in the
standalone-config-syncgroup are upgraded simultaneously. This creates downtime if the FortiGates are the only outgoing gateway in the network. We recommend disabling the option before upgrading firmware.
- Some unwanted configurations might be synced: the current design and implementation of
standalone-config-syncis based on requirements from specific customers. Thus, some users may find that unwanted parts of the configurations are synced. Should this occur, we recommend disabling the option and modifying those configurations manually.
- The wrong primary device might be picked accidentally:
standalone-config-syncis derived from the HA primary unit selection mechanism. All members in the group will join the selection process in the same way as a the HA cluster selection process. It is important to select the correct device as the primary, otherwise the wrong device could be selected and existing configurations could be overwritten.
- Layer 2 heartbeat connections must be present: similar to HA heartbeat requirements, one or more layer 2 heartbeat connections are needed to sync configurations between the primary and secondary devices.
Two or more standalone FortiGates should be connected to each other with one or more heartbeat interfaces, either back-to-back or via a switch. In the following example, the device supplying the configurations is called "conf-prim," and the devices receiving the configurations are called "conf-seco".
- Configure the conf-prim device for the group:
config system ha set hbdev ha1 50 ha2 100 set priority 255 set override enable set standalone-config-sync enable end
- Configure the conf-prim device as needed to be functional.
- Configure the other group members as conf-seco:
config system ha set standalone-config-sync enable end
- Wait 10–15 minutes for the configurations to sync over.
- Verify the synchronization status:
# get sys ha status... Configuration Status: FG201E4Q17900771(updated 3 seconds ago): out-of-sync FG201ETK19900991(updated 1 seconds ago): in-sync System Usage stats: FG201E4Q17900771(updated 3 seconds ago): sessions=1, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=16% FG201ETK19900991(updated 1 seconds ago): sessions=1, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=16% ...
If all members are
in-sync, this means all members share the same configurations, except those that should not be synced. If any members are
out-of-sync, this means the member failed to sync with the primary device.
Debugging is similar when a cluster is out of sync.