11
OpenVPN Site-to-Site Tunnel Routing Problem
Hallo zusammen,
ich versuche seit 3 Tagen einen OpenVPN Site-to-Site Tunnel aufzubauen und hänge aktuell fest und wäre sehr froh über einen Imput um das Problem zu lösen...
Mit der derzeitigen Konfiguration kann ich vom Netzwerk in welchem der OpenVPN Server läuft alle Server auf im anderen Rechenzentrum erreichen.
Das Problem ist jedoch auf der Gegenseite also im Netzwerk wo der OpenVPN Client läuft. Dort ist kein Server der Gegenseite erreichbar außer auf dem Server wo der OpenVPN Client direkt läuft.
Beispiel:
10.12.1.21--> 10.10.10.30 --> funktioniert
10.10.10.30 --> 10.12.1.21 --> funktioniert nicht
10.12.1.21--> 10.10.11.105 --> funktoniert
10.10.11.105 --> 10.10.10.30 --> funktioniert
Netzwerk:
Server:
LAN Netzwerk: 10.12.0.0/16
OpenVPN LAN IP: 10.12.1.10 (default GW für alle Server in 10.12.0.0/16)
OpenVPN Tunnel IP: 10.3.100.1
Client:
LAN Netzwerk: 10.10.10.0/24, 10.10.11.0/24
OpenVPN LAN IP: 10.10.11.105 (kein default gw)
OpenVPN Tunnel IP: 10.3.100.2
Statische Routen (global gesetzt im Router auf OpenVPN Client Seite) :
Destination Gateway
10.12.0.0/16 --> 10.10.11.105
Open VPN Server Config:
OpenVPN Client Config:
IP Tables Konfiguration auf dem OpenVPN Client (damit zumindest eine Seite mal erreichbar ist):
iptables -t nat -A POSTROUTING -o ens3 -j SNAT --to-source 10.10.11.105 (OpenVPN Client IP)
Vielen Dank für die Hilfe!
ich versuche seit 3 Tagen einen OpenVPN Site-to-Site Tunnel aufzubauen und hänge aktuell fest und wäre sehr froh über einen Imput um das Problem zu lösen...
Mit der derzeitigen Konfiguration kann ich vom Netzwerk in welchem der OpenVPN Server läuft alle Server auf im anderen Rechenzentrum erreichen.
Das Problem ist jedoch auf der Gegenseite also im Netzwerk wo der OpenVPN Client läuft. Dort ist kein Server der Gegenseite erreichbar außer auf dem Server wo der OpenVPN Client direkt läuft.
Beispiel:
10.12.1.21--> 10.10.10.30 --> funktioniert
10.10.10.30 --> 10.12.1.21 --> funktioniert nicht
10.12.1.21--> 10.10.11.105 --> funktoniert
10.10.11.105 --> 10.10.10.30 --> funktioniert
Netzwerk:
Server:
LAN Netzwerk: 10.12.0.0/16
OpenVPN LAN IP: 10.12.1.10 (default GW für alle Server in 10.12.0.0/16)
OpenVPN Tunnel IP: 10.3.100.1
Client:
LAN Netzwerk: 10.10.10.0/24, 10.10.11.0/24
OpenVPN LAN IP: 10.10.11.105 (kein default gw)
OpenVPN Tunnel IP: 10.3.100.2
Statische Routen (global gesetzt im Router auf OpenVPN Client Seite) :
Destination Gateway
10.12.0.0/16 --> 10.10.11.105
Open VPN Server Config:
dev ovpns2
verb 3
syslog
dev-type tun
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/sbin/ovpn-up
down /usr/sbin/ovpn-down
lport 1196
management /var/run/openvpn/server4.sock unix
multihome
secret /etc/openvpn/server4.secret
persist-tun
route-metric 20
ifconfig 10.3.100.1 10.3.100.2
max-clients 1
route 10.10.10.0 255.255.255.0
route 10.10.11.0 255.255.255.0
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBCOpenVPN Client Config:
dev ovpnc2
verb 3
dev-type tun
script-security 3
local 10.10.11.105
persist-tun
persist-key
cipher AES-256-CBC
auth SHA256
ifconfig 10.3.100.2 10.3.100.1
remote 85.158.X.X 1196 udp4
keepalive 10 60
route 10.12.0.0 255.255.0.0
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBC
resolv-retry infinite
lport 0
secret vpn-S2S.secretIP Tables Konfiguration auf dem OpenVPN Client (damit zumindest eine Seite mal erreichbar ist):
iptables -t nat -A POSTROUTING -o ens3 -j SNAT --to-source 10.10.11.105 (OpenVPN Client IP)
Vielen Dank für die Hilfe!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8056178092
Url: https://administrator.de/forum/openvpn-site-to-site-tunnel-routing-problem-8056178092.html
Ausgedruckt am: 23.04.2025 um 01:04 Uhr
11 Kommentare
Neuester Kommentar
Das entsprechende Tutorial dazu hast du genau gelesen und das dort gepostete Client Setup auch genau so umgesetzt??
OpenVPN Site-to-Site
Dein Kardinalsfehler ist ,wie leider sehr häufig, das wieder mal FALSCHE NAT (IP Adress Translation, Masquerading) im Tunnel, was völlig sinnfrei ist und auch kontraproduktiv im Site-to-Site VPN weil damit ein transparentes Routing zw. beiden Seiten technisch unmöglich ist. Logisch, denn wie sollte die eine Seite die NAT Firewall überwinden? So bleibt die Kommunikation eine Einbahnstrasse.
Der übliche VPN Fehler...
Lasse also den Unsinn mit Masquerading im Tunnel und halte dich an das o.a. Setup, dann kommt das auch alles sofort zum Fliegen.
Allgemeine Grundlagen zum OpenVPN Setup, wie immer, hier:
Merkzettel: VPN Installation mit OpenVPN
OpenVPN Site-to-Site
Dein Kardinalsfehler ist ,wie leider sehr häufig, das wieder mal FALSCHE NAT (IP Adress Translation, Masquerading) im Tunnel, was völlig sinnfrei ist und auch kontraproduktiv im Site-to-Site VPN weil damit ein transparentes Routing zw. beiden Seiten technisch unmöglich ist. Logisch, denn wie sollte die eine Seite die NAT Firewall überwinden? So bleibt die Kommunikation eine Einbahnstrasse.
Der übliche VPN Fehler...
Lasse also den Unsinn mit Masquerading im Tunnel und halte dich an das o.a. Setup, dann kommt das auch alles sofort zum Fliegen.
Allgemeine Grundlagen zum OpenVPN Setup, wie immer, hier:
Merkzettel: VPN Installation mit OpenVPN
Danke für den Input.
Ich habe das Setup nach dem Tutotial umgebaut... Leider funktioniert es trotzdem nicht.
Die Verbindung zwischen den OpenVPN Server und OpenVPN Client klappt soweit, aber die Server dahinter sind weiterhin nicht erreichbar...
Das mit Masquerading im Tunnel war mir bewusst. Das war nur temporär gedacht, damit der Tunnel zumindest in eine Richtung funktoniert. Masquerading ist wieder entfernt.
Die aktuelle Server Config:
OpenVPN Client config
Routing Tabelle auf dem OpenVPN Client:
Traceroute:
IPv4 Forwarding ist aktiviert.
Siehst du hier noch einen Fehler?
Ich habe das Setup nach dem Tutotial umgebaut... Leider funktioniert es trotzdem nicht.
Die Verbindung zwischen den OpenVPN Server und OpenVPN Client klappt soweit, aber die Server dahinter sind weiterhin nicht erreichbar...
Das mit Masquerading im Tunnel war mir bewusst. Das war nur temporär gedacht, damit der Tunnel zumindest in eine Richtung funktoniert. Masquerading ist wieder entfernt.
Die aktuelle Server Config:
dev ovpns2
verb 3
syslog
dev-type tun
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-key
proto udp4
cipher AES-256-CBC
auth SHA256
up /usr/sbin/ovpn-up
down /usr/sbin/ovpn-down
lport 1196
management /var/run/openvpn/server4.sock unix
multihome
reneg-sec 3600
tls-crypt /etc/openvpn/server4.tls
ca /etc/openvpn/server4.ca
cert /etc/openvpn/server4.cert
key /etc/openvpn/server4.key
persist-tun
route-metric 20
server 10.3.100.0 255.255.255.0
client-config-dir /etc/openvpn/ccd/server4
duplicate-cn
tls-server
client-to-client
dh /etc/ssl/dh2048.pem
push "route 10.12.0.0 255.255.0.0"
max-clients 1
# tls-verify "/usr/local/sbin/ovpn_auth_verify tls '' 1" # NOT USED AT THE MOMENT
persist-remote-ip
float
route 10.10.10.0 255.255.255.0
route 10.10.11.0 255.255.255.0
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBC
topology subnetifconfig-push 10.3.100.2 255.255.255.0
push "route 10.12.0.0 255.255.0.0"
push "route 10.11.0.0 255.255.0.0"
iroute 10.10.10.0 255.255.255.0
iroute 10.10.11.0 255.255.255.0OpenVPN Client config
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA256
client
keepalive 10 60
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-CBC
remote 85.158.X.X 1196 udp4
resolv-retry infinite
lport 0
tls-client
reneg-sec 3600
remote-cert-tls server
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client01.crt
key /etc/openvpn/client/client01.keyRouting Tabelle auf dem OpenVPN Client:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.10.11.1 0.0.0.0 UG 0 0 0 ens3
10.3.100.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.11.0.0 10.3.100.1 255.255.0.0 UG 0 0 0 tun0
10.12.0.0 10.3.100.1 255.255.0.0 UG 0 0 0 tun0Traceroute:
traceroute 10.12.1.21
traceroute to 10.12.1.21 (10.12.1.21), 30 hops max, 60 byte packets
1 10.10.11.1 (10.10.11.1) 2.068 ms 1.976 ms 1.933 ms
2 10.10.11.105 (10.10.11.105) 2.482 ms 2.426 ms 2.535 ms
3 * * *
4 * * *
5 * * *IPv4 Forwarding ist aktiviert.
Siehst du hier noch einen Fehler?
Die Routing Tabelle auf dem Client stimmt ja soweit!
Interessanter wäre die Routing Tabelle auf dem Server bei aktiver Client Verbindung.
Dort müssten ja die beiden lokalen Client Netze 10.10.10.0/24 und 10.10.11.0/24 zu sehen sein mit einem Next Hop Gateway auf die interne Client IP 10.3.100.2 sofern die Routing Kommandos korrekt ausgeführt wurden!
Ist das der Fall?
Einen Fehler hast du aber dennoch wieder gemacht. Es ist sinnfrei und auch kontraproduktiv die „push route...“ Kommandos zum Propagieren der lokalen Server LAN Segmente doppelt auszuführen!
In der Client spezifischen Setup Datei auf dem Server haben die nichts zu suchen. Siehe o.a. Site-to-Site Tutorial!
Interessanter wäre die Routing Tabelle auf dem Server bei aktiver Client Verbindung.
Dort müssten ja die beiden lokalen Client Netze 10.10.10.0/24 und 10.10.11.0/24 zu sehen sein mit einem Next Hop Gateway auf die interne Client IP 10.3.100.2 sofern die Routing Kommandos korrekt ausgeführt wurden!
Ist das der Fall?
Siehst du hier noch einen Fehler?
Ja leider...Einen Fehler hast du aber dennoch wieder gemacht. Es ist sinnfrei und auch kontraproduktiv die „push route...“ Kommandos zum Propagieren der lokalen Server LAN Segmente doppelt auszuführen!
In der Client spezifischen Setup Datei auf dem Server haben die nichts zu suchen. Siehe o.a. Site-to-Site Tutorial!
Ja. Die Routing Tabelle auf dem Server stimmt auch:
Das Gateway 10.3.100.2 ist auch erreichbar.
Ich bin echt ratlos...
Das Gateway 10.3.100.2 ist auch erreichbar.
Ich bin echt ratlos...
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 85.158.2.177 0.0.0.0 UG 10 0 0 eno2
10.10.10.0 10.3.100.2 255.255.255.0 UG 20 0 0 ovpns2
10.10.11.0 10.3.100.2 255.255.255.0 UG 20 0 0 ovpns2
10.11.0.0 0.0.0.0 255.255.0.0 U 0 0 0 bond0
10.12.0.0 0.0.0.0 255.255.0.0 U 0 0 0 bond0.12
Ist das ein internes „one armed“ Setup, sprich gibt es im Client und Server Netz ggf. noch jeweils interne Internet Router die Default Gateway für dortige Endgeräte sind und sind in dem Falle alle statischen 10er Routen dort auch eingetragen mit next Hop auf die lokalen OpenVPN Server bzw. Client? Das ist jetzt mit abgeschaltetem Tunnel NAT zwingend! Siehe Topologie Zeichnung Tutorial...
Mit der 85er IP sieht das aber eher nach sowas wie einem Jumphost Szenario aus?! 🤔
Mit der 85er IP sieht das aber eher nach sowas wie einem Jumphost Szenario aus?! 🤔
Ja es ist ein "one armed" Setup. Also auf Client Netz Seite gibt es interne Internet Router (OpenStack), die statischen Routen habe ich dort auch eingetragen. Das scheint soweit auch zu funktionieren. Der Traffic geht vom OpenStack Router (10.10.11.1) an den OpenVPN Client.
Client Netz (OpenStack)
Es sieht so aus als wäre auf dem OpenVPN Client dann Schluss also der Traffic wird nicht an das tun Interface geleitet...
Im Server Netz läuft OpenVPN auf dem Router bzw. der Firewall selbst. Die Firewall dient als default GW.
Client Netz (OpenStack)
traceroute 10.12.1.21
traceroute to 10.12.1.21 (10.12.1.21), 30 hops max, 60 byte packets
1 10.10.11.1 (10.10.11.1) 2.068 ms 1.976 ms 1.933 ms
2 10.10.11.105 (10.10.11.105) 2.482 ms 2.426 ms 2.535 ms
3 * * *
4 * * *
5 * * *Es sieht so aus als wäre auf dem OpenVPN Client dann Schluss also der Traffic wird nicht an das tun Interface geleitet...
Im Server Netz läuft OpenVPN auf dem Router bzw. der Firewall selbst. Die Firewall dient als default GW.
Richtig, bei .11.105 ist Schluss, der kann das Zielnetz nicht mehr routen. Dort liegt vermutlich der Fehler.
Dann müsste es am OpenVPN Client liegen? Hast du ggf. noch einen Tipp was die Ursache sein könnte?
Vermutlich ist dort das IPv4 Forwarding (Routing) nicht wirklich aktiv?! Oder...an dessen next Hop Gateway scheitert das Forwarding.
Das Tunnel funktioniert jetzt endlich. Vielen Dank @aqui!
Das Problem lag tatsächlich am internen OpenStack Router. Ich habe den Netzwerkservice einmal neu gestartet.
Danach ging die Verbindung sofort. Vorher wurden wie Pakete wohl verworfen.
Jetzt habe ich noch das Problem, dass die Verbindung extrem langsam ist. 1 <MB/s.
An welchen Settings könnte man hier etwas drehen, damit die Performance besser wird?
Das Problem lag tatsächlich am internen OpenStack Router. Ich habe den Netzwerkservice einmal neu gestartet.
Danach ging die Verbindung sofort. Vorher wurden wie Pakete wohl verworfen.
Jetzt habe ich noch das Problem, dass die Verbindung extrem langsam ist. 1 <MB/s.
An welchen Settings könnte man hier etwas drehen, damit die Performance besser wird?
Wie üblich vermutlich ein falsches MTU bzw. MSS Setting. Wenn du die Tunnel MTU nicht anpasst zwingst du den Router zur Fragmentierung was dann massiv auf die Performance geht.
