14
PPTP-VPN Abbruch nach 20 Sekunden
Hallo Freunde des Internets,
aktuell stehe ich seit gut einer Woche für einem sehr merkwürdigem Problem.
Wir nutzen einen 2012 R2 Server, auf dem 3 Vserver per HyperV laufen. (DC, SQL und Exchange) [Bitte keine Kritik daran].
Davor sitze ein Lancom, der auch den VPN Zugang mittels pptp verwaltet.
Einer unserer Mitarbeiter kann zwar die VPN-Verbindung aufbauen, allerdings 'verschwindet' er nach ~20 Sekunden.
Das heißt er kann weder einen Client/Server anpingen noch angepingt werden. Die VPN-Verbindung allerdings bleibt aktiv bestehen,
was auch der VPN-log bestätigt.
Für jeglichen möglichen Lösungsansatz wäre sehr dankbar.
Vielen Dank im Vorfeld.
aktuell stehe ich seit gut einer Woche für einem sehr merkwürdigem Problem.
Wir nutzen einen 2012 R2 Server, auf dem 3 Vserver per HyperV laufen. (DC, SQL und Exchange) [Bitte keine Kritik daran].
Davor sitze ein Lancom, der auch den VPN Zugang mittels pptp verwaltet.
Einer unserer Mitarbeiter kann zwar die VPN-Verbindung aufbauen, allerdings 'verschwindet' er nach ~20 Sekunden.
Das heißt er kann weder einen Client/Server anpingen noch angepingt werden. Die VPN-Verbindung allerdings bleibt aktiv bestehen,
was auch der VPN-log bestätigt.
Für jeglichen möglichen Lösungsansatz wäre sehr dankbar.
Vielen Dank im Vorfeld.
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: 319264
Url: https://administrator.de/contentid/319264
Printed on: April 25, 2024 at 21:04 o'clock
14 Comments
Latest comment
Hallo,
Ein Traceroute auf ein externes Ziel müsste dann über das VPN Gateway gehen solang kein Split Tunneling aktiviert ist.
Gruß
Die VPN-Verbindung allerdings bleibt aktiv bestehen,
was auch der VPN-log bestätigt.
Kann das Clientseitig auch verifiziert werden?was auch der VPN-log bestätigt.
Ein Traceroute auf ein externes Ziel müsste dann über das VPN Gateway gehen solang kein Split Tunneling aktiviert ist.
Für jeglichen möglichen Lösungsansatz wäre sehr dankbar.
Ist das bei jedem Client so?Gruß
Moin,
ist die Verschlüsselung am Client richtig, so wie in der Firewall eingestellt?
Also mal im VPN Client des Users, den Cipher Wert mit der Firewall prüfen.
Sonst, eventuell mal, geschwärzt der wichtigen Sachen, das VPN Log hierher posten.
Gruß
hagerino
ist die Verschlüsselung am Client richtig, so wie in der Firewall eingestellt?
Also mal im VPN Client des Users, den Cipher Wert mit der Firewall prüfen.
Sonst, eventuell mal, geschwärzt der wichtigen Sachen, das VPN Log hierher posten.
Gruß
hagerino
Vielen Dank erst einmal für die beiden Antworten. Zum Thema Traceroute kann ich nicht viel sagen, da ich dies in der Vergangenheit fast nie brauchte. Ich habe mich per Teamviewer aufgeschaltet und http://ping.eu/traceroute/ benutzt (auf microsoft.com). Einmal mit aktivem vpn und einmal ohne. Das Ergebnis sah in beiden Fällen identisch aus. An der Verschlüsslung liegt es nicht, das was das erste das ich geprüft habe. Das Problem besteht auch ausschließlich bei diesem Mitarbeiter. Zwei andere externe Mitarbeiter (als auch auch!) können wie gewohnt mit dem VPN arbeiten.
Wie stellst du die Verbindung her am betroffenen Client?
Mit onboard Mitteln oder dem Lancom Client?
Mit onboard Mitteln oder dem Lancom Client?
Von hier aus schalte ich mich per Teamviewer auf den betroffenen Client.
Der Client verbindet sich mit Onboard Mitteln mit dem Lancom.
Der Client verbindet sich mit Onboard Mitteln mit dem Lancom.
Teste das Ganze doch mal mit dem Lancom VPN Client und schau ob das Problem weiter besteht.
Nachtrag: Der Mitarbeiter wohnt zur Zeit in einem Studentenwohnheim. Das Problem scheint nur dort zu bestehen, denn wenn er die Internetverbindung der Uni nutzt (gerade während einer Vorlesung), funktioniert die VPN-Verbindung ohne Abbrüche und co. ist nutzbar.
Dann kann es natürlich auch sein, dass die Firewall des Studentenwohnheims das ohnehin unsichere PPTP Protokoll blockt.
Laut Aussage des IT-Menschen des Wohnheims kann dieser problemlos pptp-Verbindungen nutzen. Vielleicht doch eine Routingsache ?
Er soll mit bestehender VPN Verbindung einen Server bei euch tracerouten
Und dann sieht er ja wo bzw. ob er hängen bleibt.
tracert SERVERIP
Es hatte vorerst geholfen 'ipv6' in den Adapterinstellungen komplett zu deaktivieren, allerdings besteht das selbe Probleme wie vorher nun nach knapp 2.5 Wochen wieder. Traceroute auf einen internen Server sieht wie folgt aus:
In wie weit hilft dies nun eine Lösung zu finden?
In wie weit hilft dies nun eine Lösung zu finden?
Gar nicht.
Ich habe gesagt, er soll vom Studentenwohnheim aus, mit aktiver VPN Verbindung einen deiner 3 VServer tracerouten.
Dann sieht man ob er am Studentenwohnheim bereits hängen bleibt oder erst am LANCOM etc.
Ich habe gesagt, er soll vom Studentenwohnheim aus, mit aktiver VPN Verbindung einen deiner 3 VServer tracerouten.
Dann sieht man ob er am Studentenwohnheim bereits hängen bleibt oder erst am LANCOM etc.
Die IP auf die der Tracert angesetzt wurde ist die IP eines der Server (über die auch dann per rdp verbunden wird). Oder habe ich das falsch verstanden?
Ist zwar etwas älter, aber...
Falls der Betroffene User in dem Studentenwohnheim hinter einem NAT sitzt und andere Leute sich problemlos per PPTP verbinden können lehne ich mich mal weit aus einem Fenster und behaupte, dass genau das das Problem ist.
Das für PPTP genutzte GRE-Protokoll kennt im Gegensatz zu TCP oder UDP keine Ports - ein NAT-Router kann also nicht mehr unterscheiden, welcher seiner internen Nutzer die Datenpakete die von außen kommen, angefordert hat. Es gibt dann durchaus teilweise die Effekte, dass der jenige, der sich zuletzt verbindet, einfach pauschal alle GRE-Pakete abbekommt und der andere, vorherige Nutzer keine Daten mehr bekommt und der Meinung ist, der Tunnel wäre zusammengebrochen.
Wenn er in der Uni seine eigene öffentliche IP bekommt hat er das Problem dort natürlich nicht, da ja das NAT wegfällt.
Die einzige Lösung (auch hinsichtlich der Sicherheit) wäre ein VPN-Protokoll zu verwenden welches besser damit klar kommt - wobei da leider quasi nur OpenVPN (UDP-Basiert) übrig bleibt, denn der Rest setzt in der Regel auf IPSec (ESP) auf, welches ebenfalls keine Ports kennt.
Falls der Betroffene User in dem Studentenwohnheim hinter einem NAT sitzt und andere Leute sich problemlos per PPTP verbinden können lehne ich mich mal weit aus einem Fenster und behaupte, dass genau das das Problem ist.
Das für PPTP genutzte GRE-Protokoll kennt im Gegensatz zu TCP oder UDP keine Ports - ein NAT-Router kann also nicht mehr unterscheiden, welcher seiner internen Nutzer die Datenpakete die von außen kommen, angefordert hat. Es gibt dann durchaus teilweise die Effekte, dass der jenige, der sich zuletzt verbindet, einfach pauschal alle GRE-Pakete abbekommt und der andere, vorherige Nutzer keine Daten mehr bekommt und der Meinung ist, der Tunnel wäre zusammengebrochen.
Wenn er in der Uni seine eigene öffentliche IP bekommt hat er das Problem dort natürlich nicht, da ja das NAT wegfällt.
Die einzige Lösung (auch hinsichtlich der Sicherheit) wäre ein VPN-Protokoll zu verwenden welches besser damit klar kommt - wobei da leider quasi nur OpenVPN (UDP-Basiert) übrig bleibt, denn der Rest setzt in der Regel auf IPSec (ESP) auf, welches ebenfalls keine Ports kennt.
