Messages

I am guessing you meant lower-case g instead of uppercase G?

           -G               Return the log file of the last upgrade.  Since
                            upgrades run without network connectivity and user
                            interaction there is no direct way to observe it
                            other than an attached console or monitor which
                            can still miss important context.

           -g               Return the log file of the last update.  Update
                            logs are stored persistently when the update or
                            upgrade procedure requested a reboot.  It is also
                            stored when errors have been encountered.  This
                            can help with diagnosing update problems, package
                            conflicts and package manager bugs.


lowercase g is indeed only from when the upgrade succeeded so not useful to debug further.

unless those logs are kept across several reboots and the final successful upgrade, i do not have any logs to share.
if they are, and you really want to investigate further, let me know where I can find them please.

Not a DNS issue, but close.
IPv6 bugging out was the cause. Apparently the FW itself can't speak IPv6 with the outside world anymore hence IPv6 timed out.
Clients behind the FW have no issue with IPv6. Weird.

Already tried disabling IPv6, but I missed that there was still a default fe80:: route learned via RA that caused the timeout.
After deleting that route:

Starting web GUI... done.
Fetching base-26.7.3-amd64.txz: ................. done
Fetching kernel-26.7.3-amd64.txz: ............... done
!!!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-26.7.3-amd64.txz... done
Installing base-26.7.3-amd64.txz... done
Cleaning obsolete files... done
Please reboot.
***REBOOT***


Still confused how the FW rebooted with the last upgrade when kernel and base were missing. Don't suppose anybody feels like explaining that bit to the noob? :)
Anyway, upgrade fixed. Now of to figure out why IPv6 from the FW itself no longer works.

Much appreciated!

Tried with multiple mirrors.
Command errors in the same was as in the upgrade message:

Code Select Expand

root@OPNsense:~ # opnsense-update -bkr 26.7.3
Fetching base-26.7.3-amd64.txz: ................................[fetch: transfer timed out
fetch: /var/cache/opnsense-update/64157/base-26.7.3-amd64.txz.sig appears to be truncated: 0/1332 bytes] failed, no signature found
root@OPNsense:~ #

Nobody has an idea?

Upgraded to 26.7.3_8 when it came out. As far as I noticed no issues appeared during the upgrade.
Now however, the OPNsense VM keeps claiming "There are 2 updates available, total download size is 125.1MiB. This upgrade requires a reboot."
The 2 files it want me to upgrade are base & kernel, both current version 26.7.2, new version 26.7.3.

Rebooting the FW does not resolve this. Neither does selecting a different mirror.
When I click the Update button it fails to do anything:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.7.3_8 (amd64) at Mon Aug 31 09:25:24 CEST 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files... done
Starting web GUI...done.
Fetching base-26.7.3-amd64.txz: ...[fetch: transfer timed out] failed, no signature found
***DONE***


How do I get rid of this mess?

Code Select Expand

root@OPNsense:~ # configctl firmware product
{
    "CORE_ABI": "26.7",
    "CORE_ARCH": "amd64",
    "CORE_COMMIT": "26.7.3 8 bf16bfcda",
    "CORE_CONFLICTS": "os-firewall os-firewall-devel os-wireguard os-wireguard-devel os-wireguard-go os-wireguard-go-devel",
    "CORE_COPYRIGHT_HOLDER": "Deciso B.V.",
    "CORE_COPYRIGHT_WWW": "https://www.deciso.com/",
    "CORE_COPYRIGHT_YEARS": "2014-2026",
    "CORE_GID": "789",
    "CORE_GROUP": "wwwonly",
    "CORE_HASH": "bf16bfcda",
    "CORE_MAINTAINER": "project@opnsense.org",
    "CORE_NAME": "opnsense",
    "CORE_NEXT": "27.1",
    "CORE_NICKNAME": "Xenial Xenops",
    "CORE_PACKAGESITE": "https://pkg.opnsense.org",
    "CORE_PKGVERSION": "26.7.3_8",
    "CORE_PRODUCT": "OPNsense",
    "CORE_PYTHON_DOT": "3.13",
    "CORE_SERIES": "26.7",
    "CORE_SERIES_FW": "26.7 ",
    "CORE_SYSLOGNG": "4.12",
    "CORE_UID": "789",
    "CORE_USER": "wwwonly",
    "CORE_VERSION": "26.7.3",
    "CORE_WWW": "https://opnsense.org/",
    "product_abi": "26.7",
    "product_arch": "amd64",
    "product_check": {
        "api_version": "2",
        "connection": "ok",
        "downgrade_packages": [],
        "download_size": "",
        "last_check": "Mon Aug 31 09:36:22 CEST 2026",
        "needs_reboot": "1",
        "new_packages": [],
        "os_version": "FreeBSD 15.1-RELEASE-p2",
        "product_id": "opnsense",
        "product_target": "opnsense",
        "product_version": "26.7.3_8",
        "product_abi": "26.7",
        "reinstall_packages": [],
        "remove_packages": [],
        "repository": "ok",
        "upgrade_major_message": "",
        "upgrade_major_version": "",
        "upgrade_needs_reboot": "0",
        "upgrade_packages": [
            {
                "name": "base",
                "size": "97993432",
                "repository": "OPNsense",
                "current_version": "26.7.2",
                "new_version": "26.7.3"
            },
            {
                "name": "kernel",
                "size": "33187412",
                "repository": "OPNsense",
                "current_version": "26.7.2",
                "new_version": "26.7.3"
            }
        ],
        "upgrade_sets": []
    },
    "product_conflicts": "os-firewall os-firewall-devel os-wireguard os-wireguard-devel os-wireguard-go os-wireguard-go-devel",
    "product_copyright_owner": "Deciso B.V.",
    "product_copyright_url": "https://www.deciso.com/",
    "product_copyright_years": "2014-2026",
    "product_email": "project@opnsense.org",
    "product_hash": "bf16bfcda",
    "product_id": "opnsense",
    "product_latest": "26.7.3",
    "product_license": [],
    "product_log": 1,
    "product_mirror": "https://pkg.opnsense.org/FreeBSD:15:amd64/26.7",
    "product_name": "OPNsense",
    "product_nickname": "Xenial Xenops",
    "product_repos": "OPNsense (Priority: 11)",
    "product_series": "26.7",
    "product_tier": "1",
    "product_time": "Fri Aug 28 22:18:09 CEST 2026",
    "product_version": "26.7.3_8",
    "product_website": "https://opnsense.org/"
}

Login with my Authentik works if I use the link https://<my_opnsense_hostname>/api/oidc/auth/login?provider=openid
But no button

This works for me:

Code Select Expand

%url%
  %icon%
  Login with %name%
</a>

<style>
.login-sso-link-container {
  display: flex;
  justify-content: end;
  margin-bottom: 20px;
}

.btn-primary {
  width: 100%;
  height: 35px !important;
  margin-top: 20px;
}
</style>
or this one if you don't use an icon:

Code Select Expand

%url%
  Login with %name%
</a>

<style>
.login-sso-link-container {
  display: flex;
  justify-content: end;
  margin-bottom: 20px;
}

.login-sso-link-container .btn-primary {
  width: 100%;
  height: 35px !important;
  margin-top: 20px;
}
</style>

Please let me know what you think :)

I love it! Thank you.
Not having OIDC in the community edition was a real bummer. Until I saw your plugin.

SO, I have been running OPNsense with wireguard on top of it for quite a while now, but have recently noticed my wireguard setup isn't working anymore.
Both my peer devices (mobile phone and laptop) are having issues.
FW has a rule to allow any to WAN_addr udp 1234
A record remote.domain.tld resolves to this WAN_addr
I have wg0 tied into my VPN interface and have a VPN_net alow any any rule set.
Tunnel address is an internal subnet x.y.z.1/24.
Peer endpoint address is remote.domain.tld:1234 (non-default port).
Peer address is x.y.z.2/32 and x.y.z.3/32
Peers allowed IPs is 0.0.0/0

Symptoms:
Peer shows tunnel state active, I can see traffic sent (on the peer), but none received.
Interface shows status up, but down for both peers and transfer sent/receive does not move. Any way to reset these statistics?

Why is this not working anymore?

I have to ask, you understand: Did you apply the changes? If so, you got me.

hehe, fair question, but yes.. i did save and apply.

gotcha.
So I went ahead and checked the statistics checkbox for a couple of my aliases. I.e. I enabled this for my PC's alias (2x IPv4 + 2x IPv6).
But now multiple hours later, I still get no packet or byte values to show in Firewall > Diagnostics > Aliases.

I don't know if you're missing it, but it would be "Statistics" under the alias config. Stats gathering from pf is a bit wonky, so there will be limitations. (I haven't examined them fully, but block rules don't appear to count, for instance.)

I did miss this so thank you for the info.
Can I enable this for all and everything or will this impact load or disk or whatever too negatively?

Curious. Is Firewall > Diagnostics > Aliases supposed to contain no packet or byte data?  Or am I missing a setting somewhere?

cool, much appreciated for the answers (and corrections).

uch, you are correct off course. corrected my previous post.

Follow-up Q:
The Optional interface ID is then simply the last 64 bits (60 really) to select the actual interface IP address?

Interface ID 0000000000000001 for 2001:db8:ffff:ff79:0000:0000:0000:0001 interface IP or
Interface ID 0000000000000254 for 2001:db8:ffff:ff79:0000:0000:0000:0254 interface IP or (at most)
Interface ID 7fffffffffffffff for 2001:db8:ffff:ff79:7fff:ffff:ffff:ffff interface IP?  (so actually the last 60 bits)

Can someone explain the details regarding getting/offering the correct/a specific prefix from an ISP?

Say I should get the following range:
eg. 2001:db8:ffff:ff00:0000:0000:0000:0000/56   
The prefix in this would be    2001:db8:ffff:ff00::0/56

Now, say i want 2001:db8:ffff:ff01::0/64 for one vlan 1  and 2001:db8:ffff:ff02::0/64 for vlan 2 and 2001:db8:ffff:ff79::0/64 for vlan 79.
How do I go about configuring OPNsense prefix IDs to enable that?

Should the prefix ID for vlan 1: 01, vlan 2: 02 and vlan 79: 79?

Or am I completely wrong here? Or is my ISP not giving me the correct range?