Technical Tip: Auto-restore a previous config if the change fails

Description

This article is a use-case scenario that provides the network administrator the possibility to quickly revert a bad config remotely and automatically in case the newly uploaded config removes routing or produces loss of access to the FortiGate.

Surely, a remote FortiManager or FortiGateCloud can help in such cases, but that also implies that the internet access is still available after the config change. This also applies to distributed deployments, such as SD-WAN environments, where it is problematic to lose management connectivity to a unit when changes related to routing are being applied.

Scope

Automatically restoring or rolling back a FortiGate configuration change in case of unsuccessful config load, without the need for local access to the unit.
It is focused on isolated environments, where no FortiManager or other tool exists to push the configuration to the FortiGate.

Solution

The regular rollback can be accomplished in a few ways:

1. This is valid for configuration changes that are performed in the command line:

config system global
    set cfg-save revert
    set cfg-revert-timeout 600 <- The default is 600s of admin session being idle.
end

execute cfg save  <- Execute this when all CLI changes have been made.

See related article Technical Tip : Using the save option 'set cfg-save revert' to automatically reboot and revert to a previous configuration of a FortiGate.

2. Use a USB stick inserted in the unit's port with the preloaded configuration (the one to default to), and load the config from USB. This can be done automatically through a script, but this is only good in cases where the USB exists/is already plugged into the unit.
   
   
3. Reload a configuration revision from FortiGate flash memory after a given time.
   This is the use case in focus.
   The problem arises when a pre-edited config is directly loaded on the FortiGate, which will trigger problems (access loss).

As a result, it is necessary to have the FortiGate auto-reload a previously good config.

Possible ways to achieve this:

• auto-script: this is not an option in this case because, regardless of the timeout, it runs for a first time immediately after the FortiGate boots up with the modified configuration, thus immediately restoring the previous config.
• automation stitch: this is the only viable method, but it can be triggered by various events.

Steps to take:

• Create a configuration revision in FortiGate GUI and note down the revision number. See related article: Technical Note: Using revision option to revert to previous configuration.

• Prepare the new configuration (the one to upload to the FortiGate).

In this configuration, it is necessary to add the following automation-stitch lines.

FortiOS 7.0.x (the delay is now added to the 'automation-stitch' as opposed to '-action' in 6.4.x):

config system automation-trigger
    edit "started"
        set event-type event-log
        set logid 32009
    next
end

config system automation-action
    edit "restorecfg"
        set action-type cli-script
        set script "exec restore config flash 1y"
        set accprofile "super_admin"
    next
end

config system automation-stitch

edit "cfg_reload"

set trigger "started"

config action
    edit 1
        set action "restorecfg"
        set delay 300
        set required enable
    next
end

next

end

FortiOS 6.4.x:

config system automation-trigger
    edit "cfg_reload"
        set event-type event-log
        set logid 32009
    next
end

config system automation-action
    edit "reboot"
        set action-type cli-script
        set delay 300
        set required enable
        set script "exec restore config flash 1y"
        set accprofile "super_admin"
    next
end

config system automation-stitch
    edit "cfg_reload"
        set trigger "cfg_reload"
        set action "reboot"
    next
end

Note:
This script is triggered by the 'FortiGate started' log (set logid 32009) and reloads the previous configuration (revision #1) after the delay (in seconds) has passed.

This is the time available to perform the checks and disable/remove the script manually.

Load this new configuration file into the FortiGate (GUI -> Username -> Configuration -> Restore -> Upload ).

• After the configuration is loaded and FortiGate boots up, it is necessary to check the connectivity and access.
• If checks pass correctly (and, most importantly, there is still have access to the unit), it is possible to remove the automation set up above. (It will also be possible to clear the associated elements):

config system automation-stitch
    delete "cfg_reload"

end

config system automation-action
    delete "reboot"

end

config system automation-trigger
    delete "cfg_reload"

end

Note:

These tests were performed in FortiOS 6.4.8 and 7.0.5.

The automation trigger can be set up differently. But if 'Reboot' is selected as action, run the 'exec reboot' command manually (it will not be triggered by a config restore action).