Securepoint Support Forum

Nach dem update auf den 2.0.41 Client (Win11 Bulid :22635.3420) Der Fehler tritt aber auch in Win10 auf, folgenden Eintrag im Log:
  p, li { white-space: pre-wrap; }
Checksum 5b9d4e24e47ab7e1c17c52f59fc8e36a2c966917008acb65473f4e9a68f5e6c5 is okay
Try to start OpenVPN connection 59c542d8-b5dd-4f3e-a8c8-d92c7bfcf368 C:/Program Files (x86)/Securepoint SSL VPN/vault/S-1-5-21-1451449360-2225281883-4105489104-1001
2024-04-03 16:17:13 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2024-04-03 16:17:13 Note: ovpn-dco-win driver is missing, disabling data channel offload.
2024-04-03 16:17:13 OpenVPN 2.6.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] [DCO]
2024-04-03 16:17:13 Windows version 10.0 (Windows 10 or greater), amd64 executable
2024-04-03 16:17:13 library versions: OpenSSL 3.2.0 23 Nov 2023, LZO 2.10
2024-04-03 16:17:13 DCO version: N/A


ERROR: Application Exiting!
2024-04-03 16:18:20 OpenSSL: error:0308010C:digital envelope routines::unsupported:Global default library context, Algorithm (whirlpool : 97), Properties (<null>)
2024-04-03 16:18:20 Message hash algorithm 'whirlpool' not found
2024-04-03 16:18:20 Exiting due to fatal error

Mit dem Client 2.0.40 funktioniert das problemlos.
Es ist mir bislang nur noch nicht aufgefallen, weil ich normalerweise die Fritzbox-Wireguard-UTM Verbindung nutze.
Ich hoffe da kann mir jemand etwas raten.

Hallo,
das Problem hatte ich auch. Fleißarbeit ist angesagt. Antwort vom Support:

mit der neusten Version des SSL-VPN Clients werden Zertifikate die mit dem Algorithmus SHA1 verwendet wurden nicht mehr "gültig".
Um diesen Fehler zu beheben müssten Sie die gesamte Zertifikatskette erneuern und mit einen SHA256 Algorithmus oder höher ausstatten.
Dies hängt mit der neuen OpenSSL Version (3.11) und der neusten OpenVPN Version (2.6. zusammen.


Sie müssten für die Benutzer die einen neuen Client bekommen eine neue CA anlegen und dann neue Zertifikate erstellen.
Ein Workaround an sich gibt es nicht. Sie könnten höchstens für neue Benutzer einen zweiten Tunnel anlegen  und dann Stück für Stück die alten umziehen.

Viele Grüße
Stefan Pohl

Guten Morgen,
Vielen Dank für die schnelle Antwort. Dann habe ich ja heute schon etwas zu tun
Ich habe auch schon angefangen und die Option Stück für Stück umziehen gewählt. Bei meinem Client funktioniert das schon mal.

Guten Morgen,
ich habe aktuell auch mit obiger Fehlermeldung zu tun:
Checksum 1be8840910b41e947967443fb891ba2747794993cd13e6a0fba3c3cf57b1314c is okay
Try to start OpenVPN connection 35f4d555-1128-4d00-b22f-c89dcaead91d C:/Program Files (x86)/Securepoint SSL VPN/vault/S-1-5-21-4124347600-2775559935-4139798646-1003
2025-04-11 17:53:41 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2025-04-11 17:53:41 Note: ovpn-dco-win driver is missing, disabling data channel offload.
2025-04-11 17:53:41 OpenVPN 2.6.12 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] [DCO]
2025-04-11 17:53:41 Windows version 10.0 (Windows 10 or greater), amd64 executable
2025-04-11 17:53:41 library versions: OpenSSL 3.0.15 3 Sep 2024, LZO 2.10
2025-04-11 17:53:41 DCO version: N/A
2025-04-11 17:53:41 TCP/UDP: Preserving recently used remote address: [AF_INET]109.40.242.201:1194
2025-04-11 17:53:41 Socket Buffers: R=[65536->65536] S=[65536->65536]
2025-04-11 17:53:41 UDPv4 link local: (not bound)
2025-04-11 17:53:41 UDPv4 link remote: [AF_INET]109.40.242.201:1194
2025-04-11 17:54:41 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
ERROR: TLS error! See log for details
2025-04-11 17:54:41 TLS Error: TLS handshake failed
2025-04-11 17:54:41 SIGUSR1[soft,tls-error] received, process restarting
2025-04-11 17:54:41 Restart pause, 1 second(s)
Da unser externer Servicetechniker im Urlaub ist, habe ich versucht, mich in die Problematik einzuarbeiten.
Der Fehler tritt auf bei einem externen Notebook, welches sich über SSL-VPN einwählen soll. Auf dem Notebook ist die Version 2.0.43 installiert. Bei der Einwahl kommt obige Fehlermeldung. Das ganze hat bis vor einigen Wochen noch ohne Beanstandungen funktioniert. Erschwerend kommt hinzu, dass wir zum 01. April von der Telekom zu PYUR gewechselt sind. Bei den diversen Einstellungen habe ich festgestellt, dass beim Benutzer im Bereich OTP als Hash-Algorithmus noch [sha1] hinterlegt ist. Was kann ich noch prüfen um dem Fehler auf den Grund zu gehen? Falls die Zertifkate zu erneuern sind, in welcher Reihenfolge muss ich hier vorgehen?

Man liest sich (hoffentlich :-)
Gruß Roland

Auf Grund des Logs lässt sich leider erst einmal wenig sagen. 
Hier kommt schlicht keine Antwort vom Server zurück.

Am Besten Sie schauen mal in der UTM auf das Log>>SSLVPN Meldungen.
Gibt es hier Einwahlversuche mit der externen IP des Clients (meist in grün angezeigt)?

Wenn nicht, prüfen Sie den Router. Hier muss die öffentlich IP zu finden sein ebenso wie eine Portweiterleitung zur UTM.