Nach Update auf DSM keine VPN-Verbindung möglich

[IPNS]

Hallo zusammen,

privat habe ich eine Diskstation 213+ (DS) und in der Firma eine Rackstation 812+ (RS).
Auf beiden habe ich das VPNServer Package installiert und verwende eigene Zertifikate und Keys.
Das hat super funktioniert. Mit meinem Notebook konnte ich mich problemlos mit DS oder RS verbinden (hatte jeweils getrennte Zertifikate und Keys).

Nach dem Update von DS und RS auf DSM 5 kann ich mich nur noch mit der DS verbinden. Mit der RS nicht mehr.
Um das Problem einzugrenzen, verwende ich auf der RS die von der RS erzeugten Original ca.crt und habe auch die Konfigurationsfiles auf den Client exportiert.
Auch hier bekomme ich aber den gleichen Fehler, wie vorher mit meinen eigenen Zertifikaten:

Sat Mar 22 11:23:45 2014 us=743912 MULTI: multi_create_instance called
Sat Mar 22 11:23:45 2014 us=744017 x.x.x.x:1194 Re-using SSL/TLS context
Sat Mar 22 11:23:45 2014 us=744060 x.x.x.x:1194 LZO compression initialized
Sat Mar 22 11:23:45 2014 us=744207 x.x.x.x:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Mar 22 11:23:45 2014 us=744240 x.x.x.x:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Mar 22 11:23:45 2014 us=744317 x.x.x.x:1194 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sat Mar 22 11:23:45 2014 us=744341 x.x.x.x:1194 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sat Mar 22 11:23:45 2014 us=744382 x.x.x.x:1194 Local Options hash (VER=V4): '530fdded'
Sat Mar 22 11:23:45 2014 us=744418 x.x.x.x:1194 Expected Remote Options hash (VER=V4): '41690919'
Sat Mar 22 11:23:45 2014 us=744484 x.x.x.x:1194 TLS: Initial packet from x.x.x.x:1194, sid=b8efa7bf ba2eac58
Sat Mar 22 11:23:45 2014 us=809753 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:23:47 2014 us=905682 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:23:48 2014 us=164509 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:23:51 2014 us=276694 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:23:52 2014 us=885179 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:23:59 2014 us=551638 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:24:00 2014 us=945531 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:24:15 2014 us=913246 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Sat Mar 22 11:24:45 2014 us=544197 x.x.x.x:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Mar 22 11:24:45 2014 us=547029 x.x.x.x:1194 SYNO_ERR_CERT
Sat Mar 22 11:24:45 2014 us=547088 x.x.x.x:1194 TLS Error: TLS handshake failed
Sat Mar 22 11:24:45 2014 us=547275 x.x.x.x:1194 SIGUSR1[soft,tls-error] received, client-instance restarting

Die openvpn.conf wurde von der RS erzeugt und so übernommen:

push "route 192.168.110.0 255.255.255.0"
push "route 192.168.118.0 255.255.255.0"
dev tun

management 127.0.0.1 1195

server 192.168.118.0 255.255.255.0


dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh1024.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5

comp-lzo

persist-tun
persist-key

verb 4

log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf 
client-cert-not-required 
username-as-common-name
duplicate-cn

Die Konfiguration des Clients wurde bis auf die Server-IP ebenfalls übernommen:

dev tun
tls-client

remote RemoteIPdesRouters 1194

# The "float" tells OpenVPN to accept authenticated packets from any address, 
# not only the address which was specified in the --remote option. 
# This is useful when you are connecting to a peer which holds a dynamic address 
# such as a dial-in user or DHCP client.
# (Please refer to the manual of OpenVPN for more information.)

#float

# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)

#redirect-gateway

# dhcp-option DNS: To set primary domain name server address.
# Repeat this option to set secondary DNS server addresses.

#dhcp-option DNS DNS_IP_ADDRESS

pull

proto udp
script-security 2

ca caRS.crt

comp-lzo

reneg-sec 0

auth-user-pass

Am Router wurde der Port 1194 UDP auf die IP der RS forwarded.

In der Log des Servers ist ja zu erkennen, dass Pakete ankommen. Mir ist nur nicht ganz klar, was [EHOSTUNREACH]: No route to host (code=113) bedeutet?
Ich interpretiere es so, dass er keinen Weg zurück zum Client findet und deshalb die Key negotiation nicht funktioniert.

Habe aber leider keine Ahnung, wo ich ansetzen soll, denn ich habe einen Client, mit dem ich auf RS und DS zugreifen konnte. An den Routern wurde nichts geändert, lediglich die Updates auf DSM 5 wurden durchgeführt.

Herzlichen Dank schon mal vorab für sachdienliche Hinweise.

Gruß
Andy

 

[fpo4711]

Hallo,

in erster Linie würde ich mal deine Netzwerkeinstellungen überprüfen. Steht hier auch wirklich ein korrekter Eintrag unter Gateway und DNS?

Gruß Frank

 

[IPNS]

Hallo Frank,

vielen Dank für den Hinweis. Die Einträge für DNS und Gateway sind korrekt.
Ich kann auch von der RS ins Internet und z.B. Pakete laden oder Updates installieren. Weiterhin habe ich einen WLAN-Stick angeschlossen, über den auch Endgeräte ins Internet kommen.

Nachdem die Pakete von aussen beim VPNServer ankommen (im LOG zu sehen), gehe ich davon aus, dass mein Portforwarding ok ist (außerdem klappte vor dem DSM-Update der VPN-Zugang problemlos)
[EHOSTUNREACH]: No route to host (code=113) bedeutet für mich (aber vielleicht liege ich da falsch), dass wohl keine Route mehr zurück gefunden wird, also die Verbindung rein ok ist, aber raus nicht.

Habe aber keine Idee, wo ich weiter ansetzen kann, denn selbst wenn ich den Log-Level nach oben setzen wird es nicht aussagekräftiger.

 

[fpo4711]

Nachdem die Pakete von aussen beim VPNServer ankommen (im LOG zu sehen), gehe ich davon aus, dass mein Portforwarding ok ist (außerdem klappte vor dem DSM-Update der VPN-Zugang problemlos)
[EHOSTUNREACH]: No route to host (code=113) bedeutet für mich (aber vielleicht liege ich da falsch), dass wohl keine Route mehr zurück gefunden wird, also die Verbindung rein ok ist, aber raus nicht.

Hab diese Meldung noch nicht gehabt, aber sehe das genauso das der Rückweg nicht funktioniert. Eventuell die Frirewall auf der DS aktiviert? Ansonsten kenne ich die WLAN-Lösung auf der DS nicht, da nirgends bei mir im Einsatz. Vielleicht mal zum Test deaktivieren. Ansonsten fiele mir noch ein, das der VPN-Server auch an eine Schnittstelle gebunden werden kann. Zu finden in den Einstellungen des VPN-Servers.

Gruß Frank

 

[IPNS]

Nach einiger Forschungsarbeit, konnte ich das ganze nun weiter eingrenzen.
Starte ich meinen Router neu, funktioniert danach die OpenVPN-Verbindung problemlos. Im Router unterscheiden sich allerdings die Routingtabellen nicht zu vorher.
Ich kann den OpenVPN-Server der Synology RS restarten, ohne Auswirkungen.
Wenn ich allerdings die Synology neu boote, geht danch die OpenVPN-Verbindung nicht mehr. Boote ich den Router, geht's wieder.
Da die einzig durchgeführte Änderung das DSM 5 Update war, muss es aus meiner Sicht an der Synology liegen.

Es sieht für mich so aus, als würde die Synology nach dem Start irgendwie "vergessen" beim Router anzufragen und somit keine "saubere" Route vorhanden sein (komischerweise geht aber der Zugriff aufs Internet über einen WLAN-Stick an der RS)
Wenn ich den Router neu starte, werden wohl die Routen dann richtig aufgebaut, da vermutlich die RS dann "antwortet".

Es könnte auch daran liegen, dass es im neuen DSM irgend eine Einstellung gibt, die vorher gesetzt war und nach dem Update jetzt nicht mehr, aber ich habe noch nichts finden können.
Evtl. hat jemand von Euch noch einen Tipp - das ist ja fast wie Ostereier suchen

 

[fpo4711]

Hallo,

hatte im OpenVPN-Forum zu dieser Fehlermeldung einen Hinweis gefunden, das eventuell eine geänderte mtu zum Ziel führte. Kann das zwar nicht ganz nachvollziehen aber wie heißt es so schön Versuch mach kluch. Setze doch mal sowohl in die Client- als auch in die Server-Config folgende Directive.

tun-mtu 1400

Danch VPN-Server Neustart nicht vergessen.

Gruß Frank

 

[IPNS]

Danke, Frank,
habe ich mit tun-mtu 1400 getestet. Leider ohne Erfolg. Habe es auch mal mit route-gateway probiert, da ich der Ansicht bin, dass er den Weg zurück nicht mehr findet.
Hat leider auch nichts bewirkt, allerdings habe ich den Router nicht neu gestartet (wäre jetzt im Tagesbetrieb schlecht, solange alle arbeiten). Werde es morgen früh dann nochmals nach einem Neustart des Routers testen.

Gruß Andy

 

[IPNS]

So, Jugend forscht geht weiter.

inzwischen habe ich doch einen Unterschied festgestellt, der verantwortlich für die Ursache sein könnte. Ich habe mir mal die Routingtable an der RS ausgegeben. Hier die Table mit der keine OpenVPN-Verbindung geht:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.110.1   0.0.0.0         UG        0 0          0 eth1
192.168.110.0   *               255.255.255.0   U         0 0          0 br0
192.168.110.0   *               255.255.255.0   U         0 0          0 eth1
192.168.118.0   192.168.118.2   255.255.255.0   UG        0 0          0 tun0
192.168.118.2   *               255.255.255.255 UH        0 0          0 tun0

und hier die Table der RS nach einem Boot des Routers (OpenVPN geht):

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.110.1   0.0.0.0         UG        0 0          0 br0
192.168.110.0   *               255.255.255.0   U         0 0          0 eth1
192.168.110.0   *               255.255.255.0   U         0 0          0 br0
192.168.118.0   192.168.118.2   255.255.255.0   UG        0 0          0 tun0
192.168.118.2   *               255.255.255.255 UH        0 0          0 tun0

Der Unterschied liegt also in der default route. Wobei im ersten Fall eth1 direkt mit dem Router verbunden ist. Sollte also eigentlich auch funktionieren.

Sonnige Grüße
Andy

 

[IPNS]

Ursache erkannt

Das Problem liegt am LAN2. Ist LAN2 inaktiv funktioniert es.
D.h. aber es wurde im Vergleich zu DSM 4.3 irgend ein Skript verändert, denn vorher hat es ja auch mit aktiver LAN2 funktioniert.

Falls jemand eine Idee hat, gerne.

Gruß
Andy

 

[fpo4711]

Hallo Andy,

den Hinweis auf #4 hast Du beachtet. Das der VPN-Server an verschiedene Schnittstellen gebunden werden kann. Einstellung im VPN-Server. In deinen Routen kann ich bloß eine Bridge sehen und eth1 sehen. Wie gesagt kenne die WLAN Einstellungen der DS/RS nicht, da nirgends genutzt. Eventuell bringt vielleicht ein Wechsel der Subnetze (Schnittstellen) etwas so das die Bridge mit eth1 erstellt wird. Denke mal die läuft im Augenblick mit eth0 und bindet das WLAN.

Gruß Frank

Edit: DHCP?

 

[IPNS]

Hallo Frank,

den VPN-Server habe ich auf LAN (nicht LAN2) eingestellt. Trotzdem erscheint in der Routingtabelle eth1 was falsch wäre.
WLAN habe ich auch schon deaktiviert, dass ändert in der Routingtabelle nichts.
DHCP hatte ich auch schon durch (hatte zuerst DHCP an der RS und im Router feste IP-Adressen zugewiesen und auch schon feste IP-Adressen in der RS eingestellt).
Bin mir fast sicher, dass im Vergleich zu DSM 4.3 ein Skript verändert wurde, welches nun das falsche Interface in die Routingtabelle einträgt sobald LAN2 aktiv ist.
Hab nur noch nichts finden können.

Sonnige Grüße
Andy