Synology OpenVPN - kein Zugriff auf LAN

[fpo4711]

Durch deine X'se kann man das natürlich nicht beurteilen. (Lokale IP's braucht man nicht aus'X'sen das bringt keinem was.) Sollte eine deiner X'sen die entsprechende Route sein, so muß dann unter den folgenden Zeilen im Clientlog auch sowas wie beispielsweise:

.... /sbin/route add -net 192.168.100.0 10.8.0.5 255.255.255.0

stehen. Falls nicht dann wahrscheinlich eine Fehlermeldung wie

.... WARNING: potential route subnet conflict between local LAN

oder wie auch immer. Das gibt dann den Fehler an warum fehlgeschlagen. Jedenfalls empfängt dein Client schonmal den Reply vom Server mit den Daten die vom Server z.Bsp. push kommen, z.Bsp. die IPs des Tunnels. Auch die müßten ja in der openvpn.conf auf der Serverseite stehen und werden ja scheinbar verarbeitet. Kann jedenfalls ja schnell durch ein "route" oder "route print" auf der Kommandozeile des Clienten geprüft werden. Auch für diese sollte oben beschriebene erste Zeile vorhanden sein.

Ist deine Route unter den X'sen nicht dabei, dann liegt der Fehler auf der Serverseite. Immer noch sehr beliebt sollen Tippfehler oder falsche Zeilenabschlüße sein. Oder Du edititiers hier vieleicht nicht das richtige File oder irgendwas anderes - Jedenfalls serverseitig.

Gruß Frank

 

[cmdr_tom]

Servus,

da hab ich wohl ein bisschen viel ge-xt.

Thu Jan  7 19:36:16 2016 tomtom/::ffff:[public-ip](51877) SENT CONTROL [tomtom]: 'PUSH_REPLY,route 10.11.1.0 255.255.255.224,route [public-ip] 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)

Mein lokales Netz ist ein Klasse-A (10.11.1.0 255.255.255.224) und wird auch korrekt im Log angezeigt. LAN-Zugriff mit dieser Einstellung dennoch nicht möglich. Wie schon erwähnt nur, wenn ich die Route clientseitig eintrage.

Ein Konflikt mit dem IP-Range des VPN liegt auch nicht vor.

 

[fpo4711]

Mein lokales Netz ist ein Klasse-A (10.11.1.0 255.255.255.224)

Also 255.255.255.224 würde ich nicht gerade als Klasse-A Netz bezeichnen. Aber die Denkweise in Klassen ist ja eh seit langem überholt. Bist Du dir mit der Subnetzmaske da sicher? Das wären nur 30 Hosts.

Gruß Frank

 

[cmdr_tom]

Tja, als ich in der Ausbildung war sprach man noch von Klasse A, Cidre und Subnetting. Die Subnetzmaske ist richtig. Wozu soll ich ein größeres Subnetz verwenden, wenn ich nich mehr Clients habe? Das ist bewußt so gewählt.

 

[ghostdog_id]

Hallo zusammen,

wollte mich zu dem Thema mal wieder zu Wort melden:

Hallo Frank..

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.

Ich gebe dir Recht, eine Kaskade macht das ganze nur komplexer. Leider habe ich die FritzBox noch als DECT Station gebraucht, daher die etwas unsaubere Umgebung. Nun läuft nur noch der RT1900ac als Router und das Problem besteht weiterhin.

Wie ich hier bereits schrieb, habe ich die fehlende Route in der client config eingetragen und es lief. Jedoch ließ mir das Thema keine Ruhe. Heute hatte ich mal wieder Zeit mir die Sache genauer anzuschauen.

Mir fiel auf, dass das vpninterface im VPN Center wie folgt aussah:
Anhang anzeigen 27811
genau diese IP wurde auch gepusht...

ifconfig brachte etwas Licht:

eth0 Link encap:Ethernet HWaddr 00:11:32:4D:21:65
inet addr:169.254.120.13 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::211:32ff:fe4d:2165/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21370414 errors:0 dropped:0 overruns:0 frame:0
TX packets:12236529 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:316214188 (301.5 MiB) TX bytes:1099686537 (1.0 GiB)
Interrupt:179 Base address:0x2000

eth1 Link encap:Ethernet HWaddr 00:11:32:4D:21:66
inet6 addr: fe80::211:32ff:fe4d:2166/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10142424 errors:0 dropped:0 overruns:0 frame:0
TX packets:14432203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3922310913 (3.6 GiB) TX bytes:201071333 (191.7 MiB)
Interrupt:180 Base address:0x3000

gbr0 Link encap:Ethernet HWaddr 02:11:32:4D:21:66
inet addr:192.168.78.1 Bcast:192.168.78.255 Mask:255.255.255.0
inet6 addr: fe80::f84f:3ff:fe19:c52b/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:258 (258.0 B)

lbr0 Link encap:Ethernet HWaddr 00:11:32:4D:21:66
inet addr:192.168.77.1 Bcast:192.168.77.255 Mask:255.255.255.0
inet6 addr: fe80::211:32ff:fe4d:2166/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12491431 errors:0 dropped:0 overruns:0 frame:0
TX packets:21401026 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:859341853 (819.5 MiB) TX bytes:30150023404 (28.0 GiB)


In der Datei /var/packages/VPNCenter/etc/synovpn.conf fand ich die Zuweisung des vpninterface. Eine Änderung von eth0 auf lbr0 und ein Neustart des VPNcenter brachte die erhoffte Lösung. Nun wird die Route korrekt gepusht.

Soweit der Lösungsweg... Wie es zu diesem Problem kommt kann ich nur mutmaßen.

Schönen Abend noch

Gruß

Johann

 

[cmdr_tom]

Servus,

ich habe heute einen Anruf vom Support bekommen - das Problem tritt offenbar nicht auf allen Routern auf. Aber der Techniker bestätigte mir, dass es ein Bug ist und in einem der nächsten Updates behoben wird. Da es offenbar nicht alle Router betrifft, ist damit erklärbar, warum die Einstellungen nicht immer funktionieren.

 

[ghostdog_id]

Hallo Tom,

danke für die Info!

Gruß

Johann

 

[cmdr_tom]

Guten Morgen,

es steht ein Update des VPN Servers bereit, wo dieser Bug behoben sein soll.

 

[ghostdog_id]

Guten Morgen,

kann bestätigen, nach dem Update ist der Bug gefixt. Erreiche nun alle Clients im LAN ohne Anpassung der Route oder der config.

Gruß
Johann

 

[cmdr_tom]

Servus,

kann auch bestätigen, dass es nun ohne Probleme funktioniert.