New firewall rules require OPNSense to be restarted before are enabled

[vileda]

Hi,

1st post so apologies if I've missed anything.

Running on Protectli type N100 fanless device with 8GB DDr5 Ram and 128GB SSD, Zenarmor plugin enabled.


OPNsense 25.1.5_5-amd64
FreeBSD 14.2-RELEASE-p2
OpenSSL 3.0.16


Basically, am really pleased with OPNSense and have Dual WAN, IPv4 & IPv6 DHCP and a few Vlans set up (most of this by trial and error as I'm not generally the network guy).

However I've found that half of my troubleshooting has been caused due to Firewall Rules not applying until OPNSense has been rebooted.

Can anyone advise if this is a known scenario/issue and any troubleshooting steps I can take to diagnose, luckily this is really really easy to replicate :)

TIA

[EricPerl]

There's an "apply changes" after rules have been updated but I assume you've seen that.
A reboot is not necessary.

The other aspect that could get in your way is that the firewall is stateful.
For example, if a connection is allowed, state is created for it.
For as long as that state exists, traffic will continue to flow over that connection.
Deleting the rule that allowed it does nothing. Adding a deny rule does nothing.

The state needs to be reset for that to happen:
* The connection is closed
* The state expires (inactivity)
* The state is deleted explicitly (FW diagnostics)
* The entire state table is dropped (same place)
* The FW is restarted
* OPN is rebooted

[vileda]

Thanks EricPerl.

Yes I've seen the apply changes button and reset state table, both seem to not resolve this.

I'm fairly certain that this wasn't always the case though so I've managed to break it at some point (maybe when configuring vlans)

I've seen a couple of references to this sort of scenario, but no fixes apart from reinstall which doesn't help me understand what's broken ( https://www.reddit.com/r/OPNsenseFirewall/comments/obw379/comment/ll89kn3/ )

Any pointers on which logs to interrogate would be appreciated

[EricPerl]

The "apply changes" is required for any change to become effective.

Resetting all states is a big hammer that I almost never use. It should be reserved for significant updates to the rule set, assuming that too much access was given and needs to be curtailed. It forces all connections to be re-established...

If something was blocked, an allow rule was added, and changes were applied, traffic will flow immediately.
State can never get in the way for such use cases.

From a logging perspective, you might be able to correlate configurations changes (system > configuration > history) with FW logs in some cases.
But once state exits, there are no logs for all subsequent traffic...

If you have specific series of steps that you don't produce expected results, feel free to add them.

[Greg_E]

If you decide it really does need a reboot, you could schedule it for a time period where no one is using the system, use a cron job from system --> settings --> cron and it is one of the preconfigured choices you can select. Turn it on when needed, off when not needed. Mine generally only gets turned on when I have a job to apply updates, in this case about an hour later than the updates to make sure everything is ready for the next working day.