15
L2TP VPN auf Windows 2012-Server mit mehreren VLANs. VPN-Client erreicht nur VLAN des VPN-Servers
Hallo zusammen,
ich bereite mich gerade auf die Einführung von VLANs vor und habe noch ein Problem mit der VPN-Einwahl, wo ich mich über eure Hilfe freuen würde.
Zunächst die technischen Details.
momentanes Netz (Default VLAN):
192.168.0.0/24
- Internetrouter 192.168.0.254
- Router für VLAN in Form eines L3-Switches: 192.168.0.1
neues Netz als VLAN 200
10.10.20.0/25
- Router für VLAN in Form eines L3-Switches: 10.10.20.1
- Windows 2012 (kein R2) RRAS VPN-Server mit L2TP-Einwahl 10.10.20.10
- DHCP-Server für alle Netze 10.10.20.11
diverse andere VLANs, die aber noch nicht genutzt werden.
Aktueller Stand:
Das Routing zwischen den VLANs und ins Internet funktioniert. DHCP funktioniert auch in allen Netzen. VPN-Einwahl geht. Clients bekommen IP aus dem VLAN 200 (10.10.20.0/25) mit GW 10.10.20.1.
Die VPN-Clients haben auch Zugriff auf alle VLANs, allerdings nur, wenn in der VPN-Verbindung eingestellt wird, dass der gesamte Verkehr über das VPN geroutet werden soll. Schalte ich das aus, ist im VLAN 200 Schluss. Ich erreiche zwar alle Geräte im VLAN, aber nichts in anderen VLANs. Das ist soweit auch logisch, da die Routen auf Clientseite fehlen.
Als VPN-Clients kommen, die OS-eigenen von Windows, MacOS und iOS zum Einsatz.
Gibt es eine Möglichkeit, den Clients bei der Einwahl die Routen mitzugeben? Ich habe mich jetzt schon seit mehreren Tagen durch Anleitungen durchgelesen, bin aber nur bei bestimmten VPN-Clients oder Router-Router-Kopplungen fündig geworden.
Der RRAS-Dienst ist aktuell nur eine Übergangslösung, bis in 4-5 Monaten der neue Internetrouter zum Einsatz kommt. Dann soll der direkt das VPN übernehmen. Ich hätte auch kein großes Problem, eine andere VPN-Software einzusetzen, sie sollte allerdings einfach einzusetzen sein, weil es ja nur für recht kurze Zeit ist.
Ich hoffe, ich habe alle notwendigen Informationen bereitgestellt und jemand kann mir helfen. Danke schon mal im Voraus für die Hilfe und ein besinnliches Weihnachtsfest.
Centauri.
ich bereite mich gerade auf die Einführung von VLANs vor und habe noch ein Problem mit der VPN-Einwahl, wo ich mich über eure Hilfe freuen würde.
Zunächst die technischen Details.
momentanes Netz (Default VLAN):
192.168.0.0/24
- Internetrouter 192.168.0.254
- Router für VLAN in Form eines L3-Switches: 192.168.0.1
neues Netz als VLAN 200
10.10.20.0/25
- Router für VLAN in Form eines L3-Switches: 10.10.20.1
- Windows 2012 (kein R2) RRAS VPN-Server mit L2TP-Einwahl 10.10.20.10
- DHCP-Server für alle Netze 10.10.20.11
diverse andere VLANs, die aber noch nicht genutzt werden.
Aktueller Stand:
Das Routing zwischen den VLANs und ins Internet funktioniert. DHCP funktioniert auch in allen Netzen. VPN-Einwahl geht. Clients bekommen IP aus dem VLAN 200 (10.10.20.0/25) mit GW 10.10.20.1.
Die VPN-Clients haben auch Zugriff auf alle VLANs, allerdings nur, wenn in der VPN-Verbindung eingestellt wird, dass der gesamte Verkehr über das VPN geroutet werden soll. Schalte ich das aus, ist im VLAN 200 Schluss. Ich erreiche zwar alle Geräte im VLAN, aber nichts in anderen VLANs. Das ist soweit auch logisch, da die Routen auf Clientseite fehlen.
Als VPN-Clients kommen, die OS-eigenen von Windows, MacOS und iOS zum Einsatz.
Gibt es eine Möglichkeit, den Clients bei der Einwahl die Routen mitzugeben? Ich habe mich jetzt schon seit mehreren Tagen durch Anleitungen durchgelesen, bin aber nur bei bestimmten VPN-Clients oder Router-Router-Kopplungen fündig geworden.
Der RRAS-Dienst ist aktuell nur eine Übergangslösung, bis in 4-5 Monaten der neue Internetrouter zum Einsatz kommt. Dann soll der direkt das VPN übernehmen. Ich hätte auch kein großes Problem, eine andere VPN-Software einzusetzen, sie sollte allerdings einfach einzusetzen sein, weil es ja nur für recht kurze Zeit ist.
Ich hoffe, ich habe alle notwendigen Informationen bereitgestellt und jemand kann mir helfen. Danke schon mal im Voraus für die Hilfe und ein besinnliches Weihnachtsfest.
Centauri.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 324656
Url: https://administrator.de/contentid/324656
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
15 Kommentare
Neuester Kommentar
Danke für die verständliche und nachvollziehbare Frage, obwohl Freitag ist...
Informationen, Absätze und Rechtschreibung. Wow! Nicht mehr Standard hier.
LEIDER kenne ich auch keine Lösung ausser den Clients eben die Routen manuell mitzuteilen. Das geht doch über route add in windows.
Hier ist ein Artikel, der das gut beschreibt mit dem Vorschlag das über ein Batch-File zu lösen:
http://www.itsyourip.com/networking/howto-add-persistent-static-routes- ...
So würde ich jedenfalls vorgehen.
Wie das mit anderen OS'en funktioniert...? Sollten die alle können.
Oder du setzt eben doch übergangsweise irgendeine Büchse mit IPSEC v1 als VPN Server dazwischen. PfSense, Raspberry oder... Das ist schnell eingerichtet, wenn man es schonmal gemacht hat. Sonst ist es Fortbildung...
Dann könntest du nämlich z.B. mit einem Shrew Client die Routen bei der Einwahl setzen...
Übergangslösungen sind aber immer doof...
Frohe Weihnachten!
Buc
Informationen, Absätze und Rechtschreibung. Wow! Nicht mehr Standard hier.
LEIDER kenne ich auch keine Lösung ausser den Clients eben die Routen manuell mitzuteilen. Das geht doch über route add in windows.
Hier ist ein Artikel, der das gut beschreibt mit dem Vorschlag das über ein Batch-File zu lösen:
http://www.itsyourip.com/networking/howto-add-persistent-static-routes- ...
So würde ich jedenfalls vorgehen.
Wie das mit anderen OS'en funktioniert...? Sollten die alle können.
Oder du setzt eben doch übergangsweise irgendeine Büchse mit IPSEC v1 als VPN Server dazwischen. PfSense, Raspberry oder... Das ist schnell eingerichtet, wenn man es schonmal gemacht hat. Sonst ist es Fortbildung...
Dann könntest du nämlich z.B. mit einem Shrew Client die Routen bei der Einwahl setzen...
Übergangslösungen sind aber immer doof...
Frohe Weihnachten!
Buc
1
In deinem Design gibt es einen grundlegenden Fehler oder ist es so gewollt das JEDES VLAN seinen eigenen Internet Zugang hat ??
In den klassischen Standardszenarien benutzt man einen zentralen Internet Zugang und die Produktivnetze hängen auf den jeweiligen VLANs.
Soll das so sein bei dir ist dein Konzept oben schlicht falsch !
Dann sähe es so aus:
Wenn du einen zentralen DHCP Server betreibst im VLAN 200 mit der IP 10.10.20.11 dann musst du aus dem Default VLAN 1 eine entsprechende DHCP Relay Adresse (IP Helper Adresse) auf den DHCP Server konfigurieren, damit auch DHCP Requests aus dem VLAN 1 den DHCP Server erreichen.
Das kann natürlich entfallen wenn im VLAN 1 keine Endgeräte sind !
Generell sollte man das Internet VLAN, sprich also den Zugriff auf den Internet Router vom Switch, imemr in ein separates VLAN legen und niemals in eins der Produktiv VLANs für Clients oder Server etc. !!!
Der Internet Traffic sollte davon getrennt sein (Security)
Das wäre das saubere Grundkonzept !
Kommen wir mal zum VPN...
Erster gravierender Designfehler ist das VPN in ein internes Netzwerk zu ziehen damit weichst du das Sicherheitskonzept massiv auf.
Generell gehört ein VPN Server auf den Internet Router direkt oder auf eine Firewall dort. Ein Fakt der immer wieder falsch gemacht wird
Aber nungut...betrachten wir das Design mal.
Ein route print auf dem aktiven VPN Client zeigt dir das !!
Du musst also dafür sorgen das auch dein 192.168er Netz an den Client bzw. seine Routing Tabelle gepusht wird beim Dialin. Dort hast du also einen Konfig Fehler gemacht oder das Winblows VPN supportet das nicht !
Dann hast du in der Tat nur die Chance das Default Gateway auf den Tunnel umzubiegen.
Kollege Buccaneer hat ja schon alles dazu gesagt.
Wenn du so oder so planst (richtigerweise) das auf die Firewall oder Internet Router zu verlagern musst du halt erstmal damit leben.
Je nachdem welches VPN Protokoll du nacher auf Router oder Firewall nutzt löst dann das Problem von ganz allein !
Diese Tutorials haben noch Details dazu:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
In den klassischen Standardszenarien benutzt man einen zentralen Internet Zugang und die Produktivnetze hängen auf den jeweiligen VLANs.
Soll das so sein bei dir ist dein Konzept oben schlicht falsch !
Dann sähe es so aus:
- Default VLAN 192.168.0.0/24 mit Internet Router IP 192.168.0.254 und Switch L3 IP 192.168.0.1
- VLAN 200 10.10.20.0/25 mit Switch L3 IP 10.10.20.1 (keine separate Internet Router IP !)
- Windows 2012 Server mit 10.10.20.10. Default Gateway hier dann 10.10.20.1
- Switch hat eine Default Route auf die 192.168.0.254
- Internet Router hat eine statische Route: Ziel: 10.10.20.0, Maske: 255.255.255.0, Gateway: 192.168.0.1
Wenn du einen zentralen DHCP Server betreibst im VLAN 200 mit der IP 10.10.20.11 dann musst du aus dem Default VLAN 1 eine entsprechende DHCP Relay Adresse (IP Helper Adresse) auf den DHCP Server konfigurieren, damit auch DHCP Requests aus dem VLAN 1 den DHCP Server erreichen.
Das kann natürlich entfallen wenn im VLAN 1 keine Endgeräte sind !
Generell sollte man das Internet VLAN, sprich also den Zugriff auf den Internet Router vom Switch, imemr in ein separates VLAN legen und niemals in eins der Produktiv VLANs für Clients oder Server etc. !!!
Der Internet Traffic sollte davon getrennt sein (Security)
Das wäre das saubere Grundkonzept !
Kommen wir mal zum VPN...
Erster gravierender Designfehler ist das VPN in ein internes Netzwerk zu ziehen damit weichst du das Sicherheitskonzept massiv auf.
Generell gehört ein VPN Server auf den Internet Router direkt oder auf eine Firewall dort. Ein Fakt der immer wieder falsch gemacht wird
Aber nungut...betrachten wir das Design mal.
Das Routing zwischen den VLANs und ins Internet funktioniert. DHCP funktioniert auch in allen Netzen. VPN-Einwahl geht.
Zeigt das du mit den obigen Einstellungen und Design, auch Port Forwarding für die L2TP VPN Ports auf dem Internet Router alles richtig gemacht hast soweit ! Gut !dass der gesamte Verkehr über das VPN geroutet werden soll.
Das ist klar, denn vermutlich gibt dein VPN Server ohne das nur mit das das 10.10.20er Netz in den VPN Tunnel geroutet wird ?!Ein route print auf dem aktiven VPN Client zeigt dir das !!
Du musst also dafür sorgen das auch dein 192.168er Netz an den Client bzw. seine Routing Tabelle gepusht wird beim Dialin. Dort hast du also einen Konfig Fehler gemacht oder das Winblows VPN supportet das nicht !
Dann hast du in der Tat nur die Chance das Default Gateway auf den Tunnel umzubiegen.
Kollege Buccaneer hat ja schon alles dazu gesagt.
Wenn du so oder so planst (richtigerweise) das auf die Firewall oder Internet Router zu verlagern musst du halt erstmal damit leben.
Je nachdem welches VPN Protokoll du nacher auf Router oder Firewall nutzt löst dann das Problem von ganz allein !
Diese Tutorials haben noch Details dazu:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
1
Hallo und frohe Weihnachten Buccaneer und Aqui,
danke für eure Hilfe.
Kurz zu dir, Buccaneer:
Ich versuche schon, es denen so leicht wie möglich zu machen, die mir hier helfen wollen. Danke für das Lob. Scheine ich es ja nicht ganz falsch gemacht haben.
Die Routen müßte ich auf den Clients setzen, die eine dynamische IP bei jeder Einwahl bekommen. Sicherlich möglich, aber zumindest für mich mit einem nicht unerheblichen Zeitaufwand, dass so dynamisch zu machen. Bei iOS wird das aber glaube nicht gehen.
Und genauso ist es konfiguriert. Woran hast du herausgelesen, dass es anders ist? Dann würde ich das an der Beschreibung ändern.
IP-Helper ist für alle VLANs konfiguriert und die DHCP-Server haben auch nur eine IP im eigenen VLAN (10.10.20.11)
So ist es geplant. Aber ich muss halt einen gleitenden Übergang machen. Ergo bleibt erstmal das Default-LAN wie es ist und ich ziehe nach und nach die Geräte in die entsprechenden VLANs. Der neue Internetrouter soll dann gleich in sein eigenes VLAN.
Das ist mir bewusst und nur eine Übergangslösung, bis der neue Router da ist. Dann wird dieser, wie ich geschrieben habe, der VPN-Endpunkt.
Das ist korrekt und mein Problem.
Es ist ja die Frage, ob ich beim Windows VPN nur was übersehen habe, ob der das nicht kann. Das Routen des gesamten Verkehrs über das VPN wäre, wegen unserer schmalen Anbindung ans Internet nicht sehr glücklich. Ich müsste dann das Verteilen der Geräte auf die VLANs erstmal ruhen lassen, bis der neue Router da ist. Dieser wird dann das mitgeben von Routen unterstützen.
Ich werde mir auch noch mal die Links von dir anschauen. Habe sie schon länger nicht mehr gelesen. Vielleicht lasse ich mich hinreißen einen anderen VPN-Server zu installieren. Wenn jemand weiß, wie man unter Windows 2012 RRAS die Routen vom Server aus mitgeben kann, wäre ich für eine Info sehr dankbar.
Ich wünsche eine schöne Weihnachtszeit
Centauri
danke für eure Hilfe.
Kurz zu dir, Buccaneer:
Ich versuche schon, es denen so leicht wie möglich zu machen, die mir hier helfen wollen. Danke für das Lob. Scheine ich es ja nicht ganz falsch gemacht haben.
Die Routen müßte ich auf den Clients setzen, die eine dynamische IP bei jeder Einwahl bekommen. Sicherlich möglich, aber zumindest für mich mit einem nicht unerheblichen Zeitaufwand, dass so dynamisch zu machen. Bei iOS wird das aber glaube nicht gehen.
Zitat von @aqui:
In deinem Design gibt es einen grundlegenden Fehler oder ist es so gewollt das JEDES VLAN seinen eigenen Internet Zugang hat ??
In den klassischen Standardszenarien benutzt man einen zentralen Internet Zugang und die Produktivnetze hängen auf den jeweiligen VLANs.
Soll das so sein bei dir ist dein Konzept oben schlicht falsch !
Dann sähe es so aus:
In deinem Design gibt es einen grundlegenden Fehler oder ist es so gewollt das JEDES VLAN seinen eigenen Internet Zugang hat ??
In den klassischen Standardszenarien benutzt man einen zentralen Internet Zugang und die Produktivnetze hängen auf den jeweiligen VLANs.
Soll das so sein bei dir ist dein Konzept oben schlicht falsch !
Dann sähe es so aus:
- Default VLAN 192.168.0.0/24 mit Internet Router IP 192.168.0.254 und Switch L3 IP 192.168.0.1
- VLAN 200 10.10.20.0/25 mit Switch L3 IP 10.10.20.1 (keine separate Internet Router IP !)
- Windows 2012 Server mit 10.10.20.10. Default Gateway hier dann 10.10.20.1
- Switch hat eine Default Route auf die 192.168.0.254
- Internet Router hat eine statische Route: Ziel: 10.10.20.0, Maske: 255.255.255.0, Gateway: 192.168.0.1
Und genauso ist es konfiguriert. Woran hast du herausgelesen, dass es anders ist? Dann würde ich das an der Beschreibung ändern.
Wenn du einen zentralen DHCP Server betreibst im VLAN 200 mit der IP 10.10.20.11 dann musst du aus dem Default VLAN 1 eine entsprechende DHCP Relay Adresse (IP Helper Adresse) auf den DHCP Server konfigurieren, damit auch DHCP Requests aus dem VLAN 1 den DHCP Server erreichen.
Das kann natürlich entfallen wenn im VLAN 1 keine Endgeräte sind !
Das kann natürlich entfallen wenn im VLAN 1 keine Endgeräte sind !
IP-Helper ist für alle VLANs konfiguriert und die DHCP-Server haben auch nur eine IP im eigenen VLAN (10.10.20.11)
Generell sollte man das Internet VLAN, sprich also den Zugriff auf den Internet Router vom Switch, imemr in ein separates VLAN legen und niemals in eins der Produktiv VLANs für Clients oder Server etc. !!!
Der Internet Traffic sollte davon getrennt sein (Security)
Das wäre das saubere Grundkonzept !
Der Internet Traffic sollte davon getrennt sein (Security)
Das wäre das saubere Grundkonzept !
So ist es geplant. Aber ich muss halt einen gleitenden Übergang machen. Ergo bleibt erstmal das Default-LAN wie es ist und ich ziehe nach und nach die Geräte in die entsprechenden VLANs. Der neue Internetrouter soll dann gleich in sein eigenes VLAN.
Kommen wir mal zum VPN...
Erster gravierender Designfehler ist das VPN in ein internes Netzwerk zu ziehen damit weichst du das Sicherheitskonzept massiv auf.
Generell gehört ein VPN Server auf den Internet Router direkt oder auf eine Firewall dort. Ein Fakt der immer wieder falsch gemacht wird
Erster gravierender Designfehler ist das VPN in ein internes Netzwerk zu ziehen damit weichst du das Sicherheitskonzept massiv auf.
Generell gehört ein VPN Server auf den Internet Router direkt oder auf eine Firewall dort. Ein Fakt der immer wieder falsch gemacht wird
Das ist mir bewusst und nur eine Übergangslösung, bis der neue Router da ist. Dann wird dieser, wie ich geschrieben habe, der VPN-Endpunkt.
Aber nungut...betrachten wir das Design mal.
Ein route print auf dem aktiven VPN Client zeigt dir das !!
Das Routing zwischen den VLANs und ins Internet funktioniert. DHCP funktioniert auch in allen Netzen. VPN-Einwahl geht.
Zeigt das du mit den obigen Einstellungen und Design, auch Port Forwarding für die L2TP VPN Ports auf dem Internet Router alles richtig gemacht hast soweit ! Gut !dass der gesamte Verkehr über das VPN geroutet werden soll.
Das ist klar, denn vermutlich gibt dein VPN Server ohne das nur mit das das 10.10.20er Netz in den VPN Tunnel geroutet wird ?!Ein route print auf dem aktiven VPN Client zeigt dir das !!
Das ist korrekt und mein Problem.
Du musst also dafür sorgen das auch dein 192.168er Netz an den Client bzw. seine Routing Tabelle gepusht wird beim Dialin. Dort hast du also einen Konfig Fehler gemacht oder das Winblows VPN supportet das nicht !
Es ist ja die Frage, ob ich beim Windows VPN nur was übersehen habe, ob der das nicht kann. Das Routen des gesamten Verkehrs über das VPN wäre, wegen unserer schmalen Anbindung ans Internet nicht sehr glücklich. Ich müsste dann das Verteilen der Geräte auf die VLANs erstmal ruhen lassen, bis der neue Router da ist. Dieser wird dann das mitgeben von Routen unterstützen.
Dann hast du in der Tat nur die Chance das Default Gateway auf den Tunnel umzubiegen.
Kollege Buccaneer hat ja schon alles dazu gesagt.
Das Umbiegen wäre auf Windows und Mac vielleicht nicht das Problem, wenn man sich damit etwas auseinander setzt. Auf den iOS-Geräten sehe ich da aber schwarz. Da wüßte ich keine andere Lösung als den gesamten Verkehr zu routen.Kollege Buccaneer hat ja schon alles dazu gesagt.
Ich werde mir auch noch mal die Links von dir anschauen. Habe sie schon länger nicht mehr gelesen. Vielleicht lasse ich mich hinreißen einen anderen VPN-Server zu installieren. Wenn jemand weiß, wie man unter Windows 2012 RRAS die Routen vom Server aus mitgeben kann, wäre ich für eine Info sehr dankbar.
Ich wünsche eine schöne Weihnachtszeit
Centauri
also: ich habe mir gerade nochmal auf einem server 2003 den dhcp-server angesehen. du kannst da schon routen mitgeben. auf dem win2003 ist das option 033 - "statische routenoption" oder 249 "statische routen ohne klassen"
der windows-ras unterstützte immer die vpn einwahl per statischem adresspool oder per dhcp. wenn du das per dhcp auf dem ras konfigurierst, spricht doch nichts dagegen, die option bei der einwahl mitzugeben?
habe das noch nicht realisiert, aber. "why not?"
guten rutsch!
buc
der windows-ras unterstützte immer die vpn einwahl per statischem adresspool oder per dhcp. wenn du das per dhcp auf dem ras konfigurierst, spricht doch nichts dagegen, die option bei der einwahl mitzugeben?
habe das noch nicht realisiert, aber. "why not?"
guten rutsch!
buc
Hallo Buc,
ich wünsche dir und allen anderen hier ein gesundes, glückliches und erfolgreichen 2017.
Die Idee ist wirklich nicht schlecht. RAS war schon auf DHCP konfiguriert. Ich habe inzwischen den RAS-Server in einem separatem VLAN. Ab Windows 2008 (soweit ich das in Erfahrung bringen konnte) ist es dann die Option 121.
Ich habe Routen eingetragen, allerdings werden diese bei VPN-Einwahl ignoriert (Win, MacOS, iOS). Im lokalen Netz hatte zumindest ein Windows-Client diese Option übernommen.
Ich habe mehrere Beiträge gefunden, wo dies, so konfiguriert, funktionieren soll. Ich werde mal weiter suchen. Es scheint der richtige Weg zu sein.
Die aktuelle Konfiguration:
VLAN 1(Default) 192.168.0.0/24
VLAN 200: 10.10.20.0/25
- DHCP Server 10.10.20.11
- Scope 10.10.180.0/24 Option 121: 192.168.0.0 / 255.255.255.0 / 10.10.180.1
VLAN 1800: 10.10.180.0/24
- RAS-Server: 10.10.180.59 mit DHCP-Relay
Danke für den Tipp.
Centauri
ich wünsche dir und allen anderen hier ein gesundes, glückliches und erfolgreichen 2017.
Zitat von @the-buccaneer:
also: ich habe mir gerade nochmal auf einem server 2003 den dhcp-server angesehen. du kannst da schon routen mitgeben. auf dem win2003 ist das option 033 - "statische routenoption" oder 249 "statische routen ohne klassen"
der windows-ras unterstützte immer die vpn einwahl per statischem adresspool oder per dhcp. wenn du das per dhcp auf dem ras konfigurierst, spricht doch nichts dagegen, die option bei der einwahl mitzugeben?
also: ich habe mir gerade nochmal auf einem server 2003 den dhcp-server angesehen. du kannst da schon routen mitgeben. auf dem win2003 ist das option 033 - "statische routenoption" oder 249 "statische routen ohne klassen"
der windows-ras unterstützte immer die vpn einwahl per statischem adresspool oder per dhcp. wenn du das per dhcp auf dem ras konfigurierst, spricht doch nichts dagegen, die option bei der einwahl mitzugeben?
Die Idee ist wirklich nicht schlecht. RAS war schon auf DHCP konfiguriert. Ich habe inzwischen den RAS-Server in einem separatem VLAN. Ab Windows 2008 (soweit ich das in Erfahrung bringen konnte) ist es dann die Option 121.
Ich habe Routen eingetragen, allerdings werden diese bei VPN-Einwahl ignoriert (Win, MacOS, iOS). Im lokalen Netz hatte zumindest ein Windows-Client diese Option übernommen.
Ich habe mehrere Beiträge gefunden, wo dies, so konfiguriert, funktionieren soll. Ich werde mal weiter suchen. Es scheint der richtige Weg zu sein.
Die aktuelle Konfiguration:
VLAN 1(Default) 192.168.0.0/24
VLAN 200: 10.10.20.0/25
- DHCP Server 10.10.20.11
- Scope 10.10.180.0/24 Option 121: 192.168.0.0 / 255.255.255.0 / 10.10.180.1
VLAN 1800: 10.10.180.0/24
- RAS-Server: 10.10.180.59 mit DHCP-Relay
Danke für den Tipp.
Centauri
Ich habe Routen eingetragen, allerdings werden diese bei VPN-Einwahl ignoriert
Das ist für L2TP auch normal, denn das VPN Protokoll kann keine Netze hinter dem VPN Routen. Dafür benötigst du ein anderes VPN Protokoll wie native IPsec oder SSL (OpenVPN) was diese Routen übergeben kann.L2TP macht lediglich simples Bridging.
Mit anderen VPN-Protokollen habe ich es bis jetzt noch nicht versucht.
OpenVPN hab ich mir mal angeschaut, aber soweit ich das verstanden habe, benötigt das einen Linuxhost und einen eigenen Client.
Jetzt geht bei uns der Jahreswechsel langsam zu Ende und ich werde wieder ein bisschen Zeit haben, mich dem zu widmen.
Aqui's Aussage hat mich auch sehr erschrocken. Mehrere Subnetze sind ja nicht gerade eine Erfindung der letzten Jahre.
Sobald ich weiter gekommen bin, werde ich das hier kund tun.
OpenVPN hab ich mir mal angeschaut, aber soweit ich das verstanden habe, benötigt das einen Linuxhost und einen eigenen Client.
Jetzt geht bei uns der Jahreswechsel langsam zu Ende und ich werde wieder ein bisschen Zeit haben, mich dem zu widmen.
Aqui's Aussage hat mich auch sehr erschrocken. Mehrere Subnetze sind ja nicht gerade eine Erfindung der letzten Jahre.
Sobald ich weiter gekommen bin, werde ich das hier kund tun.
soweit ich das verstanden habe, benötigt das einen Linuxhost und einen eigenen Client.
Völliger Quatsch ! Woher hast du so einen Blödsinn ?OVPN rennt auf allen bekannten Betriebssystemen. Einen dedizierten Client braucht es aber, das ist richtig.
https://www.heise.de/download/product/openvpn-gui-38071
Aqui hatte natürlich mal wieder recht. Ich hatte die Setup-Datei für die eines Clients gehalten. OpenVPN läuft jetzt und propagiert auch die Routen in die anderen Subnetze. Nur das Routing vom OpenVPN-Server weg klappt noch nicht. Aber das ist ein anderes Problem. Ich setze das hier deswegen auf erfüllt.
Danke für die Unterstützung.
Danke für die Unterstützung.
Nur das Routing vom OpenVPN-Server weg klappt noch nicht.
Mmmhhh, falsches Gateway dort ??Was häufig nicht bedacht wird:
Wenn du Endgeräte im OpenVPN Server Netzwerk erreichen willst haben die meist als Default Gateway den dortigen Internet Router, wie der OVPN Server ja auch.
Intern nutzt das OVPN aber ein anderes IP Netz, nämlich das was du mit server xyz... in der Konfig Datei definierst.
Wenn so ein Client jetzt mit der OVPN Netz Absender IP im lokalen Netzwerk ein Endgerät erreicht muss das ja antworten und da die Absender IP ja ein fremdes IP Netz ist schickt dieses Endgerät das jetzt zum Internet Router seinem Gateway.
Fehlt dort eine statische Route auf das interne OVPN Netzwerk mit Next Hop IP lokale IP OVPN Server, dann gehen die Antwortpakete zum Provider und damit ins Nirwana.
Möglich das das ebenso dein Fehler ist... ?!
Deine Freunde sind hier Traceroute (Windows: tracert) oder Pathping. Die zeigen dir die einzelnen Routinghops an.
Da wo es nicht weitergeht ist auch immer der Fehler
Ich denke ich habe den Fehler gefunden. Ich habe auf dem L3-Switch eine Route in das VLAN gesetzt, in dem der Open-VPN-Rechner läuft.
10.10.180.1 L3-Switch
10.10.180.50 IP Windows-Server mit OpenVPN-Software
10.10.181.1 IP OpenVPN-Server
10.10.181.4 IP OpenVPN Client (iOS)
Die Route auf dem Switch lautet 10.10.181.0 GW 10.10.180.1
Ich bekomme einen Timeout auf dem Switch und ein Zielnetz nicht erreichbar von einem anderen VLAN aus. Von dem iOS-Client erreiche ich aber den Internet-Router (192.168.0.254) aber nicht andere Netze als 180 und 181. Deswegen bin ich mir sicher dass, das Problem auf dem L3-Switch liegt. Der L3-Switch ist Defaultgateway und routet alles unbekannte dann zum Internetrouter weiter.
-- Edit --
Ich habe das Problem jetzt gelöst. Die Route auf dem L3-Switch habe ich gelöscht. Dafür habe ich eine Router auf dem Internetrouter gesetzt. Jetzt geht es von iOS aus.
-- Edit Ende --
Ein anderes Problem:
Bisher habe ich immer mit iOS getestet, weil ich es da am meisten benötigt habe. Da ich da aber nun nicht weiter kam zwecks Routineanalyse, wollte ich es mit MacOS und Windows probieren. Natürlich geht es da gar nicht.
Nachdem er den OpenVPN-Gateway-Namen aufgelöst hat, kommt diese Fehlermeldung:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Aus dem gleichen Netz geht es aber mit iOS. Gleiche Konfigdatei. Ich versteh es nicht. Firewall auf den Clients sind aus.
10.10.180.1 L3-Switch
10.10.180.50 IP Windows-Server mit OpenVPN-Software
10.10.181.1 IP OpenVPN-Server
10.10.181.4 IP OpenVPN Client (iOS)
Die Route auf dem Switch lautet 10.10.181.0 GW 10.10.180.1
Ich bekomme einen Timeout auf dem Switch und ein Zielnetz nicht erreichbar von einem anderen VLAN aus. Von dem iOS-Client erreiche ich aber den Internet-Router (192.168.0.254) aber nicht andere Netze als 180 und 181. Deswegen bin ich mir sicher dass, das Problem auf dem L3-Switch liegt. Der L3-Switch ist Defaultgateway und routet alles unbekannte dann zum Internetrouter weiter.
-- Edit --
Ich habe das Problem jetzt gelöst. Die Route auf dem L3-Switch habe ich gelöscht. Dafür habe ich eine Router auf dem Internetrouter gesetzt. Jetzt geht es von iOS aus.
-- Edit Ende --
Ein anderes Problem:
Bisher habe ich immer mit iOS getestet, weil ich es da am meisten benötigt habe. Da ich da aber nun nicht weiter kam zwecks Routineanalyse, wollte ich es mit MacOS und Windows probieren. Natürlich geht es da gar nicht.
Nachdem er den OpenVPN-Gateway-Namen aufgelöst hat, kommt diese Fehlermeldung:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
Aus dem gleichen Netz geht es aber mit iOS. Gleiche Konfigdatei. Ich versteh es nicht. Firewall auf den Clients sind aus.
Die Route auf dem Switch lautet 10.10.181.0 GW 10.10.180.1
Sorry, aber du siehst doch selber das das routingtechnischer Schwachsinn ist.Die Route besagt ja das der Switch alle Pakete die eine Zieladresse von 10.10.181.x haben an sich selbst senden soll.
Er aber kennt ja das 10.10.181.0er netz gar nicht.
In sofern ist die Route doch Quatsch !
Gehen wir mal davon aus das das 10.10.181.0er Netz das interne OVPN Netz ist dann müsste die Route auf dem Switch syntaktisch und logisch richtig so lauten:
10.10.181.0 Maske 255.255.255.0 Gateway 10.10.180.50
Das geht jetzt mal davon aus das dein 10er Netz mit einer 24Bit Maske segmentiert ist ?! Ist das der Fall ??
Die Route auf dem L3-Switch habe ich gelöscht. Dafür habe ich eine Router auf dem Internetrouter gesetzt.
Wenn sie genau ist wie die oben gepostete ist das genauso blödsinnig.Ohne eine kurze Skizze WIE dein Netzwerk aussieht, wie es segmentiert ist auf dem L3 Switch und Netzadressen der Segmente kommen wir hier nicht wirklich weiter !
Da ich da aber nun nicht weiter kam zwecks Routineanalyse, wollte ich es mit MacOS und Windows probieren. Natürlich geht es da gar nicht.
Mmmhhh ist auch logisch und sagt einem schon der gesunde Menschenverstand.MacOS hat z.B. gar keinen OVPN Client an Bord. Dort benötigst du einen entsprechenden OVPN Client wie Tunnelblick:
https://tunnelblick.net
Bei Windows natürlich entsprechend...
Bei Windows lauert noch die Firewall als weitere Gefahr.
Da Winblows auf dem virtuellen tap VPN Interface kein Gateway erkennt deklariert es das Netz dort als Public und blockt somit sämtlichen Inbound Traffic auf dem VPN Interface.
Das musst du in den Winblows FW Settings entsprechend anpassen.
Beim Mac funktioniert das natürlich auf Anhieb !
Der Fehler:
https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tl ...
..lässt darauf schliessen das du irgendwo im Mac und Winblows Client Pfad eine Firewall (kann auch die lokale a.d. Rechner sein !) oder ein NAT Gateway (IP Adress Translation) hast und dort den OVPN Port UDP 1139 nicht freigegeben hast.
Das ist so der 98% Klassiker bei diesem Fehler.
Zitat von @aqui:
Du hast ja sowas von Recht. Keine Ahnung, warum ich das nicht selbst gesehen habe.Die Route auf dem Switch lautet 10.10.181.0 GW 10.10.180.1
Sorry, aber du siehst doch selber das das routingtechnischer Schwachsinn ist.Das geht jetzt mal davon aus das dein 10er Netz mit einer 24Bit Maske segmentiert ist ?! Ist das der Fall ??
ja, alles 24er oder 25er Masken.Ohne eine kurze Skizze WIE dein Netzwerk aussieht, wie es segmentiert ist auf dem L3 Switch und Netzadressen der Segmente kommen wir hier nicht wirklich weiter !
Skizze hänge ich mal am Startbeitrag an.Da ich da aber nun nicht weiter kam zwecks Routineanalyse, wollte ich es mit MacOS und Windows probieren. Natürlich geht es da gar nicht.
Mmmhhh ist auch logisch und sagt einem schon der gesunde Menschenverstand.MacOS hat z.B. gar keinen OVPN Client an Bord. Dort benötigst du einen entsprechenden OVPN Client wie Tunnelblick:
https://tunnelblick.net
Bei Windows natürlich entsprechend...
Bei Windows lauert noch die Firewall als weitere Gefahr.
Da Winblows auf dem virtuellen tap VPN Interface kein Gateway erkennt deklariert es das Netz dort als Public und blockt somit sämtlichen Inbound Traffic auf dem VPN Interface.
Das musst du in den Winblows FW Settings entsprechend anpassen.
FW ist aus und die OpenVPN.exe habe ich als Ausnahme hinzugefügt. Unter Windows habe ich noch nicht die eigentlichen Regeln geprüft. Werde ich noch machen.Da Winblows auf dem virtuellen tap VPN Interface kein Gateway erkennt deklariert es das Netz dort als Public und blockt somit sämtlichen Inbound Traffic auf dem VPN Interface.
Das musst du in den Winblows FW Settings entsprechend anpassen.
Beim Mac funktioniert das natürlich auf Anhieb !
Eben nicht.Der Fehler:
https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tl ...
..lässt darauf schliessen das du irgendwo im Mac und Winblows Client Pfad eine Firewall (kann auch die lokale a.d. Rechner sein !) oder ein NAT Gateway (IP Adress Translation) hast und dort den OVPN Port UDP 1139 nicht freigegeben hast.
Das ist so der 98% Klassiker bei diesem Fehler.
Den Artikel habe ich gelesen. Auf dem Mac habe ich die interne FW und little Snitch deaktiviert. Auf dem Router ist kein Portforwarding aktiv. Mit einem iPhone aus dem selben Netz, wie der Mac, geht es.https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tl ...
..lässt darauf schliessen das du irgendwo im Mac und Winblows Client Pfad eine Firewall (kann auch die lokale a.d. Rechner sein !) oder ein NAT Gateway (IP Adress Translation) hast und dort den OVPN Port UDP 1139 nicht freigegeben hast.
Das ist so der 98% Klassiker bei diesem Fehler.
A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
Kann ich ausschließen, da es mit iOS geht.A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
Das selbe. iOS läuft.A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
Portforwarding zum OpenVPN-Server ist auf 192.168.0.254 eingerichtet.The OpenVPN client config does not have the correct server address in its config file.
Ist das selbe Configfile, wie auf iOS. Name wird korrekt aufgelöst.The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
Zeigt auf den DNS-Namen des GW.Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.
Habe ich unter Windows getan. Unter MacOS hab ich die Tunnelblick.App in die Firewalllisten eingetragen.Noch eine Idee? Wenn es erstmal unter MacOS läufen würde, wäre eine Hürde getan.
Portforwarding zum OpenVPN-Server ist auf 192.168.0.254 eingerichtet.
Ist das die lokale LAN IP Adresse des OVPN Servers ??Das Port Forwarding muss natürlich auf die lokale IP Adresse des OVPN Servers gemacht werden. Ansonsten gehen die eingehenden OVPN Pakete ins Nirwana....
Sollte die 192.168.0.254 einen Switch IP sein schmeisst der das Paket logischerweise gleich weg, denn der hat ja gar keinen Dienst für UDP 1139 sprich OVPN laufen.
Nicht das du hier einen Denkfehler im Port Forwarding machst... ?!
Zum Checken ob das Port Forwarding sauber rennt und ob die UDP 1139 überhaupt am OVPN Server ankommen lässt du ganz eichfach mal einen Wireshark dort mitlaufen und checkst ob die UDP 1139 Paket dort überhaupt ankommen.
Wenn dein OVPN Server Linux basierend ist geht z.B. auch tcpdump.
tcpdump port 1139 zeigt dir dann ale eingehenden OVPN Pakete an.
Damit kannst du schnell und einfach checken ob deine VPN Client Pakete am Server ankommen.
Idealerweise testest du Mac und Winblows Client mal in einem separaten Test VLAN an deinem lokalen L3 Switch.
Auch das geht sehr schnell und damit kannst du ohne lästige NAT und Port Forwarding erstmal generell klären ob die Clients einen Tunnel aufbauen.
Das Client UND auch das Server Log sind hier wie immer deine besten Freunde
