Fortigate new Workspace Mode to commit changes in a batch - with an example of changing default gateway


Introduction

Fortigate saves and applies changes made on CLI immediately after you issue end / next commands. And this can be a problem, if you, for example, need to change WAN IP address AND default gateway of the Fortigate at the same time. Or if you want multiple changes applied if, and only if, all of those changes are successful or else roll back all those changes.

Important facts about WorkSpace Mode

Starting with FortiOS 6.2 Fortigate firewalls have a new feature - WorkSpace Mode that enables all such cases. Few facts about this feature:

  • The algorithm is simple: you start this mode on CLI with execute config-transaction start, you make all the changes you want, you commit changes and finish the configuration session with execute config-transaction commit.

  • When you edit an object in this mode, the object is locked and other admins cannot edit it at that time.

  • WorkSpace transaction is universal for CLI and GUI - the locked in CLI object cannot be edited in GUI management as well until the transaction expires/finishes on CLI.

  • The WorkSpace mode is available to all administrator users of Fortigate, subject to the usual permissions for a user.

  • There is an Idle Timeout (5 mins by default, can be changed), which discards all the changes and aborts session if the user is inactive for that much of a time.

  • If an admin user disconnects/loses connection while transaction is active, all changes are discarded when the session expires on Idle Timeout. You cannot re-connect to the lost/someone else’s session.

  • Changes can be aborted by the admin at any time until committed with exe config-transaction abort.

  • There can be multiple WorkSpace sessions by the same or different users, provided they edit/work on different subconfig trees/objects. That is, say user admin is logged in and configures routing, then you can still log in with admin in another session, and configure anything except routing.

Example - change WAN IP address and default gateway

Let’s see an example and it will make everything clear. We have a Fortigate connected to the Internet via the interface port1. The IP is 10.10.10.111, the default gateway is 10.10.10.2. We need to change IP to 192.168.213.3/24, and the default gateway to 192.168.213.30/24. All this while connected through the port1 interface.

Let’s start WorkSpace session.

exe config-transaction start mins

FGT-7-2-0 # exe config-transaction start 10 (1)
config transaction (id=7) started
  1. 10 here is the Idle Timeout in minutes, as the default of 5 minutes is too short

Verify that the session runs:

diagnose sys config-transaction status

FGT-7-2-0 # diagnose sys config-transaction status
The CLI is running config transaction (id=7)

Do the configuration we need

We need to change IP address on the interface and the default gateway.

config system interface
    edit "port1"
        set vdom "root"
        set ip 192.168.213.3 255.255.255.0
        set allowaccess ping https ssh http fgfm
        set type physical
        set snmp-index 1
    next
end
config router static
    edit 1
        set gateway 192.168.213.30
        set device "port1"
        set comment "Default Gateway to Internet"
    next
end

Verify

Let’s connect in a second session with the same user admin and try to edit static route:

FGT-7-2-0 # config router static
Can not config the object since either the object or the referenced objects are
being configured by other transactions.
Command fail. Return code 14

As you see, the user cannot edit object that was/is edited in the 1st session where the WorkSpace session started. Also, in this session, we cannot yet see changes made in the 1st session as they were not committed yet.

FGT-7-2-0 # show sys int port1
config system interface
    edit "port1"
        set vdom "root"
        set ip 10.10.10.111 255.255.255.0
        set allowaccess ping https ssh http fgfm
        set type physical
        set snmp-index 1
    next
end

We can see information about the running WorkSpace session(s):

diagnose sys config-transaction show txn-meta

FGT-7-2-0 # diagnose sys config-transaction show txn-meta
txn_next_id=8, txn_nr=1

Here, txn_nr shows number of currently active configuration sessions.

Next command, run inside WorkSpace session, will show all the changes made so far in this session - important to check yourself before committing:

diagnose sys config-transaction show txn-cli-commands

FGT-7-2-0 # diagnose sys config-transaction show txn-cli-commands
  config router static
      edit 1
          set gateway 192.168.213.30
      next
  end
  config sys int
      edit "port1"
          set ip 192.168.213.3/24
      end

We can see short info on active sessions also with

diagnose sys config-transaction show txn-info

FGT-7-2-0 # diagnose sys config-transaction show txn-info
txn_id=7, expire=1193 seconds, user='admin', userfrom='ssh(172.14.14.1)',
clicmd_fpath='/dev/cmdb/txn/8_zkDnGZ.conf'

If the user is idle for the set duration, Fortigate warns 1 minute before expiring the session, then undoes all changes and finishes the session.

FGT-7-2-0 # config transaction id=7 will expire in 30 seconds
config transaction id=7 will expire in 20 seconds
config transaction id=7 will expire in 10 seconds
config transaction id=7 has expired

Commit the changes and finish the session

Once we have done all the changes, we can commit and made them active with

exe config-transaction commit

FGT-7-2-0 # exe config-transaction commit
config transaction (id=7) committed

In another session I run non-stop ping to the 8.8.8.8 and after committing the changes that included change of the WAN IP and the default gateway, there was no single ping lost! That is, downtime 0.

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