Site2Site VPN mit OpenVPN. Kein Zugriff von Clientnetzwerk in Richtung Servernetzwerk

Hallo zusammen,

ich bin gerade ziemlich mit meinem Latein am Ende und würde mich bezüglich der Verbindung zweier Netze mittels OpenVPN über Euren Rat/Tipp freuen. Ich habe mich diesbezüglich hier und in anderen Foren schon umgeschaut, aber keine der dortigen Tipps konnte mir weiterhelfen. Bspw. die Anleitung von Jan Karres (https://jankarres.de/2013/05/raspberry-pi-openvpn-vpn-server-installiere ..) oder die Tipps im OpenVPN Forum https://openvpn.net/vpn-server-resources/site-to-site-routing-explained- ... bzw. https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-t ....

Da es sich um ein privates Problem handelt, bin ich nicht böse, falls sich hier keine Lösung finden lassen sollte. Zum folgenden Fließtext habe ich einen grafischen Netzwerkplan beigefügt, um die Netzwerkstruktur einfacher darzustellen.

Ich fange einfach mal mit der Problembeschreibung an:

Den OpenVPN-Server betreibe ich auf einem Raspberry-PI mit aktiviertem Routing hinter einer FritzBox.

Netzwerk "Server": 172.16.0.0/16  
Fritz-Box im Server-Netzer: 172.16.0.254/16
RPI im OpenVPN-Server-Netz: 172.16.0.40/16 
RPI im OpenVPN-Netz: 10.9.0.1/24

Den OpenVPN-Client betreibe ich ebenfalls auf einem Rasberry-PI mit aktiviertem Routing hinter zwei Fritz-Boxen.

Netzwerk mit Internet-Zugang: 192.168.178.0/24
Fritz-Box mit Internet-Zugang: 192.168.178.1/24
Netzwerk mit RPi-Client: 192.168.188.0/24
Fritz-Box im Netz mit RPi-Client (als WLAN-Client 192.168.178.24/24 mit FritzBox 192.168.178.1 verbunden): 192.168.188.1/24
RPI im OpenVPN-Client-Netz: 192.168.168.25/24 
RPI im OpenVPN-Netz: 10.9.0.2/24

Mein Problem ist, dass ich aus dem Client-Netz (192.168.188.0/24) alle Rechner im Server-Netz (172.16.0.0/16) erreichen kann. Aus dem Server-Netz (172.16.0.0/24) kann ich aber weder den VPN-Client (192.168.188.25/24 oder 10.9.0.2/24) noch sein dahinterliegendes Netz (192.168.188.0/24) erreichen. Dafür ist jedoch ein Zugriff vom VPN-Server selbst (172.16.0.40 bzw. 10.9.0.1) auf das komplette Client-Netzwerk möglich. Es funktioniert also nur nicht von den Clients im Server-Netz in Richtung Client-Netz.

Würde mich über einen Tipp zur Fehlerbehebung freuen

. Ich vermute, dass es mit dem Routing bzw. den IPTABLES-Einstellungen auf dem VPN-Server zusammenhängt.

Anbei die Routen auf dem Server:

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
10.9.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
192.168.188.0   10.9.0.2        255.255.255.0   UG    0      0        0 tun0

und auf dem Client:

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    202    0        0 eth0
10.9.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.16.0.0      10.9.0.1        255.255.0.0     UG    0      0        0 tun0
192.168.188.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0 

Auf der Fritz-Box im Server-Netz (172.16.0.254) sind folgende manuelle Routen gesetzt:

Ziel: 192.168.188.0 Netmask: 255.255.255.0 Gateway 172.16.0.40
Ziel: 10.9.0.0 Netmask 255.255.255.0 Gateway 172.16.0.40

Auf der Fritz-Box (192.168.188.1) im Client-Netz sind es folgende Routen:

Ziel: 172.16.0.40 Netmask: 255.255.0.0 Gateway 192.168.188.25
Ziel: 10.9.0.0 Netmask 255.255.255.0 Gateway 192.168.188.25

Auf der Fritz-Box mit Internet-Zugang (192.168.178.1) auf Client-Seite sind keine speziellen Routen gesetzt.

Hier noch ein

tcpdump -eni any icmp

wenn ich von einem Client im Server-Netz ins Client-Netz pinge.

Auf dem VPN-Server:

pi@pi:~ $ sudo tcpdump -eni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:07:09.260488  In c8:0e:14:9d:17:8a ethertype IPv4 (0x0800), length 76: 172.16.0.31 > 192.168.188.1: ICMP echo request, id 1, seq 4490, length 40
15:07:14.057269  In c8:0e:14:9d:17:8a ethertype IPv4 (0x0800), length 76: 172.16.0.31 > 192.168.188.1: ICMP echo request, id 1, seq 4491, length 40
15:07:19.058940  In c8:0e:14:9d:17:8a ethertype IPv4 (0x0800), length 76: 172.16.0.31 > 192.168.188.1: ICMP echo request, id 1, seq 4492, length 40
15:07:24.054670  In c8:0e:14:9d:17:8a ethertype IPv4 (0x0800), length 76: 172.16.0.31 > 192.168.188.1: ICMP echo request, id 1, seq 4493, length 40

Auf dem VPN-Client: Nichts

 pi@pipi:~ $ sudo tcpdump -eni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

Hier noch ein Traceroute vom Client im Servernetz ins Client-Netz:

C:\Windows\System32>tracert 192.168.188.1

Routenverfolgung zu 192.168.188.1 über maximal 30 Hops

   3 ms     2 ms     4 ms  fritz.box [172.16.0.254]
   2 ms     2 ms     3 ms  pi.fritz.box [172.16.0.40]
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *     ^C

und noch ein erfolgreiches Traceroute vom VPN-Server ins Client-Netz:

pi@pi:~ $ pi@pi:~ $ traceroute 192.168.188.1
traceroute to 192.168.188.1 (192.168.188.1), 30 hops max, 60 byte packets
 1  10.9.0.2 (10.9.0.2)  27.892 ms  27.829 ms  27.765 ms
 2  192.168.188.1 (192.168.188.1)  27.803 ms  27.818 ms  27.835 ms
pi@pi:~ $

Abschließend noch meine OVPN-Configs:

========SERVER=======
dev tun0
proto udp
port 1194
management localhost 5555
push "topology subnet"  
topology subnet

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
client-config-dir /etc/openvpn/client
ifconfig-pool-persist ipp.txt
key-direction 0

server 10.9.0.0 255.255.255.0
push "dhcp-option DNS 172.16.0.254"  
route 192.168.188.0 255.255.255.0 
push "route 192.168.188.0 255.255.255.0"  
push "route 172.16.0.0 255.255.0.0"  

push "explicit-exit-notify 3"  
log-append /var/log/openvpn
persist-key
persist-tun
user nobody
group nogroup
;status /var/log/openvpn-status.log
verb 3
client-to-client
comp-lzo
script-security 2
client-connect /etc/openvpn/easy-rsa/startup/openvpn_connect.sh
========/SERVER=======

========CCD=======
iroute 192.168.188.0 255.255.255.0
========/CCD=======

========Client=======
dev tun
client
proto udp
remote irgendwas.dyndns.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
<ca>
</ca>
<cert>
</cert>
<key>
</key>
key-direction 1
<tls-auth>
</tls-auth>
========/Client=======

Update: Vielen Dank für Eure Unterstützung und die privaten Mitteilungen. Die eigentliche Ursache ist zwar nicht gelöst, aber umgangen. Ich habe jetzt ein VPN zwischen den beiden Fritz-Boxen eingerichtet.