Messages

That is an 10G Base-SR type SFP+ transceiver, which is way less power-consuming than RJ45 ones. For DAC cables, you do not even get a temp reading, because they are the least power hungry of the three types.

This seems to differ in business and community versions. In the community version, you have to acquire a license yourself and enter the corresponding URL with a token, whereas in the business version, you only have to choose which one you want.

The problem you had is literally described in this article, point 5. Maybe you should read it in full.

There are also other pitfalls, like not creating an "Allow any" rule, which is automatically created only for the first LAN and which may be the cause of your DHCP problem. Other than that, the HOWTOs in the OpnSense documentation are mostly very good. Also, there is a tutorial section in the forum where specific topics are covered.

That being said, I repeat what I often say: OpnSense is not your average consumer router where point-and click just works. It is a professional tool that should be operated by experts. Otherwise, it can (and probably will) do more harm than good.

For the same reason, I urge everyone to refrain from using all kinds of external "internet" guides and/or videos, because they are often outdated or too unspecific. More often than not, these videos leave the impression that anyone can somehow "make their network more secure" by using OpnSense - which may even be dangerous in many cases. If you really aim to use OpnSense, you should either be network-savvy in the first place or be prepared to go to a steep (and long) learning curve. The READ ME FIRST article is a good starting point.

Also, sometimes, there is a misunderstanding that in the forum, you will be taken by the hand and guided through the process - that is simply not possible. For starters, this forum is not an official Deciso support forum, but mostly used by hobbyists.

Thus, you will have to learn by yourself and if you get stuck, you can come back and ask for specific unclear points.

Isn't that exactly what the documentation shows? https://docs.opnsense.org/manual/how-tos/shaper_limit_per_user.html

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.