OpenVPN stellt auf einmal keine Verbindung mehr her

[unrealSpeedy]

Hallo zusammen,

nach nunmehr einigen Stunden Debugging bin ich mit meinem Latein am Ende.
Ich habe mir mittels OpenVPN eine statische IP erstellt - tut hier genau genommen nichts zur Sache.
Wie auch immer, der Dienstleister stellt einen VPN-Server zur Verfügung.
Die Verbindung habe ich als Netzwerkschnittstelle über das DSM eingerichtet (siehe https://addictedtocode.de/nas-und-co/statische-ip-adressen-fuer-dslite-anschluesse-oder-lte/).
Hat jetzt 2 Wochen problemlos funktioniert.
Seit gesten - ich kann absolut keine Änderung am System in dem Zusammenhang feststellen - lässt sich par tout keine verbindung mehr herstellen.
Es wird immer mit der Fehlermeldung "Es konnte keine Netzwerkverbindung hergestellt werden" und "Autorisierung erforderlich" quittiert.

Das einzige was sein könnte ist, dass ich in dem Zeitraum (aber schon vor mindestens einer Woche) das letzte DSM-Update eingespielt habe.

Folgendes habe ich probiert/kann ich ausschließen:
1) Traceroute zum VPN-Server: Funktioniert problemlos über 12 Hops.
2) VPN-Verbindung in einer Ubuntu-VPN eingerichtet - funktioniert problemlos
3) Mit VPN-Anbieter Kontakt aufgenommen - keine Probleme bekannt.
4) VPN-Verbindung komplett aus dem DSM gelöscht und neu erstellt - keine Veränderung.
5) Neue VPN-Verbindung beim Dienstleister gebucht und eingerichet - keine Veränderung.
6) Einrichtugn in einem unabhängigen virtualDSM - gleiches Ergebnis, klappt nicht.
7) Im messages log geschaut mit folgendem Ergebnis:

2020-08-10T11:48:02+02:00 DSHS916 openvpn[23042]: WARNING: file '/tmp/ovpn_client_up' is group or others accessible
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: WARNING: file 'ta_o1595535083.key' is group or others accessible
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1440)
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2020-08-10T11:48:02+02:00 DSHS916 openvpn[23043]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
2020-08-10T11:48:03+02:00 DSHS916 openvpn: SYSTEM:    Last message 'WARNING: INSECURE ci' repeated 1 times, suppressed by syslog-ng on DSHS916
2020-08-10T11:48:03+02:00 DSHS916 gateway_change hook event: NEW 192.168.177.1 on ovs_eth0
2020-08-10T11:48:05+02:00 DSHS916 synovpnc: connection.c:1303 CreateOVPNConnection(o1595535083) failed
2020-08-10T11:48:05+02:00 DSHS916 synovpnc: synovpnc.c:427 SYNOVpnClientConnectionCreateMain((null)) failed
2020-08-10T11:48:06+02:00 DSHS916 gateway_change hook event: DEL 192.168.177.1 on ovs_eth0

Mit meinen Tests habe ich ausgeschlossen, dass es am Dienstleister liegt oder an meinem ISP, der irgendetwas sperrt.
Das Problem lässt sich klar auf die Diskstation bzw. das DSM eingrenzen.
Ich bin mit meinem Latein am Ende,, hat noch jemand eine Idee, was hier los sein könnte?

Beste Grüße
unrealSpeedy

 

[the other]

Moinsen,
heißt, dass es mit anderen Clients läuft? ODer warum die Aussage, dass es am NAS liegen MUSS?

Mal die /tmp Dateien gelöscht?
Stimmt denn der openVPN Port (udp? tcp?), stimmt die Verschlüsselung zwischen config-Datei und Servereinstellung, denn dort wird ja och gemeckert...?

 

[unrealSpeedy]

Danke für Deine Antwort
Ja, mit anderen Clients läuft es. Auch am gleichen Anschluss. Sogar in einer Ubuntu-VM auf dem gleichen NAS.

Die tmp Dateien hab ich noch nicht gelöscht, probiere ich nachher mal aus.
Die config hat die letzten Wochen exakt so funktioniert (im log sehe ich auch, dass er damals schon gemeckert hat wegen der Verschlüsselung).

Beste Grüße
unrealSpeedy

 

[the other]

Moinsen,
na wenn er damals wegen crypto-settings gemeckert hat und es trotzdem lief...
Aber neben der Verschlüsselung scheint er ja auch was an den Rechten auszusetzen, vielleicht analog der ssh-Pubkey Vorgaben, dass die Datei eben nicht zu offen sein darf?
Wüßte ich jetzt aber auch nicht, warum sich das von alleine ändern sollte...
Kannst du nicht die Einstellungen im Docker und im NAS mal anschauen und abgleichen, oder denke ich da zu simpel?

 

[unrealSpeedy]

Danke für Deine Antworten.
Das Problem ist so dämlich wie einfach zu lösen gewesen:

In der Ursprungsconfig ist die folgende Zeile:

auth-user-pass "path/to/file"

Wenn man den dortigen Pfad zum auth-file entfernt, klappt es:

auth-user-pass

Wieso es zu Anfang funktioniert hat?
Ich habe keine Ahnung ^^

Beste Grüße
unrealSpeedy