"Recent posts
#21
25.7, 25.10 Series / Re: IPv6 connectivity issue wi...
Last post by hfvk - December 19, 2025, 08:52:06 PMQuote from: Maurice on December 19, 2025, 07:40:45 PMQuote from: hfvk on December 19, 2025, 07:12:08 PMWAN ipv6 address is zzz/128LAN should be a /64. If it's showing /56, the prefix delegation size probably isn't configured correctly (Interfaces / WAN / DHCPv6 client configuration). This needs to be set to the prefix length actually delegated by your ISP.
LAN ipv6 address is yyy/56
Cheers
Maurice
Thanks for the hint. I checked that Interfaces / WAN / DHCPv6 client configuration has 64 as prefix delegation size.
#22
25.7, 25.10 Series / Re: DHCP Not working on Unifi ...
Last post by meyergru - December 19, 2025, 08:45:03 PMQuote from: OPNenthu on December 19, 2025, 07:50:55 AMyou can optionally secure those ports with 802.1X (best, but this is still broken in UniFi as reported by @meyergru).
Matter-of-fact, I got a beta version these days that ought to fix the 802.1x problem. It still does not, but reintroduced the "all VLANs are visible during bootstrap" problem. But at least it seems Ubiquiti is on it.
#23
25.7, 25.10 Series / [solved] 25.7.10 update fails...
Last post by Gromhelm - December 19, 2025, 08:41:31 PMI 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:
I did an health audit:
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:
dmesg looks good, too. It is a little protectli box that has never caused problems before.
Here is the full log:
Code Select
***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
***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
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/libdmesg looks good, too. It is a little protectli box that has never caused problems before.
#24
General Discussion / Re: Seemingly straightforward ...
Last post by brigmaticlaw - December 19, 2025, 08:22:49 PMAlright, I think this is solved since what I was attempting technically works now. That said, I've noticed/learned a few things and am curious...
With the proxy ACLs in place, it would appear I don't even need the original firewall rule allowing access to the service domains. I only need the rule allowing access to the proxy and then NPM takes care of the rest. Is this technically the "correct" way of going about it anyway? Or have I stumbled into the "wrong" way of getting it to work? I ask because even though I'm operating all of this in my home primarily as a way to learn deeper networking topics, I enjoy doing things cleanly and following "best practices".
I have been considering switching over to Traefik as my proxy so I can play around/learn with it and things like Authentik and Crowdsec as middlewares. The Traefik docs mention adding IP access lists to the labels to restrict access like I'm now doing in NPM. Again, I'm assuming that would be the correct way of going about it? I'm trying to mentally square the extent of the firewall's job and the jobs of things like Traefik and Authentik so far as service access and authentication goes. I am starting to suspect I need to alter my thinking from "access control is solely the job of the firewall" to "the firewall is a part of a larger access/security stack with many parts".
With the proxy ACLs in place, it would appear I don't even need the original firewall rule allowing access to the service domains. I only need the rule allowing access to the proxy and then NPM takes care of the rest. Is this technically the "correct" way of going about it anyway? Or have I stumbled into the "wrong" way of getting it to work? I ask because even though I'm operating all of this in my home primarily as a way to learn deeper networking topics, I enjoy doing things cleanly and following "best practices".
I have been considering switching over to Traefik as my proxy so I can play around/learn with it and things like Authentik and Crowdsec as middlewares. The Traefik docs mention adding IP access lists to the labels to restrict access like I'm now doing in NPM. Again, I'm assuming that would be the correct way of going about it? I'm trying to mentally square the extent of the firewall's job and the jobs of things like Traefik and Authentik so far as service access and authentication goes. I am starting to suspect I need to alter my thinking from "access control is solely the job of the firewall" to "the firewall is a part of a larger access/security stack with many parts".
#25
25.7, 25.10 Series / Re: DHCP Not working on Unifi ...
Last post by Thorium - December 19, 2025, 07:43:53 PMThanks resident experts!
I think this thread serves as the definitive "OPnsense router with Unifi switches" need to know.
I think this thread serves as the definitive "OPnsense router with Unifi switches" need to know.
#26
25.7, 25.10 Series / Re: IPv6 connectivity issue wi...
Last post by Maurice - December 19, 2025, 07:40:45 PMQuote from: hfvk on December 19, 2025, 07:12:08 PMWAN ipv6 address is zzz/128LAN should be a /64. If it's showing /56, the prefix delegation size probably isn't configured correctly (Interfaces / WAN / DHCPv6 client configuration). This needs to be set to the prefix length actually delegated by your ISP.
LAN ipv6 address is yyy/56
Cheers
Maurice
#27
25.7, 25.10 Series / Re: IPv6 connectivity issue wi...
Last post by hfvk - December 19, 2025, 07:33:54 PMQuote from: hfvk on December 19, 2025, 07:12:08 PMProblems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN and immediately enable it back to "Track interface", LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.
Just realized that I had a typo. Here are the correct steps to reproduce:
Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.
#28
General Discussion / Re: Net-SNMP Temporarily Stops...
Last post by PhYrE - December 19, 2025, 07:33:08 PMCuriously, this happens for 2h5m each time (the past three times it has happened in the past couple weeks). The probe is every 5 minutes, but the 2h mark is interesting, as it's not just that it's unavailable for a period, but that it's unavailable for a consistent period.
It's strange that it goes on for the same interval. It seems to have a random start time (23:50, 17:50, 8:10) though has happened 3 times in the past two weeks.
It's strange that it goes on for the same interval. It seems to have a random start time (23:50, 17:50, 8:10) though has happened 3 times in the past two weeks.
#29
25.7, 25.10 Series / [SOLVED]: IPv6 connectivity is...
Last post by hfvk - December 19, 2025, 07:12:08 PMHi! I'm having the following issue with IPv6.
My OPNsense box is acting as firewall and router between WAN/LAN with the following setup:
Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN and immediately enable it back to "Track interface", LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.
Restarting DHCP servers or router advertisement daemon doesn't help. So far the only way to get the IPv6 connectivity seems to be temporarily disabling IPv6 and then enabling it again.
Would anybody have any idea what might be wrong with my setup? What additional information you would need to help narrowing down the issue?
I started testing IPv6 with OPNsense 25.7.9 which was also the first time I observed the issue.
Now I am running OPNsense 25.7.10-amd64 and the issue is the same.
My OPNsense box is acting as firewall and router between WAN/LAN with the following setup:
Code Select
TOPOLOGY
Internet -- WAN|opnsense|LAN -- LAN network
WAN igb0 IPv4 DHCP
WAN igb0 IPv6 DHCPv6
LAN em0 IPv4 static KEA DHCP serving the IPv4 LAN network (192.168.xx.yy/24)
LAN em0 IPv6 Track interface ISC DHCPv6 running on the interface
OPNsense addresses:
WAN ipv6 address is zzz/128
LAN ipv6 address is yyy/56
Router advertisement daemon enabled
pf enabled for both IPv4 and IPv6
Problems and steps to reproduce:
1. When I reboot the OPNsense box, WAN and LAN interfaces get the IPv4 and IPv6 addresses. Also, client in the LAN network get their IPv4 and IPv6 addresses correctly.
2. OPNsense box has both IPv4 and IPv6 connectivity to the internet. However, LAN clients can connect only using IPv4 trough the OPNsense box. IPv6 to the internet does not work.
3. When I disable IPv6 for LAN and immediately enable it back to "Track interface", LAN clients can connect to the internet using both IPv4 and IPv6 through the OPNsense box.
4. Both IPv4 and IPv6 connections remain stable until next time I reboot the system.
Restarting DHCP servers or router advertisement daemon doesn't help. So far the only way to get the IPv6 connectivity seems to be temporarily disabling IPv6 and then enabling it again.
Would anybody have any idea what might be wrong with my setup? What additional information you would need to help narrowing down the issue?
I started testing IPv6 with OPNsense 25.7.9 which was also the first time I observed the issue.
Now I am running OPNsense 25.7.10-amd64 and the issue is the same.
#30
25.7, 25.10 Series / Re: Version 25.7.9 did not cha...
Last post by kozistan - December 19, 2025, 07:01:19 PMBefore proceeding with `pkg install opnsense`, the system wants to install 105 new packages:
Many of these packages (like php83, ca_root_nss, etc.) are already installed according to `pkg info`.
Current package count: 134
After this operation: 239 packages
Should I proceed with this, or is there a better way to register the opnsense package without reinstalling dependencies?
Would `pkg install -f opnsense` be more appropriate?
Code Select
root@fw:~# pkg install opnsense
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
SunnyValley repository is up to date.
All repositories are up to date.
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
The following 105 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
beep: 1.0_2 [OPNsense]
boost-libs: 1.89.0_1 [OPNsense]
ca_root_nss: 3.117_2 [OPNsense]
choparp: 20150613_1 [OPNsense]
cpdup: 1.22_1 [OPNsense]
...
php83: 8.3.28 [OPNsense]
php83-ctype: 8.3.28 [OPNsense]
php83-curl: 8.3.28 [OPNsense]
...
opnsense: 25.7.10 [OPNsense]
opnsense-update: 25.7.10 [OPNsense]
...
Number of packages to be installed: 105
The process will require 728 MiB more space.
117 MiB to be downloaded.
Many of these packages (like php83, ca_root_nss, etc.) are already installed according to `pkg info`.
Current package count: 134
After this operation: 239 packages
Should I proceed with this, or is there a better way to register the opnsense package without reinstalling dependencies?
Would `pkg install -f opnsense` be more appropriate?
