Messages

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.

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

Hi

Ok, that makes sense. Thanks for your reply!

I'm just wondering, why a release is coming out with these 2 new vulnerabilities?

Currently running OPNsense 25.1.10 (amd64) at Fri Jul  4 11:50:37 CEST 2025
Fetching vuln.xml.xz: .......... done
php83-8.3.22 is vulnerable:
  php -- Multiple vulnerabilities
  CVE: CVE-2025-1220
  CVE: CVE-2025-6491
  CVE: CVE-2025-1735
  WWW: https://vuxml.freebsd.org/freebsd/d607b12c-5821-11f0-ab92-f02f7497ecda.html

sudo-1.9.17 is vulnerable:
  sudo -- privilege escalation vulnerability through host and chroot options
  CVE: CVE-2025-32463
  CVE: CVE-2025-32462
  WWW: https://vuxml.freebsd.org/freebsd/24f4b495-56a1-11f0-9621-93abbef07693.html

2 problem(s) in 2 installed package(s) found.
***DONE***

Hi Seimus

Yeah, it's me being ignorant here, I guess.
I just noticed, that I got quite a few messages from hosts on the network, that I'm managing today.
Messages about time-drifts. And these machines synchronize with the OPNSense-box in question.
So I investigated, and this ntpd-status inopnsense seemed strange.
But of course you are right, that these entries are not resolving to real ip's, since they are pools.
Why the have chosen to show them in the status as failing/pending is a design choice, I guess.
Why these hosts of mine are complaining must me some kind of coincidence, that I will investigate further.
Thanks for your help and attention  :)
Hans Otto

Absolutely.
It's very basic. And apart from the page in the attachment, everything is default settings, as far as I know.
Hans Otto

I just want to add that

ntpdate 0.opnsense.pool.ntp.org
0 Jul 08:39:30 ntpdate[1280402]: adjust time server 192.53.103.108 offset +0.000235 sec

from the same network works just fine. So it's not that these time-sources are down or something...

I just noticed, that the ntp-server in 24.7 seems to have a problem getting time from the configured servers.
And this seems to be the case with all of the four instances, that I take care of.
Below all of the 4 configured time-sources say Unreach/Pending..
Does anybody have  a clue about this?

Unreach/Pending    0.dk.pool.ntp.org    .POOL.    16    p    -    64    0    0.000    +0.000    0.000
Unreach/Pending    1.dk.pool.ntp.org    .POOL.    16    p    -    64    0    0.000    +0.000    0.000
Unreach/Pending    0.opnsense.pool.ntp.org    .POOL.    16    p    -    64    0    0.000    +0.000    0.000
Unreach/Pending    0.debian.pool.ntp.org    .POOL.    16    p    -    64    0    0.000    +0.000    0.000
Active Peer       194.45.79.110    185.181.223.169    2    u    23    64    177    10.386    -0.403    0.087
Unreach/Pending    217.116.227.3    149.117.239.139    2    u    23    64    177    5.703    -0.526    0.212
Unreach/Pending    193.200.91.90    192.38.7.240    2    u    16    64    167    3.396    -0.775    0.057
Unreach/Pending    5.186.56.205    217.198.219.102    2    u    19    64    177    1.912    -0.054    1.106
Unreach/Pending    213.32.246.229    22.75.108.217    3    u    19    64    177    8.765    -0.594    2.588
Unreach/Pending    185.197.135.6    131.188.3.220    2    u    14    64    177    19.042    -9.833    8.598
Unreach/Pending    213.5.39.34    123.19.30.227    2    u    17    64    177    2.459    -0.334    0.230
Unreach/Pending    162.159.200.1    10.65.8.14    3    u    10    64    177    4.502    -0.927    0.036

Just upgraded 4 systems without ANY issues. Two of them are absolutely critical.
I try not to have any hairy plugins, so it's basically IPV4 only + Wireguard and a varying number of interfaces + os-net-snmp and cicada. I'm not sure about my opinion on the new dashboard. It sure is pretty, but if it more useful than the old one, I'm not sure.
Thanks to the team for what seems to be a great job with this HUGE upgrade.
More power to them... :)

I absolutely understand how much work, that would require.
It was just a thought on Franco's remarks regarding Netgates involvement in FreeBSD-development.

Hi
I don't want to interfere with your discussion, but just mention that I use OPNSense in production at several locations and has been VERY pleased with it for several years.
Not just the software, but also the friendliness I've encountered in my quite few interactions with the company.
I came from PfSense for these systems but got really annoyed because of the way PfSense behaved when they screwed up their WireGuard VPN implementation.
This company does not operate in a way, that I can stand behind. They are close to being complete a**holes, to be frank.
So the budget-money I have for these routers goes to OPNSense.

By the way. I have a CRAZY question for you, Franco:
Have you EVER considered moving the OPNSense-project over to run on top of a Linux-kernel?
Or is this simply too big a change to contemplate at all?
It would cut some ties to this malevolent FreeBSD sponsor, though... :)
summer greetings from Denmark

Hi

I've encountered the same problem.
I'll get back to you when I have investigated further..

Hi
I have experienced just about the exact same symptoms today - also with quad9.
I'll look into it tomorrow and get back to you about my results...

Hi Franco

No, the squid-plugin is not installed, so I guess the error-message was just related to a dependency for the squid-package, if there is such a thing. But now I checked and nothing squid-related seems to be installed on any of the 4 routers.
The only plugins I have installed is os-net-snmp and the cicada-theme.
Hmmm, maybe I don't recall this correctly. But I did see the error-message.
Anyway, it all seems to run absolutely great on all 4 systems.
Thanks for your feedback.

Hi

I just want to acknowledge the team for doing a great job with this HUGE update.
The 4  routers mentioned do not have a very complicated setup, but two of them are a bit complex.
We use Wireguard on all of them and are VERY pleased with it.
Only other thing to mention is, that we try to stay away from third-party plugins etc.
The only glitch I can think of during the update is these two message:

'squid is missing a required shared library: libssl.so.11
squid is missing a required shared library: libcrypto.so.11'

We do not use squid although it is installed, so this is not really important at all. Just reinstalled squid to get rid of the error-message.

Thanks to the team for a smooth upgrade and a great product.

Hans Otto Lunde