Das Freifunknetz ist ein eigenständiges Netzwerk, über das sich deren Nutzer intern miteinander verbinden können, das aber auch die Verbindung ins Internet ermöglicht. Dazu kommen verschiedene Komponenten zum Einsatz, die im Folgenden anhand einer schematischen Übersicht erklärt werden sollen.

Die Nutzer, die sich mit dem Freifunknetz verbinden, nennen wir Clients. Typischerweise verbindet man sich per WLAN mit einem Freifunk-Router, den wir als Node bezeichnen, und der beim Freifunk Stuttgart die SSID „Freifunk“ ausstrahlt. Aus Sicht der Clients ist ein Node gar kein Router, sondern lediglich ein Accesspoint, der den Zugang zum Freifunknetz herstellt.

Da das Freifunknetz als vermaschtes Netzwerk (Mesh) konzipiert ist, um allen aufgeschlossenen Bürgern ein einfaches Mitmachen und Mitbauen am Netzwerk zu ermöglichen, können die Datenpakete von und zu den Clients nicht unmittelbar übertragen werden, sondern müssen in ein Mesh-Protokoll eingebunden werden. Beim Freifunk Stuttgart, wie auch bei vielen anderen Freifunk-Communities, kommt hier batman-adv zum Einsatz.

Nodes können sich untereinander direkt per WLAN verbinden und so miteinander „meshen“. Dazu strahlen sie neben der für die Clients bestimmten SSID „Freifunk“ eine weitere SSID aus, die entweder als ad-hoc-Netz (IBSS mit der hidden SSID 02:04:08:16:32:64) oder seit der Firmware-Version 1.3 als IEEE 802.11s-Netz mit der SSID „ffsmesh_batman“ arbeitet. Man kann aber auch für den Mesh-Traffic Kabel zwischen den Nodes benutzen, was je nach verwendeter Konfiguration als Mesh-on-LAN oder Mesh-on-WAN bezeichnet wird. Eine Gruppe aus miteinander meshenden Nodes nennen wir Mesh-Wolke.

Um Mesh-Wolken untereinander zu verbinden bzw. um Clients im Freifunknetz den Zugang zum Internet zu ermöglichen, muss jede Mesh-Wolke über mindestens einen Node verfügen, der mit einem Freifunk-Gateway verbunden ist. Für diese Verbindung nutzt zwar ein Node einen normalen Internet-Router (DSL- oder Kabel-Router), aber lediglich als Mittel zum Zweck, um eine VPN-Verbindung zum FF-Gateway aufbauen zu können (beim Freifunk Stuttgart per „fastd“). Es wird also keinerlei Mesh-Traffic oder darin eingebettete Datenpakete der Clients unmittelbar am Node ins Internet ausgeleitet, sondern in einem Tunnel zum FF-Gateway geführt. Dieser Umstand sorgt dafür, dass sich ein Node-Betreiber keine Gedanken zur Haftung für mögliche Fehlverhalten der Clients an seinem Node machen muss.

Ein Freifunk-Gateway hat mehrere Aufgaben, die in einem eigenen Beitrag im Detail beschrieben sind. An dieser Stelle ist lediglich von Bedeutung, dass ein Gateway die Verknüpfung zwischen den Mesh-Wolken herstellt, die Clients mit IP-Adressen versorgt und den Clients den Zugang zum Internet bereitstellt.

Bei der Verbindung zwischen Nodes im Freifunknetz bzw. den Clients, die über die Nodes mit dem Freifunknetz verbunden sind, sind mehrere Situationen möglich, die zu unterschiedlichen Datenflüssen führen:

• Die Nodes/Clients sind mit demselben Gateway verbunden. Hier wickelt dieses Gateway alles ab.
• Die Nodes/Clients sind mit unterschiedlichen Gateways im selben Segment verbunden. Hier läuft die Querverbindung zwischen den beteiligten Gateways über den Segment-Backbone auf Basis eines fastd-VPN (bbXX), das auf den Gateways in dieselbe batman-adv Instanz eingebunden ist, wie die fastd-VPNs von den Nodes. Damit befinden sich die Nodes/Clients im selben logischen Netz, als wären sie über einen Switch direkt miteinander verbunden.
• Die Nodes/Clients sind mit unterschiedlichen Gateways in verschiedenen Segmenten verbunden. Hier muss ein Routing stattfinden, das über den zentralen Backbone läuft, der aktuell (01.09.2018) noch als Layer3-tinc-Netz (ffsl3) realisiert ist. Es gibt aber bereits ein Konzept und erste Tests für einen Umbau, der mit dem Routingprotokoll BGP auf Basis expliziter Punkt-zu-Punkt VPN-Verbindungen arbeiten wird.

Am zentralen Backbone werden auch die zentralen Dienste für das Freifunknetz bereitgestellt, insbesondere befinden sich hier die drei DHCP-Server. Die Clients erhalten nämlich ihre IP-Adressen nicht unmittelbar von „ihrem“ Gateway, sondern die Gateways sind lediglich DHCP-Relays, welche ihrerseits die IP-Adressen von den DHCP-Servern anfordern. Dieser Schritt ist notwendig, weil nicht abschätzbar ist, wie viele Clients sich mit welchem Gateway verbinden werden, so dass man den Gateways keine festen Kontingente an IP-Adressen zuweisen kann.

Wir haben im Freifunknetz IPv4 und IPv6. Die Clients bekommen IPv4 und IPv6-Adressen, während die Knoten nur IPv6 haben.

Beim Freifunk Stuttgart werden IP-Adressen aus folgenden Subnetzen verwendet:

• IPv4 = 10.190.0.0/15 (aktuell genutzt nur 10.190.0.0/18 und 10.191.255.0/24 vom zentralen Backbone)
• IPv6 = fd21:b4dc:4b00::/40 - rein intern (aktuell genutzt nur fd21:b4dc:4b00::/42, davon fd21:b4dc:4b00::/64 vom zentralen Backbone)

Die Namensauflösung ist in der Regel über die GWs geregelt. Diese sind Nameserver. Die GWs sind per IPv4 und IPv6 erreichbar. Prinzipiell wäre es denkbar, dass die Namensauflösung auch per IPv6 gemacht wird. Über DHCP bekommen die Clients aber einen IPv4 Nameserver mitgeteilt.

Mit zunehmender Anzahl Nodes und Clients im Freifunknetz nimmt auch die Grundlast im Netzwerk zu. Das hängt einerseits mit dem Verhalten des für das Mesh-Konzept benutzten batman-adv zusammen und ist andererseits eine normale Situation innerhalb eines Ethernet-Netzwerks (Layer 2). Während diese Grundlast jedoch bei den verfügbaren Bandbreiten in einem LAN nicht besonders stört, kann es ein auf WLAN basiertes Mesh-Netz und deren VPN-Uplinks zum Erliegen bringen.

Beim Freifunk Stuttgart haben wir uns daher im Jahr 2016 entschieden, das Netzwerk in verschiedene Teilnetze aufzuteilen, die wir Segmente nennen. Jedes Segment hat seinen eigenen IP-Bereich, und die Gateways verknüpfen diese Segmente per Routing (Layer 3), so dass weiterhin alle Nodes und Clients im gesamten Freifunknetz erreichbar sind.

Bei Änderungen der Segmentzuweisung eines Nodes gibt es folgende Punkte zu beachten:

1. FF-Router mit eigenem VPN-Uplink nutzen je nach Segment und Firmwarestand einen unterschiedlichen Port (Details zu diesem Thema siehe hier). Bitte im vorgelagerten Internetrouter am Besten dem FF-Router die Nutzung aller beim Freifunk-Stuttgart in Frage kommenden Ports erlauben, um bei einem Segment- oder Firmwarewechsel nicht versehentlich ausgesperrt zu sein. Typische Fälle mit Einschränkungen sind Gast-Netze (z.B. bei der FritzBox), an denen der FF-Router angeschlossen wird.

Wir verwenden UDP-Ports, und zwar die Ports 10041 - 10139 (bis Firmware v1.1) bzw. 10201 - 10299 (ab Firmware v1.3). Insbesondere wer noch eine ältere Firmware einsetzt, öffnet am Besten den kompletten Bereich von 10041 - 10299, um nicht nur für Segmentwechsel auf der sicheren Seite zu sein, sondern auch problemlos die Firmware aktualisieren zu können.

2. Die IPv6-Adressen der FF-Router beginnen alle mit fd21:b4dc:4b und direkt anschließend die zweistellige Segmentnummer, gefolgt vom individuellen Teil des Geräts, also z.B. fd21:b4dc:4b04:0:32b5:c2ff:febd:da4 bei einem FF-Router im Segment 04. Bei einer Segmentänderung ändern sich die zwei Ziffern des Segments entsprechend. Der Teil ist nur interessant für diejenigen, die per Browser auf die Statusseite des FF-Routers wollen oder sich per SSH verbinden.

3. Neben den Änderungen bei den FF-Routern ändern sich für die Clients auch die zugewiesenen IP-Adressen. Bei IPv6 gilt für die Clients dasselbe, wie für die FF-Router, bei IPv4 ist der Bereich vom Segment abhängig. Wer keine besondere „Bastellösung“ mit fixen IP-Adressen einsetzt, braucht sich um nichts zu kümmern, weil die DHCP-Server automatisch die passenden IP-Adressen verteilen. Und die „Bastler“ wissen sich selbst zu helfen.

Damit Nodes und Clients, die innerhalb eines Segments mit unterschiedlichen Gateways verbunden sind, sich dennoch innerhalb eines großen Layer-2-Netzes befinden, sind die Gateways pro Segment untereinander jeweils über einen Segment-Backbone verbunden. Dieser ist über VPN-Verbindungen auf Basis von eigenen fastd-Instanzen „bbXX“ realisiert, die jeweils an dieselbe Batman-Instanz angekoppelt sind, wie die VPN-Verbindungen von den Nodes.