Tunable-values out of sync with sysctl-values...?

[holunde]

First, thanks to the team for really great work with this HUGE upgrade to version 26.7 (FreeBSD 15.1)
I have 4 production OPSense routers that all upgraded with any problems.
Ok, there is a few widgets that look a little off, but that is not important now.
Since I do a little tuning af network performance, I set a few things in System->Settings->Tunables.
And on one of these systems, just one, I noticed something strange: The values(not defaults) for some variables don't match with what the 'sysctl'-command on the cli tells me. Here are a sample of values from the sysctl-command:

sysctl net.pf.share_forward net.pf.share_forward6 net.route.multipath security.bsd.see_other_gids security.bsd.see_other_uids vfs.read_max
net.pf.share_forward: 1
net.pf.share_forward6: 1
net.route.multipath: 0
security.bsd.see_other_gids: 0
security.bsd.see_other_uids: 0
vfs.read_max: 32

And here is what the "Tunables" page shows, values are in the third column, defaults in the fourth:
You cannot view this attachment.

So for these 6 variables - all values differ from what sysctl shows.
Has anybody an idea what is going on with this?
The system runs 26.7 and a health test checks out. I should also mention, that I reset all tunables to default after upgrading to 26.7 - and then reinserted my few optimization-things.

Again, praise to the OPNSense team

[pfry]

tunables set to unknown values, reset to default does nothing

You could check loader.conf, and try setting them in a terminal. Could be some oddities regarding placement, as many settings are duplicated across loader.conf, sysctl.conf, and rc.conf.

[holunde]

Hi pfry
Thanks for answering.
I can see there has been som activity around this subject.
My point was not so much, that the tunable-values you can set in the web-interface are not really being 'set'. They absolutely seem to be.
But it still puzzles me, that so many of the 'values' listed in "Tunables" simply are not correct - if you compare them to what the sysctl command tell us from the cli. It must be a bug of some kind. And it would be nice to have it fixed.