Scheduled Configuration Rollback

How often have you been working on a FortiGate remotely and you want to make a change but are terrified you will lock yourself out from the device. It could be something as simple as adding a default route, making a change to an interface or even add a firewall rule. It would be great if there just happened to be some way to make a change on the FortiGate and it automatically roll back the change if there was no further interaction from the FortiGate administrator.

Many other network vendors accommodate a request like this via the concept of a “start-up configuration” and a “running configuration”. To schedule the roll back of a configuration on these platforms, the workflow would typically look like this:

Save the existing “running-configuration” (working) to the “start-up configuration”
Execute a command to reload (reboot) the device in 10 minutes
Execute commands to change the existing “running configuration”

In this case, if the changes to the “running configuration” causes an interruption where the administrator is no longer to access the device, the device will reload the original “start-up configuration” in 10 minutes and put the device back in its pre-changed state. Alternatively, if the changes to the “running configuration” work as expected, the administrator can cancel the reload command and continue working with the device.

While the FortiGate does not have this exact type of method for accommodating this request, it does have a solution for this particular requirement.

Default Configuration Behavior

The default behavior of the FortiGate configuration management is to “commit” and “save” the changes immediately. What this means is that as soon as you make a change to the configuration, it takes effect immediately. Also, if you were to reboot the FortiGate after making those changes, they should be retained upon completion of the boot process with the FortiGate. This is usually the desirable behavior, however, in the case as identified earlier in this post, this causes a problem.

Changing behavior to Revert Configuration

To change this default behavior, FortiOS has a command called “cfg-save” under the “config system global” stanza. This command is defined in the CLI guide as:

cfg-save {automatic | manual | revert}
Specify the configuration file save mode for changes made using the CLI. Default is automatic.

automatic: automatically save the configuration after every change.
manual: manually save the configuration using the execute cfg save command.
revert: manually save the current configuration and then revert to that saved configuration after cfg-revert-timeout expires.
Switching to automatic mode disconnects your session. This command is used as part of the runtime-only configuration mode.
FortiOS CLI Reference – cfg-save

The configuration parameter we will use is the “revert” parameter which achieves exactly what we are looking to accomplish. This command will be used in the conjunction of the “cfg-revert-timeout” command which is defined as such:

set cfg-revert-timeout {integer} Time-out for reverting to the last saved configuration. range [10-4294967295]
FortiOS CLI Reference – cfg-save

In totality, the following commands should be used in order to configure this behavior.

config system global
    set cfg-save revert
    set cfg-revert-timeout <seconds>
end

Observing the Revert Process

When the commands to enable the revert process have been enabled on the FortiGate, the new workflow associated with changing a configuration is as follows:

Administrator makes a configuration change on the FortiGate
If the administrator does not execute the “execute cfg save” command, the revert process occurs once the timeout has been exceeded.

For this example, the following configuration will be used:

config system global
    set cfg-save revert
    set cfg-revert-timeout 120
end

With this configuration in place, the process of the FortiGate automatically reverting the configuration can be observed:

Preventing the Revert Process

When the administrator wishes to retain the configuration, they follow the following workflow:

Administrator makes a configuration change on the FortiGate
Administrator executes the “execute cfg save” command and the revert process is avoided.

Caveats

Changes made in the GUI are subject to the “revert” process, however there is no way to execute a “save” command in the GUI (must be done via the CLI)
If the timer expires and the configuration needs to be reverted, you may temporary lose access to the firewall and it will likely impact forwarding traffic through the firewall.
There are no means to commit/roll-back certain portions of the configuration, it will either be completely committed or completely reverted.
Some changes (such as modification to the “allow access” under an interface) do not qualify for the rollback process.

Hopefully this information will be helpful when you need to make a change to a remote FortiGate but need to have a back-out plan that does not necessarily require out-of-band access. Please leave a comment below on your thoughts of this feature.

5 2 votes

Article Rating