Kleinere Probleme mit OpenVPN

Michi777

Commander
Registriert
Apr. 2009
Beiträge
2.148
Liebe Community!

wir haben nun die aktuelle Synology am Heimstandort via OpenVPN angebunden um ein automatisches Backup außerhalb des Standortes zu gewährleisten und es funktioniert meistens bis auf folgende Probleme:


1)
Wenn ich z.B. für Testszenarien mehrfach die VPN-Verbindung wiederverbinde kommt SIGUSR1[soft,auth-failure] oder do_ifconfig, tt->did_ifconfig_ipv6_setup=0 ohne Verbindungserfolg.
Wenn ich dann die VPN-Netzerverbindungen deaktiviere\aktivere geht der nächste Versuch meistens.
Wir sind hinter eine fixen öffentlichen WAN-IP eines Firmenanschluss und das Ziel ist ein Heimstandort (dynamisch via synology.me erreichbar).
Ist hier vl. ein zusätzlicher Konfigurationseintrag oder eine Einstellung an der NAS (z.B. Timeout) notwendig?


2)
Obwohl wir ein Certificat generiert und in der Config eingespielt haben kommt eine Meldung wie No server certificate verification method has been enabled.
Kann ich diese Nachricht sicherheitstechnisch ignorieren oder ist eine wirkliche Gefahr von ManInTheMiddle-Attacke in diesem Szenario vorhanden?

3)
Wenn ich via Aufgabenplanung einstelle, dass bei einem Systemstart das OpenVPN Profil automatisch geladen wird, bleibt der Vorgang aber stehen, weil das Authentifizierungsfenser mit bereits eingetragenem Passwort zu bestätigen wartet.
Was läuft hier falsch, denn jeder hat doch Zugangsdaten bei VPN einzutragen, muss aber laut Anleitung nichts zu dem Profilstart beitragen.
https://community.hide.me/tutorials/automatische-verbindung-bei-systemstart-openvpn.30/

Im Anhang die OpenVPN Konfigurationsdatei, mit entfernten sensiblen Einträgen.


Vielen Dank im Voraus!
 

Anhänge

  • OpenVPN config.jpg
    OpenVPN config.jpg
    155,1 KB · Aufrufe: 334
Michi777 schrieb:
Liebe Community!
2)
Obwohl wir ein Certificat generiert und in der Config eingespielt haben kommt eine Meldung wie No server certificate verification method has been enabled.
Kann ich diese Nachricht sicherheitstechnisch ignorieren oder ist eine wirkliche Gefahr von ManInTheMiddle-Attacke in diesem Szenario vorhanden?

Du hast die Server Zertifikat Verifizierung noch ausgeklammert in der Config.

Grüße
 
@BrenneX (zu Frage 2):
die Raute von #remote-cert-tls server entfernen?
 
Ja, in älteren Versionen von OpenVPN heißt die Option "ns-cert-type server".

Das ist in der Tat keine unwichtige Option. Zertifikate können und müssen in diesem Fall mit einem speziellen Tag versehen werden. Sie identifizieren sich damit explizit als Server-Zertifikat. Hat ein Client obige Option eingeschaltet, prüft er ob der VPN-Server auch tatsächlich mit einem Server-Zertifikat antwortet.

Hintergrund der ManInTheMiddle-Attacke ist Folgender: Wenn ein Angreifer irgendwie an ein Client-Zertifikat deines VPNs kommt - zB während du oder ein anderer VPN-Nutzer auf Toilette ist - kann er mit diesem Zertifikat, das ja ordnungsgemäß von der CA des VPNs signiert ist, seinerseits einen VPN-Server starten und sich quasi zwischen deinen VPN-Client und den eigentlichen VPN-Server einklinken, er sitzt dann "in der Mitte" und kann mitlesen. Weist sich das Zertifikat aber nicht explizit als Server aus, merkt ein VPN-Client beim Verbindungsaufbau und aktivierter remote-cert-tls bzw. ns-cert-type Prüfung, dass er gerade nicht mit dem Server spricht, sondern einem potentiell kompromittierten/gestohlenen Client!

Daher: Client-Zertifikate ganz normal generieren und Server-Zertifikate stets mit Server-Tag. In der client.ovpn die entsprechende Prüfung aktivieren und man ist weitestgehend sicher vor MITM-Attacken.
 
Danke für die Antwort.

Was wäre denn zu tun gegen:
1)Die Zwangstrennung nach einigen Stunden
2)Einer automatischen Passworteingabe (bisher nur eingefügt und muss auf OK klicken)
3)Den Fehler, dass ich nach dem Trennen TAP Adapter deaktivieren\aktivieren muss um wieder erfolgreich eine Verbindung hinzukriegen?
4)Der Fehlercode do_ifconfig, tt->did_ifconfig_ipv6_setup=0 weist ja auf IPv6 hin, was wir ja nicht nutzen, wie kann ich das deaktivieren?

Vielen Dank!
 
1) Sofern die Funktion von DynDNS sichergestellt ist und resolv-retry infinite in der client.conf steht, sollte sich der OpenVPN-Client auch nach einer Zwangstrennung des Servers wiederverbinden. Standardmäßig versucht der Client alle 5 Sekunden eine Verbindung aufzubauen.

2) Willst du jetzt, dsas man das Passwort eingeben muss oder willst du das ganze ohne Passwort lösen?

3) Versuch mal persist-tun in der client.conf. Damit verhindert man, dass der TAP-Adapter bei einer Neuverbindung offen bleibt.

4) Ohne ein vollständiges Log kann man nix sagen. Einzelne Zeilen aus dem Kontext gerissen sind wenig aussagekräftig. Ist das ein error oder eine warning?
 
@Raijin:
Danke für deine rasche Antwort.
1.Ich habe die 2 vorgeschlagenen Befehle nun hinzugefügt, passt das in dieser Position (siehe Screenshot)?
Dennoch muss ich für eine erfolgreiche Neuverbindung den Netzwerkadapter (TAP) reaktivieren (Log siehe Screenshot) - Betriebssystem ist Windows SBS 2011.
2.Ich denke sicherheitstechnisch möchten wir schon dass ein Kennwort notwendig ist um zu verbinden.
3.Was muss den nun gemacht werden, nachdem ich remote-cert-tls server aktiviert habe (Rautezeichen entfernt) - gibt es da eine verständliche Anleitung oder kannst du mir die Schritte nennen?
 

Anhänge

  • screeny.jpg
    screeny.jpg
    51,7 KB · Aufrufe: 232
  • error.jpg
    error.jpg
    148,1 KB · Aufrufe: 241
Zuletzt bearbeitet:
1. Die Position ist vollkommen egal. Die .conf (linux) bzw. .ovpn (Windows) Dateien sind einfach nur eine Ansammlung von Parametern. Theoretisch (und praktisch) kann man OpenVPN auch ohne Datei starten und alle diese Parameter in der Kommandozeile eingeben (openvpn.exe -bla -blubb -etc). Beim TAP Adapter kann ich dir leider nicht helfen, den Fehler kenne ich nicht. Im Log sehe ich im übrigen nix dazu. Ich habe bei mir zB 3 TAP-Adapter, weil ich 3 verschiedene VPNs habe, die durchaus auch gleichzeitig laufen. Nachdem ich die Adapter einmal hinzugefügt habe, musste ich sie nie wieder anfassen. Evtl. mal mit den mitgelieferten Tools den TAP Adapter entfernen und neu hinzufügen. Dazwischen am besten einmal den PC neustarten.

2. Man kann die Zertifikate auch mit eingebautem Passwort generieren. Dann muss bei jedem Verbindungsaufbau das Passwort eingegeben werden, da es sonst nicht entschlüsselt werden kann. Infos dazu siehe google, "openvpn zertifikate erstellen passwort" o.ä.

3. Eigentlich gar nichts. Wenn in der client.conf remote-cert-tls bzw. der Vorgänger ns-cert-type steht, prüft der Client das Zertifikat des Servers auf das entsprechende Server-Flag. Weitere Einstellungen sind nicht erforderlich - sofern das Server-Zertifikat auch wirklich mit Server-Flag generiert wurde. Ist das nicht der Fall, schlägt die Überprüfung nämlich fehl und das vermeintliche Server-Zertifikat wird vom Client abgelehnt (da potentiell MITM-Attacke)
 
1)
Okay, ich bin mir nicht sicher ob der Server neugestartet wurde nach dem OpenVPN installieren, vl. tut ein Neustart dem TAP Adapter gut.
Parallel werde ich auf meinem Windows 10 Client den Tunnel aufbauen und schauen ob es hier online bleibt.

3)
Verbindungsaubau schlug dann fehl d.h. das Zertifikat wurde ohne Server-Flag generiert - wie macht man es mit Server-Flag?
 
3) Ich weiß nicht wie das bei der aktuellen Installation von OpenVPN ist, aber ich denke auch da gibt es noch die Option "OpenSSL" zu installieren. Es sollten dann eigentlich auch Batch-Dateien bzw. Skripte mitgeliefert werden, die "build-key-server.bat" oder so heißen (easy-rsa heißt das Verzeichnis mit den Skripten, wenn ich mich nicht irre.. Dort wird das Sever-Flag automatisch gesetzt. Für Details was genau da passiert kann man sich die Batch-Dateien auch anschauen. Wichtig: Erstellst du eine neue CA, müssen alle Zertifikate mit dieser CA neu erstellt bzw. signiert werden. Es reicht also im Prinzip, wenn du nur das Server-Zertifikat mit der bestehenden CA neu erstellst.

Prinzipiell sollte in der OpenSSL.cnf eine Sektion "x509_server" o.ä. vorhanden sein. Dort wird auch der Parameter "nsCertType=Server" gesetzt. Beim Erstellen des Zertifikats muss man dann "-extensions x509_server" angefügt werden und das Zertifikat bekommt die Parameter aus diesem Block in der OpenSSL.cnf verpasst.

Beispiel:

Code:
[ X509_server ]
# X509v3 extensions for server certificates
basicConstraints        = CA:FALSE
nsCertType              = server                # restrict the usage
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = serverAuth            # restrict the usage
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer
#subjectAltName          = email:move            # Move email address from DN to extensions
#crlDistributionPoints   = URI:http://www.example.com/example_ca.crl

Schau mal hier

Es kann nicht schaden, evtl. erst mit einem Test-Set an Zertifikaten auszuprobieren. Beispielsweise 1x CA, 1x Server, 2x User. Wenn alles läuft wie gewünscht, kann man die richtigen Zertifikate generieren. Lieber so als wenn man für xx Mitarbeiter Zertifikate generiert und dann merkt, dass da was schiefgelaufen ist und man alles nochmal machen muss.
 
Zum Hauptproblem "VPN Tunnel trennt sich immer wieder und Netzwerkadapter muss reaktiviert werden um wieder einen Tunnel aufzubauen":
Die Erreichbarkeit trotz wechselnder öffentlicher IP wird durch einen fixen synology.me link gewährleistet.
Trotz den Hinzufügen der Parametern und Serverneustart, passieren die Abbrüche und Verbindungsprobleme noch immer.

1)
Was kann ich noch machen um den VPN-Tunnel dauerhaft online zu halten?

2)
Kann ich vielleicht mit einem besseren VPN Tool oder dem intergrierten VPN von Microsoft das stabiler hinbekommen?
...bei Windows VPN kommt bei Verbindungsversuch unter ZIEL "https://name.synology.me:1194 mit den Zugangsdaten eingetragen folgende Fehlermeldung "RAS Server konnte nicht aufgelöst werden"
 
1) Prinzipiell gibt es dafür die option "keepalive x y". Wobei x angibt wie lange der Tunnel inaktiv sein darf bis ein ping an die Gegenstelle geschickt wird und y für den Timeout steht nachdem der Tunnel neugestartet wird. Gängige Einstellungen sind zB "keepalive 10 120", bei der nach 10 Sekunden Tunnelinaktivität ein Ping gesendet wird und wenn 120 Sekunden lang keine Antwort kommt, wird der Tunnel neugestartet.

2) Das integrierte VPN von MS habe ich nie benutzt. OpenVPN geht damit auf keinen Fall, sondern nur PPTP (unsicher) und IPsec. Es ist also kein Wunder, dass du damit keine Verbindung zum OpenVPN-Server aufbauen konntest ;)
Wenn die Synology IPsec kann - und davon gehe ich aus -, wäre das auch eine Option. Mit IPsec habe ich allerdings nur wenig Erfahrung, da ich ausschließlich OpenVPN einsetze und dort den frei wählbaren Port sehr hoch schätze. Da ich beruflich viel unterwegs bin, muss mein VPN zuverlässig laufen, auch hinter fremden Firewalls. Daher läuft mein OpenVPN nicht auf 1194, sondern auf einem Standard-Port, der so gut wie nie geblockt wird (zB 53, 80, 443, etc). Bei IPsec hast du diese Freiheit nicht, bei "Standortverbindungen" ist das aber einerlei, da man die Firewall ja selbst konfiguriert und die benötigten Ports dann einfach freigibt. Individuelle Ports sind nur hinter fremdverwalteten Firewalls von Interesse (zB Hotel, Hotspot, etc).


Bezüglich des TAP-Adapters kann ich nur sagen, dass ich so ein Problem noch nie hatte, im www gibt es aber wohl durchaus noch andere mit dem Problem. Hier ist ein Bug-Report mit einigen Workarounds dazu. An deiner Stelle würde ich als erstes mal OpenVPN komplett neu installieren. Evtl. auch mal eine ältere bzw. neuere Version ausprobieren. Zuvor natürlich die Konfiguration sichern ;)
 
Habe nun parallel auf meinem Windows 10 Client und SBS 2011 Server den Tunnel gestartet.
Bei beiden gab es die Zwangstrennung (VPN Server Synology NAS, wird via synology.me link angesprochen), beim Wiederverbinden musste ich am Server den Netzwerkadapter reaktivieren, beim Windowsclient musste ich nur nochmals auf verbinden klicken, der Unterschied liegt wohl am OS\Treiberstruktur und wäre natürlich wünschenswert wartungsfrei ohne Zwangstrennung.

Die Zwangstrennung allgemein wegzubekommen wäre schon die Lösung, das mit dem Adapter reaktivieren muss dann eh nicht gemacht werden, da der Tunnel aufrecht bleibt.

Parameter aus Konfig & Logzeilen siehe oben #7
 
Hallo!

OpenVPN funktioniert nun seit einiger Zeit sehr gut und hält die Verbindung auch meist durchwegs online.

1)
Viele CIFS Zugriffe sind zu sehen auf der NAS, eh von unserem Benutzer.
Ich wollte nachfragen ob ich das getrost so belassen kann oder irgendwo umkonfigurieren soll?

2.)
Nur dass ich nach Serverneustart bei Abfrage der bereits eingetragenen Nutzerdaten auf OK drücken muss - habt ihr da Eine Idee den Schritt wegzubekommen?

Bilder im Anhang

Danke
 

Anhänge

  • openvpnparameters.JPG
    openvpnparameters.JPG
    23,1 KB · Aufrufe: 221
  • CIFS.png
    CIFS.png
    14,7 KB · Aufrufe: 225
Was wohin und wie oft über OpenVPN verbindet, ist OpenVPN ziemlich egal und auch nicht dessen Sorge. Wenn du ungewöhnlich viele Zugriffe auf das NAS siehst, dann ist das ein Problem der Software auf einem Client, der entweder direkt oder über VPN auf das NAS zugreift. Das kann eine Dateisynchronisation, o.ä. sein oder auch simple KeepAlive-Pakete, o.ä.

Mit OpenVPN kannst du sowas nicht einschränken. OpenVPN ist sogesehen nur ein virtuelles LAN-Kabel und dem LAN-Kabel ist es auch vollkommen schnuppe ob darüber gezockt wird, eine Datenbank abgefragt wird, Netzlaufwerke befüllt werden oder auch der IP-Türöffner betätigt wird..


Zum Anmeldefenster: Ich habe offen gestanden keine Ahnung was du meinst. Ich starte die OpenVPN-Verbindung nur bei Bedarf und klicke dabei rechts auf die OpenVPN-GUI, wähle das VPN-Profil und klicke auf connect. Keine Ahnung was wie wo du da Anmeldedaten eingeben willst. Wenn das Zertifikat des Clients allerdings mit Export-Passwort generiert wurde, muss in der Tat bei jeder Verbindung eben dieses Passwort eingegeben werden, da das Zertifikat ansonsten nicht entschlüsselt werden kann.
 
Zurück
Oben