UniFi - 5G Load Balancing mit Telekom: IPv6, APN, IP Passthrough und Dual-WAN

Ein UniFi 5G Backup klingt zunächst unkompliziert: 5G-Router an WAN2 anschließen, Failover oder Load Balancing aktivieren und bei einem Ausfall der Hauptleitung übernimmt der Mobilfunkanschluss. Mit IPv4 funktioniert dieses Prinzip vergleichsweise einfach. Sobald IPv6 ins Spiel kommt, ändert sich jedoch ein entscheidender Punkt: Die öffentliche Adresse gehört nicht nur zum Anschluss, sondern stammt aus dem Präfix eines bestimmten Providers.

Genau das macht IPv6 Failover und IPv6 Load Balancing deutlich komplizierter als bei IPv4. In meinem Testaufbau mit UniFi und einem Telekom-Mobilfunkanschluss zeigte sich außerdem, wie stark das Verhalten davon abhängt, welchen Telekom-APN man verwendet und ob der 5G-Router im Router-Modus oder mit IP Passthrough arbeitet.

Ein Client kann gleichzeitig mehrere Adressen besitzen:

Für normale öffentliche Dual-Stack-Ziele kann man sich die Auswahl stark vereinfacht so merken:

Diese Merkhilfe beschreibt öffentliche Dual-Stack-Ziele mit der üblichen Adressauswahl nach RFC 6724. Sie ist keine feste Reihenfolge für alle Betriebssysteme und Anwendungen: Erreichbarkeit, lokale Richtlinien und Happy Eyeballs beeinflussen die tatsächliche Verbindung. Für interne ULA-Ziele gelten andere Voraussetzungen. Das ist für die GUA-vs-ULA-Problematik entscheidend.

Eine GUA – Global Unicast Address – ist eine öffentlich routbare IPv6-Adresse. Hat ein Client eine funktionierende GUA und die Gegenstelle bietet ebenfalls IPv6 an, wird normalerweise IPv6 verwendet.

Das Problem bei Dual-WAN: Die GUA stammt aus dem Präfix eines bestimmten Providers.

Diese Adresse gehört routingtechnisch zu WAN1. Fällt WAN1 aus, kann die UniFi diese Adresse nicht einfach über WAN2 eines anderen Providers schicken. Der zweite Provider besitzt keine Route zurück zu diesem Präfix; außerdem kann er Pakete mit einer fremden Quelladresse verwerfen. Für neue IPv6-Verbindungen braucht der Client deshalb eine passende Adresse des aktiven Anschlusses oder eine geeignete Übersetzung am Gateway.

Bei IPv4 ist das wesentlich einfacher:

Die private IPv4-Adresse ist providerunabhängig. UniFi entscheidet erst am Gateway, über welchen WAN-Anschluss die Verbindung geht.

Bei nativem IPv6 ist die Providerzuordnung dagegen bereits in der Clientadresse enthalten.

Das erklärt auch, warum ein 50/50-Load-Balancing nicht automatisch 50 Prozent des gesamten Verkehrs über jeden Anschluss schickt. Besitzt der Client eine funktionierende GUA von WAN1, können viele Verbindungen direkt per IPv6 über WAN1 laufen. Das klassische NAT-basierte IPv4-Load-Balancing verteilt nur den IPv4-Verkehr. Ob und wie IPv6 über beide Anschlüsse funktioniert, muss für das konkrete UniFi-Gateway, die Softwareversion und die konfigurierten Regeln separat geprüft werden. Auch bei IPv4 beziehen sich Gewichte auf die Verteilung von Verbindungen; ein einzelner Download nutzt dadurch nicht automatisch beide WANs gleichzeitig.

Ein normaler Festnetzanschluss stellt häufig ein größeres IPv6-Präfix per Prefix Delegation bereit. Bei Telekom-Festnetzanschlüssen ist beispielsweise ein /56 üblich. Ein /56 enthält 256 separate /64-Netze und eignet sich hervorragend für VLANs. Telekom hilft Community (Prefix Delegation)

UniFi kann ein solches Präfix per IPv6 Prefix Delegation übernehmen und für die einzelnen Netzwerke jeweils ein /64 verwenden. Ubiquiti unterstützt sowohl Prefix Delegation als auch den Sonderfall eines einzelnen /64 für nur ein Netzwerk. Ubiquiti Hilfezentrum

Beim Mobilfunk sieht es anders aus. Dort erhält das Endgerät typischerweise lediglich ein einzelnes /64 und keinen großen /56-Block zur Weiterdelegation. Auch die Telekom-Business-Option „Feste IPv6-Adresse“ stellt ausdrücklich ein festes /64 bereit. Telekom Business

Technisch enthält natürlich auch ein /64 sehr viele IPv6-Adressen. Für einen nachgelagerten Homelab-Router ist das Problem aber: Er bekommt kein großes Präfix, das er wiederum auf mehrere VLANs aufteilen kann. In manchen Router-Konstellationen sieht die UniFi deshalb lediglich eine einzelne GUA auf dem WAN-Interface.

Für ein Smartphone ist das kein Problem. Für eine Firewall mit mehreren internen Netzen schon.

Beim Telekom-Mobilfunk sollte man den APN nicht als nebensächliche Einwahleinstellung betrachten. Je nach APN bekommt man technisch einen ziemlich anderen Internetzugang.

Die Telekom dokumentiert aktuell internet.v6.telekom als Standard-APN und internet.telekom für ältere Geräte: Telekom APN-Einstellungen

Die aktuelle Telekom-Hilft-Übersicht führt internet.t-d1.de als veraltet, aber weiterhin als IPv4-Single-Stack-APN ohne NAT auf. internet.telekom arbeitet mit NAPT für IPv4, während internet.v6.telekom auf IPv6 und 464XLAT setzt. Telekom hilft Community (APN-Übersicht)

Für internet.t-d1.de wird traditionell folgende Konfiguration verwendet:

Diese Daten werden in der Telekom-Hilft-Community seit Jahren für den Zugang mit öffentlicher IPv4 verwendet. Telekom hilft Community (Legacy-APN)

Wichtig: internet.t-d1.de ist heute ein Legacy-APN und unterstützt laut aktueller Telekom-Übersicht kein 5G Standalone beziehungsweise 5G+. Er sollte daher nicht als vertraglich garantierte Lösung für eine öffentliche IPv4 betrachtet werden. Telekom hilft Community (APN-Übersicht)

Gerade für einen 5G Router mit IP Passthrough ist er trotzdem interessant: Bekommt der 5G-Router tatsächlich eine öffentliche IPv4, kann diese – sofern das Gerät es unterstützt – direkt an das UniFi-WAN durchgereicht werden. Damit entfallen Double NAT und die private Transitadresse des Mobilfunkrouters.

Der aktuelle Standard-APN verfolgt einen anderen Ansatz. Der eigentliche Mobilfunkzugang kann IPv6-only arbeiten, während IPv4-Ziele über Übersetzungsverfahren erreichbar bleiben.

Eine wichtige Technik dabei ist 464XLAT.

Vereinfacht:

Ein IPv4-Paket wird also zunächst in einen IPv6-basierten Transport überführt und auf Providerseite wieder zu IPv4 umgesetzt.

Für Smartphones ist das sehr praktisch: Die Anwendung muss nicht wissen, dass das Mobilfunknetz intern IPv6-only arbeitet.

Für Homelabs können NAT64, DNS64 und 464XLAT jedoch zusätzliche Abhängigkeiten schaffen. DNS64 wird bei DNS-basierter NAT64-Nutzung eingesetzt; 464XLAT selbst benötigt für IPv4-Anwendungen nicht zwingend DNS64. Entscheidend ist außerdem, ob der Mobilfunkrouter CLAT unterstützt. Eine öffentliche IPv4 für eingehende Verbindungen entsteht dadurch beispielsweise nicht automatisch.

Bei solchen Übersetzungsketten sollte man außerdem die MTU und Path MTU Discovery im Blick behalten.

IPv4 und IPv6 besitzen unterschiedlich große Header. Außerdem fragmentieren IPv6-Router Pakete auf dem Weg nicht einfach wie im klassischen IPv4-Modell. Ist ein Paket zu groß, muss der Absender über ICMPv6 „Packet Too Big“ erfahren, dass er kleinere Pakete schicken soll.

Wenn dieser Mechanismus irgendwo zwischen Client, UniFi, 5G-Router und Mobilfunknetz nicht sauber funktioniert, kann ein irritierendes Fehlerbild entstehen:

Der Grund: Ein kleiner Ping passt problemlos durch den Pfad. Beim Aufbau einer TLS-Verbindung werden dagegen größere TCP-Segmente übertragen.

ICMPv6 „Packet Too Big“ sollte auf dem Pfad zugelassen werden. Bei TCP kann MSS Clamping helfen, indem bereits beim Verbindungsaufbau eine kleinere maximale Segmentgröße ausgehandelt wird. Gerade bei mehreren Übersetzungsstufen wie IPv4 → IPv6 → IPv4 sollte ein MTU-/PMTU-Problem deshalb nicht vorschnell als DNS- oder Firewallfehler interpretiert werden. Die genannten Symptome sind ein Hinweis, aber kein eindeutiger Nachweis. MSS Clamping betrifft TCP; UDP und QUIC benötigen weiterhin einen funktionierenden Umgang mit der Pfad-MTU.

Im normalen Router-Modus kann sich eine interessante Kombination ergeben:

Damit besitzt die UniFi zwar nur eine private IPv4 hinter dem Mobilfunkrouter, aber bereits eine globale IPv6.

Und genau hier wird das Verhalten der Clients wichtig.

Wenn diese GUA beziehungsweise ein entsprechendes Präfix bis zu den Clients gelangt, bevorzugen diese für Dual-Stack-Dienste normalerweise IPv6.

Das kann dazu führen, dass man in UniFi ein vermeintliches IPv4-Load-Balancing eingerichtet hat, der größte Teil des Traffics aber trotzdem über den Anschluss läuft, der die GUA bereitstellt.

IPv6 Load Balancing ist deshalb nicht einfach die IPv6-Version des bekannten NAT-basierten IPv4-Load-Balancings.

UniFi unterstützt inzwischen NAT66. Damit lässt sich ein völlig anderes Modell aufbauen. Ubiquiti Hilfezentrum

Die Clients erhalten keine providerabhängige GUA mehr, sondern ausschließlich eine Unique Local Address:

Diese ULA bleibt unabhängig davon gleich, welcher Internetanschluss gerade verwendet wird.

UniFi könnte anschließend übersetzen:

Das ist für IPv6 Failover konzeptionell attraktiv, weil die Adresse des Clients nicht mehr aus dem Präfix eines bestimmten Providers stammt.

Allerdings gibt es einen wichtigen Nachteil.

Besitzt der Client:

aber keine GUA, weiß er nichts davon, dass UniFi seine ULA später per NAT66 in eine öffentliche Adresse übersetzen könnte.

Für normale öffentliche Dual-Stack-Ziele gilt deshalb wieder die vereinfachte Reihenfolge:

Entfernt man die GUA und behält IPv4 + ULA, wird ein großer Teil des normalen Dual-Stack-Verkehrs also über IPv4 laufen. NAT66 bleibt trotzdem nützlich für IPv6-only-Ziele und für spezielle Multi-WAN-Designs, sofern IPv6-Standardroute, Firewall und passende NAT-Regeln eingerichtet sind. Das Diagramm beschreibt ein mögliches Netzwerkdesign; daraus folgt keine Zusage, dass jede UniFi-Version IPv6-Failover oder IPv6-Load-Balancing automatisch unterstützt. Bestehende Sitzungen können beim WAN-Wechsel abbrechen, wenn sich die öffentliche Quelladresse ändert.

Der stärkere Fokus auf IPv4 kann gewollt sein: Wer beispielsweise UniFi Load Balancing vor allem für große Downloads verwenden möchte, bekommt den Traffic so leichter in das klassische IPv4-Multi-WAN-Modell.

Das eigentliche Problem bei einem UniFi 5G Backup ist weniger 5G selbst als die unterschiedliche Philosophie von IPv4 und IPv6.

IPv4 funktioniert typischerweise so:

Bei nativem IPv6:

Eine GUA ist damit faktisch an den Anschluss gebunden, aus dessen Präfix sie stammt.

Zusätzlich bekommt ein normaler Festnetzrouter häufig ein /56, das sich problemlos auf zahlreiche /64-VLANs aufteilen lässt. Mobilfunk liefert dagegen typischerweise nur ein /64 und keine entsprechend große Prefix Delegation für das Homelab.

Dazu kommen je nach Telekom-APN völlig unterschiedliche Netzwerkmodelle: internet.telekom, internet.v6.telekom, das alte internet.t-d1.de oder im Businessbereich festip.telekom. 464XLAT und NAT64 ermöglichen IPv4 über IPv6-only-Infrastrukturen, bringen aber zusätzliche Themen wie MTU, Path MTU Discovery und Paketübersetzung mit.

Für ein stabiles Homelab sollte man deshalb IPv4 und IPv6 bei Dual-WAN getrennt planen. Ein funktionierender IPv4-Failover bedeutet noch lange nicht, dass IPv6 denselben Weg nehmen kann.