MS VPN-Server und Routing
Hallo zusammen.
Ich habe folgendes Konstrukt
Externe Benutzer wählen sich über den MS VPN Server ein. Das klappt auch wunderbar.
( VPN-Server vergibt IP Adressen aus dem Segment 192.168.255x )
Wenn jetzt ein remoteclient in zb. das Segment 192.168.250.x möchte klappt das nicht.
Habt Ihr eine Idee wie ich das hingebekomme ?
Vielen Dank im voraus
hier war der Fehler in den eigenschaften der VPN Verbindung
Ich habe folgendes Konstrukt
Externe Benutzer wählen sich über den MS VPN Server ein. Das klappt auch wunderbar.
( VPN-Server vergibt IP Adressen aus dem Segment 192.168.255x )
Wenn jetzt ein remoteclient in zb. das Segment 192.168.250.x möchte klappt das nicht.
Habt Ihr eine Idee wie ich das hingebekomme ?
Vielen Dank im voraus
hier war der Fehler in den eigenschaften der VPN Verbindung
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 276048
Url: https://administrator.de/contentid/276048
Ausgedruckt am: 05.11.2024 um 12:11 Uhr
9 Kommentare
Neuester Kommentar
Dir fehlt schlicht und einfach ein Routing in diese beiden Netze !!
Trage das nach am Router und am VPN Server mit einer simplen statischen IP Route und fertig ist der Lack.
In max. 3 Minuten ist das gefixt !
Kann deine VPN Lösung (hilfreich wäre hier verwendetes Protokoll und HW gewesen) diese Routen nicht dynamisch an den VPN Client distribuieren hilft auch eine statische Route ala
route add <Zielnetz> mask <Maske_Zielnetz> <Gateway_IP> -p
auf dem Client Ist aber die technisch schlechtere Variante. Die remoten IP Netze sollten dem VPN Client immer dynamisch übermittelt werden.
OpenVPN macht das z.B. mit dem push route Kommando.
Ob Daten Pakete für diese VPN Zielnetz in den Tunnel geroutet werden kannst du bei eingewähltem VPN Client immer mit dem Kommando route print (Winblows OS) herausbekommen !
Danach sind Traceroute (tracert) und Pathping immer deine besten Freunde beim Troubleshooten
Trage das nach am Router und am VPN Server mit einer simplen statischen IP Route und fertig ist der Lack.
In max. 3 Minuten ist das gefixt !
Kann deine VPN Lösung (hilfreich wäre hier verwendetes Protokoll und HW gewesen) diese Routen nicht dynamisch an den VPN Client distribuieren hilft auch eine statische Route ala
route add <Zielnetz> mask <Maske_Zielnetz> <Gateway_IP> -p
auf dem Client Ist aber die technisch schlechtere Variante. Die remoten IP Netze sollten dem VPN Client immer dynamisch übermittelt werden.
OpenVPN macht das z.B. mit dem push route Kommando.
Ob Daten Pakete für diese VPN Zielnetz in den Tunnel geroutet werden kannst du bei eingewähltem VPN Client immer mit dem Kommando route print (Winblows OS) herausbekommen !
Danach sind Traceroute (tracert) und Pathping immer deine besten Freunde beim Troubleshooten
Hallo das Standart Gateway auf dem VPN-Servers zeigt bereits auf den Router
Das besagt aber ja noch lange nicht das der VPN Server diese Routen auch den Clients bei der VPN Einwahl mit übergibt !!!WAS also sagt ein route print bei eingewähltem Client ??
Kannst du dort sehen das das 192.168.249.0 /24 und auch das 192.168.250.0 /24 Netz mit über den Tunnel auf den .255er Server geroutet werden ??
Vermutlich wohl nicht, oder ?
Wenn nein, ist es a) einen Fehlkonfiguration des VPN Gateways deinerseits, und b) schickt der Client diese Pakete logischerweise dann an sein lokales Default Gateway was es dann ins Internet schickt. Da das alles RFC 1918 private IPs sind gehen diese Pakete in den Netzwerk Orcus !
Fazit: Verbindung in diese Netze schlägt fehl...genau das Verhalten also was du siehst !!
Nein, das war kein Fehler sondern du hast die Schrotschusslösung gewählt.
Der Haken bewirkt nun das sämtlicher Traffic und Internettraffic des Clients in den Tunnel geleitet wird und nicht nur dein spezifischer für die beiden remoten Netze. Aus Performancegründen ist das kontraproduktiv und hätte man auch granularer lösen können aber wenns für dich reicht und dein Problem fixt ist ja alles gut
Der Haken bewirkt nun das sämtlicher Traffic und Internettraffic des Clients in den Tunnel geleitet wird und nicht nur dein spezifischer für die beiden remoten Netze. Aus Performancegründen ist das kontraproduktiv und hätte man auch granularer lösen können aber wenns für dich reicht und dein Problem fixt ist ja alles gut
Jein ! Denn die Routen müssen ja an den VPN Client propagiert werden damit der bei VPN Einwahl diese Routen dynamisch übermittelt bekommt uns so weiss das er Traffic für die beiden anderen remoten Netze AUCH in den Tunnel routen muss.
Meist passiert das auch wenn der VPN Server diese statischen Routen hat.
Relevant ist aber logischerweise der Client ! Der Server sorgt nur dafür das er diese Routen auch bekommt !
Meist passiert das auch wenn der VPN Server diese statischen Routen hat.
Relevant ist aber logischerweise der Client ! Der Server sorgt nur dafür das er diese Routen auch bekommt !
route print ergab ergab folgendes:
Und ??? Kannst du dort irgendeinen gültigen Eintrag für das 192.168.250.0 /24 Netz sehen auf das du Pingen willst ???Siehste, deshalb ist ein Ping Versuch dahin auch komplett sinnfrei, denn den schickt der Client dann an sein Default Gateway und damit dann ins Nirwana !
Deinem Client fehlt schlicht und einfach die Route ins 192.168.250.0 /24er Netz !!! Wie oben schon lang und breit beschrieben !
und wenn ich pingen wollte kommt das:
Klar...wie zu erwarten...siehe oben !Vermutlich routet der Default Router etwas weiter an einen Router in diesem 10er Netz und der hat dann keine Route ins .250.0er Netz, deshalb die kryptische Meldung !
Auch hier wieder: Warum hast du kein Traceroute oder Pathping auf das .250.0er Netz gemacht oder hier mal gepostet ???
Das zeigt dir Hop für Hop den Routing Weg und hätte uns alle hier einen Schritt weiter gebracht...
Denn da wo es nicht mehr weitergeht fehlt auch die Route !
Zum 10er Netz solltest du wohl erstmal deine Hausaufgaben machen und deine Netzwerkstruktur besser kennenlernen ?!
Irgend jemand hat ja eine Route dahin definiert !!
Kann aber auch sein das du einen Provider DS-Light anschluss hast oder LTE wo der Provider private RFC 1918 IP Adresen in seinem Backbone benutzt ?! Aber auch das verschweigst du uns ja leider und zwingst uns zum Blickt in die Kristallkugel