7
Server 2016 mit RAS - SSTP VPN - Routen fehlen
Hi zusammen,
Vielleicht könnt ihr mir helfen - ich habe einen Server 2016 mit RAS und SSTP VPN aktiviert.
Dieser VPN funktioniert einwandfrei.
Intern gibt es ein 10.16.1.0/24 Netzwerk und per IPSec ist ein 10.17.1.0/24er Netzwerk angebunden.
Wenn sich nun der Client per SSTP VPN ohne Remote Gateway in das 10.16.1.0/24er verbindet, kommt er ebenfalls in der 10.17.1.0/24er Netzwerk
Soweit so gut - nun gibt es aber am Router vom 10.16.1.0/24 noch 2 weitere Netzwerke 192.168.22.0/24 und 192.168.20.0/24 welche ich per SSTP VPN ebenfalls erreichen will.
Leider gekomme ich das nicht hin - könnt ihr mir vielleicht ein paar Tipps geben?
DANKE
Vielleicht könnt ihr mir helfen - ich habe einen Server 2016 mit RAS und SSTP VPN aktiviert.
Dieser VPN funktioniert einwandfrei.
Intern gibt es ein 10.16.1.0/24 Netzwerk und per IPSec ist ein 10.17.1.0/24er Netzwerk angebunden.
Wenn sich nun der Client per SSTP VPN ohne Remote Gateway in das 10.16.1.0/24er verbindet, kommt er ebenfalls in der 10.17.1.0/24er Netzwerk
Soweit so gut - nun gibt es aber am Router vom 10.16.1.0/24 noch 2 weitere Netzwerke 192.168.22.0/24 und 192.168.20.0/24 welche ich per SSTP VPN ebenfalls erreichen will.
Leider gekomme ich das nicht hin - könnt ihr mir vielleicht ein paar Tipps geben?
DANKE
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: 499919
Url: https://administrator.de/forum/server-2016-mit-ras-sstp-vpn-routen-fehlen-499919.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Windows VPN mit SSTP supportet kein automatisches "Pushen" von Routen zum Client. Microsoft hat diese Option nicht implementiert und auch nicht vorgesehen. In so fern ist SSTP bei einem Split Tunneling Betrieb das falsche VPN Protokoll !
Deine einzige Chance ist STP mit einem Gateway Redirect zu konfigurieren also den gesamten Traffic des VPN SSTP Clients in den Tunnel zu routen. Oder du musst dir mit Power Shell ein Script selber stricken was dir per "route add xyz..." die statischen Routen in deine beiden 192.168er Netze dann in die Routing Tabelle addiert sobald dein SSTP Client aktiv ist.
Eine andere Lösung gibt es bei Verwendung von SSTP nicht.
Deine einzige Chance ist STP mit einem Gateway Redirect zu konfigurieren also den gesamten Traffic des VPN SSTP Clients in den Tunnel zu routen. Oder du musst dir mit Power Shell ein Script selber stricken was dir per "route add xyz..." die statischen Routen in deine beiden 192.168er Netze dann in die Routing Tabelle addiert sobald dein SSTP Client aktiv ist.
Eine andere Lösung gibt es bei Verwendung von SSTP nicht.
Danke für deine Infos - welche Protokollen wären dann dafür auf einen Windows RAS das richtige?
Bei L2TP brauche ich aber immer das Remote Gateway am Client aktiv richtig?
Das Problem bei Langsamen Road warriors ist das dann alles relativ langsam geht.
Bei L2TP brauche ich aber immer das Remote Gateway am Client aktiv richtig?
Das Problem bei Langsamen Road warriors ist das dann alles relativ langsam geht.
Wenn du auf Split Tunneling angewiesen bist dann immer IPsec oder ein SSL basiertes wie OpenVPN z.B.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Hi.
Und statt das VPN auf einem Winblows Server zu terminieren besser gleich das VPN auf einer entsprechende Router-Instanz terminieren statt den Winblows-Server dem Netz auszusetzen, da fliegt dir das Konstrukt ganz schnell um die Ohren. Und wenn es nur eine OpenSense/pfSense VM ist, allemal besser als ne Windose als VPN Responder zu nutzen!
Als schnelle Alternative zu OpenVPN kann ich dir inzwischen auch Wireguard sehr ans Herz legen. Es ist schnell, ressourcensparend. kommt auch mit instabilen Verbindungen sehr gut klar und die Einrichtung ist in Nullkommanix auch von Laien aufgsetzt.
Gruß
Und statt das VPN auf einem Winblows Server zu terminieren besser gleich das VPN auf einer entsprechende Router-Instanz terminieren statt den Winblows-Server dem Netz auszusetzen, da fliegt dir das Konstrukt ganz schnell um die Ohren. Und wenn es nur eine OpenSense/pfSense VM ist, allemal besser als ne Windose als VPN Responder zu nutzen!
Als schnelle Alternative zu OpenVPN kann ich dir inzwischen auch Wireguard sehr ans Herz legen. Es ist schnell, ressourcensparend. kommt auch mit instabilen Verbindungen sehr gut klar und die Einrichtung ist in Nullkommanix auch von Laien aufgsetzt.
Gruß
Schneller in der Übertragung (Durchsatz) ist WireGuard im Vergleich zu OpenVPN nicht, das ist Unsinn. Die Einrichtung über die Schlüssel ist in der Tat etwas einfacher zu handhaben und unkomplizierter je nach Sichtweise. OpenVPN supportet ja auch ein shared Secret was einfach zu handhaben ist, wenn einem das als Sicherheit reicht.
Man sollte nicht vergesen das WireGuard noch immer Beta Status hat. Für jemand der sich mit IT und VPN auskennt kein Thema aber bei einem reinen Anwender sollte man es derzeit besser noch nicht in Produktion einsetzen.
Man sollte nicht vergesen das WireGuard noch immer Beta Status hat. Für jemand der sich mit IT und VPN auskennt kein Thema aber bei einem reinen Anwender sollte man es derzeit besser noch nicht in Produktion einsetzen.
Zitat von @aqui:
Schneller in der Übertragung (Durchsatz) ist WireGuard im Vergleich zu OpenVPN nicht, das ist Unsinn.
Das ist richtig, darauf wollte ich aber nicht hinaus, aber es ist weit effizienter in der Handhabung der Verschlüsselung und benötigt diesbezüglich auf Client und Server weniger Performance.Schneller in der Übertragung (Durchsatz) ist WireGuard im Vergleich zu OpenVPN nicht, das ist Unsinn.
Wenn du mal OpenVPN und Wireguard auf einem Androiden vergleichst sind das Welten. Auf anderen OS lässt sich das auch nachstellen.
Das ist in der Tat richtig...
