Messages

Are you referring to this commit? https://github.com/opnsense/core/commit/7e93cdb63f030

I'm not catching the error in either, which doesn't mean it's not there.

Might be worth checking the system log file as well for "ifconfig" failures.


Cheers,
Franco

Yep, see https://github.com/opnsense/core/issues/9690


Cheers,
Franco

I checked legacy associated rules in the config.xml and they appear to have source and destination. I export them and the CSV has source and destination.

Can you check on your end where the data goes missing? I don't see a lot of potential for losing the values since the CSV is the same structure for all rules.


Cheers,
Franco

My understanding is no. No application on divert socket = no traffic passing through.


Cheers,
Franco

Historically "lo0" hasn't been an interface to put any rules on. I'd simply discard it.


Cheers,
Franco

Makes no sense to me. What does this dump?

# pluginctl -g filter.rule


Cheers,
Franco

See the screencapture of the interfaces - lan is there.

Ok, not an anti-lockout issue IMO.


Cheers,
Franco

Just for reference the plugin maintainer/author approved these changes in October. https://github.com/opnsense/plugins/pull/4952

It was in part merged because Fabian doesn't have time for improvements in OPNsense these days and we don't want to demotivate community submissions either.

Don't mind a bit of discussion, but this outcry is a bit misplaced in my opinion for a community-based plugin and changes in plain sight (on GitHub).


Cheers,
Franco

Yes, these rules don't really belong to the rules GUI. Just there for visibility as generated by the system for other settings/configuration.


Cheers,
Franco

Okay, once more. This has nothing to do with the upgrade whatsoever.

Go to Interfaces: Assignments and see the "Identifiers" for all your interfaces.  I'm guessing there's no "lan" because you deleted and redid it at some point, could be years ago.


Cheers,
Franco

If you deleted your original LAN interface (and possibly your WAN, identifiers "lan" and "wan") interface the ancient anti-lockout code can't really guess which one is secure so it uses the first "optX" as the base for the anti-lockout.  If that's the case the best solution is to disable the anti-lockout and just add manual rules that emulate the behaviour if you want/need it.


Cheers,
Francp

There will be no flip-flopping. If you want you can install the plugin from the stable/25.7 branch and lock the package.


Cheers,
Franco

> This is rather important to me, because I am using ISC DHCP and a lot of static mappings as well.

I'm not aware of a static mappings issue (yet).


Cheers,
Franco

This change was submitted by a user to avoid backing up configs that haven't changed overnight and to get the full history.


Cheers,
Franco

Which is planned based on user feedback in 26.1.x ;)

As said elsewhere we did not expect so many people to migrate this quickly.  It's very good, just not expected.


Cheers,
Franco