Fortigate - revert configuration as a safety measure, analog to Cisco reload in, or Juniper commit confirmed

in Fortigate
#Fortigate

Introduction

I want to talk today about the safety switch the Fortigate has for us when changing its configuration and something goes wrong. Most reputable vendors have such rollback-if-sh*t-happens - Juniper has commit confirmed <minutes>, Cisco routers have reload in <hh:mm:ss> and Fortinet does too - cfg-save.

This setting is part of the global configuration and looks by default like that:

FGT4 # get sys global | grep cfg

cfg-save : automatic

The key word here is automatic - it means once you hit Enter on CLI or click Apply in GUI, the changes are automatically saved to the configuration file of the Fortigate on flash. It also means they (configuration changes) will survive reboot. So, what happens if you make a mistake or miscalculate the consequences of the config change and lose management access to the Fortigate? Well, the solution is physical access to the Fortigate with a console cable. To prevent this, all we need to do is change cfg-save from automatic to revert before doing the risky changes.

After we change this setting, any change to the configuration you do either on CLI or in GUI, will take effect immediately (as usual) but will BE REVERTED BACK if you do not manually save this change and your session times out. The time out you set too with set cfg-revert-timeout <seconds>.

Warning
 When reverting changes on time out, the Fortigate will RE-LOAD the saved configuration, which means it will NOT reboot (technically), but there will be disconnection of all passing sessions still. So, this operation of rolling back will cause very short downtime, from my experience - 20-30 seconds if dynamic protocols involved. Just be informed.

Step by step instructions for CLI

  • Before making the planned configuration changes, set on CLI cfg-save to revert:

config sys global

set cfg-save revert

Do not leave the global config yet, read on

  • The default idle time-out, if you do not change it, will be 600 seconds, or 10 minutes. This means if you cause downtime by doing changes, they will be reverted after 10 minutes of your losing the access to the Fortigate. If you want to change it (still in sys global config mode):

set cfg-revert-timeout 120

end

Here I set idle time-out to 2 minutes.

  • Now you can safely do the planned configuration changes (change default gateway, reset BGP/OSPF routing, change WAN IP address and so on), be it on CLI or GUI.

  • If your changes lock you out of the Fortigate and you cannot reconnect, just wait 2 minutes and changes you have done will be reverted.

  • If, on the other hand, you did changes and nothing bad happened - do NOT log out/leave the Fortigate yet. For changes NOT to be reverted 2 minutes after you log out, you have to manually save/commit them to the configuration file. You can only do this on cli:

exe cfg save

  • Lastly, do not forget to change back cfg-save to automatic, unless you want to play an evil joke on the next admin configuring this Fortigate - any changes they will do will be rolled back to much of their confusion.

config sys global

set cfg-save automatic

end

Instructions for GUI

  • Enable this setting:

The name of the setting differs by FortiOS version, but the path to it is the same: System → Settings:

cfg save fortios 7.0
cfg save fortios 7.4

  • Change the revert time-out if needed from the default 600 seconds.

  • Click Apply to save config.

After that, in the upper right corner will appear new information menu "Unsaved Changes". Clicking on it will tell us if there are unsaved changes and time until reverting back.

  • Now, do your planned changes and if the change you did goes OK, and no need to revert it - in the same menu you have the option to click "Save staged changes", like that:

cfg save fortios saved staged 7.4

OR, if something went wrong - just wait to the timeout and reboot of the Fortigate (it says reboot but uptime of the Fortigate stays the same, looks like only the config file is reloaded).

That’s it for this feature. There is another way of doing safe configuration changes that was introduced in FortiOS 6.2 which is CLI-only, and is called WorkSpace Mode. But it is more involved in its configuration and for one-time config change is probably not worth the effort. You can read more about this at https://yurisk.info/2022/04/04/fortigate-workspace-mode-commit-changes-example/

Fortimanager Note: For those Fortigates that are managed by FortiManager there exists another mechanism of safe changes, completely automated - you don’t need to do anything for that. If you push the configuration change via Fortimanager and this change causes this Fortigate to lose the management connection to the FortiManager - the Fortigate will wait for 15 minutes to restore the conneciton to FMG, and if not successful - will roll back these changes.

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ and https://github.com/yuriskinfo/ not to miss what I publish on Linkedin, Github, blog, and more.