Easy way to revert changes, especially for remote locked-out scenarios

[hutiucip]

Maybe a "Cisco-like" approach would be something worth considering?

I mean, having 2 separate configs:

1. A running config, effective immediately at "Save"
2. A start-up config, effective at OS load. Would require an extra "Save to start-up config" step to be modified.

This way, if a mistake is made, and you get locked-out or something, a restart would be also a roll-back, since no "Save" has been made to the start-up config yet.

Thank you!

[thutex]

i can see the potential benefit, but it still would not be "remote lockout" (i.e.: if it were remote, you would likely not be able to reboot the machine anyway, unless connected to a pdu that would not be behind the firewall...)

so since you would still have to be onsite, it can always be managed either via console or (if applicable for your appliance) by just attaching screen and keyboard. and if this option exists, there wil always be people that forget to save and then complain...

alternatively, you can also get the hardware with ipmi, giving you a remote shell, which in turn will also allow a rollback remotely afaik, since configs are saved for every change.

so yes, i can see a potential benefit... but i doubt its worth the time to implement due to the -imho- better alternative options?

[hutiucip]

Hi!

It would be much more easier to find in that remote location a pair of "dumb enough hands" able to only cycle the power than a pair of "smart enough hands" able to properly reinstate a backup config.

Otherwise, I completely agree with everything else you have said, 100% true and standing.

Thank you.

[johnr14]

I just messed up my config trying to configure multi subnet routing with the firewall. So I got here from google, must mean that it's more frequent than expected.

EDIT : Comments retracted as I was able to find exactly what I was proposing in the system->configuration->history tab. Looks like I was able to salvage the installation and not restart from scratch. I did not see shell provide a revert to history version CLI. That would be nice.

[thutex]

@johnr14 shell option 13: Restore a backup ;)

[banym]

Franco was so nice to point me to this request since I posted a similiar FR here: https://github.com/opnsense/core/issues/3695

For me a similar functionality would be nice, too. I prefer a solution that could be used from UI and CLI the same way. To be sure only one user is entering that configuration mode with potential reset a locking for the session would be necessary in my opinion. This way other administrators on the same firewall would see, that the system changes are maybe reseted by someone else. One more thing I would need is the possibility to select the configuration I want to revert to from the backup history for example. This way you could select the current running configuration when you enter the mode or you select a configuration from the past. If the timer runs out the selected configuration is applied. One more feature would be to select "revert and reboot", to be sure the firewall reverts to a configuration state defined ealier and then does a reboot to be sure everything works as requested. This could be handy if critical changes to interfaces are done that maybe need a reboot to be aktiv and fully functional.

From technical perspective I would prever an implementation that works the same way on UI and CLI so a service or helper tool that is triggered through api would be the way to go?

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

[tcsi-github]

I realize this is a bit of an old thread, however, rather than duplicating I thought it would be proper to post here.

I have multiple sites that am having to make several changes that could break access (Network address changes, Firewall changes, Routing, Etc.) ........ I'm scared. HAHA!

The remote sites have 0.75% technical experience. Yes, I might be able to find someone to power cycle a router. However, I've also worked as an MSP and had the resident "IT person" unplug the network cable to "reboot" which they thought worked because "the lights went off and came back on" (Link Lights) #facepalm

Needless to say, took me a bit to figure out that's what they were doing.

I was thinking about my MikroTik days and remember that if I happened to make a incorrect change that those changes would be reverted if I failed to connect back or didn't apply them within X time. Sometimes it was a pain, but it saved my butt so so many times. Kept me from having to make calls to talk someone through a reboot and just gave me a bit of room to breathe.

@banym had a good template as well and I include his here for comparison. Personally, I feel like the simpler thing would be to take a snapshot as soon as the breaking change option is enabled. I can see the use in giving the option for a timer, however, I would think setting a "middle-road" 120 seconds would be a default.

Describe the solution you'd like It would be nice to lock the firewall in a "major change" mode where only one session is able to do changes until the major change mode is exited. This mode should be able to define a working configuration from the backup config history or the current configuration when this specific mode is activated. It should be possible to set a timer for change commitment. Now the administrator can for example make significant changes to routing or rules that possible could lock him out of the firewall. If he does not approve that his change was successful and works as intended the firewall roles back to the defined configuration. This way the administrator can log in an "try" again or rethink his change

I would submit something the below as a rough draft for an option.

The ability might stay disabled by default and only enabled prior to the change. This would allow the option to stay out of the way and only be used when explicitly needed.

@fichtner -- I believe this to be a worthwhile addition to the OS and would be a step in the direction of more enterprise use-cases. My development skills are limited, however, I would commit to time testing and anything within my abilities to help this become a actual feature.

I would welcome any thoughts or feedback on the suggestion.

Example Change ---> Admin has to change a WAN IP

Scenario - Successful Change

1. Admin logs in and enables "Breaking Changes Mode" (Or whatever better name)
   1. The working config is immediately snapshot.
   2. Notification alert is placed at the top bar
   3. No other logins are allowed but the user
   4. Working config is marked as the config to be used for restoration
   5. Perhaps the connection is marked for monitor?
   6. Timer Starts (120 second?)
   7. Notification Alert shows at top (See above)
2. Admin makes changes just as they normally would
   • Complete with "Apply Changes", etc.
3. Tests changes and is happy with results
   • Connection either not broken or reconnected within timer
4. Admin disables "Breaking Changes Mode"
   • Previous snapshot config is then removed to prevent use on reboot.
   • System returns to normal operation
   • Notification removed from top bar

Now lets try a screw-up....

Scenario - Failed Change

1. Admin logs in and enables "Breaking Changes Mode" as before
   1. Same as above happens to enable feature
2. Admin makes changes just as they normally would
   • Complete with "Apply Changes", etc.
3. Finds they have made a mistake and are unable to connect back to the GUI
   • Connection timer expires, or some other defined trigger
     • "Breaking Changes Mode" begins
       1. Previous Snapshot is automatically restored
       2. Router is Rebooted (if needed)
       3. Other actions such as logging the issue, etc...
4. Admin wait for completion of restore
   • Perhaps an email or other notification could be sent notifying all is well again.
5. Admin is able to start again, thankful they have not created a bigger problem requiring an on-site visit (For me, an EXPENSIVE multiple day trip)