118080
May 15, 2016, updated at 11:57:31 (UTC)
4080
33
0
L2TP VPN Server funktioniert nicht - Win2012R2
Moin 
Ich fange gerade mit dem Thema VPN over L2TP auf Windows Server 2012 R2 an. Dazu habe ich einen VPN Server via PPTP eingerichtet. Kein Problem, funktioniert alles wunderbar.
Nun wollte ich einen VPN Server via L2TP einrichten, allerdings kriege ich immer die folgende Fehlermeldung:
Da ich leider neu in dem Gebiet bin kann ich nichts damit anfangen... Ist die erste Sicherheitsaushandlung der PreShared-Key?
LG Luca
Ahja: Ich habe Port 500, 4500 und 1701 an den Server weitergeleitet. Dabei ist 1701 nicht mal zwingend nötig glaube ich..
Ich fange gerade mit dem Thema VPN over L2TP auf Windows Server 2012 R2 an. Dazu habe ich einen VPN Server via PPTP eingerichtet. Kein Problem, funktioniert alles wunderbar.
Nun wollte ich einen VPN Server via L2TP einrichten, allerdings kriege ich immer die folgende Fehlermeldung:
Da ich leider neu in dem Gebiet bin kann ich nichts damit anfangen... Ist die erste Sicherheitsaushandlung der PreShared-Key?
LG Luca
Ahja: Ich habe Port 500, 4500 und 1701 an den Server weitergeleitet. Dabei ist 1701 nicht mal zwingend nötig glaube ich..
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: 304617
Url: https://administrator.de/contentid/304617
Printed on: April 20, 2024 at 01:04 o'clock
33 Comments
Latest comment
Ich habe Port 500, 4500 und 1701 an den Server weitergeleitet. Dabei ist 1701 nicht mal zwingend nötig glaube ich..
Doch, 1701 ist zwingend wenn du Winblows L2TP machst.Den allerwichtigsten Port bzw. Protokoll hast du aber vergessen !!
L2TP nutzt IPsec ESP als Transporttunnel !!
Du musst also zwingend auch das ESP Protokoll (IP Protokoll Nummer 50) auf die internen Server IP forwarden.
Machst du das nicht kann der ESP Tunnel nicht aufgebaut werden und das gesamte L2TP Konstrukt scheitert schon von Anbeginn ! Bei dir ist das vermutlich der Fall.
Achtung: ESP (Encapsulation Security Payload) ist einen eigenständiges IP Protokoll !! Es ist NICHT UDP oder TCP Port 50 !
Dein Router muss dafür ESP Port Forwarding oder VPN Passthrough supporten !
Grundlagen dafür findest du hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
und auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Noch sinnvoller und gängige Praxis ist es das VPN auf dem Router oder einer separaten Firewall zu terminieren statt auf einem Server hinter einem NAT Prozess !
Ist die erste Sicherheitsaushandlung der PreShared-Key?
Nein das sind die IPsec Crypto Credentials. Phase 1. Der key ist für die Phase 1 Session Key relevant. Siehe Tutorial oben.Du kannst auch immer einen Wireshark Sniffer auf dem Server starten und dir den Inbound L2TP Traffic ansehen, da siehst du dann immer aus erster Hand wo das Problem liegt.
Zitat von @aqui:
Achtung: ESP (Encapsulation Security Payload) ist einen eigenständiges IP Protokoll !! Es ist NICHT UDP oder TCP Port 50 !
Dein Router muss dafür ESP Port Forwarding oder VPN Passthrough supporten !
Dass unterstützt mein Zyxel schrott leider nicht.. Sche Achtung: ESP (Encapsulation Security Payload) ist einen eigenständiges IP Protokoll !! Es ist NICHT UDP oder TCP Port 50 !
Dein Router muss dafür ESP Port Forwarding oder VPN Passthrough supporten !
Noch sinnvoller und gängige Praxis ist es das VPN auf dem Router oder einer separaten Firewall zu terminieren statt auf einem Server hinter einem NAT Prozess !
Habe ich mir auch überlegt, aber ich hätte gerne, dass die User Ihre internen Domain Anmeldedaten zum Aufbau des VPN Tunnels nutzen können...Dass unterstützt mein Zyxel schrott leider nicht.. Sche
Oha... Böses Faul !Dann bist du natürlich chancenlos....keine Frage !
Checke das aber besser nochmal wasserdicht mit einem Wireshark Trace wenn du eine eingehende L2TP Sessions hast !
Zyxel Firmware auf dem aktuellsten Stand ?!
Aber ich denke ich kann ESP in der Firewall öffnen.. Aber Portforwarding kann er nicht.
Checke das aber besser nochmal wasserdicht mit einem Wireshark Trace wenn du eine eingehende L2TP Sessions hast !
Werde ich machen. Obwohl.. Ich bekomme zu 80% am Donnerstag eine Ablösung für den Zyxel Müll..Zyxel Firmware auf dem aktuellsten Stand ?!
Ja..Aber Portforwarding kann er nicht.
Brauchst du aber logischerweise zwingend, denn sonst ist nada mit L2TP !!Ich bekomme zu 80% am Donnerstag eine Ablösung für den Zyxel Müll..
Na hoffentlich dann keinen anderen Müll sondern was sinnvolles was den Namen Router auch verdient ?!Zitat von @aqui:
Das ist mir bewussst Aber Portforwarding kann er nicht.
Brauchst du aber logischerweise zwingend, denn sonst ist nada mit L2TP !!
Ich bekomme zu 80% am Donnerstag eine Ablösung für den Zyxel Müll..
Na hoffentlich dann keinen anderen Müll sondern was sinnvolles was den Namen Router auch verdient ?! Wenn Santa Klaus das neue Gerät bringen würde ware es eine Sophos UTM Leider muss die Firmenkasse herhalten also wirds wahrscheinlich eine MikroTik 
Hallo hayvan,
hast du schon mal intern eine Verbindung zu deinem Testserver aufgebaut, also nicht über den Router? Das musst du zuerst mal testen, damit du die Server- und Clientkonfiguration als Fehler ausschließen kannst. Erst danach solltest du weitermachen.
Deine Konfiguration ist nämlich richtig, du brauchst nur NAT-Regeln für die Ports 500/4500. Die Portnummer 1701 sieht der Router niemals, da alles mittels IPSec verschlüsselt ist. ESP brauchst du ebenfalls nicht, da auch bei Windows standardmäßig NAT-Traversal aktiv ist. Die Pakete sehen dann so aus:
Wenn du Windows 7 benutzt, muss du noch eine Änderung in der Registry machen, damit L2TP/IPSec funktioniert. Für Windows 8 oder höher kann ich es dir nicht genau sagen, da ich nur Windows 7 habe.
Der Pre-shared Key wird in Phase 1 benutzt und muss auf beiden Seiten übereinstimmen. Aus dem PSK wird der sogenannte Session-Key SKEYID berechnet, der in alle Schlüsselberechnungen eingeht.
Viel Erfolg
BB
hast du schon mal intern eine Verbindung zu deinem Testserver aufgebaut, also nicht über den Router? Das musst du zuerst mal testen, damit du die Server- und Clientkonfiguration als Fehler ausschließen kannst. Erst danach solltest du weitermachen.
Deine Konfiguration ist nämlich richtig, du brauchst nur NAT-Regeln für die Ports 500/4500. Die Portnummer 1701 sieht der Router niemals, da alles mittels IPSec verschlüsselt ist. ESP brauchst du ebenfalls nicht, da auch bei Windows standardmäßig NAT-Traversal aktiv ist. Die Pakete sehen dann so aus:
Wenn du Windows 7 benutzt, muss du noch eine Änderung in der Registry machen, damit L2TP/IPSec funktioniert. Für Windows 8 oder höher kann ich es dir nicht genau sagen, da ich nur Windows 7 habe.
Der Pre-shared Key wird in Phase 1 benutzt und muss auf beiden Seiten übereinstimmen. Aus dem PSK wird der sogenannte Session-Key SKEYID berechnet, der in alle Schlüsselberechnungen eingeht.
Viel Erfolg
BB
Moin
LG
Zitat von @BitBurg:
hast du schon mal intern eine Verbindung zu deinem Testserver aufgebaut, also nicht über den Router? Das musst du zuerst mal testen, damit du die Server- und Clientkonfiguration als Fehler ausschließen kannst. Erst danach solltest du weitermachen.
Ja habe ich und das funktioniert. Auch ohne die entsprechenden Anpasssungen in der Registry (Win 10 Pro).hast du schon mal intern eine Verbindung zu deinem Testserver aufgebaut, also nicht über den Router? Das musst du zuerst mal testen, damit du die Server- und Clientkonfiguration als Fehler ausschließen kannst. Erst danach solltest du weitermachen.
Deine Konfiguration ist nämlich richtig, du brauchst nur NAT-Regeln für die Ports 500/4500. Die Portnummer 1701 sieht der Router niemals, da alles mittels IPSec verschlüsselt ist. ESP brauchst du ebenfalls nicht, da auch bei Windows standardmäßig NAT-Traversal aktiv ist. Die Pakete sehen dann so aus:
Funktionieren tut es leider trotzdem nicht LG
Schmeiss den Wireshark an wie Kollege BitBurg und checke ob deine L2TP Pakete vom Client weggehen und am Server ankommen.
So gehst du auf Nummer sicher !!!
So gehst du auf Nummer sicher !!!
Also ich seh die ankommenden Pakete mit Wireshark..
Dann ist doch alles gut !!
Ist ist positiv aber nicht gut
Ich meine intern krieg ich die L2TP Verbindung hin und über die externe IP nicht...
Ich meine intern krieg ich die L2TP Verbindung hin und über die externe IP nicht...
Es war auch so gemeint das du den externen Zugriff mal mit dem Wireshark am Server mitsnifferst !!! Ob da die geforwardeten Pakete vom Router eintreffen ! Logisch...
Ist da nichts zu sehen, dann ist das Port Forwarding für L2TP am Router falsch konfiguriert oder fehlerhaft !
Ggf. mal ein Screenshot der PFW Router Konfig hier posten ?!
Ist da nichts zu sehen, dann ist das Port Forwarding für L2TP am Router falsch konfiguriert oder fehlerhaft !
Ggf. mal ein Screenshot der PFW Router Konfig hier posten ?!
Eben, das finde ich ja so komisch.. Die Pakete 500 und 4500 kommen an! Und das von extern! Aber die VPN Verbindung kommt nicht zustande
Was sagt denn das VPN Server Log.
Wo genau ist der Unterschied zw. einem lokalen Login und externen wenn du das vergleichst im Wireshark ?
Wo genau ist der Unterschied zw. einem lokalen Login und externen wenn du das vergleichst im Wireshark ?
Der Log sagt nichts.. Als würde die Verbindung gar nie ankommen..
Dies ist beim lokalen Zugriff.. Beim externen Zugriff erscheinen nur die letzten 4... (Intern hatte ich mal das Passwort falsch eingegeben, dann erschienen die anderen Pakete auch so lange nicht, bis ich das Passwort richtig eingegeben habe. Aber dies muss ja so sein.)
Beim Port 4500 kommen immer nur die letzten 4, egal ob intern oder extern.
Wo genau ist der Unterschied zw. einem lokalen Login und externen wenn du das vergleichst im Wireshark ?
Port 500:Beim Port 4500 kommen immer nur die letzten 4, egal ob intern oder extern.
Der Trace stammt aber von intern also NICHT von einer externen Verbindung ?!
Da klappt das ja wie du selber sagst !
Abgesehen davon sind das nur UDP 500 Frames...wo sind denn die 4500er mit ESP ?
Externer Trace wäre hier also das wichtigere...
Da klappt das ja wie du selber sagst !
Abgesehen davon sind das nur UDP 500 Frames...wo sind denn die 4500er mit ESP ?
Externer Trace wäre hier also das wichtigere...
Ja, ich habe mir den Screenshot zum externen gespart, da dort einfach die letzten 4 Pakete wie beim internen Trace auftauchen!
Port 1701 zeigt er beim externen gar nichts an, beim Internen jedoch schon..
Abgesehen davon sind das nur UDP 500 Frames...wo sind denn die 4500er mit ESP ?
Port 4500 zeigt er mir die selben Pakete an wie beim 4500.. Intern sowie extern..Port 1701 zeigt er beim externen gar nichts an, beim Internen jedoch schon..
da dort einfach die letzten 4 Pakete wie beim internen Trace auftauchen!
Das wäre ja komisch, denn dann fehlt ja die Hälfte ? Das ist alles UDP 500, oder ??4500 müssen da aber auch auftauchen..
Ich denke er hat hier ein Hairpin-NAT Problem, seinem anderen (neuen) Thread zu urteilen. Dort wollte er mir extern so verkaufen als wenn er nur über die externe IP aus seinem internen Netz verbindet 
statt "tatsächlich" von extern die Verbindung aufzubauen.
statt "tatsächlich" von extern die Verbindung aufzubauen.Ich denke er hat hier ein Hairpin-NAT Problem, seinem anderen (neuen) Thread zu urteilen.
OK, wenn er uns verar... hat hier und von intern eine VPN Verbindung auf die externe IP gemacht hat ist das klar. Grrrr...Das sein Schrottrouter kein NAT Hairpinning kann ist klar !!!
Der TO MUSS also zwingend die Verbindung von extern testen also mit Smartphone oder einem Kumpel der wirklich extern ist !
Eigentlich sollte so ein Umstand klar sein
Das Thema ist hier beschrieben:
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Zitat von @aqui:
4500 müssen da aber auch auftauchen..
Ich sagte ja bereits, dass ich es komisch finde da dort einfach die letzten 4 Pakete wie beim internen Trace auftauchen!
Das wäre ja komisch, denn dann fehlt ja die Hälfte ? Das ist alles UDP 500, oder ??4500 müssen da aber auch auftauchen..
Zitat von @129413:
Ich denke er hat hier ein Hairpin-NAT Problem, seinem anderen (neuen) Thread zu urteilen. Dort wollte er mir extern so verkaufen als wenn er nur über die externe IP aus seinem internen Netz verbindet statt "tatsächlich" von extern die Verbindung aufzubauen.
!NEIN!Ich denke er hat hier ein Hairpin-NAT Problem, seinem anderen (neuen) Thread zu urteilen. Dort wollte er mir extern so verkaufen als wenn er nur über die externe IP aus seinem internen Netz verbindet
statt "tatsächlich" von extern die Verbindung aufzubauen.1. Hier habe ich es von meinem Rechner zu Hause probiert!
2. Der Router der verwendet wird kann kein Hairpin-NAT!
Und dass ich hier wissentlich jemanden verarsche war hoffentlich auch nicht ernst gemeint...
Ich hab auch im anderen Thread dir einen internen Aufruf auf die externe IP auch nicht als externen Aufruf "verkaufen" wollen. Dies war ein kurzer Fehlgedanke meinerseits, welchen ich innerhalb von 2 Minute wieder richtig gestellt hatte.
Hier habe ich es von meinem Rechner zu Hause probiert!
Von zuhause auf einen anderen Standort oder von zuhause via externer IP oder Hostname auf den VPN Server zuhause ?Letzteres wäre dann das Hairping Szenario...
Von Zuhause auf einen anderen Standort.
...und am anderen Standort wo der VPN Server steht machst du die Messungen ??
Das wäre dann richtig !
Das wäre dann richtig !
Ja, genau
Nimm mal einen anderen Client, manche Windows 7 Systeme haben eine verbuggte IPSec Config z.B. wenn man vorher Fritz Fernzugang oder ähnliches installiert hatte. Solche Clients setzen oft Einstellungen nicht zurück.
Und nutze stattdessen mal testweise den Shrew-Client.
Du siehst, einer der vielen Gründe warum man einen VPN-Responder besser auf dem Router oder der Firewall platziert.
Auch wirst du oft Probleme bekommen wenn du versuchst aus Hotspots heraus eine VPN-Verbindung aufzubauen, denn diese Blocken oft die IPSec Ports. Hier würde dann parallel zusätzlich auf ein VPN-Protokoll setzen das sich auch auf Port 443 fahren lässt wie z.B. für Windows-Clients SSTP oder universeller OpenVPN.
Und nutze stattdessen mal testweise den Shrew-Client.
Du siehst, einer der vielen Gründe warum man einen VPN-Responder besser auf dem Router oder der Firewall platziert.
Auch wirst du oft Probleme bekommen wenn du versuchst aus Hotspots heraus eine VPN-Verbindung aufzubauen, denn diese Blocken oft die IPSec Ports. Hier würde dann parallel zusätzlich auf ein VPN-Protokoll setzen das sich auch auf Port 443 fahren lässt wie z.B. für Windows-Clients SSTP oder universeller OpenVPN.
Sehr guter Tipp dem an nur zustimmen kann !!
Besonders die Anmerkung mit dem VPN Responder.
Kann man nur hoffen das der TO das verinnerlicht.
Besonders die Anmerkung mit dem VPN Responder.
Kann man nur hoffen das der TO das verinnerlicht.
Zitat von @129413:
Und nutze stattdessen mal testweise den Shrew-Client.
Werde ich machen und mich nochmals melden Und nutze stattdessen mal testweise den Shrew-Client.
Auch wirst du oft Probleme bekommen wenn du versuchst aus Hotspots heraus eine VPN-Verbindung aufzubauen, denn diese Blocken oft die IPSec Ports. Hier würde dann parallel zusätzlich auf ein VPN-Protokoll setzen das sich auch auf Port 443 fahren lässt wie z.B. für Windows-Clients SSTP oder universeller OpenVPN.
Für mich gibt es einfach zwei Punkte die erfüllt sein müssen:- Folgende VPN Clients müssen andbindbar sein: iPhone, Windows Desktop
- Authentifizierung mit den AD Login Daten
Also für mich Schlussendlich: L2TP on Win2012 oder OpenVPN.. Allerdings wusste ich damals die Tatsache mit den Sperrung der VPN Ports noch nicht..
Also für mich Schlussendlich: L2TP on Win2012 oder OpenVPN..
Nööö...das ist Unsinn. Du kannst das auch an jedem Router machen den man per LDAP ans AD koppeln kann.Alternativ Radius wenn man den NPS unter Winblows aktiviert.
Generell ist es immer kontraproduktiv einen VPN Server hinter der NAT Firewall zu betreiben ! Deshalb macht man das in einem sauberen Design auch nicht.
Ein Nachteil ist die Frickelei mit NAT und der andere das man potentielle Angreifer so schon per PFW ins lokale Netz lässt. Sicher ist was anderes...
Allerdings wusste ich damals die Tatsache mit den Sperrung der VPN Ports noch nicht..
Das sollte man aber als Netzwerker... Abgesehen davon gilt das auch nicht für alle VPN Protokolle. SSL basierte Protokolle wie z.B. bei OpenVPN haben diese Einschränkung nicht !
Zitat von @aqui:
Nööö...das ist Unsinn. Du kannst das auch an jedem Router machen den man per LDAP ans AD koppeln kann.
Darum sagte ich ja für mich.. Mein Router kann kein LDAP..Nööö...das ist Unsinn. Du kannst das auch an jedem Router machen den man per LDAP ans AD koppeln kann.
Alternativ Radius wenn man den NPS unter Winblows aktiviert.
Da gibt es für mich ganz viele Fragezeichen Darum sagte ich ja für mich.. Mein Router kann kein LDAP..
Dann heul nicht, und besorge dir einfach mal was vernünftiges in Haus dann lösen sich plötzlich alle deine Probleme! Ich fahr auch nicht mit einem VW-Käfer in einem Formel-Eins Rennen mit ...
Ich werde hier einfach mal L2TP auf dem Router einrichten und mich um die LDAP Integration später kümmern. Radius hat nicht auf Anhieb geklappt. Also werde ich das später machen.
