Topics

I tried to update today to 25.7.10 and it downloads forever at "Fetching base-25.7.10-amd64.txz". The update then fails after 10 Minutes with "failed, signature invalid"

Here is the full log:

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 25.7.9_7 (amd64) at Fri Dec 19 20:16:28 CET 2025
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 (85 candidates): .......... done
Processing candidates (85 candidates): .. done
The following 16 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    dpinger: 3.3 -> 3.4
    gettext-runtime: 0.23.1 -> 0.26
    glib: 2.84.1_3,2 -> 2.84.4,2
    libgpg-error: 1.56 -> 1.58
    libucl: 0.9.2_2 -> 0.9.3
    nss: 3.118.1 -> 3.119.1
    opnsense: 25.7.9_7 -> 25.7.10
    opnsense-update: 25.7.8 -> 25.7.10
    php83-phpseclib: 3.0.47 -> 3.0.48
    py311-anyio: 4.11.0 -> 4.12.0
    py311-certifi: 2025.10.5 -> 2025.11.12
    py311-dns-lexicon: 3.21.1 -> 3.23.2
    py311-numpy: 1.26.4_10,1 -> 1.26.4_11,1
    py311-tzdata: 2025.2 -> 2025.3
    py311-urllib3: 2.5.0,1 -> 2.6.0,1
    socat: 1.8.0.3 -> 1.8.1.0

Number of packages to be upgraded: 16

22 MiB to be downloaded.
[1/16] Fetching py311-anyio-4.12.0.pkg: .......... done
[2/16] Fetching dpinger-3.4.pkg: . done
[3/16] Fetching opnsense-update-25.7.10.pkg: .... done
[4/16] Fetching py311-numpy-1.26.4_11,1.pkg: .......... done
[5/16] Fetching nss-3.119.1.pkg: .......... done
[6/16] Fetching py311-dns-lexicon-3.23.2.pkg: .......... done
[7/16] Fetching php83-phpseclib-3.0.48.pkg: .......... done
[8/16] Fetching py311-certifi-2025.11.12.pkg: .......... done
[9/16] Fetching py311-tzdata-2025.3.pkg: .......... done
[10/16] Fetching socat-1.8.1.0.pkg: .......... done
[11/16] Fetching libgpg-error-1.58.pkg: .......... done
[12/16] Fetching gettext-runtime-0.26.pkg: .......... done
[13/16] Fetching py311-urllib3-2.6.0,1.pkg: .......... done
[14/16] Fetching glib-2.84.4,2.pkg: .......... done
[15/16] Fetching libucl-0.9.3.pkg: ........ done
[16/16] Fetching opnsense-25.7.10.pkg: .......... done
Checking integrity... done (0 conflicting)
[1/16] Upgrading dpinger from 3.3 to 3.4...
[1/16] Extracting dpinger-3.4: .... done
[2/16] Upgrading gettext-runtime from 0.23.1 to 0.26...
[2/16] Extracting gettext-runtime-0.26: .......... done
[3/16] Upgrading glib from 2.84.1_3,2 to 2.84.4,2...
[3/16] Extracting glib-2.84.4,2: .......... done
[4/16] Upgrading libgpg-error from 1.56 to 1.58...
[4/16] Extracting libgpg-error-1.58: .......... done
[5/16] Upgrading libucl from 0.9.2_2 to 0.9.3...
[5/16] Extracting libucl-0.9.3: .......... done
[6/16] Upgrading nss from 3.118.1 to 3.119.1...
[6/16] Extracting nss-3.119.1: .......... done
[7/16] Upgrading opnsense-update from 25.7.8 to 25.7.10...
[7/16] Extracting opnsense-update-25.7.10: .......... done
[8/16] Upgrading php83-phpseclib from 3.0.47 to 3.0.48...
[8/16] Extracting php83-phpseclib-3.0.48: ......... done
[9/16] Upgrading py311-anyio from 4.11.0 to 4.12.0...
[9/16] Extracting py311-anyio-4.12.0: .......... done
[10/16] Upgrading py311-certifi from 2025.10.5 to 2025.11.12...
[10/16] Extracting py311-certifi-2025.11.12: .......... done
[11/16] Upgrading py311-dns-lexicon from 3.21.1 to 3.23.2...
[11/16] Extracting py311-dns-lexicon-3.23.2: .......... done
[12/16] Upgrading py311-numpy from 1.26.4_10,1 to 1.26.4_11,1...
[12/16] Extracting py311-numpy-1.26.4_11,1: .......... done
[13/16] Upgrading opnsense from 25.7.9_7 to 25.7.10...
[13/16] Extracting opnsense-25.7.10: .......... done
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
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.
[14/16] Upgrading py311-tzdata from 2025.2 to 2025.3...
[14/16] Extracting py311-tzdata-2025.3: .......... done
[15/16] Upgrading py311-urllib3 from 2.5.0,1 to 2.6.0,1...
[15/16] Extracting py311-urllib3-2.6.0,1: .......... done
[16/16] Upgrading socat from 1.8.0.3 to 1.8.1.0...
[16/16] Extracting socat-1.8.1.0: ......... done
==> Running trigger: glib-schemas.ucl
Compiling glib schemas
No schema files found: doing nothing.
==> Running trigger: gio-modules.ucl
Generating GIO modules cache
=====
Message from opnsense-25.7.10:

--
Some will win, some will lose, some are born to sing the blues
=====
Message from py311-urllib3-2.6.0,1:

--
Since version 1.25 HTTPS connections are now verified by default which is done
via "cert_reqs = 'CERT_REQUIRED'".  While certificate verification can be
disabled via "cert_reqs = 'CERT_NONE'", it's highly recommended to leave it on.

Various consumers of net/py-urllib3 already have implemented routines that
either explicitly enable or disable HTTPS certificate verification (e.g. via
configuration settings, CLI arguments, etc.).

Yet it may happen that there are still some consumers which don't explicitly
enable/disable certificate verification for HTTPS connections which could then
lead to errors (as is often the case with self-signed certificates).

In case of an error one should try first to temporarily disable certificate
verification of the problematic urllib3 consumer to see if that approach will
remedy the issue.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
The following package files will be deleted:
    /var/cache/pkg/libucl-0.9.3.pkg
    /var/cache/pkg/py311-numpy-1.26.4_11,1~d5a615882f.pkg
    /var/cache/pkg/py311-dns-lexicon-3.23.2~cf3889e77e.pkg
    /var/cache/pkg/nss-3.119.1~4b1fda0aab.pkg
    /var/cache/pkg/py311-urllib3-2.6.0,1~c0b1f10e54.pkg
    /var/cache/pkg/glib-2.84.4,2.pkg
    /var/cache/pkg/py311-certifi-2025.11.12~215272b159.pkg
    /var/cache/pkg/dpinger-3.4~276601a0c0.pkg
    /var/cache/pkg/py311-dns-lexicon-3.23.2.pkg
    /var/cache/pkg/nss-3.119.1.pkg
    /var/cache/pkg/py311-urllib3-2.6.0,1.pkg
    /var/cache/pkg/py311-anyio-4.12.0.pkg
    /var/cache/pkg/py311-anyio-4.12.0~f3781d8bca.pkg
    /var/cache/pkg/libgpg-error-1.58~dc941ea303.pkg
    /var/cache/pkg/py311-certifi-2025.11.12.pkg
    /var/cache/pkg/opnsense-25.7.10~e8fe778b04.pkg
    /var/cache/pkg/opnsense-update-25.7.10~87bc1e1d0a.pkg
    /var/cache/pkg/libgpg-error-1.58.pkg
    /var/cache/pkg/glib-2.84.4,2~6b60e61d06.pkg
    /var/cache/pkg/opnsense-update-25.7.10.pkg
    /var/cache/pkg/gettext-runtime-0.26~dadd59a075.pkg
    /var/cache/pkg/php83-phpseclib-3.0.48~5bf8d63581.pkg
    /var/cache/pkg/php83-phpseclib-3.0.48.pkg
    /var/cache/pkg/opnsense-25.7.10.pkg
    /var/cache/pkg/dpinger-3.4.pkg
    /var/cache/pkg/libucl-0.9.3~417cf27395.pkg
    /var/cache/pkg/socat-1.8.1.0.pkg
    /var/cache/pkg/py311-tzdata-2025.3.pkg
    /var/cache/pkg/py311-tzdata-2025.3~fa615f73d6.pkg
    /var/cache/pkg/py311-numpy-1.26.4_11,1.pkg
    /var/cache/pkg/gettext-runtime-0.26.pkg
    /var/cache/pkg/socat-1.8.1.0~67390374ff.pkg
The cleanup will free 22 MiB
Deleting files: .......... done
Nothing to do.
Starting web GUI...done.
Fetching base-25.7.10-amd64.txz: ... failed, signature invalid
***DONE***

I did an health audit:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 25.7.10 (amd64) at Fri Dec 19 20:36:08 CET 2025
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 25.7.8 is incorrect, expected: 25.7.10
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 25.7.8 is incorrect, expected: 25.7.10
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-acme-client 4.11
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 25.7.10 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***

In update, I see that base and kernel are still listed as updateable. If I repeat the process, I get the same. I fear restarting the box now that it is in an unstable state.

There's enough space left:

Code Select Expand

root@router:~ # df -h
Filesystem                   Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default           8.3G    1.4G    7.0G    17%    /
devfs                        1.0K      0B    1.0K     0%    /dev
zroot/tmp                    7.0G    1.2M    7.0G     0%    /tmp
zroot/var/crash              7.0G     88K    7.0G     0%    /var/crash
zroot/usr/ports              7.0G     88K    7.0G     0%    /usr/ports
zroot                        7.0G     88K    7.0G     0%    /zroot
zroot/var/audit              7.0G     88K    7.0G     0%    /var/audit
zroot/var/log                7.1G     94M    7.0G     1%    /var/log
zroot/var/mail               7.0G    112K    7.0G     0%    /var/mail
zroot/var/tmp                7.0G    100K    7.0G     0%    /var/tmp
zroot/usr/home               7.0G     88K    7.0G     0%    /usr/home
zroot/usr/src                7.0G     88K    7.0G     0%    /usr/src
devfs                        1.0K      0B    1.0K     0%    /var/dhcpd/dev
devfs                        1.0K      0B    1.0K     0%    /var/unbound/dev
/usr/local/lib/python3.11    8.3G    1.4G    7.0G    17%    /var/unbound/usr/local/lib/python3.11
/lib                         8.3G    1.4G    7.0G    17%    /var/unbound/lib
dmesg looks good, too. It is a little protectli box that has never caused problems before.

I heavily rely on my IPSEC site-to-site policy VPN and waited until now to do the legacy migration.

I got until the pre-shared Key step, where in my legacy setup I used "My IP address" for phase 1 (Auth) in the field "My identifier".

In the new IPSEC setup, there is no drop-down for selecting "My identifier". I have a dynamic IP-address on one side, so I cannot enter a static ip address here.
It says:
> This can be either an IP address, fully qualified domain name or an email address.

What do you suggest selecting here, going forward with the migration?

Since the last update, my radvd is not starting. It looks like playing with IPv6 (and finally disabling it again), I have  recurring problems with the DHCPv6 and radvd service.

Tried to reset everything following https://forum.opnsense.org/index.php?topic=34584.0 this did not solve my issue. radvd still not starting, even if clicked manually. There is also no error in logs.

When following the above guide, I got:

Code Select Expand



2023-12-17T08:06:34 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb3'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:31 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb2'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'
2023-12-17T08:06:27 Error opnsense /interfaces.php: The command '/sbin/ifconfig 'igb1'
inet6 '::1' prefixlen '128' no_dad' returned exit code '1', the output was 'ifconfig:
ioctl (SIOCDIFADDR): Invalid argument'


But I cannot assign this to any specific action.

Where would I start debugging starting of radvd?

[igb1:]

I have continuing problems with IPv6 setup in OPNsense. It works for 1-2 days after a restart, but then stops working.

Today I found the following logs under:
/ui/diagnostics/log/core/routing

> Warning   radvd   prefix length should be 64 for igb3
> Warning   radvd   prefix length should be 64 for igb1
> radvd   sendmsg: Network is down
> Warning   radvd   prefix length should be 64 for igb3
> Warning   radvd   prefix length should be 64 for igb1
> radvd   sendmsg: Network is down
> ...

Since I use "Track WAN" for IPv6 on both, and WAN is setup with /64, this does not make sense to me.

Under /status_interfaces.php, I see the following values:
igb1:
IPv4 address   192.168.100.1/24
IPv4 gateway   auto-detected: 192.168.100.1
IPv6 link-local   fe80::2e0:67ff:fe2a:72e4/64
IPv6 address   2003:e7:1f0c:8e00:2e1:37ff:fe2a:72e4/56

igb1 (lan) is configured with:
IPv6 Configuration Type - Track Interface
IPv6 Interface - WAN

wan:
DHCP           DHCPv6 up 
PPPoE                up
MTU                    1492
IPv6 link-local   fe80::2e0:67ff:fe2a:72e3/64
IPv6 address   2003:e7:1fff:d24:2e1:37ff:fe2a:72e3/64
IPv6 prefix   2003:e7:1f0c:8e00::/56
IPv6 gateway   auto-detected: fe80::224e:71ff:fe11:2cfe

My IPv6 configuration for WAN follows the DHCPv6 instructions in the docs:
IPv6 Configuration Type - DHCPv6
Request only an IPv6 prefix - yes
Prefix delegation size - 64
Send IPv6 prefix hint - yes
Use IPv4 connectivity - yes
Use VLAN priority - Disabled

How can I go further to debug this? Why does my LAN (igb1) has a /56 IPv6 address, when WAN has a /64 IPv6 address?

The same is reported here on Reddit, for the exact same ISP (Telekom).