Messages

Okay, fair.


Cheers,
Franco

Gentle chuckle. Thank you.

Reinstall elastic with

# pkg install -f elasticsearch8


The rest looks good.

DONE:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.3 (amd64) at Mon Mar  9 21:46:57 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.3 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.3 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
os-ddclient 1.30
os-isc-dhcp 1.0_4
os-qemu-guest-agent 1.3
os-sensei 2.4.1
os-sensei-agent 2.4
os-sensei-updater 1.18
os-sunnyvalley 1.5_2
os-theme-cicada 1.41
os-theme-rebellion 1.9.4
os-theme-tukan 1.31
os-theme-vicuna 1.51
>>> Check locked packages
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
>>> Check for missing package dependencies
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for missing or altered package files
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.3 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***


What do you mean a manual complication? I did not install it manually. I run vanilla OPNSense.

OPNsense has extensive check to make sure the FreeBSD repos are disabled.


The fact you ended up with pkg from FreeBSD instead of the one from OPN means that the system was modified on purpose by "something" which in turn pulled packages from FreeBSD. This is why you're seeing the db version mismatch after you reverted pkg to the one in OPN.

The db warning is not catastrophic to my knowledge so you can continue to use the system as is.


More importantly though it may be possible to have there other packages from other repos that may cause trouble in the future.


For now it would be best to post here an audit so we can get a better understanding of where you're at.

It is weird indeed...

Attaching "audit: health"

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.3 (amd64) at Mon Mar  9 21:05:23 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.3 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.3 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
os-ddclient 1.30
os-isc-dhcp 1.0_4
os-qemu-guest-agent 1.3
os-sensei 2.4.1
os-sensei-agent 2.4
os-sensei-updater 1.18
os-sunnyvalley 1.5_2
os-theme-cicada 1.41
os-theme-rebellion 1.9.4
os-theme-tukan 1.31
os-theme-vicuna 1.51
>>> Check locked packages
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
>>> Check for missing package dependencies
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for missing or altered package files
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages:
elasticsearch8-8.11.3: checksum mismatch for /usr/local/lib/elasticsearch/lib/jna-0.0.0.jar
Checking all packages............. done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.3 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***


> This update is a bit rough for many, hopefully there is an update to patch things up.

Yes, but we did establish it's rough because the wrong package manager ended up installing which is a manual complication we neither test nor can control.


Cheers,
Franco

What do you mean a manual complication? I did not install it manually. I run vanilla OPNSense.

This update is a bit rough for many, hopefully there is an update to patch things up.

# opnsense-revert opnsense


Cheers,
Franco

What is expected here? Doesn't look like it worked as expected either:


root@opnsense:~ # opnsense-revert opnsense
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
Fetching meta.conf: 100%    179 B   0.2kB/s    00:01   
SunnyValley repository is up to date.
All repositories are up to date.
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
The following packages will be fetched:

New packages to be FETCHED:
        opnsense: 26.1.3 (6 MiB: 100.00% of the 6 MiB to download)

Number of packages to be fetched: 1

The process will require 6 MiB more space.
6 MiB to be downloaded.
Fetching opnsense-26.1.3.pkg: 100%    6 MiB   6.1MB/s    00:01   
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
opnsense-26.1.3: already unlocked
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
Fetching meta.conf: 100%    179 B   0.2kB/s    00:01   
SunnyValley repository is up to date.
All repositories are up to date.
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        opnsense-26.1.3 [OPNsense]

Number of packages to be reinstalled: 1
[1/1] Reinstalling opnsense-26.1.3...
[1/1] Extracting opnsense-26.1.3: 100%
Stopping configd...done
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
Updating /etc/shells
Registering root shell
Hooking into /etc/rc
Hooking into /etc/rc.shutdown
Starting configd.
>>> Invoking update script 'refresh.sh'
Flushing all caches...done.
Writing firmware settings: FreeBSD OPNsense SunnyValley
Writing trust files...done.
Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
certctl: No changes to trust store were made.
Writing trust bundles...done.
Configuring login behaviour...done.
Configuring cron...done.
Configuring system logging...done.
=====
Message from opnsense-26.1.3:

--
One step ahead, one step behind it, now you gotta run to get even
pkg-static: warning: database version 37 is newer than libpkg(3) version 36, but still compatible

You installed the FreeBSD package manager version, which isn't good.

>   opnsense-26.1.3 [OPNsense] (Vital flag changed: 'true' -> 'false')

This looks like a weird database bug. Vital flag is never removed.

Try this first...

# opnsense-revert pkg


Cheers,
Franco

Did not work.

Had to:
# cd /tmp
# curl "https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/MINT/26.1.3/latest/All/pkg-2.3.1_1.pkg" --output pkg-2.3.1_1.pkg
# pkg install pkg-2.3.1_1.pkg
# opnsense-revert pkg

How do we fix the "Vital" flag now?

Exactly same thing happened to me. I rebooted after that and it was fine.

EDIT: actually no. check for updates reports a segmentation fault for one of the packages.

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.3 (amd64) at Fri Mar  6 12:52:54 EST 2026
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching data: ....... done
Processing entries: .......... done
OPNsense repository update completed. 931 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: . done
Fetching data: .. done
Processing entries: .. done
SunnyValley repository update completed. 15 packages processed.
All repositories are up to date.
Child process pid=88379 terminated abnormally: Segmentation fault
Upgrading package manager from version '2.5.1' to '2.3.1_1'
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
OPNsense is up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
Child process pid=99031 terminated abnormally: Segmentation fault
Checking for upgrades (198 candidates): .......... done
Processing candidates (198 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

+1 for Dark Mode

Thanks!

I can't seem to find it, does it exist? The default seems way too bright.

For those values I can think of 3 possibilities: ISP issues, VPN issues if the pings go over VPN, ISP + VPN issues in aggregate.

For reference, I get 6-20 msec pinging 1.1.1.1 over the wan, between 120-180ms pinging 8.8.8.8 and 8.8.4.4 over various VPNs and 50-70ms between OPN FWs on the latest kernel a few thousand miles/km apart.


If you have a modem - power cycle it. If the results are consistent - talk to your ISP.

That's a sound advise, I confirmed the issue is with ISP model. Cheers mate.

I am seeing issues as well, what is the last stable release prior to this pf regression?

I am getting massive latency after 24h going from >1ms to 4000ms on my WAN interface.

For now reverted back to the 24.7.8 kernel

# opnsense-update -kr 24.7.8
# opnsense-shell reboot

That's some wan there operation above the speed of light - in the olden days of 24.7.8

Things are absolutely fine on the fixed 24.7.10 kernel, reverting forward using the official guidance in the Announcements section for 24.7.10 is the only thing needed for those affected by the bug in the original 24.7.10, everyone else simply update to it.

Conflating ISP issues with FreeBSD bugs and ad-hoc reverts is not helpful guidance in this thread.

The unfortunate part this started happening after 24.7.10 update. So what do you advise here ?

Code Select Expand


64 bytes from 8.8.8.8: icmp_seq=13325 ttl=117 time=509 ms
64 bytes from 8.8.8.8: icmp_seq=13326 ttl=117 time=511 ms
64 bytes from 8.8.8.8: icmp_seq=13327 ttl=117 time=998 ms
64 bytes from 8.8.8.8: icmp_seq=13328 ttl=117 time=18.6 ms
64 bytes from 8.8.8.8: icmp_seq=13329 ttl=117 time=772 ms
64 bytes from 8.8.8.8: icmp_seq=13330 ttl=117 time=19.0 ms
64 bytes from 8.8.8.8: icmp_seq=13331 ttl=117 time=1022 ms
64 bytes from 8.8.8.8: icmp_seq=13332 ttl=117 time=1133 ms
64 bytes from 8.8.8.8: icmp_seq=13333 ttl=117 time=803 ms
64 bytes from 8.8.8.8: icmp_seq=13334 ttl=117 time=1062 ms
64 bytes from 8.8.8.8: icmp_seq=13335 ttl=117 time=1073 ms
64 bytes from 8.8.8.8: icmp_seq=13336 ttl=117 time=573 ms
64 bytes from 8.8.8.8: icmp_seq=13337 ttl=117 time=589 ms
64 bytes from 8.8.8.8: icmp_seq=13338 ttl=117 time=1141 ms
64 bytes from 8.8.8.8: icmp_seq=13339 ttl=117 time=626 ms
64 bytes from 8.8.8.8: icmp_seq=13340 ttl=117 time=566 ms
64 bytes from 8.8.8.8: icmp_seq=13341 ttl=117 time=680 ms
64 bytes from 8.8.8.8: icmp_seq=13342 ttl=117 time=588 ms
64 bytes from 8.8.8.8: icmp_seq=13343 ttl=117 time=90.0 ms
64 bytes from 8.8.8.8: icmp_seq=13344 ttl=117 time=598 ms
64 bytes from 8.8.8.8: icmp_seq=13345 ttl=117 time=622 ms
64 bytes from 8.8.8.8: icmp_seq=13346 ttl=117 time=117 ms
64 bytes from 8.8.8.8: icmp_seq=13347 ttl=117 time=142 ms
64 bytes from 8.8.8.8: icmp_seq=13348 ttl=117 time=211 ms
64 bytes from 8.8.8.8: icmp_seq=13349 ttl=117 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=13350 ttl=117 time=1193 ms
64 bytes from 8.8.8.8: icmp_seq=13351 ttl=117 time=1670 ms
64 bytes from 8.8.8.8: icmp_seq=13352 ttl=117 time=2189 ms
64 bytes from 8.8.8.8: icmp_seq=13353 ttl=117 time=2224 ms
64 bytes from 8.8.8.8: icmp_seq=13354 ttl=117 time=3230 ms
64 bytes from 8.8.8.8: icmp_seq=13355 ttl=117 time=4263 ms
64 bytes from 8.8.8.8: icmp_seq=13356 ttl=117 time=4256 ms
64 bytes from 8.8.8.8: icmp_seq=13357 ttl=117 time=3892 ms
64 bytes from 8.8.8.8: icmp_seq=13358 ttl=117 time=3260 ms
64 bytes from 8.8.8.8: icmp_seq=13359 ttl=117 time=3201 ms
64 bytes from 8.8.8.8: icmp_seq=13360 ttl=117 time=2463 ms
64 bytes from 8.8.8.8: icmp_seq=13361 ttl=117 time=2314 ms
64 bytes from 8.8.8.8: icmp_seq=13362 ttl=117 time=3036 ms
64 bytes from 8.8.8.8: icmp_seq=13364 ttl=117 time=5457 ms
64 bytes from 8.8.8.8: icmp_seq=13365 ttl=117 time=5399 ms
64 bytes from 8.8.8.8: icmp_seq=13367 ttl=117 time=5527 ms


I am seeing issues as well, what is the last stable release prior to this pf regression?

I am getting massive latency after 24h going from >1ms to 4000ms on my WAN interface.

For now reverted back to the 24.7.8 kernel

# opnsense-update -kr 24.7.8
# opnsense-shell reboot

So this worked!

For those who are wondering, you need to set "Content" to your port range, for example: 15000:15100