OPNsense Forum
International Forums => German - Deutsch => Topic started by: superwinni2 on February 15, 2019, 11:33:45 am
-
Hallo Zusammen
ich habe eine OPNsense mit aktuell 18.7 im Einsatz. Ich hätte hier gerne einen und später mehrere VPN Server am laufen welche entweder via SSL/TLS bzw über SSL/TLS mit Benutzer/Passwort Abfrage funktionieren.
Habe bisher schon so eineige VPN Server eingerichet aber irgendwie hakt es hier etwas...
Was ich bisher gemacht habe:
OPNsense installiert und Grundkonfiguriert (IPs etc).
Dann habe ich unter System -> Trust -> Authorities eine CA (HauptCA) erstellt 2048,SHA256,365,CN = Haupt-CA,E = support@test.com,O= Pri,L = Zuh,S = BW,C = DEDanach eine Unterzertifizierungsstelle (UnterCA) davon erstellt 2048,SHA256,365,CN = UnterCA,E = support@test.com,O = Priv,L = Zuh,S = BW,C = DENachdem die Unterzertifizierungsstelle eingerichtet war habe ich ein ServerZertifikat für den VPN Server erstellt.
Nun habe ich den OVPN Server einrichten wollen:
Dafür habe ich folgenden Einstellungen verwendet:
Server Mode: Remote Access (SSL/TLS)
Protocol: UDP
Device Mode: tun
Interface: Any
Local Port: 1175
TLS Authentication: Haken bei "Enable authentication of TLS packets" und Automatically generate a shared TLS authentication key"
Peer Certificate Authority: UnterCA
Server Certificate: VPN-Server-Cert (UnterCA)
DH: 2048 bit
Encryption algorithm: AES128-CBC
Auth Digest Algorithm: SHA1 (160-bit)
Hardware Crypto: No Hardware Crypto Acceleration
Certificate Depth: Do Not Check
IPv4 Tunnel Network: 10.100.140.0/24
IPv4 Local Network: 10.100.100.0/24
Disable IPv6: Aktiviert
Dynamic IP: Aktiviert
Address Pool: Aktiviert
DNS Default Domain: test.test
DNS Server 10.100.100.64
Alles was ich nicht angegeben habe ist leer oder der default Wert bzw. halte ich für unwichtig für den aktuellen Moment.
Nun noch für den Benutzer ein Zertifikat erstellen welches an der UnterCA signiert ist und Fertig.
Nun zu meinem Fehler:
Ich kann die OVPN Config ohne Probleme exportieren und starten. Bekomme jedoch auf dem Server den Fehler:
openvpn[75278]: xxx.xxx.xxx.xxx VERIFY ERROR: depth=2, error=self signed certificate in certificate chain: C=DE, ST=BW, L=Zuh, O=Pri, emailAddress=support@test.com, CN=HauptCAund auf dem Client:
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
Erweitere Infos:
Wenn ich nun einfach den auf dem Server die Peer Certificate Authority auf "HauptCA" stelle, funktioniert die Verbindung (mit der oben erstellten config), ich kann jedoch keine Zertifikate mehr exportieren.
Nun meine Große Frage...
Warum das ganze? Wo liegt hier mein Denkfehler?
Leider brauche ich diese Zertifizierungsstruktur, da in meinem Produktivem Umfeld hier die "HauptCA" nicht die OPNsense ist sondern ein Linux system. Jedoch der Fehler dort genau gleich ist. Daher auch der Test mit einer seperaten OPNsense.
Danke für eure Hilfe und Gruß
-
Niemand eine Idee?
-
Ist die UnterCA ggf. aus versehen nicht als Intermediate-CA der HauptCA erstellt worden? Das liest sich irgendwie ein wenig so. Self-signed cert in cert chain - da müsste man die Zertifikate prüfen, ob die Kette da sauber ist.
Evtl. mal alle Zerts exportieren und auf nem PC einspielen und da nachvollziehen ob die Chain OK ist. Oder erstelle dir noch ein server-zert bei der UnterCA und nutze das für die WebUI und schau im Browser nach, ob die Kette sauber ist.
-
Hi JeGr
Zertifikatskette ist korrekt und überall auch bekannt und ebenso gültig.
Wer will kann es ja wie bereits geschrieben selbst testen...
Einfach ein RootCA erstellen, davon ein UnterCA und dann wie beschrieben einrichten... (alles auf der OPNsense und nicht mit extra CertServern etc..)
Meine große Frage ist vorallem wo hier mein Denkfehler liegt...
Aktuell und vermutlich als ewiges Provisorium habe ich es nun erstmal so gelöst, dass ich eine komplett seperate RootCA erstellt habe und mit dieser die VPN-Clients signiere. So kommt weder ein Fehler und ich kann auch die Configs exportieren...
-
Die UnterCA auszuwählen ist eigentlich korrekt. Hast du die Cert Depth mal auf 2 gestellt statt auf disabled?
Wir haben ein ähnliches Konstrukt auf einem pfSense Cluster mit genau dem Aufbau (Master VPN CA unterschreibt mehrere Projekt VPN CAs und die stellen die Certs für Server und Clients aus). Ich werds aber bei Zeit kurz ins OPNlab reinwerfen und versuchen.
-
Habe die Cert Depth bereits alles mögliche versucht... Alles leider ohne erfolg...
Nach meiner logik sollte auch alles korrekt sein...
Wäre echt cool und interessant wenn wir den Fehler irgendwie finden würden...
-
Hi,
ich hatte letztens das selbe Problem, habe den Verschlüsselungsalg. auf beiden Seiten verändert, gespeichert und danach wieder zurückgesetzt.
Nach der Vorgehensweise ging es wieder.
Vielleicht klappts ja bei dir auch :)
-
habe den Verschlüsselungsalg. auf beiden Seiten verändert, gespeichert und danach wieder zurückgesetzt.
Werde ich versuchen.. Komme aber wohl erst nächste Woche dazu...
-
Hi,
da ich das gerade hinter mir habe:
- DynDNS für den uplink aktivieren, damit man das opnsense per DNS erreichen kann
- os-acme-client installieren und für den DNS Namen ein Server Zertifikat bei Let's Encrypt holen
- VPN IPSec Mobile Clients einrichten (IKVEv2)
- Auf den Clients per Bordmittel (auf Android mit StrongSwan Client) mit dem IKEv2 VPN per User/Passwort verbinden
Das ist die Kurzversion der Anleitung.
Eine lange Version habe ich mir hier zusammengesucht:
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-firewall-einrichten-337198.html
https://alephnull.uk/lets-encrypt-on-demand-ikev2-vpn-debian-ubuntu-ios-username-password-authentication
Der Vorteil der Lösung: Man muss keinen Client einrichten, es braucht nur User und Passwort
Ich habe zur User Verwaltung auf der OPNsense den freeradius plugin installiert und dann den Radius Server imt EAP-RADIUS verwendet.
Besten Gruß
Rainer
-
@rainerle Wenngleich dankenswert für die Anleitung, ist das IPSec um das es hier nicht geht, denn der OP möchte ja eine OpenVPN Zertifikatskette. Und das hat nur marginal irgendwas mit Let's Encrypt, IPSEC und sonstigem zu tun. :)
-
Hallo zusammen
so wie es aussieht war die eine Woche "Auszeit" vor der OPNSense gar nicht so schlecht.
@rainerle: Leider wie JeGr bereits geschrieben hat.. Komplett falsches Thema angegriffen... Trotz allem herzlichen Dank für die Anleitung.
An den Rest (und vorallem an JeGr und lfirewall1243 ):
Herzlichen Dank für die Hilfe und das Auffinden des richtigen Weges zur Lösung ;) :)
Ich habe es nun geschafft und nach meinem Freudentanz möchte ich es auch nicht vorenthalten... Die Lösung ist so einfach wie auch genial...
Habe wie lfirewall1243 erst versucht den Verschlüsselungsalgorhythmus zu ändern.. Leider ohne großen Erfolg... Habe dann jedoch als Fehler VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=DE, O=Guenthart, CN=OPNsense-CA erhalten...
Dann gedacht: Okay.. Fehler hat sich ja schonmals etwas verändert.. Schmeißen wir doch mal das große G an und suchen danach... Dann auf folgenden Bug gestoßen: https://redmine.pfsense.org/issues/2800 (https://redmine.pfsense.org/issues/2800)
Klang ja schonmal alles leicht ähnlich nach meiner Konstellation und Problem...
So und nun die Lösung:
Ich habe auf meiner Haupt-OPNsense die Zertifikate geschnappt und hintereinander kopiert, so dass dies in etwa so aussah:
-----BEGIN CERTIFICATE-----
MIIFZDCCA0ygAwIgeGHTwWfsdFaFEfeFRBDMQswCQYDVQQGEwJERTES
[...] Dies ist mein HAUPT-CA
gpjaGrrSFWEF*wefWSEF+feSAFtsWp3257LPagXN5aQf34G+YOv/NEjA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGADCCA+igAwIBAg4g5r6we1g61G61G165YDVQQGEwJERTES6
[...] Dies ist mein UNTER-CA
QctqCAfjV7w1fsafsgRGSgASERaREGS/gASfgSAGrgDRGVQUg5I8GiMm+PxAn
hZU9Hw==
-----END CERTIFICATE-----
Dies habe ich dann erneut als Certificate Authority bei Server + Client hinzugefügt/importiert (diesmal mit dem Namen "Unter-CA als Kette").
Danach dies als "Peer Certificate Authority" bei Server + Client geändert. Das passende Clientzertifikat (welches von der Unter-CA signiert war da ich temporär ein komplett eigenes CA auf der OPNsense erstellt hatte) ausgewählt.
Und siehe da: Es funktioniert 8)
PS.: Was es mit der "Certificate Depth" genau aufsich hat: Keine Ahnung ::) Ich kann es auf "Disabled", "One" oder "Two" stellen... Verbindung funktioniert immer...
-
OK dann würde ich das aber definitiv als Bug abstempeln, denn dann funktioniert die Auswahl bzw. Zusammenstellung von OpenVPN bei größerer Zertifikatstiefe nicht, wenn du manuell die Zertifikatskette importieren/auswählen musst. Das macht dann nur begrenzt Sinn. Bin leider nicht dazu gekommen das nachzustellen weil hier durch langen Krankheitsausfall zu viel im Backlog ist, aber bei der pfSense ist es so, dass bei einer Intermediate CA die selbst in der Zert-Verwaltung erstellt wurde und die die Sense daher kennt, man bei OpenVPN die Intermediate auswählt, Zert-Tiefe auf 2 (Intermediate + CA) stellt (das ist die Prüfung des Clients/Servers gegen die CA ob das Zert auch von 2 Zerts abstammt und die Kette stimmt), man beim Export auch auf dem Client die komplette CA Tiefe mit Intermediate erhält und bei der Einwahl das auch geprüft wird. Scheinbar hat sich da entweder bei dir oder generell was eingeschlichen, was da reingrätscht aber schön dass es nun erstmal mit Workaround läuft ;) Denn wenns richtig läuft sollte die Depth Einstellung nicht egal sein ;)
-
Das die Zert-Tiefe nicht egal ist kann ich mir schon denken... Vielleicht erkennt er es aber auch nur als ein Zertifikat da ich beide in einen Eintrag kopiert habe?!?
Das dies ein Bug ist vermute ich auch stark... Da der Bug aber wohl schon seit einigen Jahren bekannt ist (zummindest bei pfSense) denke ich, dass sich die meisten die solch eine Konstellation haben sich damit abgefunden haben. Und so wird der Fehler wohl ignoriert bis er irgendwann tot ist... :P
Meine Haupt-OPNsense läuft aktuell "noch" mit
OPNsense 19.1.1-amd64
FreeBSD 11.2-RELEASE-p8-HBSD
OpenSSL 1.0.2q 20 Nov 2018
Ich habe noch eine "Client-OPNsense" jene nur als VPN Client gilt damit ein fremdes Netzwerk auf meines zugreifen kann und hier habe ichheute Updates installiert und es steht auch folgendes in der Changelog:
o openvpn: obey verify-x509-name for remote access (user auth)
o openvpn: proper daemonize instead of background job
o openvpn: extract full CA chain for setup
o openvpn: missing "port" in protocol export
Vielleicht kommt man der Sache auch näher durch den 3. Eintrag... Aber dies alles nun nochmals durchzutesten habe ich aktuell weder Zeit noch Lust ob es nun besser ist... Vor allem auch da es ja nicht 100% mit meinem Fehler übereinstimmt.
-
> die meisten die solch eine Konstellation haben sich damit abgefunden haben. Und so wird der Fehler wohl ignoriert bis er irgendwann tot ist...
Ich denke die meisten nutzen eher selten eine Zert-Chain die mit Zwischenzertifikaten arbeitet, daher tritt das auch eher selten auf - das wäre zumindest meine Vermutung. Bei pfSense gab es da dieses Ticket und später nochmal einen Patch wegen einem Problem mit der Zertifikatstiefe aber da läuft es seit 2.4 auch sauber (zumindest bei uns).
Aber wenn es erstmal läuft ist fein, vielleicht kann ich das ggf. nochmal nachstellen wenn ich dazu komme :)
-
Hi,
interessanter Thread.
Habe ähnliches beobachtet und bin jetzt wieder bei einem neuen Setup drübergestolpert.
Hatte meine "Peer CA" noch immer auf die RootCA und nicht auf die Intermediate welche dann das Server Zert ausstellt.
Damit hatte ich jetzt plötzliche ähnliche Probleme wie du obwohl ein laufendes Setup bereits seit Jahren läuft. Habs jetzt aber auch wieder hinbekommen.
fg
-
Hatte meine "Peer CA" noch immer auf die RootCA und nicht auf die Intermediate welche dann das Server Zert ausstellt.
Damit hatte ich jetzt plötzliche ähnliche Probleme wie du obwohl ein laufendes Setup bereits seit Jahren läuft. Habs jetzt aber auch wieder hinbekommen.
fg
Hi Mks
Finde es echt toll von dir, dass auch du uns von deinen Sorgen berichtest, kannst du uns und vorallem den zukünftigen Lesern kurz in ein paar Sätzen erklären was genau dein Problem war?
Vielleicht auch ne Fehlermeldung dazu? Ist es zufällig die gleiche wie bei mir gewesen?
Und das aller aller wichtigste bitte: verrate uns was du als Lösung gemacht hast...
Ein Forum lebt von Austausch solcher Informationen und für mich persönlich gibt es nichts schlimmeres wie wenn jemand schreibt "jops hatte das problem, habe es aber in den griff bekommen" ohne das auf das problem oder die lösung eingegangen wird...
Und wenn die lösung (wie bei mir am anfang) heißt "Habe ein neues CA erstellt das unabhängig von meiner root-CA agiert" dann möge auch die vollkommen in ordnung sein :)
LG
Gesendet von meinem LG-H815 mit Tapatalk
-
Hi,
in aller Kürze.
Ich betreibe eine externe CA.
Neben der RootCa befinden sich darunter weitere CAs zB für VPN.
Daher folgende Chain:
RootCA->VPNCA--ServerCert
\--VPNClient certs
Bisher waren meine Setting das bei Opnsense als Peer Ca noch die RootCA als PeerCA konfiguriert war.
Ohne dem war es nicht möglich die Configs zu exportieren.
Zusätzlich die Certificate Depth noch auf 1
Habe eine OpenVPN inline config, die sich foldermaßen aufbaut:
<Settings>
<VPNCA_cert>
<RootCA_cert>
<Client_cert>
<ClientCertificate Depth key>
<Static TLS Key>
Läuft so seit Jahren auf Android und Windows ohne Probleme.
Hab jetzt noch ein IOS Device bekommen, und siehe da plötzlich gab es einen Fehler VERIFY ERROR: depth=0, error=unable to get local issuer certificate
, siehe auch https://forum.opnsense.org/index.php?topic=11974 (https://forum.opnsense.org/index.php?topic=11974)
Seltsamerweise auf Android oder Windows aber kein Problem mit der gleichen Client config
Nach Umstellung der PeerCA auf die VPNCA, was ja nur so eingestellt war das vor ein paar Jahren das exportieren der config ohne nicht möglich war, hat die Verbindung geklappt (selbe Client config).
Hat mich aber ein paar Stunden gekostet da ja auf Android und Windows alles funktioniert hat.
Bei der Certificate depth hab ich jetzt Two, scheint aber egal zu sein, funktioniert unabhängig dieser Einstellung.
Hab im Moment etwas wenig Zeit das im Detail zu analysieren, es scheint aber eine Unterschied zu geben bei Verbindungen von Android/Windows/IOS zumindest bei der Prüfung von den Chains.
lg
-
Hi Mks
Deine Struktur klingt ja genau so wie bei mir :)
Und nicht nur das... Dein Fehlerbild sieht ebenfalls sehr ähnlich aus...
Und du hast (im Gegensatz zu mir) einfach den Fehler ignoriert, das der Export der Configs nicht geht. So wie es sich liest, war dies bei dir auch nur eine einmalige Sache und du hast doch damit abgefunden....
Dies war bei mir jedoch ein "no-go" da ich keine Lust habe das mir alle VPNs abreißen nur weil ich mal ne config exportieren muss...
Also Lösung würde ich dir den gleichen Vorschlag machen wie das was ich gemacht habe: Importiere eine neue CA und füge die Kette komplett in den Import hinzu. Dieses "Ketten-CA" dann als PeerCA benutzen und nun kannst du exportieren und verbinden und hast zudem keine Fehler mehr wegen deinen Zertifikaten (und es läuft so wie es laufen sollte)
Lösungsversuch2:
Also wenn der Fehler auf dem iOS Gerät auftaucht, dann vermute ich, dass man vielleicht das Zertifikat explizit importieren und sich vertrauen muss...
Gesendet von meinem LG-H815 mit Tapatalk
-
Hi,
Und du hast (im Gegensatz zu mir) einfach den Fehler ignoriert, das der Export der Configs nicht geht. So wie es sich liest, war dies bei dir auch nur eine einmalige Sache und du hast doch damit abgefunden....
Habe damals 2017 keine andere Möglichkeit gefunden.
Da bisher alles mit Android und Windows funktioniert hat hab ich das dann irgendwann einfach vergessen. Die Anzahl der Exports bzw sich verbindenden Cients ist bei mir überschaubar.
Importiere eine neue CA und füge die Kette komplett in den Import hinzu. Dieses "Ketten-CA" dann als PeerCA benutzen und nun kannst du exportieren und verbinden und hast zudem keine Fehler mehr wegen deinen Zertifikaten (und es läuft so wie es laufen sollte)
Das war eh immer so, nur das ich für den Export die PeerCA auf die RootCA stellen musste und ich vergessen habe zurück auf die VPNCA zu stellen.
lg
-
Habe damals 2017 keine andere Möglichkeit gefunden.
Da bisher alles mit Android und Windows funktioniert hat hab ich das dann irgendwann einfach vergessen. Die Anzahl der Exports bzw sich verbindenden Cients ist bei mir überschaubar.
Klar :) ist ja auch nicht schlimm... Meine Gedanken waren damals am Anfang "naja dann geht es wohl nicht anderst" aber wirklich damit zufrieden geben wollte ich mich nicht... Und dann habe ich professionelle Hilfe gesucht und diese auch erhalten :)
Genau dieses zurück stellen... Wie schnell vergisst man genau diese Sache und wie schnell ist dann das Gemecker groß, dass etwas nicht funktioniert... Da war mir das Risiko einfach gesagt viel zu groß... Bei mir stecken hier beispielsweise noch andere Standorte dahinter und nicht nur einzelne Clients... Da musste es doch eine Lösung für geben.. Und die gibt es :)
Deswegen: Importiere die "neuen Ketten-CAs" und trinke das nächste Mal von der gesparten Zeit wegen dem Hin und her stellen nen Kaffee :D
Dürfte kein Benutzer bemerken wenn es so ist wie bei mir, ausser dass die VPN kurz abreißt da der Dienst neugestartet wird...
Gesendet von meinem LG-H815 mit Tapatalk
-
Nach der Hochmut kommt der Fall :-[
Habe es nun erneut probiert und nun funktioniert der export schon wieder nicht... Kann doch nicht sein....
Aktuell sieht die Lage wie folgt aus:
+--------------------------------------------------------------------------------------------------------------------+
|PeerCA |VPN Verbindung | Client Export |
|------------------------------------------------------------------------------------------------------------------- |
| | | |
| | | |
|UnterCA |VERIFY ERROR: depth=2, error=self signed certificate in certificate chain| Klappt |
| | | |
|Kette |(mit Config von UnterCA) Alles in Ordnung | Geht nicht |
| | | |
|HauptCA |(mit Config von UnterCA) Alles in Ordnung | Geht nicht |
+--------------------------------------------------------------------------------------------------------------------+
Also im Endeffekt alles wie am Anfang... Keine Ahnung ob ich irgendwo zu hastig war und dann eine alte Config genommen hatte...
Vielleicht ja ja noch jemand nen Tipp...