Hallo,
mein 1906VA hat seit LCOS 10.92RU4 oder RU5 Probleme mit IKEv1-Verbindungen. Die Nicht-LANCOM-Geräte am anderen Ende können leider nur IKEv1. In den Logs beider Seiten sehe ich nichts, nur bricht die Verbindung oft nach ca. 90% der Lifetime zusammen (also steht offiziell noch, aber es lassen sich keine Daten mehr übertragen), was nach Rekeying-Problem riecht.
Ich hatte bis 10.92RU3 keine derartigen Probleme, RU5/RU6/RU7 haben dann das Problem (RU4 habe ich nicht getestet).
Da in den Release-Notes von RU5 "Rekeying" als Stichwort auftaucht, wenn auch in Verbindung mit IKEv2, meine Frage an mögliche Insider:
Ist da etwas bekannt, viell. ein IKEv1-Bug reingekommen? Danke!
IKEv1-Problem in aktuellem LCOS 10.92?
Moderator: Lancom-Systems Moderatoren
Re: IKEv1-Problem in aktuellem LCOS 10.92?
mal ohne die insider antwort abzuwarten.
IKEv2 ist seit 12 Jahren etabliert.
IKEv1 ist seit 2023 offiziell abgekündigt (rfc9395).
Wenn ich das richtig verstanden habe ist es so, dass LANCOM IKEv1 offiziell nicht mehr unterstützt, man es aber noch nicht aktiv verhindert/ausbaut um den Kunden Zeit zu geben.
Deine möglichkeiten:
- auf einen Tip hier im Forum hoffen
- einen aktuell unterstützten gemeinsamen Nenner zwischen deinen Komponenten suchen (z.b. wireguard wenn es eine fritzbox ist)
IKEv2 ist seit 12 Jahren etabliert.
IKEv1 ist seit 2023 offiziell abgekündigt (rfc9395).
Wenn ich das richtig verstanden habe ist es so, dass LANCOM IKEv1 offiziell nicht mehr unterstützt, man es aber noch nicht aktiv verhindert/ausbaut um den Kunden Zeit zu geben.
Deine möglichkeiten:
- auf einen Tip hier im Forum hoffen
- einen aktuell unterstützten gemeinsamen Nenner zwischen deinen Komponenten suchen (z.b. wireguard wenn es eine fritzbox ist)
Gruß Lukas
Re: IKEv1-Problem in aktuellem LCOS 10.92?
Da hast Du grundsätzlich absolut recht.
Aber in der 10.92 werden wir Wireguard nicht mehr erleben, und höher geht mit dem Modell nicht.
Außerdem scheint es ja nur eine Mini-Regression zu sein, deswegen meine Hoffnung auf Behebung.
Aber in der 10.92 werden wir Wireguard nicht mehr erleben, und höher geht mit dem Modell nicht.
Außerdem scheint es ja nur eine Mini-Regression zu sein, deswegen meine Hoffnung auf Behebung.
Re: IKEv1-Problem in aktuellem LCOS 10.92?
Also dass mit dem Update auf 10.92 (bis RU4) in der Vergangenheit Probleme bei IKEv1 einhergingen, ist bekannt. Das war aber in der Regel so, dass die VPNs gar nicht mehr hochkamen, und nicht, wie bei Dir jetzt, nach einer gewissen Zeit nicht mehr laufen.
Es war immer das gleiche: Alles funktioniert und jemand macht in einem VPN-Verbund (also mindestens zwei, in der Regel ja mehr) von LANCOM-Routern bei einem Gerät ein Update auf die 10.92 (bis RU4) oder höher (bis 10.94 RU1). Dann gingen die IKEv1-VPN-Verbindungen nicht mehr. Liegen tat das daran, dass LANCOM die Algorithmen BLOWFISH, CAST128, DES mit der 10.92 entfernt hat. Sicher in guter Absicht, weil die nicht mehr zeitgemäß/sicher sind. Diese Algorithmen wurden aber auch gar nicht genutzt (durch Aushandlung auf den besten gemeinsamen Nenner, also z. B. AES). Die Gegenseite bietet sie aber natürlich noch an. Damit kam der LANCOM mit der 10.92 aber nicht klar und verstand nicht, was das für Algorithmen sein sollen. Die waren für ihn unknown. An der Stelle brach dann leider die VPN-Verhandlung zusammen, obwohl der LANCOM die unbekannten Algorithmen ja ignorieren könnte und dann unter den anderen angebotenen den besten aussuchen könnte. Machte er aber nicht.
Siehe auch: fragen-zum-thema-vpn-f14/geloest-kein-i ... ml#p123532
Dieses Problem wurde mit der 10.92-RU5 gefixt. (nicht dokumentiert in den Release-Notes, siehe Link oben)
Ich würde also kontrollieren, ob die IKEv1-Verbindungen bezüglich der verwendeten/angebotenen Algorithmen wirklich optimal (auf den LANCOM) eingestellt sind, vielleicht ist da ja doch noch irgendwo was, was dann im späteren Verlauf hakt und zu dem Stillstand führt.
Wenn das nicht klappt, könnte man das unterschiedliche Verhalten zwischen 10.92-RU4 und 10.92-RU5 mal tracen und auswerten.
Grundsätzlich kann man IKEv1-Verbindungen auch Pollen. Drei Formen des Pollings sind in einem LANCOM-VPN-Router möglich:
PPP-LCP-Echo-Monitoring: Dies kann genutzt werden, wenn es sich um eine Dynamic-VPN-Verbindung handelt (in Deinem Fall also nicht). (Polling mit Pings, sobald die pollende Seite Daten von der Gegenseite empfängt, geht sie davon aus, dass der Tunnel funktioniert und verzichtet auf das aktive Pollen (für die eingestellte Polling-Zeit, z. B. 30 Sekunden).)
Dead Peer Detection: Sendet "are you there" Pakete als Teil des IKE-Vorgangs.
ICMP-Polling: Sendet ICMP-Pakete an eine IP-Adresse der Gegenseite (im Idealfall an die interne IP-Adresse der VPN-Gegenstelle).
Eine gleichzeitige Nutzung mehrerer Pollings ist möglich. Zur Erkennung des Verbindungsabbruchs ist nur je eine einzelne Variante notwendig.
Beachten: Das Polling prüft die Phase 2, während DPD nur die Phase 1 prüft. Es gibt immer die Möglichkeit, dass zwar eine aktive Phase 1 besteht, die Phase 2 SAs aber aus irgendeinem Grund weggebrochen sind (z. B. bei einem fehlerhaften Rekeying der Phase 2). In diesem Fall würde DPD munter weiterbehaupten, dass alles ok sei, während das Polling die Verbindung trennen würde.
Es war immer das gleiche: Alles funktioniert und jemand macht in einem VPN-Verbund (also mindestens zwei, in der Regel ja mehr) von LANCOM-Routern bei einem Gerät ein Update auf die 10.92 (bis RU4) oder höher (bis 10.94 RU1). Dann gingen die IKEv1-VPN-Verbindungen nicht mehr. Liegen tat das daran, dass LANCOM die Algorithmen BLOWFISH, CAST128, DES mit der 10.92 entfernt hat. Sicher in guter Absicht, weil die nicht mehr zeitgemäß/sicher sind. Diese Algorithmen wurden aber auch gar nicht genutzt (durch Aushandlung auf den besten gemeinsamen Nenner, also z. B. AES). Die Gegenseite bietet sie aber natürlich noch an. Damit kam der LANCOM mit der 10.92 aber nicht klar und verstand nicht, was das für Algorithmen sein sollen. Die waren für ihn unknown. An der Stelle brach dann leider die VPN-Verhandlung zusammen, obwohl der LANCOM die unbekannten Algorithmen ja ignorieren könnte und dann unter den anderen angebotenen den besten aussuchen könnte. Machte er aber nicht.
Siehe auch: fragen-zum-thema-vpn-f14/geloest-kein-i ... ml#p123532
Dieses Problem wurde mit der 10.92-RU5 gefixt. (nicht dokumentiert in den Release-Notes, siehe Link oben)
Ich würde also kontrollieren, ob die IKEv1-Verbindungen bezüglich der verwendeten/angebotenen Algorithmen wirklich optimal (auf den LANCOM) eingestellt sind, vielleicht ist da ja doch noch irgendwo was, was dann im späteren Verlauf hakt und zu dem Stillstand führt.
Wenn das nicht klappt, könnte man das unterschiedliche Verhalten zwischen 10.92-RU4 und 10.92-RU5 mal tracen und auswerten.
Grundsätzlich kann man IKEv1-Verbindungen auch Pollen. Drei Formen des Pollings sind in einem LANCOM-VPN-Router möglich:
PPP-LCP-Echo-Monitoring: Dies kann genutzt werden, wenn es sich um eine Dynamic-VPN-Verbindung handelt (in Deinem Fall also nicht). (Polling mit Pings, sobald die pollende Seite Daten von der Gegenseite empfängt, geht sie davon aus, dass der Tunnel funktioniert und verzichtet auf das aktive Pollen (für die eingestellte Polling-Zeit, z. B. 30 Sekunden).)
Dead Peer Detection: Sendet "are you there" Pakete als Teil des IKE-Vorgangs.
ICMP-Polling: Sendet ICMP-Pakete an eine IP-Adresse der Gegenseite (im Idealfall an die interne IP-Adresse der VPN-Gegenstelle).
Eine gleichzeitige Nutzung mehrerer Pollings ist möglich. Zur Erkennung des Verbindungsabbruchs ist nur je eine einzelne Variante notwendig.
Beachten: Das Polling prüft die Phase 2, während DPD nur die Phase 1 prüft. Es gibt immer die Möglichkeit, dass zwar eine aktive Phase 1 besteht, die Phase 2 SAs aber aus irgendeinem Grund weggebrochen sind (z. B. bei einem fehlerhaften Rekeying der Phase 2). In diesem Fall würde DPD munter weiterbehaupten, dass alles ok sei, während das Polling die Verbindung trennen würde.
Re: IKEv1-Problem in aktuellem LCOS 10.92?
Zudem ist der VPN Trace am LANCOM, sofern Responder, Aussagekräftig. Selbst bei ikev1.
Ändert aber nichts daran das IKEv1 sich nicht mehr in der aktiven Entwicklung befindet und auch nicht mehr supportet wird durch den Partnersupport.
Ändert aber nichts daran das IKEv1 sich nicht mehr in der aktiven Entwicklung befindet und auch nicht mehr supportet wird durch den Partnersupport.
Re: IKEv1-Problem in aktuellem LCOS 10.92?
Vielen Dank, die Idee mit dem Polling als Selbstreparatur ist super und macht es mir auch möglich, am Prod-System Traces zu fahren.
Hab auch einen ersten Stillstand per Trace miterleben können. Es passiert wahrscheinlich immer, wenn beide Seiten zeitnah versuchen zu rekeyen (werd das mal auf einer versuchen abzuschalten), daraufhin sendet der LANCOM auch P1/2-Deletes (wo ich mir nicht sicher bin, ob die nicht einfach so ablaufen würden). DPD läuft weiter.
Interessant: Die FritzBox auf der Gegenseite reagiert auf das Delete, was der LANCOM dann 30s später auf das fehlgeschlagene Polling sendet, mit Fehler 0x203d ("phase 1 sa removed during negotiation"), wähnt sich also weiterhin noch in einer Aushandlungsphase?! (Ohne Polling gab es nirgends Log-Meldungen, der Tunnel hing dann einfach).
Ich denke, Ihr habt recht, es werden irgendwelche IKEv1-typischen Race Conditions und daraus folgende Verwirrungen auf LANCOM- und/oder Gegenseite sein. Ist aber erst in den letzten RUs reingekommen, lief jetzt viele Jahre stabil & wartungsfrei. Werde die Gegenseite trotzdem lieber mal auf Profi- statt Home-Equipment umstellen... und es weiter beobachten, Danke für Eure guten Hinweise.
Hab auch einen ersten Stillstand per Trace miterleben können. Es passiert wahrscheinlich immer, wenn beide Seiten zeitnah versuchen zu rekeyen (werd das mal auf einer versuchen abzuschalten), daraufhin sendet der LANCOM auch P1/2-Deletes (wo ich mir nicht sicher bin, ob die nicht einfach so ablaufen würden). DPD läuft weiter.
Interessant: Die FritzBox auf der Gegenseite reagiert auf das Delete, was der LANCOM dann 30s später auf das fehlgeschlagene Polling sendet, mit Fehler 0x203d ("phase 1 sa removed during negotiation"), wähnt sich also weiterhin noch in einer Aushandlungsphase?! (Ohne Polling gab es nirgends Log-Meldungen, der Tunnel hing dann einfach).
Ich denke, Ihr habt recht, es werden irgendwelche IKEv1-typischen Race Conditions und daraus folgende Verwirrungen auf LANCOM- und/oder Gegenseite sein. Ist aber erst in den letzten RUs reingekommen, lief jetzt viele Jahre stabil & wartungsfrei. Werde die Gegenseite trotzdem lieber mal auf Profi- statt Home-Equipment umstellen... und es weiter beobachten, Danke für Eure guten Hinweise.