Auch im Jahr 2026 ist IPv6, fast 30 Jahre nach seiner Standardisierung, immer noch nicht der Normalfall in Netzwerken. Gerade Universitätsnetzwerke (z.B. eudroam) haben hier erheblichen Nachholbedarf.1 In diesem kleinen Blogpost möchte ich zeigen, wie ich mir IPv6-Konnektivität direkt, ohne Zusatzgeräte, auf den Laptop hole. Als sehr netten Nebeneffekt kann ich nun auch das Freifunknetz jederzeit erreichen.
Für dieses Tutorial ist es praktisch, sich die Schritte aus dem Freifunk-VM-Tutorial nochmal anzuschauen. Mit diesem Wissen ist es relativ einfach, da nur ein paar Routing-Regeln im Network-Manager dazukommen.
Egons Plan
Mit bbb-configs haben wir in der Berliner Freifunk-Community ein Framework entwickelt, dass aus einer einzelnen YAML-Konfigurationsdatei die Firmware-Images für einen kompletten Standort erzeugen kann. Die Einstellungen sind hierbei bereits im Image enthalten: Nach dem Flashen des Geräts startet es also bereits mit der fertigen Konfiguration und kann direkt genutzt werden. Im Gegensatz zur normalen Falter-Firmware richtet sich bbb-configs explizit an die “Profis”. Jene Freifunker:innen, die bereits einiges an Admin- und Linuxerfahrung gesammelt haben und das Backbone-Netz aufbauen und warten.
Für unser Ziel hat bbb-configs eine ganz wesentliche Eigenschaft: IPv6 ist hier bereits fertig verfügbar (Stand März 2026), während wir es in falter noch nachrüsten müssen. Für den Rest des Tutorials werden wir also bbb-configs nutzen.
Der Plan ist folgender: Wir starten eine VM mit dem bbb-configs-Image. Dieses wird automatisch einen VPN-Tunnel ins Freifunk-Netz aufbauen und somit die komplexen IPv6-Dinge für uns erledigen.
bbb-configs Image erzeugen
Zuerst holen wir uns über den Config-Wizard eine IP-Adressen-Allokation. Dadurch müssen wir später keine DHCP-Leases von zentralen Servern bekommen (siehe hierzu auch Berlin-Tutorials im Freifunk-Wiki).
Um das Image für unsere VM erzeugen zu können, brauchen wir eine bbb-config. Hier eine Beispiel-Config:
---
location: my-vpn
location_nice: "mys IPv6-VPN und Netz-Entry VM-Router"
contact_name: "my"
contacts:
# Link zu einem Kontaktformular. Kommt mit der IP-Allokation mit
- "https://config.berlin.freifunk.net/contact/8349asdf5f_FpasdfeqF4Pc"
hosts:
- hostname: my-vpn
role: corerouter
model: "x86-64"
# Adressen aus dem Config-Wizard
#-- Mesh-IPs
# 10.31.42.42 10.31.42.43 10.31.42.44
#-- DHCP-Network
# 10.31.43.0/27
# 2001:64::/56
ipv6_prefix: "2001:64::/56"
networks:
# DHCP für clients
- vid: 40
role: dhcp
untagged: true
ifname: eth1
prefix: 10.31.43.0/27
ipv6_subprefix: 0
assignments:
my-vpn: 1
# Uplink interface
- vid: 50
role: uplink
untagged: true
- role: tunnel
ifname: ts_wg0
mtu: 1280
prefix: 10.31.42.42/32
wireguard_port: 51820
- role: tunnel
ifname: ts_wg1
mtu: 1280
prefix: 10.31.42.43/32
wireguard_port: 51821
# SSH-Keys der Maintainer ersetzen und nur eigenen Pub-Key nutzen
ssh_keys:
- comment: my
key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPumG myKey
Wenn wir diese Konfiguration bauen, erhalten wir ein Image, dass im Prinzip wie ein normales Falter-Image funktioniert: Nur, dass eben auch die Wireguard-IPv6-Tunnel enthalten sind, über die wir den IPv6-Traffic ins Internet bekommen.
Sobald das Image gebaut ist, konvertieren wir es so, dass wir es in libvirtd verwenden können. Anschließend erstellen wir die VM so, wie bereits im Freifunk-VM-Tutorial beschrieben.
Dieses Mal bauen wir uns allerdings auch ein “Kabel” zum LAN-Port der Maschine. Dafür erstellen wir uns ein Bridge-Interface und verbinden es vor dem ersten VM-Start mit dem ersten NIC der VM:
$ nmcli connection add type bridge con-name vbr42 ifname vbr42
$ nmcli connection modify vbr42 ipv4.route-metric 1000
vbr42 ist der Name, den ich für diese Bridge gewählt habe. Es ist wichtig, die zweite Zeile auch auszuführen: Wir setzen damit eine (schlechte) Metrik auf alle Routen, die wir vom Freifunk-Router per DHCP auf vbr42 bekommen werden. Warum das notwendig ist, zeige ich in einem Abschnitt weiter unten.
Die NICs in der VM sollten nun wie folgt eingestellt werden:
- Netzwerkquelle: Überbrückungsgerät, Gerätename:
vbr42(Das wird der “LAN-Port”) - Netzwerkquelle: Virtuelles Netzwerk ‘default’ (NAT) (Das wird der “WAN-Port”)
Anschließend können wir die Freifunk-VM das erste Mal starten. Wenn alles geklappt hat, sollte™ nach weniger als 5 Minuten eine IPv6-Verbindung ins Internet möglich sein.
Prüfen: Debugging der Verbindung
Um die korrekte Funktion zu überprüfen, kann man mehrere Dinge tun. Hier eine kleine Auswahl an Dingen:
Im Webbrowser: https://myip.is/ aufrufen. Es sollte eine IPv6-Adresse aus dem Berliner Freifunk-Prefix angezeigt werden.
In der Shell des Laptops:
$ ip address show vbr42
6: vbr42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether fe:42:00:42:42:86 brd ff:ff:ff:ff:ff:ff
inet 10.31.43.23/27 brd 10.31.43.0 scope global dynamic noprefixroute vbr42
valid_lft 267sec preferred_lft 267sec
inet6 2001:64::beef:fe42:0042:4286 /64 scope global dynamic noprefixroute
valid_lft 5297sec preferred_lft 2597sec
inet6 fe80::651d:beef:caff:ee/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Damit sehen wir, dass uns der Freifunk-Router (in der VM) eine IPv6-Adresse gegeben hat.
Auf dem Laptop:
ping -6 quad9.net
PING quad9.net (2001:620:2020:5:9::138) 56 Datenbytes
64 Bytes von 2001:620:2020:5:9::138: icmp_seq=1 ttl=55 Zeit=26.7 ms
64 Bytes von 2001:620:2020:5:9::138: icmp_seq=2 ttl=55 Zeit=21.0 ms
64 Bytes von 2001:620:2020:5:9::138: icmp_seq=3 ttl=55 Zeit=21.5 ms
^C
--- quad9.net Ping-Statistiken ---
3 Pakete übertragen, 3 empfangen, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 20.997/23.076/26.718/2.583 ms
Was zeigt, dass wir einen IPv6-host erreichen konnten.
Auf dem Router:
$ logread | grep tunspace
Zeigt uns die Logs zu tunspace, der Berliner Tunnel-Implementierung, an.
Warum Metrik schlechtere Metriken setzen?
$ ip route show
default via 141.23.192.1 dev wlp3s0 proto dhcp src 141.23.193.31 metric 600
default via 10.31.43.1 dev vbr42 proto dhcp src 10.31.43.23 metric 1000
10.30.96.0/19 via 10.31.43.1 dev vbr42 proto dhcp src 10.31.43.23 metric 1000
Diese Ausgabe zeigt uns die sog. default-Routen für IPv4. Eine default-Route wird immer dann genommen, wenn die Zieladresse, oder ihr Netzwerk, nicht explizit in unserer Routingtabelle genannt sind. Das heißt auch, dass der ausgehende Traffic des virtuellen Freifunk-Routers die default-Route nimmt.
Kleinere Metriken haben Vorrang vor größeren Metriken.
Hätten wir die Metrik nicht selbst festgelegt, hätte der Network-Manager der Route über den Freifunk-Router eine Metrik von 450 gegeben und damit diese Bevorzugt. Das hieße im Umkehrschluss, dass ausgehender Traffic vom Freifunkrouter beim Laptop ankommt und dann wieder an den FF-Router geschickt würde: Eine super Routingschleife, die allerdings dafür sorgt, dass man nie im Internet ankommt. Um das zu verhindern, die bewusst schlechtere Metrik.
Da unser Uplink-Netzwerk (in dem der Laptop Client ist) keine IPv6-Adressen verteilt (sonst würden wir die ganze Sache ja nicht machen), sieht die Routingtabelle für v6 in etwa so aus:
$ ip -6 r s
2001:64ff::/64 dev vbr42 proto ra metric 425 pref medium
2001:64ff::/56 via fe80::ff:fe00:1 dev vbr42 proto ra metric 425 pref medium
fe80::/64 dev vbr42 proto kernel metric 1024 pref medium
default via fe80::ff:fe00:1 dev vbr42 proto ra metric 425 pref medium
Womit wir sehen können, dass die default-Route für IPv6 über unser Bridge-interface mit dem Freifunkrouter läuft. Mission accomplished! :)