VPN über IPv6

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Frühstücksdirektor
Beiträge: 70
Registriert: 08 Jul 2022, 12:53
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von Frühstücksdirektor »

Nein, Mobike wird derzeit nicht unterstützt, ist auch nicht in der Pipeline.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Dr.Einstein hat geschrieben: 27 Mär 2023, 17:32 ....
https://www.rfc-editor.org/rfc/rfc5996

iOS / Android verarbeiten dann wenigstens die RFC korrekt.
Hab' ich da bzgl. iOS jetzt was falsch verstanden? Du sagtest doch:
Dr.Einstein hat geschrieben: 18 Mär 2023, 00:18 ....
Ich wollte das jetzt auch einmal sehen. Mein iPhone gegen den Lancom Router via v6. Und siehe da, gleiches Szenario wie bei dir, iPhone>Lancom ESP, Lancom>iPhone 4500 UDP.

Ich denke, der Lancom hat einen Bug:
....
Ich hatte das so verstanden, dass auch Dein iPhone Probleme mit den UDP Paketen vom Lancom hatte. Oder meintest Du, dass zwar das gleiche "assymetrische" Packaging wie bei mir vorliegt, das iPhone sich aber nicht drum schert und die UDP Pakete "verdaut"?
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Frühstücksdirektor hat geschrieben: 27 Mär 2023, 17:33 Nein, Mobike wird derzeit nicht unterstützt, ist auch nicht in der Pipeline.
Schade.

Ist denn die Unterstützung von dual stack IPv4/IPv6 im CFG-Mode Server in der Pipeline?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi,

unser IKE-Experte sagt dazu:

in https://www.rfc-editor.org/rfc/rfc7296. ... ction-2.23 steht:

Code: Alles auswählen

   Port 4500 is reserved for UDP-encapsulated ESP and IKE.  An IPsec
   endpoint that discovers a NAT between it and its correspondent (as
   described below) MUST send all subsequent traffic from port 4500,
   which NATs should not treat specially (as they might with port 500).

   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is a NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending ESP with UDP encapsulation is
   not required, but understanding received UDP-encapsulated ESP packets
   is required.  UDP encapsulation MUST NOT be done on port 500.  If
   Network Address Translation Traversal (NAT-T) is supported (that is,
   if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
   all devices MUST be able to receive and process both UDP-encapsulated
   ESP and non-UDP-encapsulated ESP packets at any time.  Either side
   can decide whether or not to use UDP encapsulation for ESP
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST use UDP encapsulation for ESP.
das klingt danach, daß es ein Fehler des Strongswan und des Windows-Client ist, daß die die UDP-Encapsulated Pakete ablehnen..

Gruß
Backslash
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

geppi hat geschrieben: 27 Mär 2023, 17:50 Ich hatte das so verstanden, dass auch Dein iPhone Probleme mit den UDP Paketen vom Lancom hatte. Oder meintest Du, dass zwar das gleiche "assymetrische" Packaging wie bei mir vorliegt, das iPhone sich aber nicht drum schert und die UDP Pakete "verdaut"?
iPhone kommt mit der asymmetrischen Verbindung klar. Sorry, wenn das nicht so ankam. Win10 funktioniert bei mir ebenfalls trotz asymmetrischer Verbindung.
das klingt danach, daß es ein Fehler des Strongswan und des Windows-Client ist, daß die die UDP-Encapsulated Pakete ablehnen..
Ich würde trotzdem gerne verstehen, wieso alle großen Hersteller Port 500, danach Port 4500, danach ESP übermitteln und der Lancom 500, danach 4500, und danach 4500 UDP Enc. verbleibt. Aus meiner Sicht eine Auffälligkeit, unabhängig davon, dass Strongswan mit beiden klar kommen sollte.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Dr.Einstein hat geschrieben: 27 Mär 2023, 18:22 Ich würde trotzdem gerne verstehen, wieso alle großen Hersteller Port 500, danach Port 4500, danach ESP übermitteln und der Lancom 500, danach 4500, und danach 4500 UDP Enc. verbleibt. Aus meiner Sicht eine Auffälligkeit, unabhängig davon, dass Strongswan mit beiden klar kommen sollte.
Vor allem weil der Lancom ja kein MOBIKE unterstützt. Also wozu ist dann bei IPv6 ohne NAT-T überhaupt die UDP encapsulation gut? :G)
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,
Ist denn die Unterstützung von dual stack IPv4/IPv6 im CFG-Mode Server in der Pipeline?
siehe: fragen-zum-thema-vpn-f14/vpn-ueber-ipv6 ... ml#p112950
Vor allem weil der Lancom ja kein MOBIKE unterstützt. Also wozu ist dann bei IPv6 ohne NAT-T überhaupt die UDP encapsulation gut?
Das hat nicht mit IPv6 zu tun, sondern damit daß auf den Port 4500 gewechselt wurde. Das passiert bei IPv4 ohne NAT-T genau so, denn der Client auf Port 4500 wechslet. Nur beim IPv4 hat man es selten mit Verbindugen ohne NAT zu tun (vor allem bei Clients), weshalb das nicht auffällt

UDP-Encapsluation ist nunmal definiert und daher ist die Frage wozu das gut ist, genau so gut, wie die Frage wozu es gut ist, daß eine Banane krumm ist...

Gruß
Backslash
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi Dr.Einstein
Ich würde trotzdem gerne verstehen, wieso alle großen Hersteller Port 500, danach Port 4500, danach ESP übermitteln und der Lancom 500, danach 4500, und danach 4500 UDP Enc. verbleibt. Aus meiner Sicht eine Auffälligkeit, unabhängig davon, dass Strongswan mit beiden klar kommen sollte.
ich weiss nicht was die anderen Hersteller warum machen...

Es geht nunmal darum, daß die Nutzung des Port 4500 vor MOBIKE einfach bedeutete, daß man UDP-Encaslulation machen will. Erst MOBIKE hat hinzugefügt, daß der Wechlel auf Port 4500 nicht mehr gleichbedeutend mit UDP-Encapsulation ist. Und daher hätten eigentlich alle Hersteller, die MOBIKE implementieren, berücksichtigen müssen, daß sie auch UDP-Encaslulation akzeptiern müssen...

Gruß
Backslash
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

backslash hat geschrieben: 28 Mär 2023, 10:46 Es geht nunmal darum, daß die Nutzung des Port 4500 vor MOBIKE einfach bedeutete, daß man UDP-Encaslulation machen will. Erst MOBIKE hat hinzugefügt, daß der Wechlel auf Port 4500 nicht mehr gleichbedeutend mit UDP-Encapsulation ist. Und daher hätten eigentlich alle Hersteller, die MOBIKE implementieren, berücksichtigen müssen, daß sie auch UDP-Encaslulation akzeptiern müssen...
Ich hatte eine kurze Konversation mit Tobias Brunner, einem der StrongSwan Entwickler. So wie es aussieht kann derzeit kein Linux VPN Client plain ESP und UDP enc. ESP gleichzeitig zur selben SA bedienen, weil der Linux Kernel dies nicht unterstützt:
That's not a strongSwan problem as traffic is handle by the Linux kernel. However, the kernel currently doesn't support processing plain ESP packets if the IPsec SA has UDP-encapsulation enabled (and vice-versa).
....
If we don't detect a NAT, we also don't set any encap mode or ports on the SAs, which then causes the Linux kernel to drop encapsulated packets (XfrmInStateMismatch should increase in /proc/net/xfrm_stat), which it obviously shouldn't. On the other hand, it also drops plain ESP packets if the SA has encapsulation enabled.

While some of this can probably be changed quite easily, there are aspects that could be tricky. For instance, the kernel supports various types of hardware offloading and tunneling interfaces and some of these work with static offsets that are pre-calculated per SA to find the start of the ESP header, which wouldn't work anymore (either too much or too little would be skipped).
Da sich Windows gleichermaßen verhält könnte man argwöhnen, daß die Situation dort ähnlich geartet ist.

Letztendlich bleibt es also ein "Interoperability Issue" für das es ja glücklicherweise zwei Workarounds gibt.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

geppi hat geschrieben: 28 Mär 2023, 17:48 Da sich Windows gleichermaßen verhält könnte man argwöhnen, daß die Situation dort ähnlich geartet ist.
Also Windows 10 funktioniert bei mir. Was nutzt du?
geppi hat geschrieben: 28 Mär 2023, 17:48 Letztendlich bleibt es also ein "Interoperability Issue" für das es ja glücklicherweise zwei Workarounds gibt.
Nein, die IKEv2 RFC wurde nicht korrekt implementiert.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Dr.Einstein hat geschrieben: 28 Mär 2023, 17:57 Also Windows 10 funktioniert bei mir. Was nutzt du?
Schau mal in den Eigenschaften Deines VPN-Adapters ob da das Häkchen bei 'Mobilität' gesetzt ist.
Standardmäßig ist es bei mir nach dem anlegen einer neuen VPN-Verbindung gesetzt und damit funktioniert der VPN-Tunnel über IPv6 mit dem Lancom nicht. Wenn man den Haken entfernt funktioniert's. Ich nehme mal an, dass man damit MOBIKE ausschaltet.

Hatte ich auch hier schon geschrieben:
fragen-zum-thema-vpn-f14/vpn-ueber-ipv6 ... ml#p113150
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

Muss meine Aussage zu Win10 zurückziehen. Hatte im Wireshark ESP in eine Richtung gesehen, und 4500 in die andere Richtung und konnte perfekt surfen. Dabei war es IPv6 Verkehr, der am Tunnel vorbeiging. IPv4 im Tunnel geht erst nach Ausschalten der Mobilitätsoption. Sorry für die Verwirrung.
The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later if a NAT is detected on some other path).
Tja, alle großen Hersteller machen es trotzdem, obwohl der Lancom kein "STATUS_MOBIKE_SUPPORTED" zurückschickt.

Andererseits sagt die IKEv2 RFC aus:
An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP-encapsulated ESP packets is required.
Das beißt sich doch in alle Himmelsrichtungen. Der Lancom macht 4500, obwohl er nicht muss. Die Clients verändern auf 4500, obwohl sich nicht auf NAT-T + MOBIKE geeinigt wurde. Clients verstehen zum Teil kein 4500 ESP Traffic, wenn sie selbst reines ESP schicken, obwohl RFC sagt, muss. Zum Glück hast du eine Lösung für dich gefunden.

Hast du einen Powershell-Befehl für das Deaktivieren der Mobilität im Windows? Dazu habe ich nichts gefunden.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Dr.Einstein hat geschrieben: 28 Mär 2023, 19:58 Das beißt sich doch in alle Himmelsrichtungen....
Also ich finde das inzwischen eigentlich alles recht logisch.

Sowohl der StrongSwan als auch der native Windows VPN-Client unterstützen standardmäßig MOBIKE.
Deswegen wechseln sie beim ersten IKE_AUTH Paket auf Port 4500 wie es RFC 4555 https://datatracker.ietf.org/doc/html/r ... ection-3.3 fordert.
Da ihnen der Lancom keine MOBIKE Unterstützung signalisiert und auch keine NAT vorliegt wechseln sie danach auf plain ESP, da es für eine weitere UDP Kapselung keinen Grund gibt.
Insofern verhalten sich StrongSwan und der native Windows VPN-Client absolut identisch.

Beim nativen Windows VPN-Client kann man die MOBIKE Unterstützung abschalten.
Dann wechselt er beim ersten IKE_AUTH Paket nicht auf Port 4500 sondern bleibt auf Port 500 und macht danach wie gehabt mit plain ESP weiter.

Beim StrongSwan VPN-Client kann man im NetworkManager Plugin die Unterstützung von MOBIKE nicht deaktivieren. Das ginge ohne den Gnome NetworkManager zwar über die 'swanctl.conf', diese wird aber bei Verwendung des NetworkManager Plugins gar nicht verwendet. Daher habe ich das Verhalten des StrongSwan VPN-Client ohne MOBIKE Unterstützung nicht testen können, würde aber erwarten, dass er sich dann genauso wie der native Windows VPN-Client verhält.

Andererseits bietet das StrongSwan NetworkManager Plugin die Möglichkeit UDP Encapsulation zu forcieren.
In diesem Fall wechselt der StrongSwan VPN-Client beim ersten IKE_AUTH Paket auch auf den Port 4500 (muss er ja wegen MOBIKE), konfiguriert seine SA im Linux Kernel aber mit UDP Kapselung und macht dann dementsprechend mit solchen Paketen auf Port 4500 weiter.

So sieht man das alles auch in den Wireshark Traces.

Die Möglichkeit UDP Kapselung zu forcieren gibt es wiederum beim nativen Windows VPN-Client nicht, weshalb ich das Verhalten diesbezüglich unter Windows nicht testen konnte. Ich würde aber im Umkehrschluss zur Deaktivierung von MOBIKE auch hier das gleiche Verhalten beider VPN-Clients erwarten.

Der Lancom Router wiederum versendet plain ESP solange die IKE_AUTH Pakete nur über Port 500 gekommen sind.
Sowie beim Verbindungsaufbau ein IKE_AUTH Paket auf Port 4500 empfangen wurde bleibt er in der weiteren Kommunikation bei UDP encapsulated ESP auf Port 4500.

Ich sag's jetzt mal so: "Kann man machen, muss man aber nicht".

Ja die Spezifikation erlaubt es und ja die anderen Hersteller müssten eigentlich auch damit umgehen können.
Aber, bisher habe ich noch keine Begründung gesehen warum es sinnvoll sein könnte dies zu machen.
Es beinhaltet schließlich auch einen zusätzlichen Overhead. Der ist zwar sicher gering aber trotzdem unnötig.
Ich bin aber gerne bereit mich durch eine plausible Begründung vom Gegenteil überzeugen zu lassen. :wink:
Dr.Einstein hat geschrieben: 28 Mär 2023, 19:58 Hast du einen Powershell-Befehl für das Deaktivieren der Mobilität im Windows? Dazu habe ich nichts gefunden.
Nein, leider nicht. Ich mach das halt über die GUI, was OK ist wenn man's nur einmal für eine VPN-Gegenstelle konfigurieren muss.
Ich bin mir aber relativ sicher, dass die GUI auch nur irgendeinen Registry-Key ändert, nur finden muss man den erst. :(
Antworten