Config rollback whenever a change is made, with auto-rollback option
when ever a change to config is made, create a a backup of the previous config with an option for auto rollback. this is useful incase a config change locks out the administrator. other vendors such as juniper already include this.
J Brunner commented
Great idea, Cisco hardware has been able to do this for many years now, time to catch up.
Think of this...
You have a production environment making money...but you need to test a firewall change without a dev lab. What to do?
What about having a variable that applies the change BUT after X seconds auto rolls it back. That way you can test the policy change without much of a blip.
I'm thinking about a box in the UI and a command line option such as "/test 10" to test the change for 10 seconds then auto rollback.
Bill Roland commented
Good idea especially for those who work on the firewall remotely.
This is a really important feature that would greatly improve the resiliency of the system along with helping protect users from themselves.
Expanding on the original idea a bit - let's extend the backup library beyond just the most previous. For example, with pfSense, configs are saved on a per save event basis and all configs are time\date stamped along with an overview of what changes were saved. In essence, each of these backed-up configs is a restore-point that can be used to take the system back to a known good condition at some point in the past.
Additional add-ons to this would be to specify how many configs to keep -both on a discrete number and date basis; how long to keep configs; ability to specify individual backups as persistent so they are not purged or deleted unless explicitly done so by the user; specify a backup config as the auto restore point; etc...lots of great things become possible by implementing this feature.
This could work in a variety of ways but I think the following is probably the best and safest:
--- Prior to performing any config changes, the user would enable failsafe mode. Once in this mode, config changes are not committed until the failsafe is explicitly turned off by the same user. This ensures that a lockout condition does not exist.
--- If the user does get locked out, they will not be able to turn failsafe off. They then need to just log back in via a new session.
--- This will be possible because failsafe has not yet committed the change(s) that locked out the original session.
--- It would also be good to have this configurable in a couple of different operational modes: (A) ON by default upon login and then turned off after the user is confident as to the config not causing a lockout (preferred); (B) Toggled on\off by the user on demand (more risky).