wir versuchen uns gerade an einer Neuintallation von LMN7 + OPNsense + Docker. Die Appliances stehen und die Erstkonfiguration wurde gemacht.
Uns ist aufgefallen, dass die Firewall nicht per SSH erreichbar ist. Versucht man in der OPNsense irgendeine Änderung unter System - Einstellungen - Verwaltung zu speichern, kommt folgender Fehler: Certificate linuxmuster - firewall is not intended for server use.
ist den das linuxmuster-setup auf dem Server beim INstallieren sauber durchgelaufen?
Da wird manchmal vergessen,d ass das Firewall root Passwort zu diesem Zeitpunkt
Muster!
sein muß: sonst schlägt das Einrichten der Firewall mangels Zugang fehl.
Wenn das ein ganz frisches System ist, dann würde ich nochmal die INstallation machen.
Wennes schon älter ist, dann würde ich das Script aus diesem Post mal laufen lassen:
Danach ist die OPNsense platt: aber wieder frisch und verbunden.
Habe jetzt ausgehend von Snapshots nochmal die Erstkonfiguration gemacht. Die läuft bis zum Schluss durch, nur die SSH-Verbindung zur Firewall am Ende scheitert:
wo hast du den die Umgebung her?
Sind das die ova Dateien oder hast du einen Vanilla Install gemacht?
Wurde vor dem setup alles aktualisiert?
Welche Version hat den die OPN Sense?
Läuft die OPNsense zu dem Zeitpunkt? Kannst du dich per ssh von einer anderen console aus dort einloggen?
Ich habe das ja jetzt erst gemacht und /usr/sbin/linuxmuster-opnsense-reset auf einer OPNsense 21.7.7 ausgeführt. Wenn man dann unter „System - Einstellungen - Verwaltung“ irgendeine Änderung machen möchte, scheitert das mit der Fehlermeldung die Lars beschrieben hat. D.h. das Zertifikat, welches das Linuxmuster Setup auf die OPNsense spielt wird von der Firewall nicht mehr anerkannt.
Ein Bug in OPNsense, oder dem Linuxmuster Setup?
Ich habe mir damit beholfen, auf der OPNsense eine neue CA zu erstellen (System - Sicherheit - Aussteller) und damit ein neues Zertifikat zu generieren (System - Sicherheit - Zertifikate).
das Setup von LMN funktioniert mit den aktuellen Versionen von Opnsense nicht mehr. Es kommt der Timeout am Ende und die Firewall wird nicht neu gestartet. Wenn der Neustart der Firewall manuell durchgeführt wird, dann befindet sich diese in einem undefinierten Zustand und weist Fehler auf.
Diese Fehler kann man manuell beheben, wenn man sie gefunden hat.
Als Workaround ist es sinnvoll, eine Version von Opnsense von Anfang 2020 zu installieren und damit das Setup durchzuführen. Anschließend kann die Firewall aktuallisiert werden. Opensense - alte Versionen
Das erklärt alles. War eine Installation from scratch und somit natürlich alles aktuell. Wir haben inzwischen eine für unsere VM konvertierte ova der OPNsense genommen und damit hat es dann auch funktioniert. Jetzt wissen wir wenigstens, dass es keine falsche Einstellung war.
So, jetzt alle Upgrades auf der FW durchgeführt mit dem Ergebnis, dass der selbe Fehler dann wieder auftritt, wohl weil die Versionsupdates mit einem neuen Public Key daher kommen…
Heißt das jetzt, die Firewall lieber nicht zu updaten? Und welche Auswirkungen hat das nicht akzeptierte Zertifikat, ausser dass man unter „Verwaltung“ nichts mehr ändern kann?
Und - blöde Frage - aber sollte die Firewall eigentlich als https-sicher erkannt werden, wenn man vorher auf dem Server das selbstsignierte Zertifikat akzeptiert hat? So ist sie jedenfalls auch „nicht sicher“.
Was heißt das alles später für einen FREERadius und dieWLAN-Clients?
SSH-Verbindung vom Server aus bringt „The authenticity of host ‚firewall.jpp.lan (10.32.1.254)‘ can’t be established.“ Nach Akzeptanz funktioniert die SSH-Verbindung aber.
nein: auch das „neue“ Zertifikat ist selbstsigniert. Das hat dann auch nix mit dem Server zu tun: es ist dein Browser, der dem Zertifikat nicht vertraut.
Dort kannst du es speichern: dann ist die Meldung weg.
nix: der Freeradius der OPNSense funktioniert sowiso nciht so wie wir das brauchen, weswegen wir einen extra Freeradius verwenden. Manche haben den im Docker und manche auf dem Server installiert.
Freeradius sollte durch ein selbst signiertes Zertifikat abgesichert sein.
Dieses sollte extra für diesen Zweck erstellt werden. Ab Android 11 kann es sein, dass man auf dem Client die zum Erstellen des Zertifikats verwendete CA importiert (siehe hier: Domain angeben bei Android 11 unifi Enterprise WPA2 - #15 von tjordan )
Das wird auch bei zukünftigen iOS Versionen notwendig sein.
das liegt daran, dass es schonmal eine Verbindung zur OPNsense gab und die OPNSense nun aber als „nicht mehr die alte“ erkannt wird (Fingerprint ist anders) deswegen wird gewarnt. Wenn du das einmal akzeptierst, dann ist die neue die aktuelle und vertraute Verbindung: das soll also so sein.
ich bin auch schon über das Problem mit dem Zertifikat gestolpert, weil ich die ssh-Anmeldung per Passwort in der Opnsense unter „Verwaltung“ deaktivieren wollte, was wegen dem Zertifikatsproblem nicht ging. Das Problem ist allerding bekannt: die Problembeschreibung samt Lösung gibt es hier : [SOLVED] Certificate check wrong result?
Funktionell gibt es in der lmn erst Mal keine Einschränkungen, außer man möchte eben irgendetwas an den Einstellungen der Opnsense unter „Verwaltung“ ändern.
Ich verwende das Plugin Acme-Client auf der Opnsense und lasse mir da per DNS-Challlenge ein Wildcardzertifikat für meine Domain ausstellen, das ich überall verwende, eben auch für die Weboberfläche der Sense…damit ist das Problem gegessen.
Holger @baumhof ich denke, da sollte man das Linuxmuster Setup dahingehend verbessern, daß das SSL Zertifikat entsprechend generiert wird, so daß es auch in Verwendung mit der OPNsense gültig ist.
Ich weiß jetzt nicht, in welche Hände das gehört, darum wende ich mich an Dich.
das Problem gibt es nicht nur bei Neuinstallationen. Ich habe seit 3 Jahren eine alte opnSense, lass es mal eine 20er sein, am laufen gehabt. Um die automatische Proxy-Entdeckung (WPAD) nutzen zu können hatte ich in System->Einstellungen->Verwaltung das Protokoll von HTTPS auf HTTP umgestellt damit das wpad.dat-Script abgerufen werden kann.
So seit im Dezember letzten Jahres habe ich alle opnSense-Aktualisierungen nach und nach eingespielt und bin jetzt auf Version 24.1. Letzte Woche musste ich linuxmuster-import-subnets durchführen und stellte fest dass das Script die neuen Routen nicht in die Firewall hinzufügt (das Script hängt dann). Ich wollte dann die Firewall wieder auf HTTPS umstellen und dort kam dann der Fehler mit dem „linuxmuster - firewall“-Zertifikat. Habe dann ein configctl webgui restart renew auf der firewall-Console durchgeführt und konnte mit dem dadurch neu angelegten selbstsignierten Zertifikat wieder auf HTTPS umstellen. Anschließend hab ich dann linuxmuster-import-subnets wieder erfolgreich durchführen können und die neuen Routen wurden hinzugefügt.
Wo wird denn das „linuxmuster - firewall“-Zertifikat erstellt? Passiert das nur bei einer Neuinstallation oder gibt es die Möglichkeit das manuell aufzurufen?
Ich habe mir das Zertifikat unter „/etc/linuxmuster/ssl/firewall.fullchain.pem“ angeschaut, und dieses hat überhaupt keine KeyUsage weder extendedKeyUsage Felder, die aber lt. [SOLVED] Certificate check wrong result? nötig wären. Im neu erzeugten selbstsignierten Zertifikat sind KeyUsage und ExtendedKeyUsage vorhanden.
