9
OpenVPN routing Probleme im VLAN
Hallo zusammen,
ich bin gerade etwas am verzweifeln beim Aufsetzen eines OpenVPN Clients. Der Client läuft auf einem Ubuntu 20.04 als VM in einer ESXI Umgebung. Ohne VPN hat die VM Internetzugriff und kann auch auf die anderen Hosts im Netzwerk zugreifen.
Die VM befindet sich in VLAN12 und sobald ich den Client starte ist die VM nur noch sehr schwer erreichbar. Ich kann zum Beispiel keine weitere ssh Session zur VM aufbauen. Habe ich vorher bereits eine weitere Session offen und starte dort htop, friert htop in dem Moment ein, in dem der VPN Client die Routing Einträge anlegt:
Sat Oct 31 10:52:35 2020 /sbin/ip link set dev tun0 up mtu 1500
Sat Oct 31 10:52:35 2020 /sbin/ip addr add dev tun0 local 10.32.0.238 peer 10.32.0.237
Sat Oct 31 10:52:37 2020 /sbin/ip route add 89.187.165.53/32 via 192.168.12.1
Sat Oct 31 10:52:37 2020 /sbin/ip route add 0.0.0.0/1 via 10.32.0.237
Sat Oct 31 10:52:37 2020 /sbin/ip route add 128.0.0.0/1 via 10.32.0.237
Füge ich der openvpn config "route-nopull" hinzu, startet der VPN Client und das routing der VM funktioniert normal. Dann werden allerdings, logischerweise, keine Verbindungen durch den VPN getunnelt.
Es läuft also irgendwas mit den automatisch erzeugten Routen falsch ... .
Wenn ich mich im VLAN 1 befinde, funktioniert der VPN Aufbau und das Routing einwandfrei ... . An meinem Server habe ich einfach mal die NIC für die spezielle VM getauscht um das zu überprüfen.
Woran kann es liegen, dass das routing für einen Client in einem VLAN nicht funktioniert?
Setup:
VM-IP: 192.168.12.2
VLAN12: 192.168.12.0/24
config:
dev tun
fast-io
persist-key
persist-tun
nobind
remote <URL>
remote-random
comp-lzo no
pull
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1200
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
auth-user-pass password.txt
<cert>
</cert>
<key>
</key>
<tls-auth>
</tls-auth>
<ca>
</ca>
ich bin gerade etwas am verzweifeln beim Aufsetzen eines OpenVPN Clients. Der Client läuft auf einem Ubuntu 20.04 als VM in einer ESXI Umgebung. Ohne VPN hat die VM Internetzugriff und kann auch auf die anderen Hosts im Netzwerk zugreifen.
Die VM befindet sich in VLAN12 und sobald ich den Client starte ist die VM nur noch sehr schwer erreichbar. Ich kann zum Beispiel keine weitere ssh Session zur VM aufbauen. Habe ich vorher bereits eine weitere Session offen und starte dort htop, friert htop in dem Moment ein, in dem der VPN Client die Routing Einträge anlegt:
Sat Oct 31 10:52:35 2020 /sbin/ip link set dev tun0 up mtu 1500
Sat Oct 31 10:52:35 2020 /sbin/ip addr add dev tun0 local 10.32.0.238 peer 10.32.0.237
Sat Oct 31 10:52:37 2020 /sbin/ip route add 89.187.165.53/32 via 192.168.12.1
Sat Oct 31 10:52:37 2020 /sbin/ip route add 0.0.0.0/1 via 10.32.0.237
Sat Oct 31 10:52:37 2020 /sbin/ip route add 128.0.0.0/1 via 10.32.0.237
Füge ich der openvpn config "route-nopull" hinzu, startet der VPN Client und das routing der VM funktioniert normal. Dann werden allerdings, logischerweise, keine Verbindungen durch den VPN getunnelt.
Es läuft also irgendwas mit den automatisch erzeugten Routen falsch ... .
Wenn ich mich im VLAN 1 befinde, funktioniert der VPN Aufbau und das Routing einwandfrei ... . An meinem Server habe ich einfach mal die NIC für die spezielle VM getauscht um das zu überprüfen.
Woran kann es liegen, dass das routing für einen Client in einem VLAN nicht funktioniert?
Setup:
VM-IP: 192.168.12.2
VLAN12: 192.168.12.0/24
config:
dev tun
fast-io
persist-key
persist-tun
nobind
remote <URL>
remote-random
comp-lzo no
pull
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1200
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
auth-user-pass password.txt
<cert>
</cert>
<key>
</key>
<tls-auth>
</tls-auth>
<ca>
</ca>
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: 620151
Url: https://administrator.de/contentid/620151
Printed on: April 26, 2024 at 06:04 o'clock
9 Comments
Latest comment
Hilfreich wäre hier die Konfiguration des OpenVPN Servers gewesen ! Dieser beeinflusst das Routing des Clients maßgeblich.
Da diese Info leider fehlt kann man nur vermuten und raten das im OVPN Server ein Client Redirect konfiguriert ist (push "redirect-gateway def1 bypass-dhcp")
Bei einem Redirect wird im Gegensatz zum VPN Split Tunneling der gesamte Traffic des Clients in den VPN Tunnel geroutet, was dann vermutlich diese Probleme verursacht, da ein lokales Routing über VLANs so nicht mehr möglich ist. Aber eben wegen dieser fehlenden Info nur geraten...
Nebenbei: Eine Menge deiner Konfig Parameter sind überflüssig und eher kontraproduktiv (z.B. die fehlerhafte Tunnel MTU die ja wegen des VPN Overheads nie 1500 sein kann). Hier gilt oft weniger ist mehr !
Alle wichtigen Tips und ToDos zu diesem Thema findest du, wie immer, im hiesigen OpenVPN "Merkzettel" !
Merkzettel: VPN Installation mit OpenVPN
Da diese Info leider fehlt kann man nur vermuten und raten das im OVPN Server ein Client Redirect konfiguriert ist (push "redirect-gateway def1 bypass-dhcp")
Bei einem Redirect wird im Gegensatz zum VPN Split Tunneling der gesamte Traffic des Clients in den VPN Tunnel geroutet, was dann vermutlich diese Probleme verursacht, da ein lokales Routing über VLANs so nicht mehr möglich ist. Aber eben wegen dieser fehlenden Info nur geraten...
Nebenbei: Eine Menge deiner Konfig Parameter sind überflüssig und eher kontraproduktiv (z.B. die fehlerhafte Tunnel MTU die ja wegen des VPN Overheads nie 1500 sein kann). Hier gilt oft weniger ist mehr !
Alle wichtigen Tips und ToDos zu diesem Thema findest du, wie immer, im hiesigen OpenVPN "Merkzettel" !
Merkzettel: VPN Installation mit OpenVPN
Danke für deine schnelle Rückmeldung!
Der VPN-Server ist nicht selber von mir konfiguriert. Es ist ein VPN Server von ExpressVPN. Bezüglich der unnötigen Parameter, ich habe mich da einfach fürs erste an deren Guide zur Konfiguration gehalten
Allerdings würde ich Server spezifische Probleme erstmal ausschließen, weil ich es auch mit einem anderen VPN Anbieter probiert habe und der ebenfalls das gleiche Ergebnis erzeugt.
"push "redirect-gateway def1 bypass-dhcp" lese ich mir mal durch, vielleicht bringt mich das näher an die Lösung. Danke !
Entschuldige falls einige Hintergrundinformationen gefehlt haben:
Ich habe einen L3 Switch der das VLAN tagging macht, wobei ich portbasierte VLANs habe. Da mein Netzwerk recht klein ist, habe ich Port 1 als Trunk markiert und mit der Firewall verbunden (pfsense) wodurch das eigentlich Routing zwischen den internen VLANs sowie dem WAN auf der pfsense passiert. Ich weiß, dass der Switch dafür besser geeignet ist und ich werde auch langfristig darauf umstellen und mir ACLs anschauen. Da aber mein Netzwerk wie gesagt recht klein ist, kommt meine kleine PFsense Box mit dem Routing soweit erstmal zurecht.
"Bei einem Redirect wird im Gegensatz zum VPN Split Tunneling der gesamte Traffic des Clients in den VPN Tunnel geroutet, was dann vermutlich diese Probleme verursacht, da ein lokales Routing über VLANs so nicht mehr möglich ist."
Sollte es für den Server nicht erstmal egal sein ob er in einem VLAN läuft oder nicht? Ich meine das einzige was sich hier verändert ist ja quasi die DHCP IP range (192.168.12.0/24) und das Standardgateway 192.168.12.1. Warum wird durch das VLAN Setup der openVPN client beeinflusst?
Helfen dir diese Hintergrundinformationen weiter? Wäre ein Diagramm von dem Netzwerksetup hilfreich?
--- Edit:
An der Pfsense habe ich für jedes VLAN eigene interfaces definiert und diese erstmal als offen für alles angelegt. Sprich jedes VLAN kann mit jedem anderen kommunizieren sowie mit dem Internet kommunizieren. Das funktioniert auch soweit, und sollte erstmal falsche Firewallkonfigurationen ausschließen
Der VPN-Server ist nicht selber von mir konfiguriert. Es ist ein VPN Server von ExpressVPN. Bezüglich der unnötigen Parameter, ich habe mich da einfach fürs erste an deren Guide zur Konfiguration gehalten
Allerdings würde ich Server spezifische Probleme erstmal ausschließen, weil ich es auch mit einem anderen VPN Anbieter probiert habe und der ebenfalls das gleiche Ergebnis erzeugt."push "redirect-gateway def1 bypass-dhcp" lese ich mir mal durch, vielleicht bringt mich das näher an die Lösung. Danke !
Entschuldige falls einige Hintergrundinformationen gefehlt haben:
Ich habe einen L3 Switch der das VLAN tagging macht, wobei ich portbasierte VLANs habe. Da mein Netzwerk recht klein ist, habe ich Port 1 als Trunk markiert und mit der Firewall verbunden (pfsense) wodurch das eigentlich Routing zwischen den internen VLANs sowie dem WAN auf der pfsense passiert. Ich weiß, dass der Switch dafür besser geeignet ist und ich werde auch langfristig darauf umstellen und mir ACLs anschauen. Da aber mein Netzwerk wie gesagt recht klein ist, kommt meine kleine PFsense Box mit dem Routing soweit erstmal zurecht.
"Bei einem Redirect wird im Gegensatz zum VPN Split Tunneling der gesamte Traffic des Clients in den VPN Tunnel geroutet, was dann vermutlich diese Probleme verursacht, da ein lokales Routing über VLANs so nicht mehr möglich ist."
Sollte es für den Server nicht erstmal egal sein ob er in einem VLAN läuft oder nicht? Ich meine das einzige was sich hier verändert ist ja quasi die DHCP IP range (192.168.12.0/24) und das Standardgateway 192.168.12.1. Warum wird durch das VLAN Setup der openVPN client beeinflusst?
Helfen dir diese Hintergrundinformationen weiter? Wäre ein Diagramm von dem Netzwerksetup hilfreich?
--- Edit:
An der Pfsense habe ich für jedes VLAN eigene interfaces definiert und diese erstmal als offen für alles angelegt. Sprich jedes VLAN kann mit jedem anderen kommunizieren sowie mit dem Internet kommunizieren. Das funktioniert auch soweit, und sollte erstmal falsche Firewallkonfigurationen ausschließen
Moin,
jetzt überleg doch bitte einfach mal logisch:
Du hast einen VPN-Client eingerichtet, welcher vom Server anscheinend die redirect-gateway-Anweisung bekommt (sieht im Routing so aus). Das bedeutet, dass das Standard-Gateway auf die VPN-Verbindung gelegt wird.
Ergo wird JEDER Traffic ins VPN geschickt. Damit kannst du logischerweise nicht mehr lokal auf die VM zugreifen, da alle Antworten des Servers ins VPN wandern und mangels Gegenstelle dort verworfen werden.
Das hat mit VLANs erstmal nix zu tun.
Wenn du also deinen Server noch lokal erreichen willst, kannst du entweder dein VPN auf Split-Tunneling umstellen, so wie @aqui es beschrieben hat oder nach dem Verbindungsaufbau noch zusätzlich die Routen für deine lokalen Netze setzen.
VG
jetzt überleg doch bitte einfach mal logisch:
Du hast einen VPN-Client eingerichtet, welcher vom Server anscheinend die redirect-gateway-Anweisung bekommt (sieht im Routing so aus). Das bedeutet, dass das Standard-Gateway auf die VPN-Verbindung gelegt wird.
Ergo wird JEDER Traffic ins VPN geschickt. Damit kannst du logischerweise nicht mehr lokal auf die VM zugreifen, da alle Antworten des Servers ins VPN wandern und mangels Gegenstelle dort verworfen werden.
Das hat mit VLANs erstmal nix zu tun.
Wenn du also deinen Server noch lokal erreichen willst, kannst du entweder dein VPN auf Split-Tunneling umstellen, so wie @aqui es beschrieben hat oder nach dem Verbindungsaufbau noch zusätzlich die Routen für deine lokalen Netze setzen.
VG
Danke für die Klarstellung!! @aqui hatte es ja bereits erwähnt, aber ich war einfach zu versteift auf die Tatsache, dass es im VLAN 1 ja funktioniert ...
Nach hinzufügen von "route 192.168.0.0 255.255.0.0 net_gateway" zu meiner VPN config funktioniert es wie gewollt! Danke das ihr nicht direkt die Lösung verraten habt ;)
Nach hinzufügen von "route 192.168.0.0 255.255.0.0 net_gateway" zu meiner VPN config funktioniert es wie gewollt! Danke das ihr nicht direkt die Lösung verraten habt ;)
Zitat von @renpen:
Danke für die Klarstellung!! @aqui hatte es ja bereits erwähnt, aber ich war einfach zu versteift auf die Tatsache, dass es im VLAN 1 ja funktioniert ...
Gern geschehen... Warum es in deinem VLAN1 klappt, kann ich mir zwar auch nicht erklären aber gut...Danke für die Klarstellung!! @aqui hatte es ja bereits erwähnt, aber ich war einfach zu versteift auf die Tatsache, dass es im VLAN 1 ja funktioniert ...
Nach hinzufügen von "route 192.168.0.0 255.255.0.0 net_gateway" zu meiner VPN config funktioniert es wie gewollt! Danke das ihr nicht direkt die Lösung verraten habt ;)
Und öffentliche VPN Provider zu nutzen sollte man sich sehr gut überlegen ! Dort wird bekanntlich besonders viel geschnüffelt und geschnorchelt. Normalerweise ein NoGo wem die eigene Datensicherheit etwas wert ist....
Naja, es gibt eine default routing regel, die alles im 192.168.x.0/24 durch das default gateway leitet.
Ist die VM im 1er, dann ist das default Gateway 192.168.1.1 und meine anderen Clients sind auch im 1er. Entsprechend funktioniert das Routing da.
Ist die VM im 15er, dann ist das default Gateway 192.168.15.1 und meine anderen Clients nach wie vor im 1er. Entsprechend fehlt das routing ins 1er. Letztlich musste ich also 192.168.15.0/24 in 192.168.0.0/16 ändern.
Das es im 1er 192.168.1.0 255.255.255.0 ist und im 15er 192.168.15.0 255.255.255.0 ist würde ich mir durch die Vergabe der IP-Adresse durch DHCP erklären. Sprich Ubuntu legt die route automatisch je nach zugewiesener IP Adresse fest
Wäre zumindest meine naive Erklärung. Kannst du wahrscheinlich besser beurteilen ob das Sinn macht oder nicht :D
Ist die VM im 1er, dann ist das default Gateway 192.168.1.1 und meine anderen Clients sind auch im 1er. Entsprechend funktioniert das Routing da.
Ist die VM im 15er, dann ist das default Gateway 192.168.15.1 und meine anderen Clients nach wie vor im 1er. Entsprechend fehlt das routing ins 1er. Letztlich musste ich also 192.168.15.0/24 in 192.168.0.0/16 ändern.
Das es im 1er 192.168.1.0 255.255.255.0 ist und im 15er 192.168.15.0 255.255.255.0 ist würde ich mir durch die Vergabe der IP-Adresse durch DHCP erklären. Sprich Ubuntu legt die route automatisch je nach zugewiesener IP Adresse fest
Wäre zumindest meine naive Erklärung. Kannst du wahrscheinlich besser beurteilen ob das Sinn macht oder nicht :D
@aqui Das verstehe ich nicht ganz. Würde ein VPN Anbieter schnüffeln und schnorcheln, würde das doch deren aus bedeuten bzw. die würden massiv an Kundschaft verlieren?
Kannst du das etwas ausführen, bzw. hast du da Belege für? Ich spreche jetzt nicht von Gratisanbietern ;)
Kannst du das etwas ausführen, bzw. hast du da Belege für? Ich spreche jetzt nicht von Gratisanbietern ;)
Welche Kundschaft weiss das denn ? Die meisten sind ja ahnungslos.
Frage Netzwerker die Wartung in solchen RZ machen das erweitert den Horizont und öffnet die Augen...
Frage Netzwerker die Wartung in solchen RZ machen das erweitert den Horizont und öffnet die Augen...
