"Recent posts
#1
26.7 Series / Unbound stopps suddenly
Last post by MiRei - Today at 09:11:04 AMGood Morning,
thanks for the new 26.7!
OPNSense is a truly great product; thank you very much for maintaining and
further developing it.
The upgrade to 26.7 went smoothly. After two days of use, I've now noticed
Unbound crashing for the second time, with the following error message:
(unbound), jid 0, uid 59, was killed: failed to reclaim memory
After that, I can manually restart Unbound, and the system continues to run normally.
Any ideas?
Thanks a lot!
thanks for the new 26.7!
OPNSense is a truly great product; thank you very much for maintaining and
further developing it.
The upgrade to 26.7 went smoothly. After two days of use, I've now noticed
Unbound crashing for the second time, with the following error message:
(unbound), jid 0, uid 59, was killed: failed to reclaim memory
After that, I can manually restart Unbound, and the system continues to run normally.
Any ideas?
Thanks a lot!
#2
German - Deutsch / Re: Anfänger und sorry --- bek...
Last post by Bob.Dig - Today at 09:03:11 AMQuote from: Orion1984 on Today at 08:44:12 AMMit den Regeln bin ich nicht so wirklich richtig gutDas ist leider wahr, die Regeln sind eher schlecht und Du verlässt dich hier ausschließlich auf das Gateway setzen, um deine Netze zu trennen. Das mag funktionieren, muss aber nicht. Auch ist deine letzte Regel nutzlos.
Zur eigentlichen Frage, ein "DNS-Leak" in einer Sense ist nicht grundsätzlich negativ. Wenn Du es aber unbedingt vermeiden willst, musst Du dir deine DNS-Kette angucken. Also in dem Client, für den dir ein "Leak" angezeigt wird, wo löst der DNS auf? Wenn Du im Client z.B. 8.8.8.8 einträgst, dann "sollte" die Auflösung mit deinen gezeigten Firewall-Regeln über Mullvad laufen. Wenn Mullvad selbst DNS-Server anbietet, kannst Du natürlich auch diese stattdessen verwenden. In beiden Fällen wird Unbound hier nicht mehr genutzt und deine DNS-Blocklisten finden keine Anwendung. Das ist normal und letztlich deine Entscheidung.
Zwar gibt es auch noch andere Wege, aber die würde ich dir bei deinem Kenntnisstand nicht empfehlen bzw. ich selbst habe mich bewusst dagegen entschieden. So könntest Du Unbound generell durch das VPN zwingen, aber dann hast Du auch schnell generelle Probleme, wenn dieses nicht zuverlässig läuft etc.
#3
German - Deutsch / Re: Anfänger und sorry --- bek...
Last post by meyergru - Today at 08:59:02 AMIm Grunde ist es doch ganz einfach:
Welcher DNS-Server ist auf Deinem VPN-Client konfiguriert (Du hast übrigens nicht die DHCP-Einstellungen gezeigt)? Wenn es Deine OpnSense und nicht der Mullvad-VPN-Server ist, müsstest Du eine Regel auf der OpnSense haben, die für die VPN-Clients den DNS auf Mullvad umbiegt. Das ist ziemlich komplex, also würde ich entweder per DHCP diesen Clients den Mullvad DNS mitteilen oder diese Clients statisch konfigurieren.
Welcher DNS-Server ist auf Deinem VPN-Client konfiguriert (Du hast übrigens nicht die DHCP-Einstellungen gezeigt)? Wenn es Deine OpnSense und nicht der Mullvad-VPN-Server ist, müsstest Du eine Regel auf der OpnSense haben, die für die VPN-Clients den DNS auf Mullvad umbiegt. Das ist ziemlich komplex, also würde ich entweder per DHCP diesen Clients den Mullvad DNS mitteilen oder diese Clients statisch konfigurieren.
#4
26.7 Series / Re: Wireguard S2S broken
Last post by franco - Today at 08:55:38 AMSo I only mentioned this because: Name does not resolve: `xxxxxxxx.spdns.org:51820'
There's a re-resolve cron job you should use whenever you have DNS-based endpoints for WireGuard which should deal with this better now.
The issue in a nutshell:
wg will not accept the whole configuration if there is a single "syntax" error in the file. Since the kernel doesn't do DNS a syntax error is the absence of an IP address for the peer. Instead of loading everything but the peer address, wg loads nothing and their own example for re-resolve script will not address that fact either. So our re-resolve was extended to add the missing pieces. If these are all missing pieces we don't exactly know.
Cheers,
Franco
There's a re-resolve cron job you should use whenever you have DNS-based endpoints for WireGuard which should deal with this better now.
The issue in a nutshell:
wg will not accept the whole configuration if there is a single "syntax" error in the file. Since the kernel doesn't do DNS a syntax error is the absence of an IP address for the peer. Instead of loading everything but the peer address, wg loads nothing and their own example for re-resolve script will not address that fact either. So our re-resolve was extended to add the missing pieces. If these are all missing pieces we don't exactly know.
Cheers,
Franco
#5
Hardware and Performance / Re: cpu-microcode-intel: no ma...
Last post by fastboot - Today at 08:54:09 AMAnother Quick update....
Following feedback from the FreeBSD maintainer, I tested late/runtime microcode loading again, including after downgrading to the older cpu-microcode-intel-20260512 package.
After rebooting, the CPU was back at 0x432. The runtime update then successfully applied 0x43b:
/usr/local/share/cpucontrol/06-9a-04.80: updating cpu /dev/cpuctl0 from rev 0x432 to rev 0x43b... done.
This confirms that runtime loading works even with the older package. The remaining issue appears to be specific to the FreeBSD early loader path rather than the microcode package itself.
The FreeBSD bug report has been updated accordingly.
Following feedback from the FreeBSD maintainer, I tested late/runtime microcode loading again, including after downgrading to the older cpu-microcode-intel-20260512 package.
After rebooting, the CPU was back at 0x432. The runtime update then successfully applied 0x43b:
/usr/local/share/cpucontrol/06-9a-04.80: updating cpu /dev/cpuctl0 from rev 0x432 to rev 0x43b... done.
This confirms that runtime loading works even with the older package. The remaining issue appears to be specific to the FreeBSD early loader path rather than the microcode package itself.
The FreeBSD bug report has been updated accordingly.
#6
26.7 Series / Re: No problems with os-caddy ...
Last post by franco - Today at 08:51:58 AMCool, happy to hear :)
Cheers,
Franco
Cheers,
Franco
#7
26.7 Series / Re: Wireguard S2S broken
Last post by meyergru - Today at 08:51:35 AMQuote from: Patrick M. Hausen on July 16, 2026, 11:25:49 PM@franco I rather appreciate that upstream change - what are we looking for in the WG context, specifically?
The patch was about the issue that the peer was not initialized during startup. The reresolve script only changes parameters in the Wireguard connection, it does not restart from scratch.
A Wireguard connection can have a peer (like with outbound s2s or a c2s client), but it does not have to (like with inbound s2s or a c2s server), so the "allowedips" attribute can become empty during WG startup. It definitely will be when the DNS cannot be resolved on startup and the old script did not handle that case yet.
Essentially, the old script handled the case of a changed DNS entry (by reresolving the peer), but it could not create the full connection if the peer was not resolvable in the start phase due to timing conditions (it set the peer, but allowedips was still empty).
#8
German - Deutsch / Re: Anfänger und sorry --- bek...
Last post by Orion1984 - Today at 08:44:12 AMHallo, ich füge mal noch ein paae Screenshots bei.
Regeln, Unbound, Gateway, etc.
Mit den Regeln bin ich nicht so wirklich richtig gut. ;-)
Regeln, Unbound, Gateway, etc.
Mit den Regeln bin ich nicht so wirklich richtig gut. ;-)
#9
Hardware and Performance / Re: Warning about RealTek adap...
Last post by meyergru - Today at 08:30:00 AMAs I said, I had two cards from different vendors. When you look at the RTL8126/7 pinouts, you will find that the chip is directly connected to the PCIe lanes, giving the PCB manufacturer little to vary, except for routing the connections. Of course there may be problems with power filtering and such.
BTW: I do not have those cards any more, as the ASUS NIC - which is based on another chip - works nicely, as discussed.
A driver problem that is not cleared up during the next boot would explain the initialisation failures, but not the data corruption - the latter strongly suggests a signaling problem. I am using Occam's Razor here because a signaling problem explains both symptoms. I did not investigate any further because I lack the exquipment and skills to verify the finding and it simply was not worth the effort for me.
BTW: I do not have those cards any more, as the ASUS NIC - which is based on another chip - works nicely, as discussed.
A driver problem that is not cleared up during the next boot would explain the initialisation failures, but not the data corruption - the latter strongly suggests a signaling problem. I am using Occam's Razor here because a signaling problem explains both symptoms. I did not investigate any further because I lack the exquipment and skills to verify the finding and it simply was not worth the effort for me.
#10
German - Deutsch / Re: Anfänger und sorry --- bek...
Last post by meyergru - Today at 08:16:23 AMDas bedeutet, dass die DNS-Anfragen von Deinem Client nicht den Weg über die VPN-Verbindung nehmen, sondern vermutlich über den DNS-Server auf Deiner OpnSense. Du schreibst nicht, was das für ein Client ist (OS, Browser, welche DNS-Einstellungen nutzt der?).
Offenbar hast Du das VPN auf der OpnSense und nicht auf dem Client eingerichtet.
Wenn Du beispielsweise nur bestimmte Clients oder VLANs über Dein Mullvad-VPN-Gateway routest, hast Du eventuell die Routen für lokale Netze trotzdem ohne VPN konfiguriert, weil Du z.B. per SSH, RDP oder sonstiges diese VPN-Clients aus Deinem LAN kontroliieren willst und sie direkt erreichen musst. Das erlaubt natürlich die Nutzung der OpnSense als DNS-Server. Du musst auf den VPN-Clients "irgendwie" dafür sorgen, dass sie die Mullvad-DNS-Server nutzen, z.B. per DHCP, lokaler Konfiguration oder per DNS-Umleitung. Das wirkt allerdings eventuell nur begrenzt, falls z.B. im Browser DoT oder DoH eingestellt ist (obwohl diese Adressen eher nicht in einem lokalen Bereich liegen und daher wohl per VPN geroutet werden).
Ein Fehler könnte auch darin liegen, dass Du Regeln verwendest, die jeden DNS-Request per NAT auf Deine OpnSense umleiten - dann könnte sonstwas auf dem VPN-CLient eingestellt sein, jeder Request wird dann auf die OpnSense geleitet, was Du bei VPN-Clients nicht willst.
Offenbar hast Du das VPN auf der OpnSense und nicht auf dem Client eingerichtet.
Wenn Du beispielsweise nur bestimmte Clients oder VLANs über Dein Mullvad-VPN-Gateway routest, hast Du eventuell die Routen für lokale Netze trotzdem ohne VPN konfiguriert, weil Du z.B. per SSH, RDP oder sonstiges diese VPN-Clients aus Deinem LAN kontroliieren willst und sie direkt erreichen musst. Das erlaubt natürlich die Nutzung der OpnSense als DNS-Server. Du musst auf den VPN-Clients "irgendwie" dafür sorgen, dass sie die Mullvad-DNS-Server nutzen, z.B. per DHCP, lokaler Konfiguration oder per DNS-Umleitung. Das wirkt allerdings eventuell nur begrenzt, falls z.B. im Browser DoT oder DoH eingestellt ist (obwohl diese Adressen eher nicht in einem lokalen Bereich liegen und daher wohl per VPN geroutet werden).
Ein Fehler könnte auch darin liegen, dass Du Regeln verwendest, die jeden DNS-Request per NAT auf Deine OpnSense umleiten - dann könnte sonstwas auf dem VPN-CLient eingestellt sein, jeder Request wird dann auf die OpnSense geleitet, was Du bei VPN-Clients nicht willst.
