Messages

Zuerst einmal würde ich den Update-Cache leeren:

^{rm -rf /var/cache/opnsense-update/*}

und dann das Update neu erzwingen:

_{opnsense-update -F}

Und zusätzlich könntest Du mal noch eine andere Quelle einstellen per System -> Firmware -> Settings.

Und falls das alles nicht helfen sollte, wäre der Weg per Bootstrap (in-place Reinstall) sicher sinnvoll.

Hopefully not only the Linux Foundation but also the FreeBSD community and OPNsense team will gain access to this tool.

Yes, there are scams around and AI & Cyber Security are kind of buzzwords, but please read carefully:

https://red.anthropic.com/2026/mythos-preview/

I'm not a developer nor security expert, but I think this is something the BSD developers and OPNsense team shouldn't ignore ...

Apple hat diese Probleme mit Unterstützung durch Sergei Glazunov und Ivan Fratric (beide vom Google Project Zero) immerhin schon am 29. / 30. Juli 2025 gefixt, also sowohl in libxml2 als auch libxslt (CVE-2025-7425 sowie CVE-2025-7424), siehe dazu:

https://support.apple.com/de-de/124152 bzw. auch https://support.apple.com/en-us/124149

Eventuell macht es ja Sinn, das entsprechend erfahrene OPNsense-Entwickler Kontakt mit Sergei und/oder Ivan aufnehmen, um einen Fix für FreeBSD und letztlich auch OPNsense entwickeln zu können?

Man will doch ganz sicher nicht damit leben, dass diese CVEs jetzt "für immer" als Warnung in der OPNsense angezeigt werden, sobald man den Security Audit laufen lässt?

Sprich, da sollte doch ein Patch möglich sein, insbesondere bei einem so sicherheits-sensiblen Projekt wie OPNsense?

Die DCO Funktion gibt es nicht für legacy sondern nur für die neuen instances.

PS: Diese warnings verschwinden übrigens komplett, wenn man die "Certificate Revocation List" auf 'none' stellt, also deaktiviert.

Das Thema gab es ja schon mal vor ein paar Jahren, siehe:

https://forum.opnsense.org/index.php?topic=30569.0

ok  :)

Diese 'warnings' bekomme ich halt wie gesagt trotzdem in den logs...

Bin halt kein Entwickler, ob da jetzt ein 'race condition' oder ähnliches vorliegt, kann ich nicht einschätzen leider.

Aber vllt. sollte sich das dann ein Entwickler doch mal genauer ansehen?

Eigentlich nicht, in /var/etc/openvpn ist die Datei server-••••••••-••••-••••-••••-••••••••••••.crl-verify vorhanden und die hat auch einen Inhalt:

Code Select Expand

-----BEGIN X509 CRL-----
MIIC+DCB4z••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
••••••••••••••••••••••••••••••••••••••••••••••••••••••Xk1hU=
-----END X509 CRL-----

Habe es jetzt mittlerweile am laufen mit der neuen "Instances"-Variante.

Bei Interesse kann ich das auch mal (inklusive aussagekräftiger Screenshots) hier dokumentieren, das würde dem einen oder anderen User, der nicht so tief in der Materie drin steckt, sicher helfen (mich eingeschlossen).  ;)

Also mein Road Warrior OpenVPN funktioniert jetzt wieder problemlos, wobei es drei "warnings" im log gibt, deren Bedeutung / Ursache mir nicht ganz klar sind (wahrscheinlich kann ich diese ignorieren)?

Code Select Expand

2024-07-26T09:13:03 Warning openvpn_server1 •••.•••.•••.•••:12392 CRL: cannot read CRL from file /var/etc/openvpn/server-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.crl-verify
2024-07-26T09:13:03 Warning openvpn_server1 •••.•••.•••.•••:12392 OpenSSL: error:0480006C:PEM routines::no start line:
2024-07-26T09:13:03 Warning openvpn_server1 •••.•••.•••.•••:12392 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (none : 0), Properties (<null>)

ok, vielen Dank für die Info  :)

Auf lange Sicht fliegen die legacy Varianten aber wahrscheinlich komplett raus und man wird irgendwann gezwungen sein, auf die neue instances Variante umzustellen?

Wäre es da nicht gut, wenn tatsächlich etwas ausführliche tutorials dazu zur Verfügung stehen würden?

Danke Franco für die schnelle Rückmeldung.

Wie kann man denn DCO dauerhaft "unterbinden" wenn man weiterhin auf die Legacy-Variante angewiesen sein sollte (bei mir z.B. betrifft das eine ganze Menge von OPNsense-Instanzen).

Und falls es diese Möglichkeit nicht geben sollte, könntet ihr alternativ für die neuere "Instances"-Variante der OpenVPN-Server ausführlichere Anleitungen bereitstellen?

[Bin gespannt, was hier jetzt die "Lösung" sein wird.]

Ich hatte genau das selbe Problem und dachte mir, kein Problem – schmeißt Du halt die eh als 'legacy' gekennzeichnete alte Variante über Bord und machst das mittels der neuen "Instances".

Leider ist die Anleitung dazu aber auch eher dürftig, insbesondere wenn man Road Warrior OpenVPN machen möchte (ich benötige diese OpenVPN-Verbindungen inkl. 'redirect all traffic' für mein Mobiltelefon und meinen Laptop).

Mir ist ehrlich gesagt unverständlich, wie man so etwas als "release" rausgeben kann, wenn die OpenVPN Server (in der "legacy" Variante) dann plötzlich nicht mehr funktionieren!

Das wäre nicht so dramatisch, wenn es wenigstens eine ausführliche aktuelle Anleitung für die Einrichtung der neuen "Instances" gäbe – diese hier ist jedenfalls alles andere als "vollständig":

https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html

Ein konkretes Beispiel:

Redirect gateway - Leave empty

If you want all outgoing IP traffic to be redirected over the VPN, you can set the option to default. For this to work, a manual NAT outbound rule must be created.

An keiner Stelle wird dann erläutert, wie genau diese NAT outbound Regel auszusehen hat!

So ist das leider schnell einfach nur "Gefrickel" wie ich das mittlerweile von OPNsense gewohnt bin... :/

pfSense würde sich solche Schnitzer jedenfalls nicht leisten, die mögen sehr träge und "oldschool" unterwegs sein, dafür wird dort aber offensichtlich auch intensiver im Vorfeld getestet.

Wirklich sehr ärgerlich...

Bin gespannt, was hier jetzt die "Lösung" sein wird.

> Habe jetzt mal ein Interface welches eigentlich als "Gäste-Netzwerk" gedacht war, wieder entfernt, so dass nur noch WAN und LAN vorhanden sind.

Was hatte dieses Netz denn als IP Range?

WAN bekommt "Internet" von einer FB Cable aus einem 10.89.89.0/24 Netz
LAN hat bei mir ein 10.5.5.0/24 Netz

Und das nun entfernte OFFICE (bzw. Gäste) Netz hatte ein 10.6.6.0/24 Netz

[Seitdem läuft der OpenVPN-Server stabil.]

Habe jetzt mal ein Interface welches eigentlich als "Gäste-Netzwerk" gedacht war, wieder entfernt, so dass nur noch WAN und LAN vorhanden sind.

Seitdem läuft der OpenVPN-Server stabil.

Ich verstehe zwar ehrlich gesagt nicht, wie das 'reingrätschen' konnte, aber wer weiß, was ich da wieder nicht beachtet hatte...

In jedem Fall läuft die OPNsense jetzt auch insgesamt wieder "rund" (z.B. habe ich nun auch keine eigenartigen 'timeouts' für 4-5 Sekunden alle paar Minuten mehr).

Wahrscheinlich wäre es wirklich erst einmal das schnellste, wenn Du das System frisch installierst (clean install) und dann in einem zweiten Schritt dein config-Backup einspielst?