Securepoint Support Forum

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

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.

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. 

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.

"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?

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?

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.

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.

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. :-(

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.

mkoehling 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...

Geht es zufällig um Auerswald Telefone? Es gibt eine Beta-Firmware: https://filearea.auerswald.de/index.php/s/6NDaYBQepYqfcpf
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.

Ja, es geht um Auerswald (u.a. COMfortel IP 1400).
Vielen Dank für den Tip - werde ich ausprobieren, sobald ich wieder im Homeoffice bin!

(Einen Bugfix/Workaround von Securepoint würde ich natürlich vorziehen...)

Es ist ja kein Bug sondern ein versäumen anderer Hersteller rechtzeitig den VPN Client zu aktualisieren.

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.

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.

es liegt also nur an der Software-Version und nicht an einer Konfiguration der UTM oder der VPN-Konfigdatei?

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.

"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."

@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.

Idealerweise im Support anrufen. Jedoch kann es durchaus sein, das die Konfigurationen ebenfalls aktualisiert werden muessen.

Hallo,

ab welcher SSLVPN-Client-Version funktioniert es denn?

Danke und Gruß
Rolf