12
OpenVPN Site-to-Site Tunnel routet nicht richtig
Hallo zusammen,
ich will zwischen zwei Netzwerken per OpenVPN einen Tunnel einrichten. Die Netzwerke sollen so verbunden sein, dass ich von jedem Client im Netzwerk jeden anderen Client im anderen Netzwerk erreichen kann.
Die beiden Netzwerke hängen hinter einem Router am Internet. Ich habe jetzt in beiden Netzwerken ein Debian aufgesetzt welche den Tunnel aufbauen.
Topologie
Netz-A:
192.168.16.0/24
GW: 192.168.16.254
OpenVPN Server: 192.168.16.24/Tunnel IP 10.8.0.1
Netz-B:
192.168.18.0/24
GW: 192.168.18.254
OpenVPN Server: 192.168.18.10/Tunnel IP 10.8.0.6
Der Tunnel baut sich auf, ohne Fehler.
Ping von VPN Server zu Client auf 10.8.0.6: OK
Ping von VPN Client zu Server auf 10.8.0.1 OK
Ping von VPN Server zu Client auf 192.168.18.10 Timeout
Ping von VPN Client zu Server auf 192.168.16.24 OK
Ping von Clients Netz A zu Netz B Timeout
Ping von Clients Netz B zu Netz A OK
root@OpenVPN-Server:~# iptables -L -t nat
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 -- localnet/24 anywhere
MASQUERADE all -- 192.168.18.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
root@openvpn-Client:~# iptables -L -t nat
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 -- localnet/24 anywhere
MASQUERADE all -- 192.168.16.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
root@OpenVPN-Server:~# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default gw 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 * 255.255.255.255 UH 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
192.168.18.0 * 255.255.255.0 U 0 0 0 tun0
root@openvpn-Client:~# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.16.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
Ich weiß nicht ob Ihr zum helfen noch mehr Infos braucht. Ich bin langsam mit meinen Ideen am Ende und weiß nicht mehr weiter.
Bitte helft mir. Bin für jeden Tipp Dankbar!
ich will zwischen zwei Netzwerken per OpenVPN einen Tunnel einrichten. Die Netzwerke sollen so verbunden sein, dass ich von jedem Client im Netzwerk jeden anderen Client im anderen Netzwerk erreichen kann.
Die beiden Netzwerke hängen hinter einem Router am Internet. Ich habe jetzt in beiden Netzwerken ein Debian aufgesetzt welche den Tunnel aufbauen.
Topologie
Netz-A:
192.168.16.0/24
GW: 192.168.16.254
OpenVPN Server: 192.168.16.24/Tunnel IP 10.8.0.1
Netz-B:
192.168.18.0/24
GW: 192.168.18.254
OpenVPN Server: 192.168.18.10/Tunnel IP 10.8.0.6
Der Tunnel baut sich auf, ohne Fehler.
Ping von VPN Server zu Client auf 10.8.0.6: OK
Ping von VPN Client zu Server auf 10.8.0.1 OK
Ping von VPN Server zu Client auf 192.168.18.10 Timeout
Ping von VPN Client zu Server auf 192.168.16.24 OK
Ping von Clients Netz A zu Netz B Timeout
Ping von Clients Netz B zu Netz A OK
root@OpenVPN-Server:~# iptables -L -t nat
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 -- localnet/24 anywhere
MASQUERADE all -- 192.168.18.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
root@openvpn-Client:~# iptables -L -t nat
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 -- localnet/24 anywhere
MASQUERADE all -- 192.168.16.0/24 anywhere
MASQUERADE all -- 10.8.0.0/24 anywhere
root@OpenVPN-Server:~# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default gw 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 * 255.255.255.255 UH 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
192.168.18.0 * 255.255.255.0 U 0 0 0 tun0
root@openvpn-Client:~# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.16.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
localnet * 255.255.255.0 U 0 0 0 eth0
Ich weiß nicht ob Ihr zum helfen noch mehr Infos braucht. Ich bin langsam mit meinen Ideen am Ende und weiß nicht mehr weiter.
Bitte helft mir. Bin für jeden Tipp Dankbar!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 271656
Url: https://administrator.de/contentid/271656
Printed on: April 18, 2024 at 04:04 o'clock
12 Comments
Latest comment
Hi DerNano,
Sicher hast Du den Fehler begangen und in Deiner Server.conf den Eintrag "client-to-client" stehen.
Ausserdem solltest Du eine CCD (Client-Config-Directory)anlegen.
Der OpenVPN-Server sollte die 10.8.0.1, der Client die 10.8.0.2 haben, dann klappt's auch mit dem Routing.
Gruß orcape
Ich weiß nicht ob Ihr zum helfen noch mehr Infos braucht.
Server- und Client.config wären angebracht.Sicher hast Du den Fehler begangen und in Deiner Server.conf den Eintrag "client-to-client" stehen.
Ausserdem solltest Du eine CCD (Client-Config-Directory)anlegen.
Der OpenVPN-Server sollte die 10.8.0.1, der Client die 10.8.0.2 haben, dann klappt's auch mit dem Routing.
Gruß orcape
Habe deinen Rat beherzigt und mal eben die CCD angelegt. Der Client bekommt jetzt auch die 10.8.0.2. Gleiches Problem wie vorher leider. 
Hier die Client.conf
client
ca /root/certs/ca.crt
cert /root/certs/client.crt
key /root/certs/client.key
remote **.de 1194
dev tun
cipher AES-256-CBC
comp-lzo
pull
und dann noch mal die Server.conf
#Server
port 1194
proto udp
dev tun
ca /root/certs/ca.crt
cert /root/certs/server.crt
key /root/certs/server.key
dh /root/certs/dh2048.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.16.0 255.255.255.0"
route 192.168.18.0 255.255.255.0
cipher AES-256-CBC
comp-lzo
keepalive 10 120
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd/
verb 3
CCD
ifconfig-push 10.8.0.2 255.255.255.0
Hat noch jemand Ideen?
Danke und Gruß
DerNano
Hier die Client.conf
client
ca /root/certs/ca.crt
cert /root/certs/client.crt
key /root/certs/client.key
remote **.de 1194
dev tun
cipher AES-256-CBC
comp-lzo
pull
und dann noch mal die Server.conf
#Server
port 1194
proto udp
dev tun
ca /root/certs/ca.crt
cert /root/certs/server.crt
key /root/certs/server.key
dh /root/certs/dh2048.pem
server 10.8.0.0 255.255.255.0
push "route 192.168.16.0 255.255.255.0"
route 192.168.18.0 255.255.255.0
cipher AES-256-CBC
comp-lzo
keepalive 10 120
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd/
verb 3
CCD
ifconfig-push 10.8.0.2 255.255.255.0
Hat noch jemand Ideen?
Danke und Gruß
DerNano
Hallo DerNano,
die Rechner in den Netzen haben ein Standardgateway. Auf diesem muss die jeweilige RückRoute zum VPN-Server eingetragen sein.
vG
LS
die Rechner in den Netzen haben ein Standardgateway. Auf diesem muss die jeweilige RückRoute zum VPN-Server eingetragen sein.
vG
LS
Hallo laster,
auf beiden Gateways ist die Route zum OpenVPN Server/ Client eingetragen. Und selbst wenn müsste ich ja vom VPN-Server den VPN-Client pingen können, da ja mindestens der die Route kennt.
auf beiden Gateways ist die Route zum OpenVPN Server/ Client eingetragen. Und selbst wenn müsste ich ja vom VPN-Server den VPN-Client pingen können, da ja mindestens der die Route kennt.
Also, damit der VPN-Client den VPN-Server anpingen kann, brauchst Du ja nur auf dem Client die Route für den VPN-Tunnel.
Der Server routet automatisch, weil er beide Netze kennt (VPN und LAN).
Wie Du schreibst, funktioniert ja die Verbindung vom Client zum Server über den Tunnel - OK.
Wenn Du weiter willst (als nur zum Server, also zu anderen Clients im Netz des Servers) muss das Routing auf dem Server bzw. im Netz funktionieren.
Das musst Du überprüfen...
vG
LS
Der Server routet automatisch, weil er beide Netze kennt (VPN und LAN).
Wie Du schreibst, funktioniert ja die Verbindung vom Client zum Server über den Tunnel - OK.
Wenn Du weiter willst (als nur zum Server, also zu anderen Clients im Netz des Servers) muss das Routing auf dem Server bzw. im Netz funktionieren.
Das musst Du überprüfen...
vG
LS
Ich habe jetzt (nicht dass ich das das erste Mal gemacht hätte, aber sicher ist sicher :D) ein tracert von einem Client im Netz A als auch aus Netz B auf einen Server im jeweils anderen Netz geschickt.
Aus Netz B geht der tracert nach einander auf GW --> VPN-Client --> VPN-Server --> Server in Netz A.
Mache ich das ganze aus Netz A in Richtung Netz B dann kommt GW --> VPN-Server --> Zeitüberschreitung der Anforderung --> Zeitüberschreitung der Anforderung.
Das ganze läuft dann in Schleife.
Was mir Sorgen macht ist, dass ich selbst vom Server selbst keinen Ping auf die 192.168.18.10 machen kann. Die hängt ja direkt hinter dem Client. Der müsste die nur weiter routen.
Ich habe mal mit Wireshark auf VPN-Server (links) und VPN-Client (rechts) den verkehr mit geschnitten. Nur leider sagt mir das nicht wo der Fehler liegt.
https://dl.dropboxusercontent.com/u/72821109/wireshark.jpg
Aus Netz B geht der tracert nach einander auf GW --> VPN-Client --> VPN-Server --> Server in Netz A.
Mache ich das ganze aus Netz A in Richtung Netz B dann kommt GW --> VPN-Server --> Zeitüberschreitung der Anforderung --> Zeitüberschreitung der Anforderung.
Das ganze läuft dann in Schleife.
Was mir Sorgen macht ist, dass ich selbst vom Server selbst keinen Ping auf die 192.168.18.10 machen kann. Die hängt ja direkt hinter dem Client. Der müsste die nur weiter routen.
Ich habe mal mit Wireshark auf VPN-Server (links) und VPN-Client (rechts) den verkehr mit geschnitten. Nur leider sagt mir das nicht wo der Fehler liegt.
https://dl.dropboxusercontent.com/u/72821109/wireshark.jpg
Das Tutorial zu dem Thema hast du gelesen ?
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
In die CCD noch das Komando...
iroute 192.168.18.0 255.255.255.0
Kommst du denn per ssh auf den OpenVPN-Client (10.8.0.2) ?
iroute 192.168.18.0 255.255.255.0
Kommst du denn per ssh auf den OpenVPN-Client (10.8.0.2) ?
Hallo Zusammen, vielen Dank an alle für die Hilfe. Es geht jetzt.
Ich weiß es nicht genau, aber seitdem ich "iroute 192.168.18.0 255.255.255.0" in die CCD gepackt hatte ging es. Evtl auch weil ich vorher noch einmal die Iptables mit folgendem aus aqui's Link verbessert habe.
iptables -N VPN
iptables -F VPN
iptables -A VPN -i tun0 -o eth0 -j ACCEPT
iptables -I INPUT -i tun0 -j VPN
iptables -I FORWARD -i tun0 -j VPN
iptables -I POSTROUTING -t nat -o tun0 -j RETURN
Danke, ich bin jetzt Glücklich!
Ich weiß es nicht genau, aber seitdem ich "iroute 192.168.18.0 255.255.255.0" in die CCD gepackt hatte ging es. Evtl auch weil ich vorher noch einmal die Iptables mit folgendem aus aqui's Link verbessert habe.
iptables -N VPN
iptables -F VPN
iptables -A VPN -i tun0 -o eth0 -j ACCEPT
iptables -I INPUT -i tun0 -j VPN
iptables -I FORWARD -i tun0 -j VPN
iptables -I POSTROUTING -t nat -o tun0 -j RETURN
Danke, ich bin jetzt Glücklich!
Wenn Du die Firewall aktiviert hast, musst Du natürlich den Tunnel auf das LAN freigeben.
Schön das es klappt.
Gruß orcape
Schön das es klappt.
Gruß orcape
Ne, die war eben nicht aktiviert. Hatte nach den IPTables Änderungen keinen Erfolg. Erst nach dem iroute + Neustart Client + Server ging's. Aber bin mir nicht sicher ob es nicht doch was mit den IPTables zu tun hatte.
Ohne den Eintrag in der CCD hast Du jedenfalls keine Chance direkt zu verbinden.
Da kommst Du nur auf das Tunnelende und von da ins remote LAN und das ist ja nicht Dein Ziel
Da kommst Du nur auf das Tunnelende und von da ins remote LAN und das ist ja nicht Dein Ziel
