Verbindung über OPEN VPN nicht mehr möglich

Bennyaa

Lieutenant
Registriert
März 2007
Beiträge
832
Hallo, ich habe bei mir einen OpenVPN docker container laufen, über welchen ich mich von extern auf mein Netzwerk eingeloggt hatte.
Seit 2 Wochen ca. komme ich nicht mehr in das VPN.

Der Client meldet bei dem Verbindungsaufbau nur:

Wed Feb 07 16:50:21 2024 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Wed Feb 07 16:50:21 2024 OpenVPN 2.5.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 24 2021
Wed Feb 07 16:50:21 2024 Windows version 10.0 (Windows 10 or greater) 64bit
Wed Feb 07 16:50:21 2024 library versions: OpenSSL 1.1.1j 16 Feb 2021, LZO 2.10
Wed Feb 07 16:50:21 2024 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Feb 07 16:50:21 2024 Need hold release from management interface, waiting...
Wed Feb 07 16:50:21 2024 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'state on'
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'log all on'
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'echo all on'
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'bytecount 5'
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'hold off'
Wed Feb 07 16:50:22 2024 MANAGEMENT: CMD 'hold release'
Wed Feb 07 16:50:23 2024 MANAGEMENT: CMD 'username "Auth" "Mein Benutzername"'
Wed Feb 07 16:50:23 2024 MANAGEMENT: CMD 'password [...]'
Wed Feb 07 16:50:23 2024 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:23 2024 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:23 2024 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:23 2024 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:23 2024 MANAGEMENT: >STATE:1707321023,RESOLVE,,,,,,
Wed Feb 07 16:50:23 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]Meine IP:1194
Wed Feb 07 16:50:23 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Feb 07 16:50:23 2024 UDP link local: (not bound)
Wed Feb 07 16:50:23 2024 UDP link remote: [AF_INET]Meine IP:1194
Wed Feb 07 16:50:23 2024 MANAGEMENT: >STATE:1707321023,WAIT,,,,,,
Wed Feb 07 16:50:23 2024 read UDP: Unknown error (code=10054)
Wed Feb 07 16:50:25 2024 read UDP: Unknown error (code=10054)
Wed Feb 07 16:50:27 2024 Server poll timeout, restarting
Wed Feb 07 16:50:27 2024 SIGUSR1[soft,server_poll] received, process restarting
Wed Feb 07 16:50:27 2024 MANAGEMENT: >STATE:1707321027,RECONNECTING,server_poll,,,,,
Wed Feb 07 16:50:27 2024 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:27 2024 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:27 2024 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:27 2024 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:27 2024 MANAGEMENT: >STATE:1707321027,RESOLVE,,,,,,
Wed Feb 07 16:50:27 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]Meine IP:1194
Wed Feb 07 16:50:27 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Feb 07 16:50:27 2024 UDP link local: (not bound)
Wed Feb 07 16:50:27 2024 UDP link remote: [AF_INET]Meine IP:1194
Wed Feb 07 16:50:27 2024 MANAGEMENT: >STATE:1707321027,WAIT,,,,,,
Wed Feb 07 16:50:27 2024 read UDP: Unknown error (code=10054)
Wed Feb 07 16:50:29 2024 read UDP: Unknown error (code=10054)
Wed Feb 07 16:50:31 2024 Server poll timeout, restarting
Wed Feb 07 16:50:31 2024 SIGUSR1[soft,server_poll] received, process restarting
Wed Feb 07 16:50:31 2024 MANAGEMENT: >STATE:1707321031,RECONNECTING,server_poll,,,,,
Wed Feb 07 16:50:31 2024 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:31 2024 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:31 2024 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 07 16:50:31 2024 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 07 16:50:31 2024 MANAGEMENT: >STATE:1707321031,RESOLVE,,,,,,
Wed Feb 07 16:50:31 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]Meine IP:9443
Wed Feb 07 16:50:31 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Feb 07 16:50:31 2024 Attempting to establish TCP connection with [AF_INET]Meine IP:9443 [nonblock]
Wed Feb 07 16:50:31 2024 MANAGEMENT: >STATE:1707321031,TCP_CONNECT,,,,,,
Ich finde aber nirgends einen Log, woran es hängt.
Hat jemand eine idee?
 
Wie sehen denn die Server Logs aus? Wenn du da keine Einträge genau zum Zeitpunkt des Verbindungsaufbaus des Clients siehst, dann kommt gar keine Verbindung zustande (was viele Ursachen haben kann, vor allem da wir dein Aufbau und deine OpenVPN-config nicht kennen). Wenn du da Einträge hast, dann poste die mal bitte.
 
In dem Kontext kann ich UDP ehrlich gesagt überhaupt nicht einordnen. Das Management Interface von OpenVPN läuft auf TCP und der vorletzte Log-Eintrag impliziert, dass auch der OpenVPN-Server auf TCP läuft, nämlich auf TCP 9443. Wo da jetzt UDP ins Spiel kommt, geht mit gerade nicht in den Kopf.

Grundsätzlich kann man Logs natürlich besser einordnen, wenn man die dazugehörige Konfiguration kennt. Das gilt sowohl für den Client als auch für den Server. Es ist sonst ziemlich mühselig, ein Log reverse zu engineeren und davon auf die Konfiguration zu schließen.
 
  • Gefällt mir
Reaktionen: redjack1000
Die OpenVPN-Verbindung wird über UDP Port 1194 aufgebaut. Das ist die Standardkonfiguration bei OpenVPN. Das Management-Interface läuft über TCP Port 9443 und kommt nur zum Einsatz, wenn man den Status der OpenVPN-Verbindung abfragen will. Kann man im Grunde ignorieren.

@riversource hat im Grunde schon den Fehler auf Client-Seite gefunden. Der Fehler ist aber erstmal nicht sehr aussagekräftig, daher braucht man die Log vom OpenVPN-Server.

Kommen überhaupt Pakete vom Client beim Server an?

Wenn nein, dann gibts ein grundlegendes Verbindungsproblem. DNS-Auflösung falsch, Firewall dazwischen, ISP hat DS-Light aktiviert, Routingprobleme, Portweiterleitung fehlt/falsch etc.

Wenn allerdings Pakete beim OpenVPN-Server ankommen, dann ist das eher ein Konfigurationsproblem. Das hatte ich letztens auch. Hier gabs ein Problem mit einer alten Konfig nach dem Update des OpenVPN-Servers (hier wars die LZO-Komprimierung, die man aus Sicherheitsgründen deaktivieren sollte). Aber auch SSL-Pakete wie OpenSSL können reinfunken, wenn dann bestimmte Verschlüsselungen deprecated sind und standardmäßig abgeschalten werden. In OpenVPN kann man dann einen Kompatibilitätsmodus mit
Code:
providers legacy default
aktiveren. Auch das hatte ich schon.
 
Zurück
Oben