Kein SSL VPN mit 12.2.3.3
Moderator: Securepoint
-
- Beiträge: 31
- Registriert: Di 28.05.2019, 16:14
Kein SSL VPN mit 12.2.3.3
Hallo,
ich habe heute unsere UTM auf die Version 12.2.3.3 geupdated. Danach war keine Verbindung mit dem SSL VPN Client mehr möglich.
In der Übersicht werden dutzende Anmeldungen des Users angezeigt, aber der VPN Client zeigt nur ein rotes Ausrufezeichen an. Nach dem Downgrade auf 12.2.2.8 funktioniert es sofort wieder.
Ist der Fehler bekannt?
Viele Grüße
Tobias
ich habe heute unsere UTM auf die Version 12.2.3.3 geupdated. Danach war keine Verbindung mit dem SSL VPN Client mehr möglich.
In der Übersicht werden dutzende Anmeldungen des Users angezeigt, aber der VPN Client zeigt nur ein rotes Ausrufezeichen an. Nach dem Downgrade auf 12.2.2.8 funktioniert es sofort wieder.
Ist der Fehler bekannt?
Viele Grüße
Tobias
Nein, das ist so nicht bekannt.
Bitte eröffnen Sie ein Support-Ticket und übermitteln Sie uns das Log.
Dann können wir uns das genauer angucken.
Bitte eröffnen Sie ein Support-Ticket und übermitteln Sie uns das Log.
Dann können wir uns das genauer angucken.
Mit freundlichen Grüßen
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
-
- Beiträge: 45
- Registriert: Do 26.03.2020, 15:08
Hier dasselbe mit einer S2S Verbindung. Log sagt:
>..No common cipher between server and client. Server data-ciphers: 'AES-256-GCM:AES-128-GCM' client supported ciphers 'AES-256-CBC'
>..AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)'(status=1)
In der Oberfläche ist aber CBC ausgewählt und nicht GCM. Rollback und es läuft wieder.
>..No common cipher between server and client. Server data-ciphers: 'AES-256-GCM:AES-128-GCM' client supported ciphers 'AES-256-CBC'
>..AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)'(status=1)
In der Oberfläche ist aber CBC ausgewählt und nicht GCM. Rollback und es läuft wieder.
Hier wäre es spannend zu wissen, was "openvpn get" liefert.
Das sind aber Informationen, die nicht im Forum gepostet werden sollten.
Bitte eröffnen Sie eine Ticket über das Resellerportal.
Das sind aber Informationen, die nicht im Forum gepostet werden sollten.
Bitte eröffnen Sie eine Ticket über das Resellerportal.
Mit freundlichen Grüßen
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
-
- Beiträge: 45
- Registriert: Do 26.03.2020, 15:08
"openvpn get" liefert ebenfalls CBC zurück, so wie es in der Oberfläche ausgewählt ist.
Ich laufe wieder auf der alten Version, weil es damit funktioniert und der VPN gebraucht wird.
Bei euch tritt das also nicht auf oder nicht getestet?
Ich laufe wieder auf der alten Version, weil es damit funktioniert und der VPN gebraucht wird.
Bei euch tritt das also nicht auf oder nicht getestet?
Bei uns tritt das nicht auf.
Ist vielleicht die Gegenstelle der Server und dort ist ist ein anderer Wert als Cipher für die Datenverbindung eingestellt?
Ist vielleicht die Gegenstelle der Server und dort ist ist ein anderer Wert als Cipher für die Datenverbindung eingestellt?
Mit freundlichen Grüßen
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
Lauritz Laatzen
Support / Wiki
Tel. 04131/2401-0 ◦ Fax 04131/2401-50
Securepoint GmbH
Bleckeder Landstraße 28 ◦ D-21337 Lüneburg
habe das Problem auch.
Server ist eine v11 UTM, Cipher steht auf AES-256-CBC.
Gegenstelle ist 12.2.2.8, Cipher ebenfalls auf AES-256-CBC
-> läuft
Gegenstelle Upgrade auf 12.2.3.3, Tunnel kommt nicht mehr hoch, gleiche Meldung im Log wie bei joser19330
openvpn get liefert auch nach Upgrade immer noch AES-256-CBC
Downgrade auf 12.2.2.8 -> geht sofort wieder
Wir müssen die Server-UTM die Tage aber tauschen, dann sind beide auf der gleichen Version, dann gebe ich nochmal Bescheid.
Server ist eine v11 UTM, Cipher steht auf AES-256-CBC.
Gegenstelle ist 12.2.2.8, Cipher ebenfalls auf AES-256-CBC
-> läuft
Gegenstelle Upgrade auf 12.2.3.3, Tunnel kommt nicht mehr hoch, gleiche Meldung im Log wie bei joser19330
openvpn get liefert auch nach Upgrade immer noch AES-256-CBC
Downgrade auf 12.2.2.8 -> geht sofort wieder
Wir müssen die Server-UTM die Tage aber tauschen, dann sind beide auf der gleichen Version, dann gebe ich nochmal Bescheid.
-
- Beiträge: 45
- Registriert: Do 26.03.2020, 15:08
In der Config bei mir steht auch:
cipher AES-256-CBC
auth SHA256
Gestern nochmal geprüft mit einer OpenVPN Client Installation (2.5.6) als Gegenstelle und keine Verbindung möglich nach dem Upgrade.
cipher AES-256-CBC
auth SHA256
Gestern nochmal geprüft mit einer OpenVPN Client Installation (2.5.6) als Gegenstelle und keine Verbindung möglich nach dem Upgrade.
Ich habe nach einem Update auf die 12.2.3.3 gerade dasselbe Problem:
No common cipher between server and client. Server data-ciphers: 'AES-256-GCM:AES-128-GCM', client supports cipher 'AES-128-CBC'
Dabei ist auf dem Server ebenfalls AES-128-CBC eingetragen!
Wenn ich mir in einer root shell mit "ps" ansehe, mit welcher Kommandozeile openvpn genau aufgerufen wurde, finde ich u.a. dies:
--data-ciphers-fallback AES-128
In der Version 12.2.2.8 steht stattdessen hier noch:
--cipher AES-128-CBC
Die eingestellte Cipher ist also nur noch Fallback?!?
Das ist eigentlich das Gegenteil von dem, was man möchte - die eingestellte Cipher sollte Vorrang haben.
Ich vermute, die Probleme entstehen durch zu alte Clients, die noch keine Cipher negotiation beherrschen, und daher nicht auf das Fallback umschalten können.
Das Blöde in unserem Fall: die Clients sind IP-Telefone mit integriertem OpenVPN-Client - und ich rechne da eigentlich nicht so bald mit einem Update...
Ein möglichst zügige Lösung oder zumindest ein (Server-seitiges) Workaround wäre extrem nett.
Ich musste das Update jetzt erst einmal rückgängig machen. :-(
No common cipher between server and client. Server data-ciphers: 'AES-256-GCM:AES-128-GCM', client supports cipher 'AES-128-CBC'
Dabei ist auf dem Server ebenfalls AES-128-CBC eingetragen!
Wenn ich mir in einer root shell mit "ps" ansehe, mit welcher Kommandozeile openvpn genau aufgerufen wurde, finde ich u.a. dies:
--data-ciphers-fallback AES-128
In der Version 12.2.2.8 steht stattdessen hier noch:
--cipher AES-128-CBC
Die eingestellte Cipher ist also nur noch Fallback?!?
Das ist eigentlich das Gegenteil von dem, was man möchte - die eingestellte Cipher sollte Vorrang haben.
Ich vermute, die Probleme entstehen durch zu alte Clients, die noch keine Cipher negotiation beherrschen, und daher nicht auf das Fallback umschalten können.
Das Blöde in unserem Fall: die Clients sind IP-Telefone mit integriertem OpenVPN-Client - und ich rechne da eigentlich nicht so bald mit einem Update...
Ein möglichst zügige Lösung oder zumindest ein (Server-seitiges) Workaround wäre extrem nett.
Ich musste das Update jetzt erst einmal rückgängig machen. :-(
-
- Beiträge: 31
- Registriert: Di 28.05.2019, 16:14
Bei uns sind es Windows Clients die den Client aus dem Userportal nutzen. Auch die aktuellste Version.
Uppps - diese letzte Info hat mich aber nun doch etwas geschockt!
Ich habe jetzt mal testweise einen aktuellen Client (2.0.38) samt Config von einer UTM 12.2.3.3 heruntergeladen und unter Windows 10 installiert - keine Probleme! Puhhh...
Laut Client-Log wird tatsächlich TLS_AES_128_GCM_SHA256 verwendet, obwohl in der Config-Datei explizit "cipher AES-128-CBC" steht - hier scheint die Cipher Negotiation also zu funktionieren.
Ich habe jetzt mal testweise einen aktuellen Client (2.0.38) samt Config von einer UTM 12.2.3.3 heruntergeladen und unter Windows 10 installiert - keine Probleme! Puhhh...
Laut Client-Log wird tatsächlich TLS_AES_128_GCM_SHA256 verwendet, obwohl in der Config-Datei explizit "cipher AES-128-CBC" steht - hier scheint die Cipher Negotiation also zu funktionieren.
-
- Beiträge: 17
- Registriert: Fr 01.10.2021, 08:53
Geht es zufällig um Auerswald Telefone? Es gibt eine Beta-Firmware: https://filearea.auerswald.de/index.php/s/6NDaYBQepYqfcpfmkoehling hat geschrieben: Das Blöde in unserem Fall: die Clients sind IP-Telefone mit integriertem OpenVPN-Client - und ich rechne da eigentlich nicht so bald mit einem Update...
Auerswald hierzu: Die Version 2.8G002 ist eine Vorabversion, die auf 2.8G basiert und in der nur der OpenVPN-Client auf 2.5.5 und die TLS-Unterstützung auf Version 1.3 aktualisiert wurden.
Mit der funktioniert das dann auch mit der aktuellen Firmware der UTM.
-
- Beiträge: 17
- Registriert: Fr 01.10.2021, 08:53
Es ist ja kein Bug sondern ein versäumen anderer Hersteller rechtzeitig den VPN Client zu aktualisieren.
-
- Beiträge: 31
- Registriert: Di 28.05.2019, 16:14
Weiß jemand ab welcher SSL Client Version der Securepoint das ganze funktioniert?
Habe jetzt auf einigen Laptops bei uns die Version 2.0.22 gesehen und damit läuft es nicht. Dummerweise sagt der Client die Version ist aktuell und man muss manuell die neueste Version einspielen. Denke dadurch ist bei uns das Problem entstanden. Muss nun alle Clients manuell updaten und dann werde ich das Securepoint Firmware Update erneut einspielen und testen.
Habe jetzt auf einigen Laptops bei uns die Version 2.0.22 gesehen und damit läuft es nicht. Dummerweise sagt der Client die Version ist aktuell und man muss manuell die neueste Version einspielen. Denke dadurch ist bei uns das Problem entstanden. Muss nun alle Clients manuell updaten und dann werde ich das Securepoint Firmware Update erneut einspielen und testen.
Geht leider aktuell nur manuell. Bitte schauen Sie oefter einmal bei uns im Reseller Portal vorbei. Oder ueber das Wiki der Verlinkung zu Sourceforge folgen. Dort gibt es das entsprechende Update.
Wir arbeiten bereits an einer Loesung bezueglich der Updates. Es kann aber noch ein wenig dauern.
Wir arbeiten bereits an einer Loesung bezueglich der Updates. Es kann aber noch ein wenig dauern.
Mit freundlichen Grüßen
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de
Bei dem VPN-Client ist es wichtig, moeglichst die aktuellste Softwareversion zu verwenden. Es geht dabei auch um die Verwendung des aktuellsten Treibers fuer das TAP-Interface. Die Zertifikate aelterer Softwareversionen fuer den Treiber werden unter Umstaenden nicht mehr vom Betriebssystem akzeptiert. Neben der Behebung anderer Probleme.
Mit freundlichen Grüßen
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de
-
- Beiträge: 45
- Registriert: Do 26.03.2020, 15:08
@Mario was passiert hier nun? Wird die FW angepasst oder müssen alle ihre Configs umstellen oder Clients Updaten damit auch GCM funktioniert statt CBC wie in der GUI ausgewählt? Wenn neue Clients mit "Cipher Negotiation" GCM machen statt CBC wie in der Config definiert, dann ist es doch weiterhin nicht wie in der GUI eingestellt und somit ein Bug, selbst wenn es funktioniert."Wenn ich mir in einer root shell mit "ps" ansehe, mit welcher Kommandozeile openvpn genau aufgerufen wurde, finde ich u.a. dies:
--data-ciphers-fallback AES-128
In der Version 12.2.2.8 steht stattdessen hier noch:
--cipher AES-128-CBC"
...
"Laut Client-Log wird tatsächlich TLS_AES_128_GCM_SHA256 verwendet, obwohl in der Config-Datei explizit "cipher AES-128-CBC" steht - hier scheint die Cipher Negotiation also zu funktionieren."
Idealerweise im Support anrufen. Jedoch kann es durchaus sein, das die Konfigurationen ebenfalls aktualisiert werden muessen.
Mit freundlichen Grüßen
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de
Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50
Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de