Fortigate saves and applies changes made on CLI immediately after you issue
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
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
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(188.8.131.52)', 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 184.108.40.206 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.