# Tunneldigger und IPv6 — Status 2022? **URL:** \ **Category:** Gluon\ **Created:** [15. März 2022 um 00:44 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257 "2022-03-15T00:44:36Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [15. März 2022 um 00:44 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/1 "2022-03-15T00:44:36Z")
Fortsetzung der Diskussion von [Tunneldigger updates - Ihr Handeln ist erforderlich!](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/16): I’ve lost track, I admit. Dennoch, wie ist denn der aktuelle Status bzgl. Tunneldigger (in Gluon) und IPv6? ---
**Author:** ![BELzEBUB](https://forum.freifunk.net/user_avatar/forum.freifunk.net/belzebub/32/26938_2.png) [@BELzEBUB](https://forum.freifunk.net/u/BELzEBUB)\ **Post date:** [15. März 2022 um 13:40 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/2 "2022-03-15T13:40:03Z")
Ist zwar nicht ganz das Thema aber fastd kann ab v22 auch L2TPv3. Funktioniert mit IPv4 und IPv6. > **[fastd v22 — fastd 23 documentation](https://fastd.readthedocs.io/en/stable/releases/v22.html)** > > > This is still a WIP, in particular because fastd v22 hasn't been released yet. ~…In addition to more testing, I'm also thinking about (optionally) statically linking the required parts of libmnl into fastd to reduce the size before v22 final.~ libmnl is linked into fastd statically now. > > \- Most of the added logic is in \`gluon-mesh-vpn-fastd\`; the new package/feature \`gluon-mesh-vpn-fastd-l2tp\` only contains a marker file > \- With \`configurable = true\`, we always add \`null@l2tp\` before \`null\`, so the L2TP method is preferred > \- The old GMAC-based methods are not supported anymore > \- When \`mesh-vpn-fastd-l2tp\` is included, the following changed are applied to the fastd configuration: > - \`offload\_l2tp = 1\`. This also requires \`persisist\_interface = 0\` and \`mode = 'multitap'\`. > - Toplevel \`peer\_limit\` is set to 1, as Gluon supports only a single \`mesh\_vpn\` interface > \- The \`interface\` of each peer config is set to "mesh\_vpn", so the interface for the single connection is correctly named "mesh\_vpn" in Multi-TAP mode > > On supernodes the following changes are necessary: > \- Update to latest "main" branch of fastd > \- Add "null@l2tp" to the front of the method list > > By only enabling L2TP offloading on the Gluon nodes and not the super nodes, no other changes are necessary on the super nodes. If CPU performance is problematic on supernodes, L2TP offloading can be enabled on the supernode as well, but this will require more complex config adjustments, as a separate interface will be created for each peer. > > Due to the inclusion of the L2TP kernel support, enabling the \`mesh-vpn-fastd-l2tp\` Gluon feature increases the image size (by roughly 9.2KiB on ar71xx-generic, compared to an image with the same configuration and only \`mesh-vpn-fastd\`). > > TODO: > \- ~fastd v22 release~ > \- ~Testing~ > \- ~Documentation~ Ich hab das mal bei mir auf einem 842v3 getestet und die Ergebnisse können sich sehen lassen. ![threema-20220227-155954980](https://forum.freifunk.net/uploads/default/original/3X/b/b/bbe4f0c700df4e3ad17a3ad2ce5d0f215bb503b0.png) ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [15. März 2022 um 14:14 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/3 "2022-03-15T14:14:24Z")
> [@BELzEBUB](#): > > Ist zwar nicht ganz das Thema Genau … WireGuard kann auch mit IPv6 umgehen, L2TP ebenso, OpenVPN auch, … Die Frage wurde schon gezielt so gestellt, wie sie gestellt wurde; ich möchte nicht schon wieder die Infrastruktur ändern, wenn vermeidbar — zumal dann 90% der Bestandsgeräte rausfallen (4/16-Thema aka »841er«). Falls unvermeidbar (Mobilfunk- als auch DSL-Zugänge in D werden mehr und mehr v6-mainly (mit Alibi-v4-Adresse 192.0.0.4)), würde es dann wohl vxlan-in-wg werden. ```auto 1?: [LOCALHOST] pmtu 1500 1: 192.168.666.1 0.737ms 1: 192.168.666.1 0.790ms 2: 192.0.0.2 1.183ms pmtu 1452 2: 192.0.0.1 5.655ms 3: i66F666F6.versanet.de 8.397ms ``` ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [17. März 2022 um 18:19 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/4 "2022-03-17T18:19:19Z")
Der vorbereitende Schritt (entfernen der kruden NAT-hacks) ist getan und bei uns seit geraumer Zeit in Produktion. Für den eigentlichen IPv6-Support hat sich jedoch seit [diesem Draft](https://github.com/wlanslovenija/tunneldigger/pull/116) nichts mehr getan. Siehe auch [diesen Issue](https://github.com/wlanslovenija/tunneldigger/issues/75). Ich habe das auch selber nicht auf der TODO-Liste, helfe aber gerne beim Begutachten von PRs. ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [20. März 2022 um 15:13 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/5 "2022-03-20T15:13:58Z")
Ich hab mir das ganze Thema seit Ewigkeiten nicht mehr angeschaut. Ich arbeite außerdem gerade an einem Testsetup für fastd v22 mit L2TPv3 in unserem Netzwerk. Die Gluon Doku zu fastd mit L2TPv3 stammt in großen Teilen von mir. Ich vermute mal, dass ich das Thema Tunneldigger IPv6 also nicht unbedingt nochmal aufnehmen werde. Mein letzter Stand zu meinem damaligen Pull Request: Funktioniert soweit, ich hatte glaube ich nur einen Fehler bei der MTU Berechnung im Client Code gemacht, der dazu führte dass auf manchen Leitungen ein paar Verbindungen nicht klappten. Wir hatten meinen IPv6 Code sogar kurzzeitig in Produktion. Die größte Schwierigkeit (die hauptsächlich damit zu erklären ist, dass ich ein lausiger C Programmierer bin) war aus meiner Sicht die Implementierung von Happy Eyeballs, sodass stets die Verbindung zustande kommt, die am zackigsten aufgebaut werden kann. So wie es aktuell ist verbindet sich der Client nach und nach mit den in der DNS Auflösung vorhandenen Replies, die je nach Betriebssystem unterschiedlich geordnet sein können. Somit ist der Verbindungsaufbau nicht wirklich strukturiert gemäß Bevorzugung irgendeines Protokolls. Helfe gerne, falls jemand sich entscheidet die Arbeit wieder aufzunehmen. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [22. März 2022 um 01:42 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/6 "2022-03-22T01:42:40Z")
> [@Felix](#): > > Ich vermute mal, dass ich das Thema Tunneldigger IPv6 also nicht unbedingt nochmal aufnehmen werde. Danke für die klaren Worte. Damit ist aus meiner Sicht Tunneldigger als Transport EOL’d; so long and thanks for all the traffic served. ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [22. März 2022 um 02:49 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/7 "2022-03-22T02:49:57Z")
Ich fühle mich natürlich geschmeichelt, dass du die Zukunft des Tunneldiggers an meinem Involvement festmachst. Ich bin aber was Contributions angeht da eher ein kleiner Fisch gewesen 😉 Kann ja sein, dass sich das nochmal jemand zu Gemüte führt. Allerdings ist fastd als L2TPv3 broker aus meiner Sicht etwas einfacher zu handhaben (und zusammen mit systemd-networkd echt unschlagbar, dank dem batman-adv support von @awlnx und anderen (💐)) Gatewayseitig ist das fast schon ein drop-in replacement. Clientseitig ist natürlich ein Firmware Update fällig. Man kann Tunneldigger und fastd mit L2TP sogar parallel betreiben, falls notwendig. fastd kann außerdem auch die Verbindungen authentifizieren, sodass das Aussperren von Knoten im Fehler/Missbrauchsfall wieder etwas besser klappt. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [22. März 2022 um 04:11 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/8 "2022-03-22T04:11:16Z")
> [@Felix](#): > > Ich fühle mich natürlich geschmeichelt, dass du die Zukunft des Tunneldiggers an meinem Involvement festmachst. Du bist ja nicht der Erste, der kein gesteigertes Interesse an Tunneldigger & IPv6 zeigt: > [@ralfj](#): > > Ich habe das auch selber nicht auf der TODO-Liste Ist ja auch ok, ggf. muß man mit der MTU einfach weiter runter, um mit getunneltem IPv4 klarzukommen. fastd ist verbrannte Erde, fastd war der Bremsklotz, den L2TP mit Hilfe von Tunneldigger entfernte — der Drops ist PR-mäßig gelutscht, I won’t touch this. Bis auf weiteres tut Tunneldigger ja, IIRC hatten wir eine MTU gewählt, die für Unitymedia-AFTR-v4 paßte, und das, was 1&1 derzeit macht, scheint nicht mehr Overhead zu produzieren. Und jüngst wurde gerade wieder eine v4-only-Glasfaser bereitgestellt (Stadtwerke-ISP) – moar incomimg –, vielleicht wird IPv6 doch überbewertet 😉 ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [22. März 2022 um 05:55 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/9 "2022-03-22T05:55:15Z")
> [@wusel](#): > > fastd ist verbrannte Erde, fastd war der Bremsklotz, den L2TP mit Hilfe von Tunneldigger entfernte — der Drops ist PR-mäßig gelutscht, I won’t touch this. Das ist natürlich schade, dass du das so siehst. Ich denke technische Argumente werden für dich in dieser Situation belanglos sein. Aber ich habe meine Gedanken dazu dennoch mal niedergeschrieben, für die, die es möglicherweise interessieren könnte: fastd v22 macht mit der `null@l2tp` method und konfigurierter [`offload` Option](https://fastd.readthedocs.io/en/stable/manual/config.html#option-offload) exakt das selbe wie Tunneldigger (per Netlink L2TPv3 Interfaces konfigurieren). D.h. Transport komplett im Kernelspace. Gluonseitig wird das ebenso (d.h. per Kernel L2TPv3 Treiber) umgesetzt, wenn `null@l2tp` zum Einsatz kommt. Im Ergebnis hast du damit die selbe Performance wie bei Tunneldigger Setups. Nur kannst du bei fastd wie gewohnt mit peers und keys arbeiten (muss natürlich nicht, ein `on verify "true";` tut’s natürlich auch) und komplett transparent auch verschlüsselte Methoden anbieten für die, die ihren 841 eher gemächlich aber verschlüsselt mögen. All das natürlich auch per IPv6. Und ich denke IPv6 kann im Zeitalter verstopfter AFTR (Wortwitz nicht beabsichtigt) durchaus eine Verbesserung darstellen. Siehe auch die VPN Doku des Gluon `master` branch: [Mesh VPN — Gluon 2023.2.2 documentation](https://gluon.readthedocs.io/en/master/features/vpn.html) ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [23. März 2022 um 09:15 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/10 "2022-03-23T09:15:03Z")
Danke, aber das ändert nichts an der eher ungewissen Zukunft von Tunneldigger, und darauf zielte die Frage ja ab. Aber für ein Netz, daß sich vor n Jahren mühsam von fastd gelöst hat, ist der Rückwechsel zu fastd als v6-taugliches Frontend für L2TPv3 doch weder technisch noch strategisch so richtig zielführend. Wireguard macht verschlüsselte L3-Verbindungen mit näherungsweise der Geschwindigkeit von unverschlüsselten L2TP-Tunneln möglich, warum dann also, wenn man schon den Transportlayer tauschen muß, nicht gleich auf ein moderneres Setup setzen? (Wer bei fastd geblieben ist, kann nun natürlich diese Ernte billig einfahren :-)) Wobei für mich die Frage war, ob ich in diesen sauren Apfel beißen muß — und danach sieht es derzeit ja aus. ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [23. März 2022 um 13:14 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/11 "2022-03-23T13:14:56Z")
Wir nutzen nach wie vor Tunneldigger und haben aktuell auch keine Pläne, das zu ändern. Ich bin zuversichtlich dass ich Tunneldigger so weit maintainen kann dass das auch weiterhin geht. Allerdings sehe ich bisher nicht den Leidensdruck, IPv6-Support einzubauen. ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [23. März 2022 um 22:27 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/12 "2022-03-23T22:27:00Z")
> [@wusel](#): > > Aber für ein Netz, daß sich vor n Jahren mühsam von fastd gelöst hat, ist der Rückwechsel zu fastd als v6-taugliches Frontend für L2TPv3 doch weder technisch noch strategisch so richtig zielführend. Ich sehe das etwas anders. Beim Wechsel von Tunneldigger auf fastd mit L2TPv3 wechselt man nur das VPN Client/Broker-Gespann. Bei der Einführung von Wireguard hast du einen größeren Wechsel im Backend zu stemmen, da VXLAN als weiterer Layer hinzukommt. Ein Wechsel von Tunneldigger auf fastd ist mit 2-3 Änderungen am Backend und einem Gluon Update erledigt. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [24. März 2022 um 01:06 UTC](https://forum.freifunk.net/t/tunneldigger-und-ipv6-status-2022/23257/13 "2022-03-24T01:06:19Z")
> [@Felix](#): > > Beim Wechsel von Tunneldigger auf fastd mit L2TPv3 wechselt man nur das VPN Client/Broker-Gespann. Bei der Einführung von Wireguard hast du einen größeren Wechsel im Backend zu stemmen, da VXLAN als weiterer Layer hinzukommt. Die Packages für alle Varianten – fastd, L2TP mit Hilfe von Tunneldigger, VXLAN-über-Wireguard-plus-Broker – existieren ja. Und VXLAN wurde ja gerade gewählt, weil es in Gluon sowieso schon vorgesehen ist — zwischen Knoten zumindest. (Nicht auf meinem Mist gewachsen.) Was bleibt – bei einem Wechsel weg von Tunneldigger egal wohin –, ist ein inkompatibler Change, wodurch alte Knoten keine akuellen Gateways mehr ansprechen können — also abgehängt werden, wenn es für sie keine Firmware mehr gibt (4/32). Und wenn ich diesen Schritt gehen muß, dann für den größtmöglichen Nutzen. Policy: KISS. Damit fallen Ansätze mit dualen Protokollen raus. Aber wie gesagt, vermutlich reicht die aktuell gewählte MTU von 1364 noch lange …