10
Windows 7 setzt Default-Gateway Route eigenständig neu (OpenVPN
Ich nutze OpenVPN um meinen gesamten Internet-Verkehr aus unsicheren W-LANs heraus (z.B. öffentliche Hotspots) über meinen eigenen OpenVPN Server zu leiten. Leider funktioniert dies nicht immer zuverlässig, weil Windows die von OpenVPN konfigurierten Routen teilweise eigenständig umschreibt. Zumindest vermute ich das.
Hi,
ich nutze OpenVPN serverseitig mit der Konfiguration
push "redirect-gateway"
um den gesamten Netzwerkverkehr der Clients über den VPN Server laufen zu lassen.
Das funktioniert nach Verbindungsaufbau auch und "route print" liefert mir am Client als Default-Gateway nur die VPN-IP meines Servers.
Nach einiger Zeit taucht allerdings in "route print" ein zweiter Default-Gateway auf, nämlich der der eigentlichen Netzwerkverbindung ins Internet. Da dessen Metrik in meinem Fall niedriger ist als die der VPN Verbindung (wobei ich manchmal lustige Spielchen miterlebt habe, in denen die Metrik der LAN Verbindugn alle paar Sekunden angepasst wurde und dann mal über und mal unter der der VPN Verbindung lag) geht dann der gesamte Datenverkehr wieder über das unsichere Netzwerk ins Internet, ohne dass ich etwas davon merke. OpenVPN bemerkt dies ebenfalls nicht und Verbindungen zu VPN-IPs funktionieren ja weiter, da hierfür eigene Routen existieren. Allerdings birgt das eben ein eklatantes Sicherheitsrisiko!
Im Moment behelfe ich mir dadurch, dass ich die Metrik der VPN Verbindung extrem niedrig setze. Dadurch läuft der Datenverkehr auch dann über das VPN, wenn der andere Default-Gateway existiert.
Lieber wäre es mir aber zu verstehen, woher plötzlich wieder die zweite Route zum Default-Gateway kommt und wie man dies verhindern kann.
Ich habe das Verhalten vor allem unter Windows 7 beobachtet, denke aber dass Vista ebenso betroffen ist. Weiterhin nutze ich in der Regel W-LAN als Verbindung. Ein Abbruch der W-LAN Verbindung tritt aber nicht auf, jedenfalls nicht derart, dass OpenVPN den Tunnel neu aufbauen müsste. Auch ist die W-LAN Verbindung meist sehr stabil.
Weiterhin frage ich mich, ob das auch Anderen aufgefallen ist (viel gefunden habe ich dazu im Internet leider nicht) bzw. würde ich Euch bitten, die Ihr vielleicht auch derartige VPN Konstellationen nutzt, da mal genauer darauf zu achten.
Schöne Grüße,
RFZ
ich nutze OpenVPN serverseitig mit der Konfiguration
push "redirect-gateway"
um den gesamten Netzwerkverkehr der Clients über den VPN Server laufen zu lassen.
Das funktioniert nach Verbindungsaufbau auch und "route print" liefert mir am Client als Default-Gateway nur die VPN-IP meines Servers.
Nach einiger Zeit taucht allerdings in "route print" ein zweiter Default-Gateway auf, nämlich der der eigentlichen Netzwerkverbindung ins Internet. Da dessen Metrik in meinem Fall niedriger ist als die der VPN Verbindung (wobei ich manchmal lustige Spielchen miterlebt habe, in denen die Metrik der LAN Verbindugn alle paar Sekunden angepasst wurde und dann mal über und mal unter der der VPN Verbindung lag) geht dann der gesamte Datenverkehr wieder über das unsichere Netzwerk ins Internet, ohne dass ich etwas davon merke. OpenVPN bemerkt dies ebenfalls nicht und Verbindungen zu VPN-IPs funktionieren ja weiter, da hierfür eigene Routen existieren. Allerdings birgt das eben ein eklatantes Sicherheitsrisiko!
Im Moment behelfe ich mir dadurch, dass ich die Metrik der VPN Verbindung extrem niedrig setze. Dadurch läuft der Datenverkehr auch dann über das VPN, wenn der andere Default-Gateway existiert.
Lieber wäre es mir aber zu verstehen, woher plötzlich wieder die zweite Route zum Default-Gateway kommt und wie man dies verhindern kann.
Ich habe das Verhalten vor allem unter Windows 7 beobachtet, denke aber dass Vista ebenso betroffen ist. Weiterhin nutze ich in der Regel W-LAN als Verbindung. Ein Abbruch der W-LAN Verbindung tritt aber nicht auf, jedenfalls nicht derart, dass OpenVPN den Tunnel neu aufbauen müsste. Auch ist die W-LAN Verbindung meist sehr stabil.
Weiterhin frage ich mich, ob das auch Anderen aufgefallen ist (viel gefunden habe ich dazu im Internet leider nicht) bzw. würde ich Euch bitten, die Ihr vielleicht auch derartige VPN Konstellationen nutzt, da mal genauer darauf zu achten.
Schöne Grüße,
RFZ
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: 157426
Url: https://administrator.de/contentid/157426
Printed on: April 25, 2024 at 03:04 o'clock
10 Comments
Latest comment
Ist ein bekannter Fehler bei Winblows 7. Dr. Google hätte dir das in 3 Sekunden auch erzählt !
Ersetze in deiner client.conf einfach push "redirect-gateway" mit
push "redirect-gateway def1"
Dann tritt das nicht mehr auf !
Ersetze in deiner client.conf einfach push "redirect-gateway" mit
push "redirect-gateway def1"
Dann tritt das nicht mehr auf !
Du hast aber schon gelesen was ich geschrieben habe?
Das Problem ist nicht, dass Windows den Default-Gateway nicht akzeptieren würde. Der Gateway ist da und funktioniert.
Das Problem ist, dass Windows nach gewisser Zeit eigenständig einen zusätzlichen Gateway anlegt. Mit OpenVPN hat das eigentlich garnicht so viel zu tun, denn das rührt sich nach dem Verbindungsaufbau nicht mehr.
Das Problem ist nicht, dass Windows den Default-Gateway nicht akzeptieren würde. Der Gateway ist da und funktioniert.
Das Problem ist, dass Windows nach gewisser Zeit eigenständig einen zusätzlichen Gateway anlegt. Mit OpenVPN hat das eigentlich garnicht so viel zu tun, denn das rührt sich nach dem Verbindungsaufbau nicht mehr.
Ah okay... du hättst ja ein wenig dazu erklären können ;)
def1 setzt statt 0.0.0.0/0 zwei Netze 0.0.0.0/1 und 128.0.0.0/1. Das behebt zwar nicht das Problem, dass Windows den Default-Gateway neu setzt, aber verhindert zumindest dass die Daten über das Default-Gateway laufen.
Mir kam das erst suspekt vor, weil die Metrik dann ja trotzdem noch höher ist - aber das ist natürlich schmarrn, eine definierte Route mit hoher Metrik wird natürlich dem Default-Gateway mit niedriger Metrik gegenüber bevorzugt.
Ist zwar eine bessere Lösung, da ich sie nicht Client-Seitig anwenden muss (wie das Ändern der Schnittstellenmetrik), aber optimal finde ich das auch nicht...
Danke trotzdem
def1 setzt statt 0.0.0.0/0 zwei Netze 0.0.0.0/1 und 128.0.0.0/1. Das behebt zwar nicht das Problem, dass Windows den Default-Gateway neu setzt, aber verhindert zumindest dass die Daten über das Default-Gateway laufen.
Mir kam das erst suspekt vor, weil die Metrik dann ja trotzdem noch höher ist - aber das ist natürlich schmarrn, eine definierte Route mit hoher Metrik wird natürlich dem Default-Gateway mit niedriger Metrik gegenüber bevorzugt.
Ist zwar eine bessere Lösung, da ich sie nicht Client-Seitig anwenden muss (wie das Ändern der Schnittstellenmetrik), aber optimal finde ich das auch nicht...
Danke trotzdem
Wichtig ist ja das Win 7 damit das Gateway nicht mehr überrennt bzw. überrennen kann ! Bei Vista und XP passiert das nicht besser ist aber immer das def1 bei beiden mit anzuhängen.
Wenns das denn war
How can I mark a post as solved?
nicht vergessen.
Wenns das denn war
How can I mark a post as solved?
nicht vergessen.
Ja, im Prinzip isses das... Mir gefällt aber noch nicht so ganz, wie sich das z.B. auf Broadcast und Multicast Adressen auswirkt. Deren Routen sind dadurch überschrieben.
Aber mal sehn, ob das Probleme bereitet oder nicht.
Aber mal sehn, ob das Probleme bereitet oder nicht.
Hier widersprichst du dich nun aber selber oder dir sind IP Netzwerk Mechanismen schlicht unbekannt weil dir das Grundwissen fehlt...
Broadcasts werden per se wie du hoffentlich selber weisst nicht über geroutete Interfaces übertragen !
Das ist eine IP Grundlage und tieferer Sinn von gerouteten Netzen um die Broadcast Domains klein zu halten und damit das Netzwerk performant ! Wenn dann geht es nur wenn der Router sog. Relay Agents oder IP Helper supportet.
Multicast geht auch nicht so ohne weiteres über geroutete Interfaces ! Dafür muss ein Router mindestens IGMP kennen oder Multicast Routing Mechanismen wie PIM dense oder PIM sparse um mal die bekanntesten zu nennen.
So oder so hat das alles nichts mit deinem o.a. Problem zu tun und keinerlei Auswirkungen oder Beeinflussung darauf. Wo ist also genau dein Problem ??
Broadcasts werden per se wie du hoffentlich selber weisst nicht über geroutete Interfaces übertragen !
Das ist eine IP Grundlage und tieferer Sinn von gerouteten Netzen um die Broadcast Domains klein zu halten und damit das Netzwerk performant ! Wenn dann geht es nur wenn der Router sog. Relay Agents oder IP Helper supportet.
Multicast geht auch nicht so ohne weiteres über geroutete Interfaces ! Dafür muss ein Router mindestens IGMP kennen oder Multicast Routing Mechanismen wie PIM dense oder PIM sparse um mal die bekanntesten zu nennen.
So oder so hat das alles nichts mit deinem o.a. Problem zu tun und keinerlei Auswirkungen oder Beeinflussung darauf. Wo ist also genau dein Problem ??
Sorry, ich war an dem Tag irgendwie schräg drauf. Ist alles in Ordnung so. Wunder mich selbst wie ich auf sowas komme
Hi,
jetzt habe ich doch noch ein Problem mit dem Routing...
Wenn OpenVPN nicht den Standard-Gateway setzt, kann Windows Vista/7 das Netzwerk nicht klassifizieren. Kann man da irgendwie nachhelfen?
jetzt habe ich doch noch ein Problem mit dem Routing...
Wenn OpenVPN nicht den Standard-Gateway setzt, kann Windows Vista/7 das Netzwerk nicht klassifizieren. Kann man da irgendwie nachhelfen?
Ja, mit einer statischen Route. Ist aber eigentlich Blödsinn, denn mit dem "push" Kommando setzt du das remote Subnetz inklusive Maske ja.
Der Sinn deiner Frage ist irgendwie nicht ganz klar....sorry ?!
Der Sinn deiner Frage ist irgendwie nicht ganz klar....sorry ?!
Das Problem war doch, dass
push "redirect-gateway"
unter Windows 7 / Vista nicht zuverlässig funktioniert, weil es den Default Gateway verändert.
Daher haben wir uns geeinigt,
push "redirect-gateway def1"
zu verwenden, was den Default Gateway nicht antastet und statt dessen zwei /1 Subnetze routet, was effektiv auch alle Ziele betrifft.
Daraus ergibt sich aber, dass der OpenVPN Adapter eben keinen Default Gateway mehr hat. Und da Windows 7 die Adapter anhand der MAC-Adresse des Gateways klassifiziert, kann es das VPN Netzwerk jetzt nicht mehr klassifizieren und stuft es daher als öffentlich ein.
Die Frage war jetzt, wie kann ich Windows 7 dabei helfen, das Netzwerk zu klassifizieren, damit ich es als privat nutzen kann?
push "redirect-gateway"
unter Windows 7 / Vista nicht zuverlässig funktioniert, weil es den Default Gateway verändert.
Daher haben wir uns geeinigt,
push "redirect-gateway def1"
zu verwenden, was den Default Gateway nicht antastet und statt dessen zwei /1 Subnetze routet, was effektiv auch alle Ziele betrifft.
Daraus ergibt sich aber, dass der OpenVPN Adapter eben keinen Default Gateway mehr hat. Und da Windows 7 die Adapter anhand der MAC-Adresse des Gateways klassifiziert, kann es das VPN Netzwerk jetzt nicht mehr klassifizieren und stuft es daher als öffentlich ein.
Die Frage war jetzt, wie kann ich Windows 7 dabei helfen, das Netzwerk zu klassifizieren, damit ich es als privat nutzen kann?
