OpenVPN Client Probleme seit Update auf DSM 5.2-5592

[klarglas789]

Hallo,

seit dem Update auf DSM 5.2-5592 funktioniert der OpenVPN Client nicht mehr richtig. Ich bekomme folgende Fehlermeldungen unter /var/log/messages:

Jul  8 23:33:46 NAS_Backup openvpn[19006]: WARNING: file '/tmp/ovpn_client_up' is group or others accessible
Jul  8 23:33:46 NAS_Backup openvpn[19006]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jul  8 23:33:46 NAS_Backup openvpn[19006]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul  8 23:33:46 NAS_Backup openvpn[19007]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jul  8 23:33:49 NAS_Backup openvpn[19007]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Jul  8 23:33:49 NAS_Backup openvpn[19007]: Linux ifconfig failed: external program exited with error status: 1
Jul  8 23:35:20 NAS_Backup synovpnc: connection.c:934 Wait 30 seconds; Failed to get net card info 'tun0' [0x3600]
Jul  8 23:35:20 NAS_Backup synovpnc: connection.c:1247 CreateOVPNConnection(o1436390335) failed
Jul  8 23:35:20 NAS_Backup synovpnc: synovpnc.c:376 VPN id 'o1436390335' is failed to create

An der Server config und den Server wurde nichts verändert, ein anderer OpenVPN Client kann sich wie bisher problemlos verbinden. Anbei meine verwendete Client config:

dev tun
tls-client
remote 10.0.0.10 1194
pull
proto udp
tls-auth keys/ta.key 1
up /usr/syno/etc.defaults/synovpnclient/scripts/ovpn-up
route-up /usr/syno/etc.defaults/synovpnclient/scripts/route-up
ca keys/ca.crt
cert keys/NAS-Backup.crt
key keys/NAS-Backup.key
comp-lzo
script-security 2
float
reneg-sec 0
explicit-exit-notify
plugin /lib/openvpn/openvpn-down-root.so /usr/syno/etc.defaults/synovpnclient/scripts/ip-down
auth-user-pass /tmp/ovpn_client_up
redirect-gateway

Was ich bisher probiert habe:

• Zertifikate alle überprüft
• OpenVPN config komplett gelöscht
• OpenVPN config komplett neu angelegt

Hat jemand eine Idee was da seit den Update schief laufen könnte? Laut google könnte es ein Problem mit "tun0" sein, das manuelle nachladen des Kernel Moduls mittels "insmod /lib/modules/tun.ko" brachte leider keinen Erfolg.

Gruß Markus

 

[klarglas789]

Nachtrag:

am Client:

NAS_Backup> lsmod | grep tun
tunnel4                 1967  1 sit

laden des modules am Client:

NAS_Backup> modprobe tun
modprobe: chdir(2.6.32.12): No such file or directory

Da ist doch was faul ?

am Server:

DiskStation> lsmod | grep tun
tun                    12324  2 
tunnel4                 2035  1 sit

 

[fpo4711]

Hallo Markus,

Hat jemand eine Idee was da seit den Update schief laufen könnte? Laut google könnte es ein Problem mit "tun0" sein, das manuelle nachladen des Kernel Moduls mittels "insmod /lib/modules/tun.ko" brachte leider keinen Erfolg.

Um das laden der Module und das erzeugen des tun-device brauchst Du dir keine Gedanken machen. Das macht die DS alles selbst. Ohne jetzt eine Machine mit 5.2 prüfen zu können, fallen mir nur mehrere Ungereimtheiten auf. Kann aber nicht sagen ob das jetzt aktuell noch so ist. Das
Zertifikat lag meines Wissens nicht in einem keys Ordner. Und als Remote Adresse hast Du

remote 10.0.0.10 1194

angegeben. Muß nicht generell ein Fehler sein, ist aber eine Adresse in einem privaten Subnetz wohl eher nicht gerade der Standard.

Deine Fehlermeldung deutet im ersten Ansatz aber darauf hin das beim setzen der IP ein Fehler auftritt vermutlich vom tun-device. Helfen könnte Dir folgende Zeile in deiner Config einzufügen:

verb 4

Der Wert 4 sollte eine gute Wahl sein. Je größer, je mehr Informationen. Dann wird auf jeden Fall die ganze Sache im Log geschwätziger.

Und mit modprobe wirst Du ohne Anpassungen auf der DS von Haus aus kein Glück haben.

Gruß Frank

 

[klarglas789]

Hallo Frank,

danke für deine Antwort. Die remote Adresse stimmt da beide Geräte zur Zeit in meinem lokalen Netz sind.
Durch das höher stellen des Logs und definieren eines log files mittels:

log-append /var/log/openvpn.log

konnte ich den Fehler finden. Der Server hat eine falsches ifconfig-push ausgeführt für ein tun device, ich hatte folgendes in der push config

ifconfig-push 10.8.0.10 255.255.255.0

das ist aber falsch, es sollte folgendes sein

ifconfig-push 10.8.0.9 10.8.0.10

interessant ist das es seit Monaten mit der falschen config funktioniert hat, und auch mein Android Handy mit OpenVPN Client trotz falscher push Einstellungen ins VPN kommt. Anscheinend ist durch das Update irgendwas "sensibler" geworden.

Gruß Markus

 

[fpo4711]

Die remote Adresse stimmt da beide Geräte zur Zeit in meinem lokalen Netz sind.

Das kann man aber einzig und allein machen um überhaupt zu testen ob ein VPN-Server Verbindungen annimmt. Beim Routing erzeugst Du damit nur Chaos.

ifconfig-push 10.8.0.9 10.8.0.10

Ist mir nicht bekannt das irgenwo in der normalen VPN-Server Installation das verwendet wird. Wüßte auch nicht warum, denn die Zuweisung passiert automatisch. Auf der DS läuft das alles in net30 topology Die push's erzeugt der VPN-Server selbst und überschreibt diese für die routen auch selbst bei jeglicher Änderung in der GUI.

Für den Rest muß ich mal die Glaskugel bemühen. Ich vermute mal Du verwendest ccd's. Dann solltest Du auch, wie hier schon im Forum beschrieben, das überschreiben der ccd-files durch folgende Zeile in der radiusplugin.cnf verhindern.

overwriteccfiles=false

Ansonsten wirst Du nur bis zum nächsten Neustart Freude an deiner Konfiguration haben. Was vielleicht auch für das Auftreten des Fehlers nach dem Update gesorgt haben könnte.

Gruß Frank

 

[klarglas789]

Das kann man aber einzig und allein machen um überhaupt zu testen ob ein VPN-Server Verbindungen annimmt. Beim Routing erzeugst Du damit nur Chaos.

Ja stimmt, das ist auch nur vorübergehend, es funktioniert aber da ich das lokale Netz in zwei Subnetze aufgetrennt habe (10.0.0.0 und 10.0.1.0) zwischen denen per NAT geroutet wird. Nur so könnte ich die volle Config von Client und Server testen.

Ist mir nicht bekannt das irgenwo in der normalen VPN-Server Installation das verwendet wird.

Ja wie du bereits vermutet hast ist es keine Standard VPN Server Installation, da ich mit den Sicherheitsmaßnahmen von Synology nicht so glücklich war, hab ich alles zusätzlich auf Zertifikate umgestellt wie in diesen Thread beschrieben:

http://www.synology-forum.de/showth...Zertifikaten-Static-Key-und-Authentifizierung

Daher auch der Ordner "keys". Ja ich nutze ccds, zumindest versuche ich das, damit die Clients immer wieder die gleichen IPs bekommen, das mit der radiusplugin.cnf wusste ich nicht, vielleicht kommt auch daher das Problem, ich werde mir das mal morgen anschauen. In der GUI von Server und Client stelle ich tatsächlich nichts mehr rum, da sonst immer meine config weg ist, gibt es hier bessere Wege das zu lösen? Danke nochmals für die Tips.

Gruß Markus

 

[fpo4711]

gibt es hier bessere Wege das zu lösen? Danke nochmals für die Tips.

Man kann auch eine openvpn.conf.user im Verzeichnis wo jetzt die openvpn.conf liegt anlegen, dann wird diese generell verwendet und in der GUI wird das dann auch angezeigt. Für das Radiusplugin ist mir keine andere Lösung bekannt.

Gruß Frank