Linux Bridge leitet kein IPv6/ICMPv6 weiter

Tuesday, September 1 2015 · Lesezeit: 4 Minuten · 732 Wörter · Tags: bridgeipv6linux Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Zu Hause habe ich auf meinem Homeserver eine virtuelle Maschine auf der Icinga 2 läuft. Diese generiert sich anhand der MAC Adresse der virtuellen Netzwerkkarte eine Link-local-IPv6 Adresse und mit Hilfe der Router Advertisements der pfSense Firewall via SLAAC (Stateless Address Autoconfiguration) eine öffentliche IPv6 Adresse.

Nach dem Booten der Maschine funktioniert alles. Ein paar Checks, die IPv6 benötigen und an meinen Root-Server gehen werden sauber abgearbeitet. Nach einiger Zeit oder einem Prefix-Wechsel werden alle Checks plötzlich rot. Das Problem: Die Kommunikation über IPv6 ist nicht mehr möglich. Nur ein Neustart schein zu helfen.

Einschub: IPv6 tracen mit tcpdump

Meine virtuellen Server zu Hause sind alle ohne graphische Oberfläche. Wiresark ist also nicht installiert, aber tcpdump. Mit tcpdump kann man natürlich genauso arbeiten und reicht für die ersten Schritte aus. Ein Filter für die komplette IPv6 Kommunikation ist ip6. Will man sich nur auf ICMPv6 beschränken ist der Filter icmp6.

Kleines Beispiel, bei der ich ein Bridge Interface belausche:

Ein genauerer Blick ins Paket ist auf dem Terminal unübersichtlich. Man kann aber die Ausgabe von tcpdump zum Beispiel über einen SSH Tunnel in Wireshark pipen. Beispiel:

Happy debugging :-)

Erster Debuggingversuch

Meine erste Vermutung war, dass der Prefixwechsel schuld sein könnte und die pfSense Firewall Probleme mit den Routin hätte. Auf der Übersichtsseite von pfSense habe ich aber festgestellt, dass diese sich korrekte neue Adressen aus dem neuen Prefix gebastelt hat und auch das richtige Prefix via Router Advertisements im Netz bekannt macht.

Verwundert habe ich dann an ein paar Stellen tcpdump angeworfen und ICMPv6 getraced: Auf dem Quell- und Zielserver, an der Firewall und an der Bridge auf meinem Homeserver. Dabei habe ich folgenden Trafficfluss rekonstruieren können:

ICMPv6 Ping Request vom Monitoring Server -> Bridge -> Firewall -> (FritzBox) -> Root-Server gefolgt von einem ICMPv6 Ping Reply auf dem selben Weg zurück. Diese Antwort blieb aber an der Bridge hängen.

Bildlich dargestellt:

In diesem Bild fehlt die Fritz!Box, da ich auf der nicht sauber tracen konnte. Für das Ergebnis ist es uninteressant, da die dahinter gelagerte Firewall die Pakete gesehen hat. Die Fritz!Box konnte ich also ausschließen.

Das Ergebnis: Die Bridge sieht das Antwortpaket leitet es aber nicht an das virtuelle Interface des Servers weiter. Das Problem ist also nicht die virtuelle Maschine, sondern das Hostsystem. Zu diesem Zeitpunkt habe ich mir aber keinen Reim darauf machen können und Lösungen habe ich nach einer intensiven Suche nicht gefunden.

Debugging mit der Link-local Adresse

Am nächster Tag waren alle meine Services wieder rot und meine Pings schlugen fehl. Dann habe ich  Diese ist unabhängig vom öffentlichen Prefix und muss immer funktionieren. Aus diesem Grund habe ich mir zwei virtuelle Maschinen herausgepickt, die beide eine einzige Netzwerkkarte haben, die auf der selben Bridge am Hostsystem anliegen. Pinge ich dann vom Server 1 die Link-local Adresse von Server 2 müsste ich auf jeden Fall eine Antwort erhalten.

Beide Server laufen schon ein paar Stunden. So sieht der Aufbau aus:

lladdress = link layer address => MAC Adresse

 

Auf beiden Server trace ich an der jeweiligen Netzwerkschnittstelle und auf dem Hostsystem an der Bridge ICMPv6 mit.

In regelmäßigen Abständen kommt von fe80::1:1 (pfSense) Router Advertisements. Sende ich Ping Requests an diese Adresse bekomme ich Ping Replys problemlos zurück. Sende ich an die Link-local Adresse von Server 1 an Server 2 bleibt der Traffc an der Bridge hängen.

Nun starte ich beide Server neu. Beim Aufruf von ping6 auf Server 1 und der Link-local Adresse des zweiten Servers passiert exakt das, was ich erwarte: Neighbor Solicitation (ARP Request bei IPv4) geht an die Bridge, die diese Nachricht per Broadcast an alle verteilt. Auf der Server 2 empfängt diese Nachricht und triggert eine Neighbor Advertisement (ARP-Reply bei IPv4) Nachricht. Diese geht an die Bridge und kommt beim Server 1 an.

Daraufhin fliesen ganz normal ICMPv6 Ping Requests von Server 1, die der Server 2 erhält und mit ICMPv6 Ping Replys beantwortet. Diesen Traffic sehe ich logischerweise parallel auch an der Bridge.

Das Problem liegt also wirklich an der Bridge des Hostsystems und ist unabhängig vom Adresstyp.

Lösung

Die Lösung ist einfach: ICMP Snooping auf der Bridge deaktivieren. Dazu habe ich folgenden Befehl eingetippt und in mein Startscript gepackt:

:~$ echo 0 | /sys/devices/virtual/net/br1/bridge/multicast_snooping

Seitdem sind keine Problem mehr aufgetaucht und auch der Prefixwechsel heute Nacht verlief problemlos. Was genau dieser Switch macht habe ich noch nicht ganz verstanden, aber es soll irgendein Flooding verhindern. Needs research :-)

Du hast einen Kommentar, einen Wunsch oder eine Verbesserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg) Zurück