Messages

This time, when I clicked update from the WebGUI, the install/deinstall loop happened, but only for graphite2, not libdeflate.

Then I forced an update to the repositories using "pkg update -f"

I checked and graphite2 was not in the SunnyValley repository

Then I installed graphite2

root@firewall:~ # pkg install graphite2
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
Fetching meta.conf:  0%
Fetching data.pkg:  0%
SunnyValley repository is up to date.
Updating mimugmail repository catalogue...
Fetching meta.conf: 100%    179 B  0.2kB/s    00:01
mimugmail repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        graphite2: 1.3.14 [OPNsense]

Number of packages to be installed: 1

105 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching graphite2-1.3.14.pkg: 100%  105 KiB 107.1kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing graphite2-1.3.14...
[1/1] Extracting graphite2-1.3.14: 100%

Then when I checked for updates on the WebUI, it said everything was up to date.

Here is the output...

root@firewall:~ # opnsense-version
OPNsense 26.1.10 (amd64)

root@firewall:~ # pkg -d search -r SunnyValley opnsense
DBG(1)[78206]> PkgRepo: verifying update for SunnyValley
DBG(1)[78206]> Pkgrepo, begin update of '/var/db/pkg/repos/SunnyValley/db'
DBG(1)[78206]> (fetch) Request to fetch https://updates.zenarmor.net/opnsense/FreeBSD:14:amd64/26.1/86cd79bf-0b68-486c-b7a2-50f7df0f6a8b/meta.conf
DBG(1)[78206]> (fetch) Fetch: fetcher used: https
DBG(1)[78206]> (fetch) Request to fetch https://updates.zenarmor.net/opnsense/FreeBSD:14:amd64/26.1/86cd79bf-0b68-486c-b7a2-50f7df0f6a8b/data.pkg
DBG(1)[78206]> (fetch) Fetch: fetcher used: https

root@firewall:~ # pkg -d search -r OPNsense graphite2
DBG(1)[90247]> PkgRepo: verifying update for OPNsense
DBG(1)[90247]> Pkgrepo, begin update of '/var/db/pkg/repos/OPNsense/db'
DBG(1)[90247]> (fetch) Request to fetch https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/latest/meta.conf
DBG(1)[90247]> (fetch) Fetch: fetcher used: https
DBG(1)[90247]> (fetch) Request to fetch https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/latest/data.pkg
DBG(1)[90247]> (fetch) Fetch: fetcher used: https
graphite2-1.3.14              Rendering capabilities for complex non-Roman writing systems

root@firewall:~ # pkg -d search -r SunnyValley libdeflate
DBG(1)[24]> PkgRepo: verifying update for SunnyValley
DBG(1)[24]> Pkgrepo, begin update of '/var/db/pkg/repos/SunnyValley/db'
DBG(1)[24]> (fetch) Request to fetch https://updates.zenarmor.net/opnsense/FreeBSD:14:amd64/26.1/86cd79bf-0b68-486c-b7a2-50f7df0f6a8b/meta.conf
DBG(1)[24]> (fetch) Fetch: fetcher used: https
DBG(1)[24]> (fetch) Request to fetch https://updates.zenarmor.net/opnsense/FreeBSD:14:amd64/26.1/86cd79bf-0b68-486c-b7a2-50f7df0f6a8b/data.pkg
DBG(1)[24]> (fetch) Fetch: fetcher used: https
libdeflate-1.25                Fast, whole-buffer DEFLATE-based compression library

root@firewall:~ # pkg -d search -r OPNsense libdeflate
DBG(1)[76198]> PkgRepo: verifying update for OPNsense
DBG(1)[76198]> Pkgrepo, begin update of '/var/db/pkg/repos/OPNsense/db'
DBG(1)[76198]> (fetch) Request to fetch https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/latest/meta.conf
DBG(1)[76198]> (fetch) Fetch: fetcher used: https
DBG(1)[76198]> (fetch) Request to fetch https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/latest/data.pkg
DBG(1)[76198]> (fetch) Fetch: fetcher used: https
libdeflate-1.25                Fast, whole-buffer DEFLATE-based compression library

It looks like your suspicion was correct. libdeflate-1.25 is currently populated in both repositories simultaneously.

Please let me know if you need any further diagnostic logs.

Thank you!

I can confirm this is the output of pkg info -d elasticsearch8
 
elasticsearch8-8.11.3:
        bash-5.3.15
        openjdk17-17.0.10+7.1_1
        jna-5.15.0_2

Hello OPNsense Community & Developers,

I am experiencing a persistent update loop with two minor upstream shared libraries: graphite2 (v1.3.14) and libdeflate (v1.25). The WebGUI firmware status page continually prompts that these updates are available. When the update is triggered, pkg successfully fetches and extracts the files, but immediately removes them during the automatic post-install cleanup phase. Consequently, the packages reappear as missing "New" (N/A) entries on the next update check.

Environment Details:
OPNsense Version: 26.1.10-amd64
OS: FreeBSD 14.3-RELEASE-p4
OpenSSL: 3.0.18
Plugins Active: Zenarmor (Home Subscription) using a Local Elasticsearch 8.11.3 reporting database instance, running alongside Java (openjdk17).
The Behavior / Update Log CLI Output:
When running the update via the root shell, the package manager successfully pulls the files, but then explicitly lists them under Installed packages to be REMOVED directly afterward:

Processing candidates (6 candidates): .... done
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   graphite2: 1.3.14 [OPNsense]
   libdeflate: 1.25 [OPNsense]

Number of packages to be installed: 2

181 KiB to be downloaded.
[1/2] Fetching libdeflate-1.25.pkg: ....... done
[2/2] Fetching graphite2-1.3.14.pkg: .......... done
Checking integrity... done (0 conflicting)
[1/2] Installing graphite2-1.3.14...
[1/2] Extracting graphite2-1.3.14: .......... done
[2/2] Installing libdeflate-1.25...
[2/2] Extracting libdeflate-1.25: .......... done
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages:

Installed packages to be REMOVED:
   graphite2: 1.3.14
   libdeflate: 1.25

Number of packages to be removed: 2
[1/2] Deinstalling graphite2-1.3.14...
[1/2] Deleting files for graphite2-1.3.14: .......... done
[2/2] Deinstalling libdeflate-1.25...
[2/2] Deleting files for libdeflate-1.25: .......... done
Checking all packages: .......... done
The following package files will be deleted:
   /var/cache/pkg/openjdk17-17.0.10+7.1_1.pkg
   /var/cache/pkg/elasticsearch8-8.11.3~ff6f5709d3.pkg
   /var/cache/pkg/libdeflate-1.25.pkg
   /var/cache/pkg/graphite2-1.3.14.pkg
   /var/cache/pkg/elasticsearch8-8.11.3.pkg
...
The cleanup will free 295 MiB
Deleting files: .......... done
Nothing to do.
Flushing temporary package files... done
***DONE***

Has anyone else utilizing local Elasticsearch deployments run into this package manager looping pattern? Is there an upcoming repository metadata sync planned to align the Java/Elasticsearch dependency tags with these specific library versions on the FreeBSD 14.3 base?

Thank you for your time and continued incredible work on the OPNsense ecosystem!

I have been putting off running the migration assistant until I had time to set aside and be able to test everything.  Tonight, when I upgraded to v26.1.10, the Firewall Rules [new] were populated.  Are they active?  Do I still run the migration assistant? Should I rollback to v26.1.9 and run the migration assitant before upgrading to v26.1.10? The relase notes say "o firewall: always show automatic and legacy rules in new rules GUI" but I judt thought that meant if you had already ran the migration assistant?  Thoughts on next steps?

A couple of days ago, I successfully installed the free version of Zenarmor on OPNsense v25.7.8. During the install, Remote Elasticsearch Database was an option that appeared during the wizard. I used it and setup Elasticsearch on a separate computer. Everything was working great.

Today, I upgraded the hard drives in my OPNsense box and did a clean re-install of OPNsense. Installing Zenarmor was the last step. During the install, Remote Elasticsearch Databas is not listed as an option, only local Elasticsearch or local SQLite.

Any thoughts on why it's not showing up as an option in the wizard?

"Then gateway monitoring is probably misconfigured. Check the routing table for 8.8.8.8." Meeans, use a IP-Adresse on the other Side of your Wiregurad-Tunnel.

"There was a key mismatch for my VPN server, but OPNsense was reporting a successful handshake. Is it possible to change the way OPNsense reports the Wireguard status?" Yes, ther is, create a report at: https://github.com/opnsense/core/issues

Done.

Then gateway monitoring is probably misconfigured. Check the routing table for 8.8.8.8. Make sure it isn't configured as a DNS server in System / Settings / General.

WireGuard is stateless. If the keys don't match, no traffic passes the tunnel. But there is no "login" or "connection" which could fail. That's by design.

There are no entries for DNS Servers in System / Settgings / General ... I use DNSCrypt for DNS Servers.

Under VPN / Wireguard / Status, what does a green check and a handshake age in seconds mean for a given Wireguard Peer?

The interface was "green" or the gateway? Gateway monitoring creates a static route for the monitor IP to prevent the pings from taking other routes, so it should definitely show the gateway as down.

Up is Green correct?  Attached is a picture of what was displayed in the Dashboard.

I guess the simple answer is NO, OPNsense cannot detect a key mismatch when connecting to a VPN Server?

I have 8.8.8.8 as the Monitor IP in the Wireguard interface. It showed the Wireguard interface as green

I'm not talking about the WAN gateway or the WireGuard status. You can set up an additional gateway monitor (System: Gateways: Configuration) for the WireGuard tunnel. Dpinger then pings a monitor IP of your choice through the WireGuard tunnel. If the tunnel stops passing packets, the ping fails.

If that ping fails, how do I know it's a key mismatch on the VPN server as opposed to a rule on OPNsense preventing data from going out?

The problem is that OPNsense was showing the Wireguard connection as fine.  Monitoring the gateway did not help because the gateway was alive and active.

The WireGuard status in OPNsense is reporting on the Layer 2/3 connection attempt (the VPN tunnel) and not necessarily the Layer 7 data flow (internet traffic).

When OPNsense initiates the connection, it sends a handshake packet to the VPN server's endpoint IP. The handshake is built using the local private key.

The VPN server receives this handshake packet and, if the network path is clear, it sends a reply back to OPNsense.

This reply packet from the server is misinterpreted by the OPNsense WireGuard service as a successful completion of the handshake process, even though the server immediately discards the session due to a key mismatch.

In my instance, I had accidentally deleted the VPN instance with the Private Key I was using, so the VPN server, upon receiving the handshake packet, looked up my Key in its database and said I don't recognize this public key anymore.  The VPN server did not process the session and did not pass any packets, but doesn't send a clean error message back to OPNsense that the key is invalid.  The OPNsense client just sees that the connection was established to the port, and a handshake occurred, leading to the confusing "successful handshake" status with zero or stalled traffic volume.  The OPNsense Latest Handshake status primarily indicates the last time the client and server spoke to each other, even if that conversation was a one-sided failure due to the invalid key. The true indicator of failure is the lack of inbound and outbound traffic bytes after the initial handshake.

Because the link was showing as UP with no traffic, I spent hours trying to diagnose the Firewall rules thinking that a rule or something went wrong on my side with the OPNsense configuration.

There was a key mismatch for my VPN server, but OPNsense was reporting a successful handshake. Is it possible to change the way OPNsense reports the Wireguard status? Instead of reporting on the Layer 2/3 connection attempt (the VPN tunnel), can OPNsense report on the Layer 7 data flow (internet traffic)?

Hi,

I am running OPNsense v 25.7.6 in 2 locations with 2 different Internet service providers. I have a Wireguard VPN setup for each (using different VPN server on each). 

It's has been working fine for months. Simultaneously this morning, the Wireguard VPN stopped letting traffic out of the OPNsense box in each location.

I have verified that my VPN provider is working. I have changed the server, public key, etc... OPNsense shows a successful handshake.

I'm running 25.7.6 and the login button no longer appears on my Captive Portal splash screen.