Rolling out OPNsense rules safely
A wrong firewall rule can cut your own access – and on a remote system only the console helps afterwards. This guide describes how to roll changes out so that a mistake corrects itself.
The risk of changing things by hand
Anyone who changes rules in the web interface writes the configuration and applies it – there is no way back of its own. If the new rule blocks access to the firewall, it can no longer be reached over the network. With several firewalls the risk multiplies.
The flow: preview, roll out, confirm
- Preview: OPNexus shows, per target firewall and field by field, what will be created, changed or removed.
- Roll out: the rule is written to the chosen firewalls and applied.
- Confirm: you have a time window (three minutes by default) to confirm that you still have access.
- Fall-back: if the confirmation does not come, OPNexus reverts the change itself: a newly created rule is removed, a changed one gets its previous state back.
What else protects you
- Checks for several targets: OPNexus warns if the same interface name means something different on different firewalls, or if an alias has different contents.
- Locks: nothing is rolled out during maintenance or a restore.
- Change history: every rule has revisions; earlier states can be restored and rolled out again. Every step is in the audit log.
- Open operations: while a change waits for confirmation, rolling out the same rule again is locked.
Hierarchical rulebases
With pre- and post-rules, policies can be inherited from top to bottom, for example organisation-wide blocks ahead of a group's own rules. Because every rolled-out rule is evaluated strictly “first match wins”, OPNexus establishes the order actively instead of leaving it to the luck of the push order.
Adopting existing rules
Rules that were already created by hand in OPNsense can be adopted into central management. Adopting writes nothing to the firewall. Rules that cannot be represented without loss (for example with an inverted source or several interfaces) are refused with a reason instead of being distorted.
Limits
- Deleting a rule is a deliberate action and has no fall-back window.
- Changes that can cut the connection to the firewall itself (for example on the management interface) cannot be reverted automatically, because OPNexus cannot restore a broken connection itself. There the protection is instead: preview, explicit confirmation and a backup before the change.
Frequently asked questions
What happens if I do not confirm?
When the time window ends, OPNexus reverts the change automatically. A newly created rule is removed, a changed one is set back to its previous state.
Can I change the time window?
The window is 180 seconds by default and is a server setting.
Does this protection also apply to VPN and network changes?
No, a different protection applies there: preview, explicit confirmation for risky changes and a configuration backup before every change. An automatic fall-back is not possible there because a broken connection cannot be restored remotely.
Try OPNexus
Free, self-hosted, source available. Installed in a few minutes.