10
VPN-Verbindung plötzlich nicht mehr möglich wegen IP-Fragmentierung?
Hallo zusammen,
ich habe vor gut einem halben Jahr auf dem Lancom-Router (Lancom 1781VA mit aktivierter VPN25-Option) in unserer Firma einige VPN-Verbindungen (IKEv2, zertifikatsbasiert) eingerichtet, die seitdem problemlos von den Kollegen und mir mit dem in Windows 10 eingebauten VPN-Client genutzt werden.
Seit einigen Tagen können jedoch zwei Kollegen und ich keine Verbindung mehr aufbauen. Das Problem trat quasi von jetzt auf gleich auf; vormittags ging es noch, nachmittags nicht mehr. Es wurden zwischenzeitlich keine Änderungen vorgenommen und auch keine Windows-Updates eingespielt. Beim Aufbau der VPN-Verbindung steht für kurze Zeit "Anmeldeinformationen werden überprüft", dann erscheint die Meldung "Die Netzwerkverbindung zwischen Ihrem Computer und dem VPN-Server konnte nicht hergestellt werden, da der Remoteserver nicht reagiert. Dies kann daran liegt, dass eines der Netzwerkgeräte (z. B. Firewalls, NAT, Router) zwischen Ihrem Computer und dem Remoteserver nicht so konfiguriert ist, dass VPN-Verbindungen zugelassen werden. Wenden Sie sich an Ihren Administrator oder Ihren Dienstanbieter, um zu ermitteln, welches Gerät das Problem verursachen kann." In der Windows-Ereignisanzeige findet sich der Fehler 809.
Wie sich herausstellte, sind die betroffenen Kollegen und ich Kunden bei der Deutschen Glasfaser, alle anderen können sich weiterhin verbinden. Um zu untersuchen, ob es wirklich an der Deutschen Glasfaser liegt, habe ich dann auf einem Laptop die VPN-Verbindung eingerichtet. Ergebnis: Über meine Netzwerk zuhause (Glasfaser) schlägt das Herstellen der Verbindung fehl, über die mobilen Daten meines Handys war die Verbindung sofort aufgebaut.
Ich habe dann einmal Wireshark installiert und mitlaufen lassen. Beim Aufbau der VPN-Verbindung kommt es zu folgenden Einträgen (hhh.hhh.hhh.hhh ist die IP-Adresse meines Rechners zuhause, fff.fff.fff.fff ist die öffentliche IPv4-Adresse der Firma):
Stutzig gemacht haben mich die Einträge Nummer 14, 21 und 23 bezüglich der IP-Fragmentierung, denn standardmäßig sollten sowohl der Windows-10-VPN-Client als auch der Lancom-Router die IKEv2-Fragmentierung nutzen. In Eintrag 12 finde ich auch folgenden Hinweis: Payload: Notify (41) - IKEV2_FRAGMENTATION_SUPPORTED (16430); in Eintrag 13 finde ich diesen Hinweis nicht.
Nach meinem Verständnis passiert also folgendes: Mein PC meldet sich beim Lancom-Router, dass er eine VPN-Verbindung aufbauen möchte. Dabei teilt er auch mit, dass bei ihm die IKEv2-Fragmentierung eingeschaltet ist. Der Lancom-Router antwortet; meldet aber nicht, dass bei ihm die IKEv2-Fragmentierung eingeschaltet ist. Deswegen fragmentiert mein PC die Daten nicht auf IKEv2-Ebene, sondern stellt alles in ein Datenpaket. Da dessen Größe die MTU-Größe überschreitet, wird es auf IP-Ebene fragmentiert. Und diese IP-Fragmente gehen dann unterwegs verloren. Ist das so ungefähr richtig? Auf dem Lancom-Router habe ich auch einmal einen VPN-Trace laufen lassen, und auch da sehe ich, dass bis auf Nummer 12 (IKE_SA_INIT MID=00 Initiator Request) nichts ankommt.
Komisch ist nur, dass es über die mobilen Daten funktioniert. Werden da die IP-Fragmente durchgeleitet? Und wieso plötzlich bei der Deutschen Glasaser nicht mehr?
Und wie kann ich auf dem Lancom-Router die IKEv2-Fragmentierung einschalten? Es gibt da eine Einstellung für die MTU-Größe (steht standardmäßig auf 0), aber egal, was ich da eintrage (1500, 1300...), es ändert sich nichts.
Für Tipps, wie ich die VPN-Verbindung wieder ans Laufen bekomme, wäre ich sehr dankbar.
ich habe vor gut einem halben Jahr auf dem Lancom-Router (Lancom 1781VA mit aktivierter VPN25-Option) in unserer Firma einige VPN-Verbindungen (IKEv2, zertifikatsbasiert) eingerichtet, die seitdem problemlos von den Kollegen und mir mit dem in Windows 10 eingebauten VPN-Client genutzt werden.
Seit einigen Tagen können jedoch zwei Kollegen und ich keine Verbindung mehr aufbauen. Das Problem trat quasi von jetzt auf gleich auf; vormittags ging es noch, nachmittags nicht mehr. Es wurden zwischenzeitlich keine Änderungen vorgenommen und auch keine Windows-Updates eingespielt. Beim Aufbau der VPN-Verbindung steht für kurze Zeit "Anmeldeinformationen werden überprüft", dann erscheint die Meldung "Die Netzwerkverbindung zwischen Ihrem Computer und dem VPN-Server konnte nicht hergestellt werden, da der Remoteserver nicht reagiert. Dies kann daran liegt, dass eines der Netzwerkgeräte (z. B. Firewalls, NAT, Router) zwischen Ihrem Computer und dem Remoteserver nicht so konfiguriert ist, dass VPN-Verbindungen zugelassen werden. Wenden Sie sich an Ihren Administrator oder Ihren Dienstanbieter, um zu ermitteln, welches Gerät das Problem verursachen kann." In der Windows-Ereignisanzeige findet sich der Fehler 809.
Wie sich herausstellte, sind die betroffenen Kollegen und ich Kunden bei der Deutschen Glasfaser, alle anderen können sich weiterhin verbinden. Um zu untersuchen, ob es wirklich an der Deutschen Glasfaser liegt, habe ich dann auf einem Laptop die VPN-Verbindung eingerichtet. Ergebnis: Über meine Netzwerk zuhause (Glasfaser) schlägt das Herstellen der Verbindung fehl, über die mobilen Daten meines Handys war die Verbindung sofort aufgebaut.
Ich habe dann einmal Wireshark installiert und mitlaufen lassen. Beim Aufbau der VPN-Verbindung kommt es zu folgenden Einträgen (hhh.hhh.hhh.hhh ist die IP-Adresse meines Rechners zuhause, fff.fff.fff.fff ist die öffentliche IPv4-Adresse der Firma):
No. Time Source Destination Protocol Length Info
12 5.919221 hhh.hhh.hhh.hhh fff.fff.fff.fff ISAKMP 586 IKE_SA_INIT MID=00 Initiator Request
13 5.954627 fff.fff.fff.fff hhh.hhh.hhh.hhh ISAKMP 523 IKE_SA_INIT MID=00 Responder Response
14 5.964103 hhh.hhh.hhh.hhh fff.fff.fff.fff IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=00dd) [Reassembled in #15]
15 5.964103 hhh.hhh.hhh.hhh fff.fff.fff.fff ISAKMP 774 IKE_AUTH MID=01 Initiator Request
21 6.960058 hhh.hhh.hhh.hhh fff.fff.fff.fff IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=00de) [Reassembled in #22]
22 6.960058 hhh.hhh.hhh.hhh fff.fff.fff.fff ISAKMP 774 IKE_AUTH MID=01 Initiator Request
23 7.990550 hhh.hhh.hhh.hhh fff.fff.fff.fff IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=00df) [Reassembled in #24]
24 7.990550 hhh.hhh.hhh.hhh fff.fff.fff.fff ISAKMP 774 IKE_AUTH MID=01 Initiator RequestStutzig gemacht haben mich die Einträge Nummer 14, 21 und 23 bezüglich der IP-Fragmentierung, denn standardmäßig sollten sowohl der Windows-10-VPN-Client als auch der Lancom-Router die IKEv2-Fragmentierung nutzen. In Eintrag 12 finde ich auch folgenden Hinweis: Payload: Notify (41) - IKEV2_FRAGMENTATION_SUPPORTED (16430); in Eintrag 13 finde ich diesen Hinweis nicht.
Nach meinem Verständnis passiert also folgendes: Mein PC meldet sich beim Lancom-Router, dass er eine VPN-Verbindung aufbauen möchte. Dabei teilt er auch mit, dass bei ihm die IKEv2-Fragmentierung eingeschaltet ist. Der Lancom-Router antwortet; meldet aber nicht, dass bei ihm die IKEv2-Fragmentierung eingeschaltet ist. Deswegen fragmentiert mein PC die Daten nicht auf IKEv2-Ebene, sondern stellt alles in ein Datenpaket. Da dessen Größe die MTU-Größe überschreitet, wird es auf IP-Ebene fragmentiert. Und diese IP-Fragmente gehen dann unterwegs verloren. Ist das so ungefähr richtig? Auf dem Lancom-Router habe ich auch einmal einen VPN-Trace laufen lassen, und auch da sehe ich, dass bis auf Nummer 12 (IKE_SA_INIT MID=00 Initiator Request) nichts ankommt.
Komisch ist nur, dass es über die mobilen Daten funktioniert. Werden da die IP-Fragmente durchgeleitet? Und wieso plötzlich bei der Deutschen Glasaser nicht mehr?
Und wie kann ich auf dem Lancom-Router die IKEv2-Fragmentierung einschalten? Es gibt da eine Einstellung für die MTU-Größe (steht standardmäßig auf 0), aber egal, was ich da eintrage (1500, 1300...), es ändert sich nichts.
Für Tipps, wie ich die VPN-Verbindung wieder ans Laufen bekomme, wäre ich sehr dankbar.
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: 4645119524
Url: https://administrator.de/contentid/4645119524
Printed on: May 7, 2024 at 21:05 o'clock
10 Comments
Latest comment
Updates können sich ja auch mal unbemerkt automatisch einspielen...
L2TP-IPSec Problem nach CU2022-01 (KB5009543)
Ob es das Obige dann ist kannst du sehr einfach mit einem nicht MS OS wie Androiden, iPhone oder MacBook testen.
L2TP-IPSec Problem nach CU2022-01 (KB5009543)
Ob es das Obige dann ist kannst du sehr einfach mit einem nicht MS OS wie Androiden, iPhone oder MacBook testen.
Hi,
welche Anschlussart und Provider habt ihr denn in der Firma?
Eventuell hat die Deutsche Glasfaser auch wieder etwas verbastelt.
Du könntest mal ein wenig mit der MTU auf Deiner Seite rumspielen. Vgl. bspw. MTU für Wireguard IPv6 ermitteln
Eventuell hilft asuch ein Schwenk auf IPv6, da m.W.n. die DG mit CGN arbeitet.
Gruß
cykes
P.S. Ggf. hilft es auch, mal den Lancom Advanced VPN Client zu testen, der wäre aber kostenpflichtig.
welche Anschlussart und Provider habt ihr denn in der Firma?
Eventuell hat die Deutsche Glasfaser auch wieder etwas verbastelt.
Du könntest mal ein wenig mit der MTU auf Deiner Seite rumspielen. Vgl. bspw. MTU für Wireguard IPv6 ermitteln
Eventuell hilft asuch ein Schwenk auf IPv6, da m.W.n. die DG mit CGN arbeitet.
Gruß
cykes
P.S. Ggf. hilft es auch, mal den Lancom Advanced VPN Client zu testen, der wäre aber kostenpflichtig.
Moin,
bei vpn schaue ich gerne mal im Blog vom Richard Hicks vorbei.
Hier bzgl deinem Fehler codes:
https://directaccess.richardhicks.com/2019/02/14/troubleshooting-always- ...
Richard Hicks ist bekannt für seinen Always-On-VPN mit Microsoft Infrastruktur.
Eventuell helfen dir hier die Infos.
Könnte sein dass dein ISP die IP Fragmentierung blockiert durch einen Filter und direkt nichts mit deiner Infrastruktur zutun hat? Würde mich aber wundern...
Mit freundlichen Grüßen
Celiko
bei vpn schaue ich gerne mal im Blog vom Richard Hicks vorbei.
Hier bzgl deinem Fehler codes:
https://directaccess.richardhicks.com/2019/02/14/troubleshooting-always- ...
Richard Hicks ist bekannt für seinen Always-On-VPN mit Microsoft Infrastruktur.
Eventuell helfen dir hier die Infos.
Könnte sein dass dein ISP die IP Fragmentierung blockiert durch einen Filter und direkt nichts mit deiner Infrastruktur zutun hat? Würde mich aber wundern...
Mit freundlichen Grüßen
Celiko
Der ISP "sieht" ja nix von der Fragmentierung. Die findet ja nur im IPsec Tunnel statt.
Hallo und erstmal vielen Dank für Eure Antworten.
Ein Windows-Update kann ich als Schuldigen ausschließen, da die Verbindung ja mit ein und demselben Laptop über die mobilen Daten meines Handys hergestellt werden kann und über meinen Glasfaseranschluss nicht. Der Laptop ist updatemäßig auch noch auf dem Stand vom September 2022, und da hat es auch noch über die Deutsche Glasfaser funktioniert.
Eine Nachfrage bei der Deutschen Glasfaser war leider ergebnislos. Der Mitarbeiter war recht unfreundlich und kurz angebunden: "VPN ist nicht von uns, da kann ich nicht helfen". Zu irgendwelchen Umstellungen konnte oder wollte er keine Auskunft geben.
Zum Testen habe ich auf dem Lancom-Router eine IKEv1-Verbindung mit Preshared Key und eine IKEv2-Verbindung mit Preshared Key eingerichtet. Beide Verbindungen kann ich problemlos aufbauen (getestet mit dem Lancom VPN Client, dem Shrew Soft Client und einem iPad). Soweit ich weiß, sind die Datenpakete bei Preshared Keys aber nicht so groß, dass die MTU-Größe überschritten wird, so dass keine IP-Fragmentierung stattfindet. Eine zertifikatsbasierte IKEv2-Verbindung habe ich mit dem Lancom Client nicht hinbekommen, ich bekomme da immer einen "PAP/CHAP Fehler, Benutzername oder Passwort falsch". In Wireshark kann ich aber sehen, dass die Authentifizierungsinformationen vom Lancom Client in mehrere Message-Fragmente unterteilt werden. Er scheint sich also besser mit dem Lancom-Router zu verstehen als der Windows10-VPN-Client.
Der von Celiko verlinkte Beitrag von Richard Hicks scheint deswegen mein Problem zu beschreiben. In den Kommentaren zu dem Artikel steht ja auch, dass beide Seiten der jeweiligen Gegenstelle IKEV2_FRAGMENTATION_SUPPORTED mitteilen müssen, und in der Antwort vom Lancom-Router fehlt das. Jetzt frage ich mich nur, wie ich den Lancom-Router dazu bringe, IKEV2_FRAGMENTATION_SUPPORTED zu schicken. Ein Ändern der MTU-Größe bewirkt leider nichts.
Hat da jemand noch eine Idee? Oder suche ich die Ursache doch an einer ganz falschen Stelle?
Ein Windows-Update kann ich als Schuldigen ausschließen, da die Verbindung ja mit ein und demselben Laptop über die mobilen Daten meines Handys hergestellt werden kann und über meinen Glasfaseranschluss nicht. Der Laptop ist updatemäßig auch noch auf dem Stand vom September 2022, und da hat es auch noch über die Deutsche Glasfaser funktioniert.
Eine Nachfrage bei der Deutschen Glasfaser war leider ergebnislos. Der Mitarbeiter war recht unfreundlich und kurz angebunden: "VPN ist nicht von uns, da kann ich nicht helfen". Zu irgendwelchen Umstellungen konnte oder wollte er keine Auskunft geben.
Zum Testen habe ich auf dem Lancom-Router eine IKEv1-Verbindung mit Preshared Key und eine IKEv2-Verbindung mit Preshared Key eingerichtet. Beide Verbindungen kann ich problemlos aufbauen (getestet mit dem Lancom VPN Client, dem Shrew Soft Client und einem iPad). Soweit ich weiß, sind die Datenpakete bei Preshared Keys aber nicht so groß, dass die MTU-Größe überschritten wird, so dass keine IP-Fragmentierung stattfindet. Eine zertifikatsbasierte IKEv2-Verbindung habe ich mit dem Lancom Client nicht hinbekommen, ich bekomme da immer einen "PAP/CHAP Fehler, Benutzername oder Passwort falsch". In Wireshark kann ich aber sehen, dass die Authentifizierungsinformationen vom Lancom Client in mehrere Message-Fragmente unterteilt werden. Er scheint sich also besser mit dem Lancom-Router zu verstehen als der Windows10-VPN-Client.
Der von Celiko verlinkte Beitrag von Richard Hicks scheint deswegen mein Problem zu beschreiben. In den Kommentaren zu dem Artikel steht ja auch, dass beide Seiten der jeweiligen Gegenstelle IKEV2_FRAGMENTATION_SUPPORTED mitteilen müssen, und in der Antwort vom Lancom-Router fehlt das. Jetzt frage ich mich nur, wie ich den Lancom-Router dazu bringe, IKEV2_FRAGMENTATION_SUPPORTED zu schicken. Ein Ändern der MTU-Größe bewirkt leider nichts.
Hat da jemand noch eine Idee? Oder suche ich die Ursache doch an einer ganz falschen Stelle?
Bedenke nicht mehrere IPsec Clients installiert zu lassen. In der Regel "beissen" die sich gegeneinander. Außer dem onboard Client sollte immer nur ein einziger separater IPsec Client installiert sein.
Da stimmt also was nicht. Entweder kann der Lancom Client das nicht oder das Setup am VPN Server ist falsch.
ich bekomme da immer einen "PAP/CHAP Fehler
Das wäre bei einem Zertifikats Zugriff sehr ungewöhnlich, denn dort gibt es keine EAP Authentisierung mit MSCHAPv2. Der Fehler dürfte bei Zertifikatsauthentisierung gar nicht kommen, denn das passiert einzig nur bei einer User/Pass Authentisierung mit PSK.Da stimmt also was nicht. Entweder kann der Lancom Client das nicht oder das Setup am VPN Server ist falsch.
Nein, ich glaube eher, dass ich das Zertifikat beim Lancom Client nicht richtig eingebunden bekomme. Die Beschreibung von Lancom, die ich dazu gefunden habe, ist schon etwas älter, und die Oberfläche des Programms sieht mittlerweile etwas anders aus.
Hier wird übrigens ein ähnlicher Fall wie bei mir beschrieben:
Deutsche Glasfaser, Fehler VPN Verbindung zum Arbeitgeber
Am Ende wird auf den Lancom Advanced VPN Client umgestellt, aber niemand weiß, warum eine funktionierende Konfiguration mit dem Windows-10-VPN-Client von einem Moment auf den anderen nicht mehr geht.
Hier wird übrigens ein ähnlicher Fall wie bei mir beschrieben:
Deutsche Glasfaser, Fehler VPN Verbindung zum Arbeitgeber
Am Ende wird auf den Lancom Advanced VPN Client umgestellt, aber niemand weiß, warum eine funktionierende Konfiguration mit dem Windows-10-VPN-Client von einem Moment auf den anderen nicht mehr geht.
Das weiss man schon wenn man die Windows Update Relase Notes aufmerksam mitverfolgt... 
L2TP-IPSec Problem nach CU2022-01 (KB5009543)
Betrifft ja, wie immer, nur Winblows. Wenn du alternativ einmal den onboard IKEv2 Client eines Apple Macs, iPhones oder eines Androiden verwendet hättest würdest du das auch selber sehen... 😉
Wenns das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
L2TP-IPSec Problem nach CU2022-01 (KB5009543)
Betrifft ja, wie immer, nur Winblows. Wenn du alternativ einmal den onboard IKEv2 Client eines Apple Macs, iPhones oder eines Androiden verwendet hättest würdest du das auch selber sehen... 😉
Wenns das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Das weiß man nicht immer, auch wenn man die Windows Update Release Notes aufmerksam mitverfolgt...
Das Update KB5009543 ist auf den betroffenen Rechnern schon lange installiert, und mit meinem Laptop kann ich ja sowohl über die mobilen Daten eines Handys wie auch bei Bekannten, die nicht bei der Deutschen Glasfaser sind, die VPN-Verbindung problemlos herstellen. Bloß über die Deutsche Glasfaser (bei mir zu Hause, bei einem Nachbarn, bei meinem Arbeitskollegen) geht es nicht.
Ich hatte übrigens bei der Deutschen Glasfaser noch ein weiteres Mal angerufen. Anfangs schien der Mitarbeiter auch recht hilfsbereit, bis er Rücksprache mit Kollegen gehalten hat. Danach kam dann wieder nur die Auskunft, man könne mir nicht helfen, da es sich nicht um ein VPN der Deutschen Glasfaser handelt. Es wirkte fast so, als wüßte er etwas, dürfe mir aber nicht sagen, was umgestellt wurde.
Ich schliesse den Thread jetzt aber trotzdem, denn ich glaube, ohne weitere Auskünfte der Deutschen Glasfaser wird sich eine Lösung nicht finden lassen. Bis dahin nutze ich den Shrew Soft Client.
Also vielen Dank für Eure Beiträge!
Das Update KB5009543 ist auf den betroffenen Rechnern schon lange installiert, und mit meinem Laptop kann ich ja sowohl über die mobilen Daten eines Handys wie auch bei Bekannten, die nicht bei der Deutschen Glasfaser sind, die VPN-Verbindung problemlos herstellen. Bloß über die Deutsche Glasfaser (bei mir zu Hause, bei einem Nachbarn, bei meinem Arbeitskollegen) geht es nicht.
Ich hatte übrigens bei der Deutschen Glasfaser noch ein weiteres Mal angerufen. Anfangs schien der Mitarbeiter auch recht hilfsbereit, bis er Rücksprache mit Kollegen gehalten hat. Danach kam dann wieder nur die Auskunft, man könne mir nicht helfen, da es sich nicht um ein VPN der Deutschen Glasfaser handelt. Es wirkte fast so, als wüßte er etwas, dürfe mir aber nicht sagen, was umgestellt wurde.
Ich schliesse den Thread jetzt aber trotzdem, denn ich glaube, ohne weitere Auskünfte der Deutschen Glasfaser wird sich eine Lösung nicht finden lassen. Bis dahin nutze ich den Shrew Soft Client.
Also vielen Dank für Eure Beiträge!
Bloß über die Deutsche Glasfaser (bei mir zu Hause, bei einem Nachbarn, bei meinem Arbeitskollegen) geht es nicht.
Dann muss das irgendetwas mit DS-Lite zu tun haben denn die Dt. Glasfaser ist ein DS-Lite Provider mit zentralem CGNAThttps://www.elektronik-kompendium.de/sites/net/2010211.htm
Bei DS-Lite ist es generell technisch unmöglich von außen per IPv4 zuzugreifen da du das zentrale CGNAT Gateway des Providers nicht überwinden kannst.
Gut, aus deiner Sicht eigentlich egal, weil du ja als Client am DS-Lite Anschluss sitzt und aus der Richtung klappt es immer. Es sei denn du hast vergessen NAT Traversal im VPN Server zu aktivieren. Ohne NAT Traversal wird es aus DS-Lite Anschlüssen nicht klappen.
Möglich auch das Dt. Glasfaser die IPsec Ports filtert was aber eher ungewöhnlich wäre.
