# Abkündigung von Tunneldigger-Support in Gluon **URL:** \ **Category:** Gluon\ **Created:** [11. Oktober 2023 um 00:42 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907 "2023-10-11T00:42:40Z")\ **Posts on this page:** 20\ **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:** [11. Oktober 2023 um 00:42 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/1 "2023-10-11T00:42:40Z")
Fortsetzung der Diskussion von [Gluon Meetup 2023 - 05 (10.10. 20:00 CEST) - today](https://forum.freifunk.net/t/gluon-meetup-2023-05-10-10-20-00-cest-today/23904/3): Lt. [Meeting-Notes](https://github.com/freifunk-gluon/gluon/wiki/Meeting-2023-05) wird Tunneldigger als Transport in Gluon v2023.2 abgekündigt? > [@](#): > > - [👤 @tomh] Future of Tunneldigger > - Are there any Advantages over fastd with null@l2tp? > - not that the people present are aware > > - There were two quite significant issues with tunneldigger in v2023.1. Seems like nobody tests it? > - Migration for existing installations might not be easy, idk? > - But maybe at least mark it as deprecated in favour of fastd with null@l2tp? > - deprecate it with v2023.2 in docs+Release Notes > - move to community packages in v2024.1 Zu den Punkten: > [@](#): > > - Are there any Advantages over fastd with null@l2tp? Als Tunneldigger-Community-Admin würde ich die Frage genau anders herum stellen, welchen Vorteil bringt mir der Wechsel von Tunneldigger (zurück) zu fastd, jetzt mit null@l2tp? Non-l2tp-Modes fressen enorme Mengen an CPU-Zeit auf Clients und Gateways, da möchte ich nie wieder hin, das ist also kein Argument. Beide Tunnel sind somit nicht verschlüsselt, 0:0. Aber um die Frage zu beantworten, aus Adminsicht: - es funktioniert in der vorhandenen Infrastruktur seit Jahren „einfach“ - die Verbindungen landen übersichtlich in 'ner Bridge statt wie bei fastd (zumindest vor null@l2tp) in einem singlethreaded Prozeß, aus dem man den Status mühsam rauspuhlen muß - kein Schlüsselaustausch notwendig - wer das VPN wechselte ist, hatte seine Gründe (ich persönlich möchte fastd definitiv nicht wiederhaben, ist so’n Unix- vs. systemd-Philosophie-Ding) > [@](#): > > - Migration for existing installations might not be easy, idk? Definitiv nicht. Migrationsfirmware wird notwendig plus parallele Backend-Infrastruktur für den Wechsel. Plus, zuvor, Anpassung der Automatisierung — $hier zumindest wurde der fastd-Zweig des Deployments vermutlich ca. 5. Jahre nicht mehr durchlaufen. > [@](#): > > - deprecate it with v2023.2 in docs+Release Notes > - move to community packages in v2024.1 Das bedeutet was konkret für »Tunneldigger-Communities«? Wieviele der 42k Nodes lt. Gluon-Census betrifft diese Entscheidung? ---
**Author:** ![TomH](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@TomH](https://forum.freifunk.net/u/TomH)\ **Post date:** [11. Oktober 2023 um 12:08 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/2 "2023-10-11T12:08:58Z")
Die Diskussion auf dem Meetup erfolgte aus der Gluon Perspektive. Dort gibt es aktuell zwei VPN Protokolle welche letztlich das gleiche können, aber halt nicht identisch gute Optionen sind. Denn das eine erfordert halt einen Watchdog um es am Leben zu halten, hat keinen IPv6 Support und wird nicht regelmäßig getestet. Gut sichtbar wurden die Probleme mit dem Release von v2023.1. Wie sich nun herausgestellt hat war Tunneldigger damit im Prinzip komplett kaputt. Die konkreten Probleme wurden zwar mit dem gestern veröffentlichten v2023.1.1 behoben, aber die grundsätzlichen Probleme verändert das natürlich nicht. Der aktuelle Stand ist das fastd so konfiguriert werden kann das es sich sehr ähnlich wie Tunneldigger verhält: > [@wusel](#): > > - die Verbindungen landen übersichtlich in 'ner Bridge statt wie bei fastd (zumindest vor null@l2tp) in einem singlethreaded Prozeß, aus dem man den Status mühsam rauspuhlen muß Die Verbindungsthematik kann man auf verschiedene Arten angehen. Entweder zum Beispiel über hook skripte welche von fastd aufgerufen werden und die Interfaces in eine bridge packen, oder aber auch z.B. über systemd-networkd und Interfaces welche einem Pattern matchen. Beispiele zu beidem finden sich hier: [fastd L2TP Offloading on Supernodes · freifunk-gluon/gluon Wiki · GitHub](https://github.com/freifunk-gluon/gluon/wiki/fastd-L2TP-Offloading-on-Supernodes) > [@wusel](#): > > - kein Schlüsselaustausch notwendig fastd kann so konfiguriert werden das es einfach alle Verbindungen annimmt. Es gibt einen `on verify` Parameter in der [Config](https://fastd.readthedocs.io/en/stable/manual/config.html). Hier kann auch einfach immer `true` zurück gegeben werden. Dann wird einfach jede Verbindung angenommen. * * * > [@wusel](#): > > Non-l2tp-Modes fressen enorme Mengen an CPU-Zeit auf Clients und Gateways, da möchte ich nie wieder hin, das ist also kein Argument. Es geht ja explizit um fastd mit der `null@l2tp` Methode. Nicht um andere Methoden von fastd. > [@wusel](#): > > Migrationsfirmware wird notwendig plus parallele Backend-Infrastruktur für den Wechsel. Die Migrationsfirmware sehe ich nicht. Der Wechsel muss ja nicht zeitgleich erfolgen. Ein Wechsel des VPNs kann einfach über ein reguläres Update erfolgen und die neue Firmware baut die VPN Verbindung dann halt per fastd statt tunneldigger auf. Aber ja, im Backend muss fastd natürlich installiert werden. Das ist aber halt auch nur einmaliger Aufwand und anschließend gibt es dafür ja auch klare Vorteile. * * * > [@wusel](#): > > Das bedeutet was konkret für »Tunneldigger-Communities«? Wieviele der 42k Nodes lt. Gluon-Census betrifft diese Entscheidung? Es bedeutet das der aktuelle Plan ist den Communities mit Tunneldigger zu empfehlen fastd mit `null@l2tp` als die bessere Alternative zu tunneldigger zu evaluieren. Im darauf folgenden Major Release soll Tunneldigger dann nicht mehr im Core Gluon enthalten sein. Es besteht natürlich die Option tunneldigger fortan als [community-package](https://github.com/freifunk-gluon/community-packages) zu unterhalten wenn Communities dies tun möchten. Mir persönlich erscheint der einamlige Aufwand zu wechseln aber nicht den Aufwand wert weiterhin tunneldigger zu pflegen. Communities mit Tunneldigger im Einsatz sind aktuell mindestens: Eulenfunk: 902, Gütersloh: 560, Münsterland: 3900, Saarland: 741, Südwest: 1005 So ganz genau lässt sich das aber nicht sagen da die Info zum verwendeten VPN Protokoll oft nicht in den Exports enthalten ist. ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [11. Oktober 2023 um 23:52 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/3 "2023-10-11T23:52:22Z")
> [@TomH](#): > > Es besteht natürlich die Option tunneldigger fortan als [community-package](https://github.com/freifunk-gluon/community-packages) zu unterhalten wenn Communities dies tun möchten. Das ist ja möglich. @wusel vielleicht geht es bisher nicht so hervor, es ist eben ein Thema was keiner pflegt. und wir werfen sowas lieber raus, als wie mit 2023.1 plötzlich ein release zu haben, in dem soetwas defekt ist, weil sich niemand darum schert unter den aktiveren Entwicklern. Lieber ein geplantes Ende als immer wieder unerwartete Probleme um die sich keiner kümmert… … und als community-Package bleibt es ja möglich, auch da muss sich aber jemand darum kümmern. ---
**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:** [12. Oktober 2023 um 00:16 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/4 "2023-10-12T00:16:15Z")
> [@rotanid](#): > > … und als community-Package bleibt es ja möglich, auch da muss sich aber jemand darum kümmern. There’s a catch: ich für meinen Teil habe genug anderes auf der ToD-Liste, als daß ich der Gluon-Entwicklung folgen könnte, zumal ohne auch der OpenWrt-Entwicklung zu folgen. Themen auf dem IRC-Channel sind zu 70+% böhmische Dörfer für mich. Das »Tunneldigger-Problem« war, AFAICS, die Einführung/Umstellung auf procd? DAS müßte dann in den Developer Notes zur jeweiligen Gluon-Release stehen, damit daß »off-tree« gepflegt werden könnte — das wäre vermessen zu verlangen (und selbst in kommerziellen Projekten für mich kaum vorstellbar, daß da jede popelige Änderung am Gesamtsystem dokumentiert ist — read the fscking commits, Dude!). Was heißt denn »es ist eben ein Thema was keiner pflegt«? Kein Gluon-Entwickler sitzt in (mehr?) einer Community, die Tunneldigger einsetzt? ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [12. Oktober 2023 um 00:40 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/5 "2023-10-12T00:40:45Z")
> [@wusel](#): > > There’s a catch: ich für meinen Teil habe genug anderes auf der ToD-Liste, also das gleiche Problem aller ehrenamtlichen 😉 > [@wusel](#): > > Kein Gluon-Entwickler sitzt in (mehr?) einer Community, die Tunneldigger einsetzt? es gab (korrigiert mich gerne) noch nie einen Gluon-Maintainer der Tunneldigger genutzt hat. Es war also immer nur Arbeit für andere… Hinzugefügt wurde es 2017 von einem github user namens lcb01a der sich danach nie mehr darum gekümmert hat. ---
**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:** [12. Oktober 2023 um 01:47 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/6 "2023-10-12T01:47:31Z")
> [@rotanid](#): > > also das gleiche Problem aller ehrenamtlichen 😉 Yupp. > [@](#): > > Hinzugefügt wurde es 2017 von einem github user namens lcb01a der sich danach nie mehr darum gekümmert hat. Ah, danke für die Info. Tja, dann wird ›man‹ (@collimas (FFLIP), @corny456 (FFMS) ansehend; wer für FFNW (fehlt in obiger Liste) hier mitliest weiß ich nicht, dito für Saarland und Südwest – @adorfer würde ich beim Eulenfunk sehen?) sich entscheiden müssen, wie ›man‹ weitermacht. ---
**Author:** ![collimas](https://forum.freifunk.net/user_avatar/forum.freifunk.net/collimas/32/18062_2.png) [@collimas](https://forum.freifunk.net/u/collimas)\ **Post date:** [12. Oktober 2023 um 02:25 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/7 "2023-10-12T02:25:33Z")
Wir haben mit Tunneldigger angefangen, als dieser noch nicht vom Gluon Core supported wurde. In Lippe sind es ca. 1200 Nodes, die wir umstellen müssten, das würde ich gerne vermeiden, wenn das möglich ist. Ich möchte fastd auch nicht wiederhaben. Ich könnte gut damit leben, den Tunneldigger wieder als externes Paket einzubinden. ---
**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:** [12. Oktober 2023 um 02:43 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/8 "2023-10-12T02:43:40Z")
> [@rotanid](#): > > > [@wusel](#): > > > > There’s a catch: ich für meinen Teil habe genug anderes auf der ToD-Liste, als daß ich der Gluon-Entwicklung folgen könnte, zumal ohne auch der OpenWrt-Entwicklung zu folgen. > > also das gleiche Problem aller ehrenamtlichen 😉 Wie geschrieben: ja. Aber die Scherzantwort greift zu kurz: Wie ausgeführt – und leider ignoriert –, denke ich nicht, daß man _Kernkomponenten_ wie einen VPN-Dienst sinnvoll out-of-tree und losgelöst vom Gluon-Kern-Team _pflegen_ kann. Hätten wir das heute schon, wären die – von OpenWrt oder Gluon forcierten – Änderungen ja schon jetzt »der Community« auf die Füße gefallen, oder? Es gab’ ja schein’s mindestens zwei Probleme, [#2998](https://github.com/freifunk-gluon/gluon/issues/2998) und [#2977](https://github.com/freifunk-gluon/gluon/issues/2977)? Mindestens an #2998 hätte ich, ohne jedwede OpenWrt-Affinität, vermutlich Wochen gesucht. Das macht man eimal und dann ist man ›mal weg‹ … BTW, FFIN (Paging @citronalco) ist AFAICS auch eine, zumindest [in Teilen](https://freifunk-ingolstadt.de/technik/#VPN-Tunnel), »L2TP-Community«: > ### fastd > > Fastd ist klein, unkompliziert und zuverlässig und hat sich deswegen in den Anfangsjahren von Freifunk schnell als Standardlösung etabliert. Mit fastd aufgebaute VPN-Tunnel sind außerdem zusätzlich verschlüsselt. > Leider läuft fastd im Userspace und ist deswegen, anders als der Name suggeriert, ziemlich langsam. Günstige Access Points erreichen damit nur einen VPN-Durchsatz von etwa 10MBit/s. > > ### L2TP > > Seit einigen Jahren existiert als Alternative L2TP: L2TP läuft direkt im Linux-Kernel und erreicht so auf identischer Hardware einen etwa 4x so hohen VPN-Durchsatz wie fastd. Freifunk Ingolstadt bietet [seit Juni 2020](https://freifunk-ingolstadt.de/2020/06/19/neue-firmware-mit-l2tp/) L2TP an. > > VPN-Tunnel mit L2TP sind im Gegensatz zu fastd-VPN-Tunneln nicht verschlüsselt, d.h. der Internetanbieter hat theoretisch die (illegale) Möglichkeit herauszufinden, welche Daten über den VPN-Tunnel zwischen Access Point und unseren Gateway-Servern übertragen werden. Obwohl der Internetverkehr heutzutage größtenteils ohnehin SSL/TLS-verschlüsselt ist und eine zusätzliche Verschlüsselung des VPN-Tunnels an der rechtlichen Stellung des Freifunk-Access Point-Aufstellers nichts ändert, haben wir deswegen beschlossen, zusätzlich zu L2TP auch weiterhin fastd anzubieten. > > ### Wireguard > > An der Unterstützung für [Wireguard](https://de.wikipedia.org/wiki/WireGuard)-VPN-Tunnel wird gearbeitet. Wireguard ist etwa doppelt so schnell wie fastd und halb so schnell wie L2TP. Mittelfristig wollen wir fastd durch Wireguard ersetzen. (Zu Wireguard: Kudos to FFMUC, das umzusetzen. Aber Batman in VXLAN in Wireguard ist meines Erachtens 'n halber Kontinent neben KISS. Das mag daran liegen, daß ich den Sinn nicht sehe, IP-Pakete, die aus einem offenen, unverschlüsselten, WLAN kommen (das hat sich mit OWE geändert, ja, und das ist da auch gut, ändert aber nichts bzgl. Weitertransport) und die gen Transit und ab dort generell unverschlüsselt transportiert werden, auf meiner letzten Meile exorbitant teuer zu verschlüsseln.) ---
**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:** [12. Oktober 2023 um 03:57 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/9 "2023-10-12T03:57:41Z")
> [@TomH](#): > > Aber ja, im Backend muss fastd natürlich installiert werden. Das ist aber halt auch nur einmaliger Aufwand und anschließend gibt es dafür ja auch klare Vorteile. Für den Fall, daß nicht nur ich diese »klaren Vorteile« nicht wertzuschätzen weiß: welche konkret? > [@](#): > > Die Migrationsfirmware sehe ich nicht. Der Wechsel muss ja nicht zeitgleich erfolgen. Ein Wechsel des VPNs kann einfach über ein reguläres Update erfolgen und die neue Firmware baut die VPN Verbindung dann halt per fastd statt tunneldigger auf. Naja. Hast Du Ports kommuniziert, kannst Du die GWs nicht auf den gleichen Servern laufen lassen — 10000-10999 sind von Deinen L2TP-GWs belegt, also braucht’s eine Dopplung der GW-VMs. Juckte mich jetzt nicht, aber woanders täte das ggf. weh. Ich denke, es hängt schon von den lokalen Umständen ab, ob so ein VPN-Wechsel »trivial« oder »schmerzhaft« würde. Ich vermisse als Anwender (wiedereinmal) eine Empathie der Entwickler bezüglich ihrer Nutzer. > [@](#): > > Mir persönlich erscheint der einamlige Aufwand zu wechseln aber nicht den Aufwand wert weiterhin tunneldigger zu pflegen. Granted. Nach aktuellem Stand sind rd. 11k (add: FFLIP 1200, FFNW 2230) von rd. 42k Nodes betroffen, also grob ein Viertel. Oder stimmt diese Gluon-Census-Rechnung nicht? Einem Viertel ›seiner‹ Knoten den Stinkefinger zu zeigen, klar, kann man machen, aber ist es auch zielführend? ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [12. Oktober 2023 um 10:37 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/10 "2023-10-12T10:37:35Z")
Nochmal vorab: es geht nicht um „morgen fliegt was raus aus Gluon“ sondern um die Ankündigung, das heißt es wird mind. noch ein Gluon-Release damit geben! Heißt, es geht darum, in ~1 Jahr mit der Umstellung anzufangen _oder_ das community-Repository zu nutzen. > [@collimas](#): > > Ich möchte fastd auch nicht wiederhaben. wir haben schon befürchtet, dass alte Animositäten hier vor sachlichen Argumenten stehen könnten. Bitte packt alte Informationen in den Müll und schaut euch die aktuellen Fakten an. > [@wusel](#): > > Leider läuft fastd im Userspace und ist deswegen, anders als der Name suggeriert, ziemlich langsam. Günstige Access Points erreichen damit nur einen VPN-Durchsatz von etwa 10MBit/s. Gleich Zwei aus heutiger Sicht falsche Informationen die du hier einbindest. 1. mit der null@l2tp methode ist die Geschwindigkeit nicht mehr durch den userspace limitiert 2. so billige Geräte die selbst _mit_ userspace im fastd nur 10mbit/s schaffen gibt es doch gar nicht mehr? > [@wusel](#): > > Zu Wireguard die Umstellung von Tunneldigger auf Wireguard dürfte _deutlich_ aufwändiger sein als auf fastd mit l2tp 😉 > [@wusel](#): > > Ich vermisse als Anwender (wiedereinmal) eine Empathie der Entwickler bezüglich ihrer Nutzer. wenn auch nicht hier (wegen des weiten Vorlaufs) vermisse ich die auch manchmal, aber kann man halt nicht ändern im Ehrenamt und sich nur freuen wenn man es schafft nichts plötzlich zu machen (wo ich dann auch mich ärgere) sondern mit weitem Vorlauf wie hier. > [@wusel](#): > > Granted. Nach aktuellem Stand [,.] also grob ein Viertel. > [@wusel](#): > > Einem Viertel ›seiner‹ Knoten den Stinkefinger zu zeigen Also wer so kommt, dem kann man auch entgegnen: Ein Viertel der Knoten bzw. der zugehörigen Communities beteiligt sich nicht an der Weiterentwicklung von Gluon und schnorrt einfach nur? Aber vielleicht ist das in beiden Richtungen nicht zielführend 😉 ---
**Author:** ![T\_X](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/a9adbd/32.png) [@T\_X](https://forum.freifunk.net/u/T_X)\ **Post date:** [12. Oktober 2023 um 19:53 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/11 "2023-10-12T19:53:19Z")
Habe angefangen, eine kleine Übersicht zu den Features der verschiedenen in Gluon supporteten VPN Provider zu erstellen, um eine objektivere Beurteilung zumindest von der Feature-Seite aus zu ermöglichen und vereinfachen (was dann vll. später ins Gluon readthedocs könnte?): > **[HedgeDoc - Collaborative markdown notes](https://md.chaotikum.org/zRkW6JXXQs-8WCnwdtig5w?view)** Wenn noch wem was an Vor- und Nachteilen einfallen sollte, gerne Bescheid sagen oder ergänzen. Auch soweit keine Garantie auf Richtigkeit, also auch bei Fehlern gerne Bescheid sagen bzw. selber korrigieren :-). ---
**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:** [13. Oktober 2023 um 03:25 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/12 "2023-10-13T03:25:03Z")
> [@T\_X](#): > > Habe angefangen, eine kleine Übersicht zu den Features der verschiedenen in Gluon supporteten VPN Provider zu erstellen Danke. > [@](#): > > um eine objektivere Beurteilung zumindest von der Feature-Seite aus zu ermöglichen und vereinfachen (was dann vll. später ins Gluon readthedocs könnte?): Es fehlt mir eine Betrachtug der ›Performance‹ der jeweiligen VPN-Methoden, was sicherlich ein Entscheidungsfaktor ist. Und ob wer, von fastd dereinst geschwind verputzt, heute zu fastd zurückkehren will? Andererseits ist »Gluon« an sich ›feature complete‹, insofern steht nur die jeweilige Anpassung an den OpenWrt-Unterbau an. ---
**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:** [13. Oktober 2023 um 03:29 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/13 "2023-10-13T03:29:04Z")
> [@rotanid](#): > > Ein Viertel der Knoten bzw. der zugehörigen Communities beteiligt sich nicht an der Weiterentwicklung von Gluon und schnorrt einfach nur? Yepp, point taken. Zeit, die Wege zu trennen. ---
**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:** [13. Oktober 2023 um 03:49 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/14 "2023-10-13T03:49:08Z")
> [@TomH](#): > > Ein Wechsel des VPNs kann einfach über ein reguläres Update erfolgen und die neue Firmware baut die VPN Verbindung dann halt per fastd statt tunneldigger auf. Allein, für 4/32-Geräte ist dann »Tunneldämmerung« — außer, die Community beschließt für das Gros ihrer Knoten eine »Legacy«-Infrastruktur (mit Tunneldigger) weiterzubetreiben. ---
**Author:** ![T\_X](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/a9adbd/32.png) [@T\_X](https://forum.freifunk.net/u/T_X)\ **Post date:** [13. Oktober 2023 um 03:49 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/15 "2023-10-13T03:49:52Z")
Hatte ein paar Faktoren zur Geschwindigkeit in der Tabelle mit „… → faster“ in den Spaltennamen angemerkt. „fastd, null@l2tp, offloaded“ und „Tunneldigger (L2TP)“ sollten an sich gleich schnell sein. Denn beide leiten den Traffic nicht selber weiter, sondern richten den Linux Kernel nur entsprechend ein, dass dieser das selber übernimmt über das standardisierte „Layer 2 Tunneling Protocol“. Ob Wireguard oder „fastd, null@l2tp, offloaded“ / „Tunneldigger (L2TP)“ mehr Durchsatz bringt, habe ich nicht getestet, hätte aber auf L2TP getippt, weil diese nichts verschlüsseln und weniger VPN header overhead haben. Theoretisch, wenn der Flaschenhals nicht die Router-CPU ist sondern die Bandbreite des Internetuplinks selber (extremes Beispiel x86 Gluon auf einem flotten PC, aber an einer 1.5MBit/s Internetleitung), könnte auch alles schneller sein als Wireguard+VXLAN, weil es dann nur noch auf den VPN header overhead ankäme. ---
**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:** [13. Oktober 2023 um 03:58 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/16 "2023-10-13T03:58:28Z")
> [@T\_X](#): > > Ob Wireguard oder „fastd, null@l2tp, offloaded“ / „Tunneldigger (L2TP)“ mehr Durchsatz bringt, habe ich nicht getestet, hätte aber auf L2TP getippt, weil diese nichts verschlüsseln und weniger VPN header overhead haben. Im Grunde müßte mal wer ein Pseudo-GW aufsetzen, eine 4040 als Knoten per GBit-LAN daran hängen, daran einen PC und von dort mit iperf3 den Durchsatz zum, optimalerweise „nur“ durch das, GW testen; jeweils für „fastd, null@l2tp“, „Tunneldigger“ und „Wireguard+VXLAN“. ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [13. Oktober 2023 um 12:08 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/17 "2023-10-13T12:08:38Z")
> [@wusel](#): > > Allein, für 4/32-Geräte ist dann »Tunneldämmerung« diese Geräte sind schon seit Gluon v2022.1 nicht mehr unterstützt, weil OpenWrt ab 22.03 und der zugehörige Kernel zu viel Platz brauchen. Da ändert sich also nichts, deren Dämmerung hat schon vor Jahren begonnen 😉 siehe Release Notes unter „Removed devices“: [Gluon 2022.1 — Gluon 2023.2.2 documentation](https://gluon.readthedocs.io/en/latest/releases/v2022.1.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:** [13. Oktober 2023 um 12:11 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/18 "2023-10-13T12:11:52Z")
> [@rotanid](#): > > diese Geräte sind schon seit Gluon v2022.1 nicht mehr unterstützt Das ist unbestritten, aber unbestreitbar auch nicht das Thema hier. ---
**Author:** ![TomH](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@TomH](https://forum.freifunk.net/u/TomH)\ **Post date:** [13. Oktober 2023 um 13:03 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/19 "2023-10-13T13:03:12Z")
Das folgende hilft natürlich höchstens für die Zukunft, aber in Darmstadt sind kommunizierte Port Ranges extra so groß gewählt das es genügend freie Ports gibt um multiple Migrationen zu machen. dom0 verwendet aktuell 100 **0** 0, dom1 100 **1** 0, dom2 100 **2** 0 usw. und auch nach hinten hin sind auch noch ein paar Ports ungenutzt und es könnten noch Domains nach dem gleichen Schema hinzugefügt werden bevor es an die Zwischenräume gehen müsste. Es kann ja immer mal sein das man das VPN Protokoll, die MTU oder irgendwas anderes wechseln möchte oder muss und dann kann das auf den gleichen Gateways mit den gleichen IPs parallel als anderer Service laufen. ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [14. Oktober 2023 um 19:25 UTC](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907/20 "2023-10-14T19:25:21Z")
> [@TomH](#): > > aber in Darmstadt sind kommunizierte Port Ranges extra so groß gewählt das es genügend freie Ports gibt um multiple Migrationen zu machen. so haben wir es auch gehandhabt. Wir haben bei uns aber auch \<1% der Knoten die überhaupt ein Problem damit hätten, wenn sich Ports ändern. [Nächste Seite](https://forum.freifunk.net/t/abkuendigung-von-tunneldigger-support-in-gluon/23907.md?page=2)