VPN Windows 2008 R2 , Einwahl OK , Kein Routing
Moin.
Systemumgebung: Windows 2008 R2 mit Routing & RAS Dienst, eine LAN-Karte, IP:192.168.73.1,
DHCP-Bereich für VPN Einwahl 192.168.80.X (192.168.80.100 für den Server)
Lancom 1723 Router
Aus historischen Gründen wird der Lancom nicht für die VPN Einwahl verwendet, sondern die VPN Einwahl wird über Port 1723 zum Windows 2008 R2 maskiert.
Nun funktioniert die VPN Einwahl, jedoch wird nicht geroutet. Die Clients erhalten IPs aus dem 192.168.80.X und können sich selbst anpingen, jedoch nicht den Server auf seiner "VPN"-Adresse 192.168.80.100. Die "interne" Serveradresse 192.168.73.1 wird jedoch nicht erreicht.
Das komische ist, manchmal funktioniert das Routing, d.h. das Netzwerk 192.168.73.X wird erreicht.
Idee?
Gruß
Michael
Systemumgebung: Windows 2008 R2 mit Routing & RAS Dienst, eine LAN-Karte, IP:192.168.73.1,
DHCP-Bereich für VPN Einwahl 192.168.80.X (192.168.80.100 für den Server)
Lancom 1723 Router
Aus historischen Gründen wird der Lancom nicht für die VPN Einwahl verwendet, sondern die VPN Einwahl wird über Port 1723 zum Windows 2008 R2 maskiert.
Nun funktioniert die VPN Einwahl, jedoch wird nicht geroutet. Die Clients erhalten IPs aus dem 192.168.80.X und können sich selbst anpingen, jedoch nicht den Server auf seiner "VPN"-Adresse 192.168.80.100. Die "interne" Serveradresse 192.168.73.1 wird jedoch nicht erreicht.
Das komische ist, manchmal funktioniert das Routing, d.h. das Netzwerk 192.168.73.X wird erreicht.
Idee?
Gruß
Michael
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 222923
Url: https://administrator.de/forum/vpn-windows-2008-r2-einwahl-ok-kein-routing-222923.html
Ausgedruckt am: 08.05.2025 um 19:05 Uhr
13 Kommentare
Neuester Kommentar
Hallo Michael,
das sieht mir sehr nach falsch gesetztem Gateway auf den Clients aus.
Wenn du in den VPN-Eigenschaften der Clients das Häkchen "Gateway des Remote-Netzwerks verwenden" setzt, sollten sie normalerweise problemlos in das 73er Netz kommen. Wenn dieser Haken nicht gesetzt ist kennen die Clients dann zwar das 80er Netz aber das 73er kennen sie nicht, woher auch. Wenn du also nicht den VPN Server als Gateway auf den Clients verwenden willst musst du dort eine statische Route in das 73 Netz setzen.
Das der Server nicht auf ICMP-Requests reagiert liegt dann sehr wahrscheinlich an der Firewall des Servers der Pings nur aus seinem eigenen Subnetz (192.168.73.x) annimmt.
Bitte beachte das bei Verwendung des VPN-Gateways auf den Clients dessen gesamter Internet-Traffic über das VPN läuft...
Grüße Uwe
das sieht mir sehr nach falsch gesetztem Gateway auf den Clients aus.
Wenn du in den VPN-Eigenschaften der Clients das Häkchen "Gateway des Remote-Netzwerks verwenden" setzt, sollten sie normalerweise problemlos in das 73er Netz kommen. Wenn dieser Haken nicht gesetzt ist kennen die Clients dann zwar das 80er Netz aber das 73er kennen sie nicht, woher auch. Wenn du also nicht den VPN Server als Gateway auf den Clients verwenden willst musst du dort eine statische Route in das 73 Netz setzen.
Das der Server nicht auf ICMP-Requests reagiert liegt dann sehr wahrscheinlich an der Firewall des Servers der Pings nur aus seinem eigenen Subnetz (192.168.73.x) annimmt.
Bitte beachte das bei Verwendung des VPN-Gateways auf den Clients dessen gesamter Internet-Traffic über das VPN läuft...
Grüße Uwe
Zitat von @colinardo:
Hallo Michael,
das sieht mir sehr nach falsch gesetztem Gateway auf den Clients aus.
Wenn du in den VPN-Eigenschaften der Clients das Häkchen "Gateway des Remote-Netzwerks verwenden" setzt, sollten
sie normalerweise problemlos in das 73er Netz kommen. Wenn dieser Haken nicht gesetzt ist kennen die Clients dann zwar das 80er
Netz aber das 73er kennen sie nicht, woher auch. Wenn du also nicht den VPN Server als Gateway auf den Clients verwenden willst
musst du dort eine statische Route in das 73 Netz setzen.
Das der Server nicht auf ICMP-Requests reagiert liegt dann sehr wahrscheinlich an der Firewall des Servers der Pings nur aus
seinem eigenen Subnetz (192.168.73.x) annimmt.
Bitte beachte das bei Verwendung des VPN-Gateways auf den Clients dessen gesamter Internet-Traffic über das VPN
läuft...
Grüße Uwe
Hallo Michael,
das sieht mir sehr nach falsch gesetztem Gateway auf den Clients aus.
Wenn du in den VPN-Eigenschaften der Clients das Häkchen "Gateway des Remote-Netzwerks verwenden" setzt, sollten
sie normalerweise problemlos in das 73er Netz kommen. Wenn dieser Haken nicht gesetzt ist kennen die Clients dann zwar das 80er
Netz aber das 73er kennen sie nicht, woher auch. Wenn du also nicht den VPN Server als Gateway auf den Clients verwenden willst
musst du dort eine statische Route in das 73 Netz setzen.
Das der Server nicht auf ICMP-Requests reagiert liegt dann sehr wahrscheinlich an der Firewall des Servers der Pings nur aus
seinem eigenen Subnetz (192.168.73.x) annimmt.
Bitte beachte das bei Verwendung des VPN-Gateways auf den Clients dessen gesamter Internet-Traffic über das VPN
läuft...
Grüße Uwe
Moin.
Danke für die Antwort. So einfach ist es leider nicht.
"Standardgateway für dasd Remotenetzwerk verwenden" ist aktiviert. Dennoch kein Routing.
Die Konfiguration des Clients nach VPN-Einwahl für den VPN-Adapter sieht z.B. wie folgt aus:
IP: 192.168.80.105
Subnetzmaske: 255.255.255.0
Standardgateway: 0.0.0.0
DNS-Server: 192.168.73.1
Auch wenn ich auf dem Client manuell eine Route anlege funktioniert es nicht, z.B. route add 192.168.73.0 mask 255.255.255.0 192.168.80.100 metric 1
Was ja auch verständlich ist, da ich ja auch nicht die 192.168.80.100 erreiche.
Ich denke das Problem ist auf dem Server zu suchen.
Gruß
Michael
Kollege colinardo hat aber schon recht. Die Default Gateways aller Endgeräte im Netz zeigen vermutlich auf den Lancom. Bei dir ist aber der Server das Tunnelgateway für das VPN, da er ja den VPN Server darstellt. Folglich musst du also am Lancom eine statische Route auf die P2P Adressen des VPNs auf die Server IP konfigurieren, das sollte dein Problem lösen.
Ansonsten erklärt dieses Tutorial die Details:
VPNs einrichten mit PPTP
Dadurch das du unsinnigerweise nicht den Lancom zur VPN Realisierung benutzt hast du 2 Gateways und musst das berücksichtigen.
Wie immer sind hier Traceroute und Pathping sowie route print auf dem Client deine besten Freunde zum Troubleshooting.
Nochwas… Was bedeutet "die VPN Einwahl wird über Port 1723 zum Windows 2008 R2 maskiert…" ?? Was bitte wird hier "maskiert" oder meinst du ein Port Forwarding auf dem Router ??
Letzteres wäre dann richtig.
Bedenke auch immer das TCP 1723 nur die halbe Miete bei PPTP VPNs ist !!! Der eigentliche Datentraffic wird in einem GRE Tunnel übertragen ! PPTP besteht also immer aus 2 Komponenten einmal TCP 1723 und einmal dem GRE Protokoll mit der IP Nummer 47 (GRE ist ein eigenes IP Protokoll ohne TCP/UDP Ports).
Wenn dann musst du also TCP 1723 und GRE im Lancom forwarden oder "maskieren" wie du es bezeichnest. Nur TCP 1723 führt dazu das das VPN nicht funktioniert genau so wie aktuell bei dir !
Das o.a. Tutorial zeigt das richtige Port Forwarding auch noch einmal am Beispiel einer FritzBox.
Ansonsten erklärt dieses Tutorial die Details:
VPNs einrichten mit PPTP
Dadurch das du unsinnigerweise nicht den Lancom zur VPN Realisierung benutzt hast du 2 Gateways und musst das berücksichtigen.
Wie immer sind hier Traceroute und Pathping sowie route print auf dem Client deine besten Freunde zum Troubleshooting.
Nochwas… Was bedeutet "die VPN Einwahl wird über Port 1723 zum Windows 2008 R2 maskiert…" ?? Was bitte wird hier "maskiert" oder meinst du ein Port Forwarding auf dem Router ??
Letzteres wäre dann richtig.
Bedenke auch immer das TCP 1723 nur die halbe Miete bei PPTP VPNs ist !!! Der eigentliche Datentraffic wird in einem GRE Tunnel übertragen ! PPTP besteht also immer aus 2 Komponenten einmal TCP 1723 und einmal dem GRE Protokoll mit der IP Nummer 47 (GRE ist ein eigenes IP Protokoll ohne TCP/UDP Ports).
Wenn dann musst du also TCP 1723 und GRE im Lancom forwarden oder "maskieren" wie du es bezeichnest. Nur TCP 1723 führt dazu das das VPN nicht funktioniert genau so wie aktuell bei dir !
Das o.a. Tutorial zeigt das richtige Port Forwarding auch noch einmal am Beispiel einer FritzBox.
Moin.
Im Lancom ist ein Port Forwarding von Port 1723 auf IP 192.168.73.1 (der VPN-Server 2008R2) konfiguriert. GRE leitet der Lancom automatisch weiter. Das Routing für 192.168.80.0/255.255.255.0 über 192.168.73.1 ist auch schon drin. Das ganze hatte ja auch schon funktioniert.
Was mich wundert und zur Annahme führt, daß der Server das Problem hat:
- Der Server kann sich selber anpingen auf 192.168.80.100, jedoch nicht einen eingewählten Client mit z.B. IP 192.168.80.107. Da dürfte der Lancom ja gar nichts mit zu tun haben. Kann es sein, daß der Server nicht routet zwischen dem internen und dem VPN-Netzwerk?
- Von einem anderen Rechner im 192.168.73.0 Netz kann ich den Server nicht auf seiner IP 192.168.80.100 erreichen. Gateway ist der Lancom auf 192.168.73.3. Ein Tracert zeigt, daß zuerst der Lancom gefragt wird, dann nur noch Zeitüberschreitungen.
Hilft uns vielleicht eine der Tracedateien in C:\windows\tracing weiter?
Gruß
Michael
Im Lancom ist ein Port Forwarding von Port 1723 auf IP 192.168.73.1 (der VPN-Server 2008R2) konfiguriert. GRE leitet der Lancom automatisch weiter. Das Routing für 192.168.80.0/255.255.255.0 über 192.168.73.1 ist auch schon drin. Das ganze hatte ja auch schon funktioniert.
Was mich wundert und zur Annahme führt, daß der Server das Problem hat:
- Der Server kann sich selber anpingen auf 192.168.80.100, jedoch nicht einen eingewählten Client mit z.B. IP 192.168.80.107. Da dürfte der Lancom ja gar nichts mit zu tun haben. Kann es sein, daß der Server nicht routet zwischen dem internen und dem VPN-Netzwerk?
- Von einem anderen Rechner im 192.168.73.0 Netz kann ich den Server nicht auf seiner IP 192.168.80.100 erreichen. Gateway ist der Lancom auf 192.168.73.3. Ein Tracert zeigt, daß zuerst der Lancom gefragt wird, dann nur noch Zeitüberschreitungen.
Hilft uns vielleicht eine der Tracedateien in C:\windows\tracing weiter?
Gruß
Michael
Moin.
Ist das so eigentlich richtig? Wenn ich mir im Routing und RAS mmc unter IPv4/Allgemein die IP Adressen anzeigen lasse, erhalte ich folgendes:
192.168.80.100 / 255.255.255.255 Index 14
192.168.73.1 / 255.255.255.0 / Index 11
127.0.0.1 / 255.0.0.0 / index 1
Oder wäre 192.168.80.100 / 255.255.255.0 korrekt?
Gruß
Michael
Ist das so eigentlich richtig? Wenn ich mir im Routing und RAS mmc unter IPv4/Allgemein die IP Adressen anzeigen lasse, erhalte ich folgendes:
192.168.80.100 / 255.255.255.255 Index 14
192.168.73.1 / 255.255.255.0 / Index 11
127.0.0.1 / 255.0.0.0 / index 1
Oder wäre 192.168.80.100 / 255.255.255.0 korrekt?
Gruß
Michael
Hallo Michael,
mit welcher Option hast du Routing und RAS eingerichtet ?
Grüße Uwe
mit welcher Option hast du Routing und RAS eingerichtet ?
- RAS (DFÜ oder VPN)
- VPN-Zugriff und NAT
Grüße Uwe
Hallo.
RAS und Routing ist Benutzerdefiniert installiert. Ohne NAT. Warum NAT für das Routing zwischen 192.168.80.0 und 192.168.73.0 notwendig sein soll verstehe ich nicht.
Es muß doch nur geroutet werden.
Gruß
Michael
RAS und Routing ist Benutzerdefiniert installiert. Ohne NAT. Warum NAT für das Routing zwischen 192.168.80.0 und 192.168.73.0 notwendig sein soll verstehe ich nicht.
Es muß doch nur geroutet werden.
Gruß
Michael
Sorry, stimmt, war grad auf ner anderen Baustelle, hab es fälschlicherweise mit deinem Case verwechselt...
..."Von einem anderen Rechner im 192.168.73.0 Netz kann ich den Server nicht auf seiner IP 192.168.80.100 erreichen"
Das ist vermutlich klar, denn das verhindert immer die lokale Windows Firewall. Die blockt alles was nicht aus dem lokalen Netzwerk ist.
Da du ja eine andere Absender IP hast bleibt diese vermutlich dann in der lokalen Firewall hängen wenn du diese nicht entsprechend angepasst hast die IP Adressen (Netz) passieren zu lassen ?!
Das ist vermutlich klar, denn das verhindert immer die lokale Windows Firewall. Die blockt alles was nicht aus dem lokalen Netzwerk ist.
Da du ja eine andere Absender IP hast bleibt diese vermutlich dann in der lokalen Firewall hängen wenn du diese nicht entsprechend angepasst hast die IP Adressen (Netz) passieren zu lassen ?!
Firewall ist komplett deaktiviert. Aus einem anderen Netz das per VPN-Standortverbindung verbunden ist, bekomme ich eine ping Antwort vom 192.168.73.1.
Die Firewall ist also nicht das Problem.
Die Firewall ist also nicht das Problem.
Moin.
Nach einem Neustart des Server verhält es sich nun wie folgt:
Der per VPN verbundene Client kann den Server auf der 192.168.80.100 erreichen. Alle Geräte im 192.168.73.X Netz jedoch nicht.
Der Lancom Router (192.168.73.3) selber kann den Server trotz vorhandener Route nicht auf der 192.168.80.100 erreichen. Der Server hat als Standardgateway die 192.168.73.3 auf der LAN-Karte. Auf dem PPP-Adapter (192.168.80.100/255.255.255.255) ist kein Standardgateway eingetragen.
Wenn ich auf dem Server "ping 192.168.73.3 -S 192.168.80.100" teste, erhalte ich Fehler "PING: Fehler bei der Übertragung. Allgemeiner Fehler."
Gruß
Michael
Nach einem Neustart des Server verhält es sich nun wie folgt:
Der per VPN verbundene Client kann den Server auf der 192.168.80.100 erreichen. Alle Geräte im 192.168.73.X Netz jedoch nicht.
Der Lancom Router (192.168.73.3) selber kann den Server trotz vorhandener Route nicht auf der 192.168.80.100 erreichen. Der Server hat als Standardgateway die 192.168.73.3 auf der LAN-Karte. Auf dem PPP-Adapter (192.168.80.100/255.255.255.255) ist kein Standardgateway eingetragen.
Wenn ich auf dem Server "ping 192.168.73.3 -S 192.168.80.100" teste, erhalte ich Fehler "PING: Fehler bei der Übertragung. Allgemeiner Fehler."
Gruß
Michael
Moin.
Komisch. Ich habe bei ipv4 im Routing und RAS die Adresszuweisung von "Statischen Adresspool" auf DHCP umgestellt. RAS neugestartet und wieder zurück auf "Statischen Adresspool" umgestellt. Nun routet der Server wieder korrekt zwischen 192.168.80.X und 192.168.73.X.
Gruß
Michael
Komisch. Ich habe bei ipv4 im Routing und RAS die Adresszuweisung von "Statischen Adresspool" auf DHCP umgestellt. RAS neugestartet und wieder zurück auf "Statischen Adresspool" umgestellt. Nun routet der Server wieder korrekt zwischen 192.168.80.X und 192.168.73.X.
Gruß
Michael
Moin.
Leider passiert das immer mal wieder. Routing zwischen 192.168.80.X und 192.168.73.X funktioniert nicht mehr.
Ich habe bei ipv4 im Routing und RAS die Adresszuweisung von "Statischen Adresspool" auf DHCP umgestellt und wieder zurück auf "Statischen Adresspool" umgestellt. Nun routet der Server wieder korrekt zwischen 192.168.80.X und 192.168.73.X.
Hat jemand eine Idee warum der Server nicht mehr routet ohne diesen Workaround? Wo kann man ansetzen zur Fehlersuche?
Danke!
Gruß
Michael
Leider passiert das immer mal wieder. Routing zwischen 192.168.80.X und 192.168.73.X funktioniert nicht mehr.
Ich habe bei ipv4 im Routing und RAS die Adresszuweisung von "Statischen Adresspool" auf DHCP umgestellt und wieder zurück auf "Statischen Adresspool" umgestellt. Nun routet der Server wieder korrekt zwischen 192.168.80.X und 192.168.73.X.
Hat jemand eine Idee warum der Server nicht mehr routet ohne diesen Workaround? Wo kann man ansetzen zur Fehlersuche?
Danke!
Gruß
Michael
