5
OpenVPN mit Problemen
Hi Leute.
Habe schon des Öfteren OpenVPN eingerichtet doch diesmal gibts Probleme.
Und zwar klappt das Starten der Verbindung auf dem Client nur ein einziges Mal. Danach muss ich den Server PC komplett neu starten. Ein einfaches trennen und verbinden reicht nicht. Der Fehler ist immer der selbe. Die Firewall hatte ich auf dem Server zum Testen ausgeschaltet. Meine Vermutung geht Richtung Easybox 803. Kann das sein oder was kann ich noch versuchen? Die configfiles sehen bei mir bis auf IP Adresskreis und Dyndns Adresse immer gleich aus.
Hier mal das Log.
Im Log wenn es klappt geht es bei
MANAGEMENT: >STATE:1613561685,WAIT,,,,,,
zügig weiter und es folgt
MANAGEMENT: >STATE:1613562128,AUTH,,,,,,
und so weiter und sofort bis die Verbindung steht.
VG Maddoc
Habe schon des Öfteren OpenVPN eingerichtet doch diesmal gibts Probleme.
Und zwar klappt das Starten der Verbindung auf dem Client nur ein einziges Mal. Danach muss ich den Server PC komplett neu starten. Ein einfaches trennen und verbinden reicht nicht. Der Fehler ist immer der selbe. Die Firewall hatte ich auf dem Server zum Testen ausgeschaltet. Meine Vermutung geht Richtung Easybox 803. Kann das sein oder was kann ich noch versuchen? Die configfiles sehen bei mir bis auf IP Adresskreis und Dyndns Adresse immer gleich aus.
Hier mal das Log.
Wed Feb 17 12:33:39 2021 OpenVPN 2.4.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on May 11 2017
Wed Feb 17 12:33:39 2021 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Feb 17 12:33:39 2021 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.10
Wed Feb 17 12:33:39 2021 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Feb 17 12:33:39 2021 Need hold release from management interface, waiting...
Wed Feb 17 12:33:40 2021 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Feb 17 12:33:40 2021 MANAGEMENT: CMD 'state on'
Wed Feb 17 12:33:40 2021 MANAGEMENT: CMD 'log all on'
Wed Feb 17 12:33:40 2021 MANAGEMENT: CMD 'echo all on'
Wed Feb 17 12:33:40 2021 MANAGEMENT: CMD 'hold off'
Wed Feb 17 12:33:40 2021 MANAGEMENT: CMD 'hold release'
Wed Feb 17 12:33:40 2021 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Feb 17 12:33:40 2021 MANAGEMENT: >STATE:1613561620,RESOLVE,,,,,,
Wed Feb 17 12:33:40 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]92.208.140.xxx:1194
Wed Feb 17 12:33:40 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Feb 17 12:33:40 2021 UDP link local: (not bound)
Wed Feb 17 12:33:40 2021 UDP link remote: [AF_INET]92.208.140.xxx:1194
Wed Feb 17 12:33:40 2021 MANAGEMENT: >STATE:1613561620,WAIT,,,,,,
Wed Feb 17 12:34:40 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Feb 17 12:34:40 2021 TLS Error: TLS handshake failed
Wed Feb 17 12:34:40 2021 SIGUSR1[soft,tls-error] received, process restarting
Wed Feb 17 12:34:40 2021 MANAGEMENT: >STATE:1613561680,RECONNECTING,tls-error,,,,,
Wed Feb 17 12:34:40 2021 Restart pause, 5 second(s)
Wed Feb 17 12:34:45 2021 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Feb 17 12:34:45 2021 MANAGEMENT: >STATE:1613561685,RESOLVE,,,,,,
Wed Feb 17 12:34:45 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]92.208.140.xxx:1194
Wed Feb 17 12:34:45 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Feb 17 12:34:45 2021 UDP link local: (not bound)
Wed Feb 17 12:34:45 2021 UDP link remote: [AF_INET]92.208.140.xxx:1194
Wed Feb 17 12:34:45 2021 MANAGEMENT: >STATE:1613561685,WAIT,,,,,,Im Log wenn es klappt geht es bei
MANAGEMENT: >STATE:1613561685,WAIT,,,,,,
zügig weiter und es folgt
MANAGEMENT: >STATE:1613562128,AUTH,,,,,,
und so weiter und sofort bis die Verbindung steht.
VG Maddoc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 653070
Url: https://administrator.de/contentid/653070
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
offenbar geht der TLS handshake schief. Die Frage ist, warum.
Einmal wäre gewiss ein Blick in die Logs des Servers hilfreich. Was kommt da an? Was geht raus? Dann könntest Du zur weiteren Analyse auf beiden Seiten wireshark mitschreiben lassen, was an Paketen rausgeht und was an Paketen denn ankommt.
Liebe Grüße
Erik
offenbar geht der TLS handshake schief. Die Frage ist, warum.
Einmal wäre gewiss ein Blick in die Logs des Servers hilfreich. Was kommt da an? Was geht raus? Dann könntest Du zur weiteren Analyse auf beiden Seiten wireshark mitschreiben lassen, was an Paketen rausgeht und was an Paketen denn ankommt.
Liebe Grüße
Erik
Komischer Weise sah das log genau so aus, also die Stelle wo es nicht weiter kommt als ich beim Server die Verbindung trennte. Als wenn da keine Gegenstelle wäre.. Kann am Freitag mal nach den Server logs schauen.
Ach so zusatz. Muss den Server komplett neu starten. Nicht den Client. Falls das im ersten Post falsch rüber kommt 👍
Ach so zusatz. Muss den Server komplett neu starten. Nicht den Client. Falls das im ersten Post falsch rüber kommt 👍
Zitat von @maddoc:
Ach so zusatz. Muss den Server komplett neu starten. Nicht den Client. Falls das im ersten Post falsch rüber kommt 👍
Ach so zusatz. Muss den Server komplett neu starten. Nicht den Client. Falls das im ersten Post falsch rüber kommt 👍
Das war schon klar. Deshalb würde ich den Fehler auch eher auf Seiten des Servers suchen (Server-Logs).
Hi,
ganz eindeutig ein TLS-Fehler.
Wenn Du die Zertifikate selbst erstellt hast, passiert so etwas schon mal.
Ich glaube kaum, das es an Deiner Hardware liegt, auch wenn eine Easybox 803 und ein Windows-OpenVPN-Client nicht gerade die "Kombination meiner Wahl" für eine OpenVPN-Verbindung wäre.
Gruß orcape
ganz eindeutig ein TLS-Fehler.
Wenn Du die Zertifikate selbst erstellt hast, passiert so etwas schon mal.
Ich glaube kaum, das es an Deiner Hardware liegt, auch wenn eine Easybox 803 und ein Windows-OpenVPN-Client nicht gerade die "Kombination meiner Wahl" für eine OpenVPN-Verbindung wäre.
Gruß orcape
Das sieht so aus, als wenn OpenVPN keine statische Route für die Verbindung zum OpenVPN-Server anlegen kann, gleichzeitig aber "redirect-gateway" aktiviert ist. Dann versucht OpenVPN den Traffic zum Tunnelserver durch den Tunnel zu leiten und dann tritt dieser Effekt auf.
Kannst du mal die Routingtabelle des Systems zeigen?
Und: OpenVPN als Admin oder Dienst gestartet?
Kannst du mal die Routingtabelle des Systems zeigen?
Und: OpenVPN als Admin oder Dienst gestartet?
