Messages

Upgraded to 26.1-r2_2 from 25.7.11 on my home box.

Did not see too many php-cgi processes, but I did not have rapid commit enabled. System is up and running with both IPv4 and IPv6.



What I did see was two popups about errors and then this in the crash reporter:

Code Select Expand

[26-Jan-2026 18:40:11 Europe/Berlin] Error: Class "OPNsense\Mvc\Router" not found in /usr/local/opnsense/www/api.php:35
Stack trace:


There was no stack trace or panic.

I did a health check, which gave this:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.r2_2 (amd64) at Mon Jan 26 18:40:52 CET 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.r1 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.r1 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
mimugmail (Priority: 5)
OPNsense (Priority: 11)
>>> Check installed plugins
os-acme-client 4.12
os-auto-recovery-community 1.0
os-c-icap 1.9
os-cache 1.0_1
os-caddy 2.0.4_3
os-chrony 1.5_3
os-clamav 1.8.1
os-cpu-microcode-intel 1.1
os-crowdsec 1.0.12
os-ddclient 1.29
os-dmidecode 1.2
os-dnscrypt-proxy 1.16_1
os-etpro-telemetry 1.8
os-freeradius 1.10
os-ftp-proxy 1.0_4
os-gdrive-backup 1.0
os-git-backup 1.1_2
os-haproxy 4.6_2
os-homeassistant-maxit 1.0
os-igmp-proxy 1.5_6
os-intrusion-detection-content-et-open 1.0.2_2
os-intrusion-detection-content-ptopen 1.0
os-iperf 1.0_2
os-isc-dhcp-devel 1.0_3
os-mdns-repeater 1.2
os-nextcloud-backup 1.1
os-opnarp-maxit 1.0_4
os-q-feeds-connector 1.4
os-qemu-guest-agent 1.3
os-realtek-re 1.0
os-sftp-backup 1.1_2
os-smart 2.4
os-squid 1.4
os-tayga 1.3
os-telegraf 1.12.14
os-tftp 1.0
os-theme-advanced 1.1
os-theme-cicada 1.40
os-theme-flexcolor 1.0
os-theme-rebellion 1.9.4
os-theme-solarized-community 0.4_1
os-theme-tukan 1.30
os-theme-vicuna 1.50
os-udpbroadcastrelay 1.0_6
os-upnp 1.8
os-wol 2.5_3
>>> 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 26.1.r2_2 has 67 dependencies to check.
Checking packages: .............
hostwatch-1.0.9 is not set to automatic
Checking packages: ....................................................... done
***DONE***
Don't know about the hostwatch thing. In fact, it is disabled, but last time I upgraded this way, it was enabled by default and I did not touch the setting.

Associated NAT firewall rules got disassociated and are editable, as expected.

It seems there is no way I can disable the Qfeeds domain blocklist - the content of dnsbl.json is still there and used after uninstalling the Qfeeds plugins completely.

The only way I found is to recreate an empty dnsbl.json and restart Unbound.

I had two lists, but both disabled. I deleted them and still get ~235000 entries in the blocklist, maybe those are the Qfeeds items.

However, they are there regardless of me having "Register domain feeds" enabled or disabled. How do you register your blocklist into Unbound technically? This looks like there is a downloaded domain list that is injected into Unbound, but after disabling it, the list persists.

I found /var/unbound/data/dnsbl.json that seems to have the data included. I wonder how the different blocklists and the Qfeeds lists are integrated without interfering with one another...

But the instructions given there will not work for this specific setup, because the ufs partition is not the last one on the disk. The swap partition is in the way for the enlargement and has to be deleted first.

Nein, das ist nicht notwendig. Ich würde mal schauen, welchen Weg die DNS-Update-Pakete nehmen (also TCPdump auf der OpnSense). Vielleicht ist noch etwas falsch konfiguriert.

Die einzige Möglichkeit wäre, dass der DNS-Server, dem Du die Updates schickst, zufällig in Deinem internen Unbound-DNS auf die interne IP umgelenkt wird. Deswegen muss man dafür einen eigenen DNS-Namen nehmen, der ungleich dem Webserver-DNS-Namen ist, z.B. ns.domain.de vs. www.domain.de. Und dann trägt man die lokale IP nur für www.domain.de ein, nicht für ns.domain.de.

Yep. But I cannot choose a "Qfeeds" blocklist and I also do not see anything special in the generated Unbound config files, so this seems to have no effect.

"!" bedeutet Negation, also die Checkbox "Destination / Invert" zu setzen. Und dann trägt man die Host-IP in das die Destination als "Single Host or IP" ein. Damit ist alles, was NICHT HOST-IP ist, von der Regel betroffen, nicht mehr "any". Die Einschränkung auf Deine lokalen Clients braucht es gar nicht, weil "any" genausogut funktioniert - wer soll denn sonst fragen?

Schau Dir einfach mal die Bilder im ersten Post des verlinkten Threads an, da sieht man, dass das "Destination / Invert" in der Regelliste zu einem vorangestellten "!" führt, z.B. in "! LAN Address".


Und nein, nochmal, den DNS-Server musst Du nicht ändern. Für die DNS-Requests kann er ganz normal die OpnSense nutzen. Die DNS Updates werden normalerweise sowieso an den authoritativen DNS-Server für die Domain abgesetzt - das ist meist einer im Internet.

Dummerweise sorgt die Redirect-Regel aber dafür, dass JEDER DNS-Request umgebogen wird, neben den DNS-Queries auch die DNS-Updates, die weiterhin nach draußen gehen sollen. Das liegt einfach daran, dass man nur auf den UDP Port 53 matcht, und der ist bei beiden Varianten gleich. Man müsste ins Protokoll hineinschauen, um zu sehen, dass es Update und keine Queries sind, aber das geht nicht so einfach.

Wenn Du die Regel komplett deaktivierst und Deine Clients sich "wohl verhalten", würden sie ja per DHCP auch die OpnSense als DNS-Server genannt bekommen und diese ohnehin nutzen. Die ganze Umleiterei macht man doch nur "on top", um das bei böswilligen oder fehlkonfigurierten Clients zu erzwingen.

Was ist meine ist, dass man das normalerweise so macht, dass man einen Port Forward für Traffic mit Zielport UDP 53 auf 127.0.0.1:53 macht. Dadurch würde jeder DNS-Request von internen Quellen auf die OpnSense umgebogen. Die einzige Änderung ist, dass man in der Regel die Quelle mit !HOST-IP einträgt. Damit ist HOST-IP als einziger von diesem "Umbiegen" ausgenommen.

Ist alles hier beschrieben, inklusive dieses Problems, ziemlich am Ende des Threads.

Es geht doch nur um eine Ausnahme für den Redirect für den Rechner, der das Zertifikat beantragt. Der Redirect soll doch nur dazu dienen, dass kein externer DNS-Server genutzt werden kann, sondern alle Requests auf Zielport 53 auf die OpnSense umgebogen werden (somit auch die DNS Updates).

Durch die Einschränkung erlaubst Du doch nur einem einzigen Host, diese Beschränkung zu umgehen. Das heißt nicht, dass er nicht als DNS-Resolver weiterhin die OpnSense nehmen DARF - nur eben nicht MUSS. Den externen DNS nutzt er doch nur für den DNS-Update. Klar, er KÖNNTE dann auch andere DNS-Resolver nutzen, aber da es sich mutmaßlich um einen Server handelt, wird das doch eher nicht passieren, oder?

Was man mit einer solchen Regel typischerweise erzwingen will, ist, dass IoT-Geräte oder Smartphones den eigenen DNS nutzen müssen.

Wie gesagt, wenn Du den DNS-Redirect wegnimmst, kannst Du ja den DNS update direkt absetzen. Das geht an jedem lokalen DNS-Sever vorbei und bedarf nur einer Regeleinschränkung im Port-Forwarding.

This is supposed to work with Unbound according to the docs, but even after I checked "Register domain feeds", I cannot see anything w/r to Qfeeds in the Unbound blocklists, although both sets (IPs and domains) seem to be licensed.

Oh, I never used those, didn't not know they exist. Are they in a useable format for Unbound?

Machst Du DNS-01 Verifikation? Falls ja, die DNS Updates werden weder durch Unbound noch durch DNSmasq durchgeleitet - beide Server können nur DNS-Queries verarbeiten. Ich habe das gemerkt, als ich versucht habe, mit einem Server "hinter" OpnSense einen DNS-01 update per RFC2136 durchzuführen, während ich alle DNS-Requests über den lokalen Unbound geforwardet hatte. Ich musste für den betroffenen Host eine Ausnahme eintragen.

Probably. The Qfeeds list contain IPs, not domains, so you have to use the alias in a firewall rule, not in a DNS blocklist.

Good question, but I think you could create that rule as the first interface rule as well. Creating a floating rule as suggested only makes extra sure it gets processed first.