Synology OpenVPN - kein Zugriff auf LAN

[cmdr_tom]

Hallo,

ich habe am Router den VPN Server installiert und über OpenVPN bekomme ich einfach keinen Zugriff auf das LAN hinter dem Router. VPN Verbindung klappt ohne Probleme. Wenn ich über PPTP gehe, komme ich ins LAN. Fehlt da irgendwo eine FW Freischaltung am Router? Ich habe schon versucht, dass mit eine FW Freischaltung zu machen über UDP/1194 mit von allen zu allen IPs in der Firewall.

 

[Frogman]

Ich nehme an, der VPN-Server des Routers sieht ähnlich aus wie der auf der DS. Hast Du dort in der OpenVPN-Konfig des VPN-Servers auch ein Häkchen, mit dem man den LAN-Zugriff aktiviert?

 

[cmdr_tom]

Hi,

der VPN Server des Router sieht nicht nur so ähnlich aus - es ist genau der gleiche wie auf der DS. Das Häkchen habe ich gesetzt. Seltsamerweise klappt die OpenVPN Verbindung zur DS hinter dem Router ohne Probleme, wenn ich eine Portweiterleitung auf die DS vornehme. Es scheint, als ob der Router die VPN Verbindung einfach sperrt.

 

[Frogman]

Dann mach am besten ein Ticket auf...

 

[cmdr_tom]

Hab ich eh schon. Rückmeldung steht noch aus.

 

[cmdr_tom]

Hallo,

hier mal ein Update - nachdem ich mit dem Support mehrere Tage hin- und hergeschrieben habe und ich das VPN-Server Paket deinstalliert hatte, wieder installiert hatte, gab es gestern einen Fernwartungstermin mit einem Techniker. Der war leider auch etwas ratlos. Er bat mich um eine Fernzugrifffreischaltung am Router für Synology, was ich dann getan hatte. Heute kam die Rückmeldung, dass es nun funktionieren sollte. Habe ich dann gleich probiert - LAN Zugriff via OpenVPN FEHLANZEIGE! Das finde ich jetzt nicht wirklich zielführend. Scheinbar hat der Techniker nur ein bisschen mit den Firewallregeln rumprobiert. Ich bin nicht gerade begeistert davon. Ich werde mich jetzt erstmal nicht mehr mit dem Support rumschlagen, da meine Antwort sonst nur emotional wäre.

 

[dil88]

Frustrierend. Solltest Deine Emotionalität aber nach ein paar Tagen etwas absinken, würde ich dennoch so sachlich wie möglich noch einmal das Feedback geben, dass es nach wie vor nicht funktioniert. Normalerweise würde ich von jemandem, der vollen Zugriff auf Router und DS hat und eine solche Aussage abgibt, erwarten, dass er die Funktionfähigkeit verifiziert hat. Vielleicht ist es eine Kleinigkeit, die schief gegangen ist, und der Kollege bekommt es doch noch hin. Und auch dann, wenn ers nicht hinbekommt, steht dann zumindest nicht im Raum, dass das Ticket erfolgreich abgeschlossen werden konnte.

 

[Frogman]

Ich denke, einem neuen Produkt, noch dazu in einer für Synology bisher unbekannten Geräteklasse, sollte man noch eine gewisse Skepsis entgegen bringen (ähnlich wie bspw. auch einem neuen Feature namens BTRFS). Es ist offenbar nicht damit getan, ein DSM nur leicht umzukneten und in einen Kasten namens 'Router' zu pflanzen.

 

[cmdr_tom]

Heute hab ich mal das neuste Update eingespielt - leider funktioniert der LAN Access damit noch immer nicht. Hab das nun wieder an den Synology Support zurückgemeldet.

 

[ghostdog_id]

Hi Tom,

hatte anfangs das gleiche Problem. Trotz des des Hakens "Clients den Server-LAN-Zugriff erlauben" und der notwendigen Firewalregeln, hatte ich keine Verbindung in mein lokales Netz(192.168.77.0/24)

Folgender Eintrag in meiner client openvpn.opnv hat die erhoffte Lösung gebracht:

route 192.168.77.0 255.255.255.0 (192.168.77.0 muss durche deine Subnetz IP ersetzt werden)

Scheinbar fehlt der notwendige Eintrag in der Routingtabelle. Hoffe es hilft.

Gruß

Jo

 

[fpo4711]

Hallo,

hab zwar den Router noch nirgends in der Anwendung. Aber in den meisten Fällen ist es kein Problem der Synology VPN-Server Lösung sondern eine ganz simple Sache. OpenVPN "pusht" die Route auf den Clienten. Das funktioniert beispielsweise unter Windows nur wenn der OpenVPN Client auch als Adminsitrator ausgeführt wird. Nur dann kann auch die Route auf dem Clienten gesetzt werden. Das pushen der Route wird durch den Haken "Clients den Server-LAN-Zugriff erlauben" aktiviert. Wird der OpenVPN Client nicht als Administrator ausgeführt funktioniert auch nicht das setzen der Route und somit auch nicht der Zugriff auf die Geräte im LAN.

Prüfen kann man das im Log auf der Clientseite. In der Config kann je nach höherem Wert nach verb x (x = Level 0 kein log / 11 am detailliertesten) die Ausgabe beeinflußt werden.

verb 3

sollte hier die gewünschte Information schon anzeigen. Dann erscheint so etwas (oder so ähnlich - ist aus dem Kopf) wie "Push received ...... route XX.XX.XX.XX" im Log.

Gruß Frank

 

[ente_b]

Wichtig, zumindest unter Windows-Systemen:
OpenVPN-Client immer mit Admin-Rechten ausführen lassen, das kann man auch dauerhaft einstellen für den OpenVPN-Client, dann klappt das auch mit dem Routing - ich bin da auch schon mehrmals auf die Schn...e geflogen, weil ich es vergessen hatte ...

Herzliche Grüße

Heiko

 

[ghostdog_id]

Hallo Frank,
Hallo Heiko,

in die Admin Falle bin ich auch mehrmals getappt. Doch irgendwann nach jahrelanger Arbeit mit OpenVPN lernt man es. Der client wird definitiv als Admin gestartet

Genau die Tatsache, dass der client als Admin ausgeführt und die Route dennoch nicht gepusht wird, ist eben seltsam. Wie Frank es oben schreibt, kenne ich die VPN Server ebenfalls von der Synology NAS und hatte nie Probleme. Vielleicht hängt es an meiner Netzwerklandschaft. Der RT1900ac hängt aktuelle noch hinter einer fritzbox.

verb 3 zeigt mir, dass das Netz der fritzbox gepusht wird, jedoch nicht das lokale Netz des RT1900ac...


Gruß

Johann

 

[ente_b]

dann fehlt eine Route ...

 

[fpo4711]

Hallo Johann,

....

verb 3 zeigt mir, dass das Netz der fritzbox gepusht wird, jedoch nicht das lokale Netz des RT1900ac...

Ich denke mal da ist gänzlich etwas nicht richtig konfiguriert / angeschlossen. Die Routerkaskade würde ich erst einmal beseitigen (Sofern überhaupt möglich). Dann dürfte sich das von selbst lösen. Der VPN-Server übermittelt immer die Route zur LAN-Seite. Eine Übermittlung der Route zur WAN-Seite wäre wohl auch völlig sinnlos. Ich vermute mal Du hast hier den Synology Router nicht richtig angeschlossen, weshalb er sich jetzt mit der LAN-Seite im Fritzbox Netz befindet. Hier zusätzliche Routen einzufügen würde eigentlich den RT1900 als Router ad absurdum führen. Wenn Du die Kaskade aufrecht erhalten willst, wäre folgende Konfiguration denkbar.

WAN (Internet/DSL) <-> Fritzbox WAN(DSL) / Fritzbox LAN <-> RT1900ac WAN / RT1900ac LAN <-> Restliche Geräte evt. über Switch

Wie gesagt würde ich nur einen Router nutzen. Dummerweise läßt sich ja die Fritzbox nicht mehr nur als reines Modem für DSL verwenden. Kommt natürlich auf deine Version an und natürlich auch auf deinen Anschluß an oder eventuelle Anschaffungen wie Modem.

Gruß Frank

 

[cmdr_tom]

Das mit der Adminberechtigung war auch mein erster Verdacht. War aber nicht der Fall. Merkwürdig ist, dass die Route gepusht wird, wenn ich mich via OpenVPN auf meine Rackstation hinter dem Router verbinde. Da klappt der LAN Zugriff problemlos mit gleichen Einstellungen.

 

[cmdr_tom]

Hi,

der Synology Support hat nun wieder 2 Tage auf meinem Router analysiert und getestet. Leider ohne Erfolg. Ich habe nun auch im englischen Synology Forum einen Thread gefunden, wo mehrere Nutzer das gleiche Problem haben und mit workarounds mehr oder weniger erfolgreich versuchen, dass Problem zu lösen. Scheinbar bin ich da nicht allein.

 

[cmdr_tom]

So, Lösung gefunden... allerdings kaum wie es vorgesehen ist. Scheinbar pusht der VPNServer am Router die Route nicht. auch manuelles Eintragen in der Server Konfiguration brachte keine Abhilfe. Daher habe ich am Client in der openvpn.ovpn Konfigurationsdatei einfach mal folgendes eingetragen (als Beispiel ist euer internes Netz 192.168.100.1 bis 192.168.100.254):

client
route-nopull
route 192.168.100.0 255.255.255.0
route-metric 50

Damit klappt die Verbindung wunderbar.

 

[fpo4711]

Hallo,

sei mir nicht böse aber die Aussage das OpenVPN keine Routen pusht kann ich kaum glauben. Ich hätte an deiner Stelle den Fehler versucht etwas genauer zu ergründen. OpenVPN hilft Dir bei der Fehlersuche doch wunderbar. Wenn wie oben beschrieben verb 3 in der Clientconfig steht wird schon recht detailliert im Log geschrieben was passiert. Läßt sich auch noch durch höhere Werte nach verb erweitern. Steht in der Serverconfig ein push route dann sollte das auch beim Clienten ankommen. Die Serverconfig wird übrigens nur beim Start des VPNServers eingelesen. Änderungen die nach dem Start durchgeführt werden haben keine Auswirkungen. Steht also in der openvpn.conf auf der Serverseite beim Start ein

push "route 192.168.100.0 255.255.255.0"

drin, dann sollte auch im (Client)Log folgendes vorhanden sein:

.... SENT CONTROL [.....]: 'PUSH_REQUEST' (status=1)
.... PUSH: Received control message: 'PUSH_REPLY,route 192.168.100.0,topology ..

Zum aktivieren des Log (funktioniert sowohl client- als auch serverseitig.

verb 3
log-append /<entsprechender Pfad>/openvpn.log

Verhindert werden das die Route dann clientseitig gesetzt wird kann nur der Umstand das der VPNClient keine Rechte hat um routen zu setzen (dürfte in deinem Fall ja nicht der Fall sein, da Du die ja durch die Clientconfig setzen kannst), ein fehlendes pull oder aber wie in deinem Beispiel dann ein route-nopull.

Und die push-Zeile in der Config des Servers wird bei Synology durch den Haken "Clienten den Server-Lan Zugriff erlauben" oder so ähnlich aktivert. Haken gesetzt Route wird übermittelt, Haken entfernt Route wird nicht gesetzt. Bildet sich jeweils auch direkt nach der Änderung in der GUI in der Config ab.

Vielleicht könntest Du ja mal zur Sicherheit die entsprechenden Zeilen aus dem Log bzw. die Server openvpn.conf hier posten. Nicht unbedingt elementar, denn Du hast ja eine Lösung würde mich aber mal interessieren.

Gruß Frank

 

[cmdr_tom]

push "route 192.168.100.0 255.255.255.0"

drin, dann sollte auch im (Client)Log folgendes vorhanden sein:

.... SENT CONTROL [.....]: 'PUSH_REQUEST' (status=1)
.... PUSH: Received control message: 'PUSH_REPLY,route 192.168.100.0,topology ..

verb 3
log-append /<entsprechender Pfad>/openvpn.log

Hi,

kein Problem - genau die Anpassung der Serverkonfiguration habe ich vor der Clientseitigen Methode versucht.

Im Log steht dann auch dies soweit ich das erkennen kann drin:

Thu Jan  7 19:36:16 2016 tomtom/::ffff:XX.XXX.XXX.XX(51877) send_push_reply(): safe_cap=940
Thu Jan  7 19:36:16 2016 tomtom/::ffff:XX.XXX.XXX.XX(51877) SENT CONTROL [tomtom]: 'PUSH_REPLY,route XX.XX.X.X 255.255.255.224,route XX.XXX.XX.X 255.255.255.0,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)

Nur funktioniert hat das dann dennoch nicht im Gegensatz zum Push vom Client aus.