OpenVPN keine lokale Verbindung zur Syno

[dapfe]

Hallo an Alle

mein ursprünglicher Beitrag habe ich entfernt, da mir was neues aufgefallen ist.

Leider habe ich ein Problem mit OpenVPN. Ich kann mich zwar ins lokale Netzwerk einwählen, und auch meine Geräte im lokalen Netzwerk sind ansprechbar, nur die Syno ist nicht erreichbar unter der lokalen IP. Die Syno kann ich nur über deren VPN-IP aufrufen.

Jemand eine Idee wodran das liegen kann?

Grüße,
dapfe

 

[fpo4711]

Mit deinen dürftigen Angaben. Firewall?

Gruß Frank

 

[dapfe]

In der Firewall sind keine Regel aktiviert.
Bei Sicherheit ist die automatische Blockierung aktiviert, sowie Schutz gegen DoS und Schutz gegen Cross-Site-Request-Forgery-Attacken. Diese hatte ich auch schon alle zum testen deaktiviert, hat aber nichts geholfen.
Im Router sind die Firewall Einstellungen auch Standard.

Im VPN-Server ist der Server-LAN Zugriff aktiv, sowie auch in der Client-Config redirect-gateway und DNS aktiv.

Mich wundert es nur dass das lokale IP-Netzwerk erreichbar ist per OpenVPN, nur eben nicht die Syno. Diese ist nur über die VPN-IP erreichbar

Grüße, dapfe

PS: Übrigens ist über LAN Port #2 auch das zweite, getrennte lokale Netzwerk per VPN erreichbar, auf die Syno habe ich hier drüber auch kein Zugriff.

 

[fpo4711]

Hilfreich wäre es auch die DSM Version zu kennen. Auf jeden Fall wären mal die Subnetze wichtig. Clientsubnetz, Serversubnetz und Tunnensubnetz (dynamische IP).

Auch wäre es hilfreich zu wissen mit was für einem Clienten du zugreifst? Und zu letzt kann auch das Log vom Clienten hilfreich sein bzw. aber auf jeden Fall die Ausgabe von "route" bzw. "route print" nachdem du die Verbindung aufgebaut hast.

Gruß Frank

 

[dapfe]

DSM Version ist die neuste, DSM 5.2-5592 Update 2 auf einer DS214+

Subnetze sind folgende:
LAN1: 192.168.1.0
LAN2: 192.168.101.0
VPN: 192.168.17.0

Ich greife per OpenVPN iOS Client zu. Leider wüsste ich nicht wo ich dort "route print" ausgeben kann.
Log zeigt folgendes an:

2015-08-12 09:43:35 SSL Handshake: TLSv1.0/TLS-DHE-RSA-WITH-AES-256-CBC-SHA
2015-08-12 09:43:35 Session is ACTIVE
2015-08-12 09:43:35 EVENT: GET_CONFIG
2015-08-12 09:43:35 Sending PUSH_REQUEST to server...
2015-08-12 09:43:35 OPTIONS:
0 [redirect-gateway]
1 [dhcp-option] [DNS] [192.168.1.1]
2 [route] [192.168.1.0] [255.255.255.0]
3 [route] [192.168.17.0] [255.255.255.0]
4 [route] [192.168.17.1]
5 [topology] [net30]
6 [ping] [10]
7 [ping-restart] [60]
8 [ifconfig] [192.168.17.6] [192.168.17.5]

2015-08-12 09:43:35 LZO-ASYM init swap=0 asym=0
2015-08-12 09:43:35 EVENT: ASSIGN_IP
2015-08-12 09:43:35 Connected via tun
2015-08-12 09:43:35 EVENT: CONNECTED XXX.XX.net:1194 (X.X.X.X) via /UDPv4 on tun/192.168.17.6/
2015-08-12 09:43:35 NET Internet:ReachableViaWWAN/WR t----l-
2015-08-12 09:43:35 NET WiFi:NotReachable/WR t------
2015-08-12 09:43:35 SetStatus Connected

Grüße, dapfe

 

[fpo4711]

Hallo dapfe,

ehrlich gesagt. Ich kann keinen Fehler finden. Die Routen sind scheinbar korrekt gesetzt. Somit sollte auch die DS unter 192.168.1.<irgenwas> erreichbar sein. Für dies äusserst komische Verhalten habe ich keine Erklärung. Vielleicht auch einmal schauen ob im VPN-Server OpenVPN auch wirklich an die richtige Schnittstelle gebunden ist.

Gruß Frank

 

[dapfe]

Hallo,
VPN-Server ist an LAN1 gebunden.
Ich habe mal ein route print von der Syno hinzugefügt. Da frage ich mich gerade nur warum 192.168.17.2 aufgeführt ist:



grüße,
dapfe

 

[fpo4711]

Auch korrekt. Die 192.168.17.0/24 ist doch dein VPN-Tunnel.

Wenn Du den VPN-Server deaktivierst, sollten diese Routen verschwinden und entsprechend beim aktivieren wieder erscheinen. tun0 ist das verwendete Device von OpenVPN.

Gruß Frank

 

[dapfe]

okay... trotzdem vielen dank!! Frage mich echt warum es nicht geht

gruß, david

 

[jahlives]

wirf mal auf dem System welches du erreichen willst den tcpdump (oder wireshark) an und schick dann Pakete z.B. pings
Dann guckst du ob sie überhaupt am Ziel ankommen und falls ja wie genau sie ausschauen (v.a. die Sender IP wäre interessant).
Ich tippe darauf, dass die Pakete wohl ankommen, aber dann nicht auf demselben Weg zurückgehen was zu einem asymetrischen Routing führt
Falls sie überhaupt nicht am Zielsystem ankommen, gehst du einen Schritt zurück und guckst mit tcpdump ob die Pakete überhaupt auf der DS ankommen

 

[dapfe]

also habe jetzt den OpenVPN-Client (habe den VPN-Server neu installiert, deswegen hat er nun noch das 10.8.0.0 Netz) auf Win8 installiert und gestartet und die Pakete abgefangen. Interpretieren kann ich sie leider nicht.

Ping auf 192.168.1.100 (syno daheim) läuft ins leere.
Ping auf 192.168.1.1 (router daheim) funktioniert.

Hier ein Screenshot von Wireshark


Grüße,
dapfe

 

[dapfe]

ich nochmal, ich habe es jetzt hinbekommen tcpdump auf der Syno auszuführen und mit Wireshark auszulesen. Im Screenshot ist der Auszug wo ich probiere die Syno lokal per 192.168.1.100 aufzurufen.

Anhang anzeigen 25414

Lässt sich dadurch was ableiten?

grüße,
dapfe

 

[fpo4711]

Soviel ich das erkennen kann, (und das läßt sich grauenvoll lesen) kommt vom VPN z.Bsp. ein TCP-ACK aber keine Antwot. Genauso beim Ping ICMP. Scheint also so als wenn die DS unter der 192.168.1.100 nicht antwortet.

Deshalb nochmals zur Sicherheit. Irgendwelche speziellen Konfigurationen oder Pakete am Start?

Sieht so aus als wenn hier was blockiert wird. Weis nicht wie weit Du mit Regeln für iptables klar kommst, aber ohne aktivierte Firewall und Betrieb des OpenVPN-Servers sollte das bei folgenden Befehlen so aussehen:

>iptables --list

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source

> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere

Also alles leer bis auf das MASQUERADE im POSTROUTING. Das wird automatisch vom VPN-Server beim Start von OpenVPN angelegt.

Gruß Frank

 

[jahlives]

bitte nach Möglichkeit keine Bilder posten oder wenn dann grösser ;-)
Ist die 10.8.0.6 dein PC, der die DS erreichen will? Oder wem gehört diese IP? Falls dies die OVPN IP deines PCs ist, steht der denn im selben Subnetz wie die DS (192.168.1.0/24)?
Mach bitte Filter auf die Captures und hol nur icmp raus, alles andere interessiert erstmal nicht. Bei tcpdump geht das sehr einfach

tcpdump -i INTERFACE icmp and host IP_DES_SYSTEMS_DAS_DEN_PING_SCHICKT

beim whireshark kann man auch solche Filter machen (über die Expression)
Schwarz ist auf jeden Fall schlecht, weil das Retransmissions sind. Sprich eine erwartete Antwort bleibt aus, darum wird das Paket nochmals gesendet.
Wichtig wäre noch: das System (Client), das via VPN ein anderes erreichen will darf (Server) sich nicht im selben LAN Subnetz befinden wie der Server. Sonst sind Routingprobleme vorprogrammiert

 

[fpo4711]

Hi jahlives,

schön das mal ein Fachmann hier ist Ich seh den Wald vor Bäumen vieleicht nicht. Subnetze waren wie oben angegeben eigentlich in Ordnung. Oder ich hab auf Grund von geistiger Hitzelähmung was übersehen.

Gruß Frank

 

[jahlives]

wollte nur sicher (nochmals) sicher sein, dass sich der Client aktuell nicht im selben Netz befindet. Denn wieso sollte ein Client den Taffic an eine IP in seinem aktuellen Subnetz überhaupt via VPN Tunnel schicken?
Mich hat stutzig gemacht, dass er scheinbar den Router erreichen kann. Wenn man dann einen Client im selben Subnetz wie den Router nicht erreichen kann, dann deutet das m.E. nach darauf hin, dass der Client keine Route für das Sourcenetz der Anfrage hat und damit den Traffic via Router (default GW) schickt. Selbst wenn der Router dann eine korrekte Route für das Netz hat (und das hat er scheinbar, sonst könnte er auch nicht auf Anfragen aus dem VPN antworten) wird das ganze dann asymmetrisch. Der VPN Server (DS) schickt die Anfrage direkt an den Client, der hat aber dann keine Route für das Sub und geht daher via default GW zurück.

Ein weiteres Problem wenn man den VPN Server unter seiner LAN IP ansprechen will, können die reverse path filter des Kernels sein.
**offtopic**
ich versteh Synology echt nicht. Viele solche Probleme mit OVPN würde man sofort los wenn man endlich die OVPN Topologie auf subnet ändern würde. Dieses zwischengeschaltete NAT gibt immer mehr Probleme als Nutzen. Das reagiert teils sehr allergisch auf asymmetrische Geschichten. Zudem wäre es ohne NAT deutlich performanter
**/offtopic**

 

[dapfe]

erstmal sorry wegen den Bilder. Dachte er vergrößert diese beim anklicken. Ab sofort nur noch Text

@fpo4711:

Pakte sind außer Plex, Download Station, Photo Station und VPN-Server keine installiert. Firewall etc sind unverändert, ein einzigen statische Route habe ich gelegt:
(192.168.116.0 255.255.255.0 192.168.101.1 LAN2)


Also iptables --list sieht bei mir genauso aus, bis auf einen kleinen Unterschied (das letze destination):

Syno> iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Bei iptables -t nat -L sind die letzen beide Einträge unterschiedlich.

Syno> iptables -t nat -L


Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
DEFAULT_POSTROUTING  all  --  anywhere             anywhere

Chain DEFAULT_POSTROUTING (1 references)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere

@jahlives
Danke für den Tipp mit tcpdump. War das erst mal das ich es verwendet habe.
10.8.0.6 ist der Client der auf die Syno zugreifen wollte. Die Subnetze in meinen Netzwerken sind alle unterschiedlich. Den tcpdump habe ich erstellt als ich von meinem iPhone zugegriffen haben (WLAN aus), er hat also nur die öffentliche IP des Providers. (Es funktioniert aber auch nicht mit OpenVPN auf Win8 im Firmenlan (ebenfalls unterschiedliches Subnetz (192.168.116.0)).

Hier nochmal den tcpdump mit Filter auf den Client und ICMP

"No.","Time","Source","Destination","Protocol","Length","Info"
"1","0.000000","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=0/0, ttl=64"
"2","3.004437","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=1/256, ttl=64"
"3","7.134507","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=2/512, ttl=64"
"4","11.054970","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=3/768, ttl=64"
"5","15.828218","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=4/1024, ttl=64"
"6","20.104127","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=5/1280, ttl=64"
"7","22.053328","192.168.1.100","10.8.0.10","ICMP","98","Echo (ping) reply    id=0x3c13, seq=6/1536, ttl=64"

Übrigens erreiche ich nicht nur den Router, sonder auch meine anderen Netzwerkgeräte im lokalen Netz (192.168.1.*). Nur die Syno eben nicht.

Grüße,
dapfe

 

[jahlives]

aber auf der OVPN IP Adresse kannst du die DS pingen? Ich würde dann auf ein Problem mit dem NAT tippen, denn durch die NAT Übersetzung entsteht bei einem solchen Ping Pakete wohl eines wo SRC und DST gleich sind und das kommt selten gut. Probier mal ob du die Pakete an die LAN Schnittstelle der DS vom NAT ausnehmen kannst.

iptables -t nat -F
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 ! -d LAN_IP_DER_DS -j MASQUERADE

mit obiger NAT Regel sollten die Pakete welche aus dem OVPN kommen und für die LAN_IP_DER_DS sind nicht genatted werden.
Probier mal ob das was ändert

 

[dapfe]

Hallo,
so habe die NAT Regel geändert und nach dem Neustart der Syno funktioniert es nun!
Vielen Dank an Euch! Endlich keine IPs mehr ändern

Jedoch frage ich mich, warum dies manuell geändert werden musste..

Grüße,
dapfe

 

[jahlives]

wenn diese Regel nach dem Reboot immer noch drin ist, dann ist die Antwort auf deine Frage recht einfach: NAT ist sch***** Routing ist viel besser