OpenVPN - DS (Server) hat keinen Zugriff aufs Client-Netzwerk

[Simiii]

Ich kann über über meine Diskstation (OpenVPN-Server) nicht das gegenüberliegende Netzwerk mit den richtigen IP-Adressen erreichen.

Folgende Konstellation:

Netz A: 192.168.174.0/24 - Diskstation als OpenVPN-Server hinter FritzBox
Netz B: 192.168.178.0/24 - Raspberry-Pi als OpenVPN-Client hinter FritzBox

OpenVPN-Server Config:

push "route 192.168.174.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
dev tun

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0


dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.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 3
#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

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher BF-CBC
auth SHA1

route 192.168.178.0 255.255.255.0
client-config-dir ccd
client-to-client
~

Überschreiben der CCD-Files ist in radiusplugin.cnf deaktiviert.

CCD-File:

iroute 192.168.178.0 255.255.255.0

OpenVPN-Client Config

dev tun
tls-client

remote name.synology.me 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 def1

# 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

# If you want to connect by Server's IPv6 address, you should use
# "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode
proto udp

script-security 2
keepalive 10 60

comp-lzo

reneg-sec 0
link-mtu 1432
cipher BF-CBC

auth SHA1
ca /etc/openvpn/Zert.crt
auth-user-pass /etc/openvpn/auth.txt
<ca>

net.ipv4.ip_forward=1 ist auf Raspberry Pi natürlich gesetzt.

Routen sind in beiden FritzBoxen eingetragen.

FritzBox Netz A:
192.168.178.0 (Entferntes Netz)
255.255.255.0
192.168.174.19 (Gateway - Diskstation)

FritzBox Netz B:
192.168.174.0 (Entferntes Netz)
255.255.255.0
192.168.178.38 (Gateway - Raspberry Pi)

Also von Netz B (Client) kann ich ohne Probleme auf Netz A (Server) über die normalen IP-Adressen zugreifen. Mit allen Endgeräten und auch direkt von der Raspberry Pi.
Von Netz A kann ich mit allen Endgeräten (außer der Diskstation selbst) auf Netz B zugreifen. Und genau das möchte ich. Irgendwo habe ich noch einen Denkfehler.

Ich will eine IP-Cam aus dem Clienten-Netzwerk mit meiner Diskstation anzapfen.

Route auf Diskstation

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.174.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.178.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0

Die Diskstation kennt anscheint intern die Route zum Clienten-Netzwerk nicht. Für alle anderen Geräte im Server-Netzwerk laufen die Routen.

Was mache ich falsch?

Vielen Dank

 

[jahlives]

ich vermute mal es könnte daran liegen die DS sich mit ihrer OVPN IP als Source verbindet. Hast das entfernte Natz dafür auch Routen?

 

[Simiii]

Ich habe nochmal mir die hinterlegten Routen auf der Raspberry Pi angeschaut.

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 202 0 0 eth0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.174.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
192.168.178.0 * 255.255.255.0 U 202 0 0 eth0

Sollte doch so funktionieren oder fehlt noch eine Route?

Wie gesagt aus dem Client-Netz kann ich mit allen Geräten inkl. der Raspberry Pi alle Geräte im Server-Netz erreichen.

 

[jahlives]

woher wissen denn die Clients im entfernten Netz, dass die das 10.8.0.X Netz über den Raspi als Gateway routen müssen? Kann es sein, dass die Clients dort ihre Antworten an ihren default Gateway schicken?
Probier mal von der DS aus mit dem traceroute Kommando zu gucken wie weit deine Pakete kommen

traceroute IP_EINES_CLIENTS_IM_ENTFERNTEN_NETZ

irgendwo werden die Antworten aufhören: dort müsste man dann als erstes gucken

 

[Simiii]

traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *

Die Disktation routet die eigenen Pakete erst garnicht über den Tunnel.

Komischerweise können das aber alle Netzwerkgeräte hinter der Diskstation in Richtung des Clienten-Netzwerks (Raspberry Pi).

 

[jahlives]

klingt irgendwie danach als ob das iroute nicht ziehen würde. Sonst müsste mindestens ein Hop (Raspi) auftauchen. Dein ccd File heisst genauso wie der CommonName des Raspi resp in deinem Fall wie der Username mit dem sich der Raspi beim OVPN der DS anmeldet?

 

[Simiii]

Username im CCD-Ordner passt.

iroute 192.168.178.0 255.255.255.0

Wenn das nicht passen würde, hätten doch die anderen Netzwerkgeräte im Servernetz der Diskstation Probleme ihre Pakete durchzubekommen oder nicht?

Traceroute von einem Netzwerkgerät im Servernetzwerk ins entfernte Client-Netzwerk

traceroute to 192.168.178.1 (192.168.178.1), 64 hops max, 52 byte packets
1 fritz.box (192.168.174.1) 10.416 ms 5.270 ms 5.327 ms
2 192.168.174.19 (192.168.174.19) 6.898 ms 7.998 ms 4.613 ms
3 10.8.0.6 (10.8.0.6) 55.122 ms 46.356 ms 52.741 ms
4 192.168.178.1 (192.168.178.1) 61.918 ms 79.667 ms 57.568 ms

 

[jahlives]

ja dann hätten die anderen Geräte wohl auch Probleme, das stimmt
Du kannst die OVPN IP des Raspi problemlos pingen von der DS aus? Mal auf dem Raspi den tcpdump auf dem tun Interface angeworfen und von der DS aus pings geschickt? Dabei würde ich erst die OVPN IP des Raspi und dann seine LAN IP be-pingen während der tcpdump läuft z.B.

tcpdump -i tun0 -n icmp

 

[Simiii]

Ich hab das gerade mal gemacht. Es kommt etwas an der Pi.

14:38:21.983774 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 1, length 64
14:38:22.989104 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 2, length 64
14:38:23.988685 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 3, length 64
14:38:24.988888 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 4, length 64
14:38:25.988869 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 5, length 64
14:38:26.988717 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 6, length 64
14:38:27.988775 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 7, length 64
14:38:28.989246 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 8, length 64
14:38:29.989382 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 9, length 64
14:38:30.988947 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 12278, seq 10, length 64
14:38:33.258596 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68
14:38:33.258874 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68
14:38:36.258554 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68
14:38:36.258819 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68
14:38:36.259060 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68
14:38:39.298611 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68

Wodran könnte das liegen?

 

[jahlives]

wer ist die 10.8.0.6?

 

[Simiii]

10.8.0.6 ist der Client also die Pi.

 

[jahlives]

hm also oben routest du das entfernte Netz aber auf 10.8.0.2

1 fritz.box (192.168.174.1) 10.416 ms 5.270 ms 5.327 ms

und das ist nicht wirklich ideal.
Ein solches Routingkonstrukt wird sehr schnell asymetrisch: der Client 174.4 will das entfernte 178.X erreichen. Hat keine Route und geht dann über den default GW. Dieser hat wiederum eine Route für das 178.x via LAN IP der DS. Soweit so gut. Problematisch (kann) das bei der Antwort werden. Weil da kommt ein Paket für 174.4 über OVPN bei der DS an. Wieso sollte die DS das wieder an die Fritte senden? Das Ziel liegt ja im eigenen Subnetz und kann via ARP direkt angesprochen werden. Damit es aber symetrisch bliebe müsste die Antwort wieder erst an die Fritte gehen und von dort zum Client.
Je nach verwendetem Protokoll kann das massive Probleme geben (z.B. unerklärliche Verbindungsabbrüche, eingefrorene SSH Sessions). ICMP und udp Protokolle sind weniger anfällig auf solche Konstrukte, aber mit TCP wirst du damit über kurz oder lang in Probleme laufen.
Du hast eigentlich nur zwei Möglichkeiten: entweder jedem Client Routen für die entfernten Netze via DS resp Raspi eintragen oder die OVPN Dienste auf die Router (default Gateways)

Eigenntlich gäbe es noch diese Möglichkeit: der Router macht bei Paketen für das entfernte LAN ein SNAT (Source nat) und ersetzt die IP des Clients 174.4 mit seiner eigenen.
Dann wäre auch sichergestellt, dass Antworten auf dem exakt gleichen Pfad hereinkommen wie die Anfragen raus sind

 

[Simiii]

Also in einem anderen Fall habe ich es schonmal ohne Probleme hinbekommen.

Auf der IP Kamera kann ich natürlich keine Routen definieren.

Kann ich Source NAT irgendwie auf einer FritzBox einrichten?

Vom Clienten-Netz zum Server-Netz geht das ja ohne Probleme mit allen Geräten.

 

[jahlives]

Es ist ja das Fiese daran, dass es für den Moment und je nach Protokoll geht. Versuch mal eine ssh Session für ein paar Stunden oben zu halten. Irgendwann friert die ein.

Hintergrund: bei TCP wird der Client sein syn Paket an den Router schicken. Der speichert das Ereignis in seinen Tabellen, damit er ein syn/ack Paket (Antwort) einer Anfrage zuordnen kann.
Ein netter Router wird dem Client via icmp mitteilen, dass er das Netz "direkter" erreichen kann wenn er direkt mit der LAN IP der DS redet. Diese Info speichert sich der Client eine gewisse Zeit. Soweit so gut
Diese Zeit läuft aber irgendwann ab und das nächste Paket des Clients landet wieder beim Router. Dessen Timer für das syn/ack Paket ist aber abgelaufen und er kann dieses Paket keiner Verbindung mehr zuordnen und verwirft es. Der Client muss wieder eine neue TCP Verbindung aufbauen und jetzt knallt es je nach Protokoll heftig oder eben nicht icmp und udp sind hierbei unproblematisch.
tcp hingegen nur dann wenn es sich um Protokolle mit nicht dauerhaften Verbindungen handelt z.B. http(s) oder smtp ...
Protokolle die tcp Verbindungen offenhalten z.B. ssh fliegen hingegen böse auf die Nase

So genug Grundsätzlich könntest du Routen auch als dhcp Option an die Clients pushen. Bieten leider die wenigster Homerouter in ihren GUI.
Bei Kamerastreams, welche meist über udp laufen kommt diese Problematik eh wenig zum Tragen. Schlimmstenfalls ein paar Sekunden kein Bild.
Jeder Router kann (s)nat Die Frage ist eher ob man es via GUI konfigurieren kann und das weiss ich für Fritten ned

 

[Simiii]

Hätte ich noch eine andere Chance die Verbindung zwischen Diskstation (192.168.174.19) und der IP-Kamera (192.168.178.17) hinzubekommen?

Kleine Aussetzer wären bei der IP-Cam verschmerzbar.

Könnte ich die Route irgendwie auf der Pi oder der Diskstation nochmal gezielt hinterlegen? mit route add oder so?

 

[jahlives]

Das Problem, dass die Verbindung von der DS zur Cam nicht geht hat wohl nichts mit dem von mir beschriebenen Problem zu tun
Gemäss dem tcpdump schickt der Pi ein Destination unreachable an die DS zurück, wenn Pakete für die Cam kommen. Hat die Pi irgendwelche Firewallregeln v.a. in der FORWARD Chain?

 

[Simiii]

iptables -L auf Pi

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

In Ordnung?

14:38:33.258596 IP 10.8.0.6 > 10.8.0.1: ICMP host 192.168.178.17 unreachable, length 68

Das ist die DS Station, die die schon vorkonfigurierte IP-Cam sucht.

Einmal ein Vergleich

Ping von Netzwerkgeräten hinter DS zu IP CAM:

18:50:57.840492 IP 192.168.174.38 > 192.168.178.17: ICMP echo request, id 19206, seq 10, length 64
18:50:57.849378 IP 192.168.178.17 > 192.168.174.38: ICMP echo reply, id 19206, seq 10, length 64

Ping von DS zu IP CAM:

8:51:11.230642 IP 10.8.0.1 > 192.168.178.1: ICMP echo request, id 21488, seq 1, length 64

Die FritzBox an der Pi weiß ja nicht wo 10.8.0.1 ist. Sollte ich für dieses Netz nochmal eine extra Route zu diesem Netz an der FritzBox mit dem Gateway über die Pi anlegen?

 

[jahlives]

FW sollte so passen. Mal den tcpdump auf dem Pi am LAN Interface nach icmp lauschen lassen? Dann von der DS die Cam pingen.
Allenfalls könnte es helfen auf dem Pi ein nat zu machen und als src Adresse die LAN des pi angeben

iptables -t nat -I POSTROUTING -o ethX -s OVPN_IP_DS -d LAN_IP_CAM -j SNAT --to LAN_IP_PI

dabei ethX mit dem LAN Interface des Pi ersetzten

 

[Simiii]

Genau das habe ich gesucht.

Es funktioniert nun. Vielen vielen Dank für deine Mühe!