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:
- 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 ....
- 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.
- 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).
