Multi WAN IPv6

[markus.tobatz]

Hallo zusammen,

ich muss doch nochmal fragen, ob mein Vorhaben überhaupt noch so möglich ist. Ich lese seit Stunden zu Multi WAN und Dual Stack etc. und drehe mich im Kreis. Also, zum "alten" Setup nochmal:

- OPNsense 24.1.5
- Glasfaser von der Telekom mit IPv4 und IPv6 /56er Präfix
- IPv4 über PPPoE auf dem VLAN7 der Telekom
- IPv6 wird per DHCP6-PD über die IPv4 Verbindung bezogen
- mehrere VLANs im heimischen Netzwerk, mit separaten DHCPv4-Adressen
- einige der VLANs erhalten zusätzlich über das /56er IPv6-Netz eine eigene IPv6 mit Präfix, dazu wird Tracking auf das PPPoE-Interface verwendet

Das läuft alles stabil. Was die Wurzel allen Übels ist: Ich wollte über LTE eine Fallback-Verbindung aufbauen, weil Glasfaser gelegentlich mal ausfällt. Dazu habe ich meinen China-Router um ein Quectel-LTE-Modul erweitert und ein neues PPP-Interface in OPNsense eingerichtet. Das ist mittlerweile so konfiguriert, dass ich von der Telekom über LTE eine IPv4-Adresse und eine /64er IPv6-Adresse erhalte - also auch hier Dual Stack.

Was möchte ich erreichen:
- Verwendung von Glasfaser als Haupt-Gateway
- Fallback auf die LTE-Verbindung, falls Glasfaser ausfällt
- Erhaltung der IPv6-Funktionalität auch in den VLANs bei Wechsel des Gateways

Es gibt aktuell zwei Knackpunkte, falls ich nichts übersehe:

1) Ich habe für alle vier Gateways (IPv4/6 jeweils Glasfaser/LTE) eine dedizierte Monitoring-IP hinterlegt, aber sobald das LTE-Interface mit IPv6 hochfährt, wird die IPv6 vom Glasfaser Interface als detached markiert und kann von dpinger nicht mehr verwendet werden. Das ist mir zu hoch, versuche da gerade im Forum schon Hilfe zu bekommen.

2) Was vermutlich schwieriger ist: IPv6 beim Wechsel des Gateways auf die VLANs bringen. Wie gesagt, Glasfaser bietet zwar ein /56 Präfix, das ist aber nur dynamisch, über LTE bekomme ich nur eine dynamische /64. Außerdem beziehen die VLANs über Tracking vom Glasfaser Interface ihre IPv6.

Hat hier jemand ein solches Setup bereits zum Laufen bekommen und kann mir einen Hinweis geben? Insbesondere zu einer Lösung für die IPv6-Adressen in den VLANs? In IPv6 bin ich nicht wirklich fit, aber das nicht möglich, den VLANs ein ganz eigenes IPv6 Netz zu geben und die OPNsense übersetzt das ins aktive Gateway (quasi ein NAT)?

[Maurice]

2) Mit "Track Interface" wird das schwierig. Ich habe ein ähnliches Setup: Primäres WAN ist ein Kabelanschluss mit /59, bei dessen Ausfall erfolgt ein Fallback auf LTE. Entscheidender Unterschied ist, dass meine LAN-Interfaces statische IPv6-Adressen haben, ich also kein "Track Interface" verwende. Dadurch haben die LANs auch dann IPv6-Adressen, wenn das primäre WAN down ist. Für IPv6-Internetzugang über LTE NATte ich dann einfach alle LAN-Subnetze auf die LTE-WAN-Adresse. Unschön, aber funktioniert. Da es im Mobilfunk keine Prefix Delegation gibt, ist es leider kaum anders möglich.

Möglich sind die statischen LAN-Adressen, da das /59 meines Kabelanschlusses de facto statisch ist. Es wird zwar über DHCPv6-PD zugewiesen, aber immer das gleiche. Daher behandle ich es intern einfach wie ein statisches Präfix. Wie ist das bei der Telekom? Ändert sich das Präfix häufig?

Grüße
Maurice

[bimbar]

Ein faszinierendes und teilweise ungelöstes Thema, bevor ich hier ganze Abhandlungen schreibe, ob und wenn wie das möglich ist, verweise ich lieber auf:

IPv6 Multihoming IETF Draft: https://datatracker.ietf.org/doc/draft-fbnvv-v6ops-site-multihoming/

Wo die ganze Problematik, finde ich, sehr gut erklärt wird.

[markus.tobatz]

Hallo Maurice,

danke für die Rückmeldung. Ich experimentiere bereits seit Tagen und würde meine Erkenntnisse versuchen zusammenzufassen. Aber kurz vorweg: Nein, ich bekomme beim Neuverbinden ein neues IPv6-Präfix am Glasfaser-Anschluss, ist wohl nur bei Business-Anschlüssen möglich.

Ein Hauptproblem bei meinem Setup scheint wohl, dass die IPv6 vom Glasfaser als detached in OPNsense/FreeBSD markiert wird, sobald das LTE-Interface hochfährt (siehe auch https://forum.opnsense.org/index.php?topic=39995). Das kann ich lösen, indem ich manuell die Adresse per ifconfig wieder hinzufüge. Das ist aber kein sauberer Weg (da dynamisches Präfix) und macht auch Probleme beim Failover.

Genau das war meine Sorge, dass die VLANs nur vom Glasfaser (/56) per PD eine GUA erhalten, aber eben nicht vom LTE. Damit wäre das IPv6 Routing beim Failover hinüber. Meine Überlegung war daher, intern nur mit ULAs zu arbeiten, ähnlich einem IPv4 NAT-Setup. Ich habe keine Dienste, die von außen erreichbar sein müssen und ich habe in dem Fall auch kein Problem, dass Windows IPv4 gegenüber IPv6 bevorzugt. Wichtig ist mir, dass ich überhaupt eine IPv6-Verbindung für IPv6-only-Ziele habe.

Ich hatte daher gestern meine OPNsense wie folgt konfiguriert:

Glasfaser:
    IPv4 per PPPoE
    IPv6 als DHCPv6 mit zusätzlichem /56er Präfix
LTE
    IPv4 per PPPoE
    IPv6 als DHCPv6 ohne Präfix
Wie gesagt, die Glasfaser-IPv6 wird detached, aber per ifconfig konnte ich die manuell erstmal wieder binden.
Es werden dann vier Gateways in OPNsense angelegt, für jedes habe ich eine dedizierte Monitoring-IP hinterlegt und das "Allow default gateway switching" aktiviert.
Dann habe ich alle VLANs wie folgt konfiguriert:
    IPv4 als statisches Netz 192.168.x.1/24
    IPv6 als statisches Netz fd00:x::1/64
DHCPv6 habe ich in OPNsense nicht aktiviert, aber den RA-Modus auf Unmanaged gestellt. Zusätzlich habe ich unter NPTv6 jeweils für Glasfaser und LTE für jedes IPv6-ULA-Netz einen Eintrag erstellt.

Alles einmal gebootet (die detached IPv6 wieder gebunden). Endgeräte haben eine fd00-Adresse erhalten. IPv4 und IPv6 Traffic lief fein. Habe dann vom Glasfaser das Kabel gezogen. Oh wunder, der Traffic lief weiter. Ich habe mich schon tierisch gefreut.
Dann habe ich das LAN-Kabel wieder ins Glasfasermodem gesteckt und der Ärger ging weiter. IPv4 hat sich schnell gefangen und lief. Glasfaser hat zwar eine neue IPv6 bekommen, aber OPNsense schien damit nicht richtig umgehen zu können, es lief dann gar nichts mehr über IPv6. Entweder hängt es mit dem detached-Problem zusammen, oder NPTv6 konnte damit nicht umgehen, ggf. irgendwelche alten Cache-Einträge, oder OPNsense selbst hatte ne Macke, denn in der GUI war auch noch die alte IPv6 zu sehen. Nach einem manuellen delete und create über ifconfig hatte die GUI wenigstens die neue IP, aber dpinger hat sich immer noch an die alte IPv6 gebunden und ließ sich auch nicht beenden oder neustarten. Außerdem fing die OPNsense dann irgendwann an, den RAM komplett auszulasten und war nur noch schwer erreichbar, total spooky. Da war kein Prozess zu finden, der das in Anspruch hat, war einfach verbraucht:
mem_gap_vm:  +   6313377792 (   6020MB) [ 78%] Memory gap: UNKNOWN

Aktuell bin ich ziemlich genervt von allem. Habe LTE wieder deaktiviert und die funktionierende Config mit Glasfaser-Tracking für die VLANs wieder aktiv, so dass ich wenigstens mit den GUAs wieder arbeiten kann.
Ich verstehe von IPv6 auch einfach noch nicht genug und mir ist klar, dass ich hier die IPv4-Techniken nicht auf IPv6 übertragen darf und IPv6 anders konzipiert ist (danke für den Draft-Link, aber ich muss das hier erstmal verdauen), aber etwas enttäuscht bin ich schon, dass das alles so nicht funktioniert, auch wenn das Setup einfach scheint. Klar könnte man den Schuldigen bei der Telekom suchen: Warum kein statisches Präfix für Glasfaser? Warum kein /56er für LTE, zumal ich meine Karte als Datenkarte bestellt habe...

Oder ist OPNsense einfach noch nicht so weit für mein Szenario (Failover mit/ohne dynamischem IPv6 Präfix)? Ideen sind willkommen.

[Maurice]

Genau genommen geht es hier um die grundsätzliche Schwierigkeit, Failover ohne NAT umzusetzen. Das gängige IPv4-Konzept (private Adressen in den LANs + stateful NAT) funktioniert auch mit IPv6, aber das möchte man natürlich nicht. Anders herum wäre IPv4-Failover mit öffentlichen IPv4-Adressen in den LANs auch schwierig.

Bekommt man über beide WANs eine Prefix Delegation, dann kann man beim Failover prinzipiell das Tracking auf das zweite WAN umschwenken. Die LANs bekommen dann neue Adressen, die sich direkt über das zweite WAN routen lassen. Das unterstützt OPNsense aber leider (noch) nicht.

Im Mobilfunk ist mir aber ohnehin weltweit kein Anbieter bekannt, der Prefix Delegation anbietet. Daher bleibt im Failover-Fall eigentlich nur NAT. Da jedes LAN ein eigenes /64 benötigt, lassen sich mehrere LANs über Mobilfunk ohne Tricks grundsätzlich nicht mit IPv6 versorgen. Vor diesem Problem stehen auch Anwender, die Mobilfunk als einzige Anbindung verwenden.

In deinem Fall würde ich es so versuchen:
- LANs tracken das Glasfaser-WAN.
- Zusätzlich ULAs in den LANs (virtual IPs).
- Outbound NAT (kein NPT!) auf dem LTE-WAN-Interface.

Solange das primäre WAN läuft, hast Du eine normale IPv6-Internetverbindung ohne NAT. Fällt diese aus, dann hast Du in den LANs immer noch ULAs und via NAT über LTE auch noch eine IPv6-Internetverbindung (die aufgrund der ULAs aber wirklich nur für IPv6-only-Hosts verwendet wird).

Ein ganz anderer Ansatz wäre tunneln. Du kannst dir z. B. über Wireguard ein GUA-Präfix ins Haus holen, das Du dann in den LANs verwendest. Dann spielt es keine Rolle, ob der Tunnel über Glasfaser oder LTE aufgebaut wird.

Das detached-Thema ist wohl ein Bug im Zusammenhang mit PPP(oE). Stecke ich aber aktuell nicht drin, da ich schon sehr lange keine Szenarien mit PPP mehr hatte.

[schmuessla]

In deinem Fall würde ich es so versuchen:
- LANs tracken das Glasfaser-WAN.
- Zusätzlich ULAs in den LANs (virtual IPs).
- Outbound NAT (kein NPT!) auf dem LTE-WAN-Interface.

Solange das primäre WAN läuft, hast Du eine normale IPv6-Internetverbindung ohne NAT. Fällt diese aus, dann hast Du in den LANs immer noch ULAs und via NAT über LTE auch noch eine IPv6-Internetverbindung (die aufgrund der ULAs aber wirklich nur für IPv6-only-Hosts verwendet wird).

Ich habe fast das gleiche Setup wie der TE und habe das ganze zum jetzigen Zeitpunkt aufgegeben und die Subnetze, die korrektes Failover machen sollen auf v4 only umgestellt.

Der Ansatz mit der GUA dürfte nicht funktionieren, da im Falle des Ausfalls der primären Leitung die Präfixe nicht deprecated werden (https://github.com/opnsense/core/issues/7018 dort habe ich zwar beschrieben, dass es mit dem Disconnect Button nicht funktioniert, aber das Verhalten war mit Leitung absöpseln exakt das Gleiche). Man hat also beim Ausfall weiterhin GUAs an den Clients die nicht mehr gerouted werden können.

[tiermutter]

Ich habe zufällig auch erst die Tage darüber nachgedacht und mir vorgenommen für das failover die ULA zu natten, wie Maurice schon vorgeschlagen hat.
Umgesetzt habe ich es noch nicht, wüsste aber auch nicht was dagegen spricht, mit den ULAs der VPNs mache ich das ja auch schon so...

[schmuessla]

Hat man den Bedarf v6 only Endpunkte zu erreichen kann das schon Sinn machen, aber ich persönlich habe den nicht, weil ich das ganze nur als Hobby in meinem Heimnetz betreibe und der Rest meines Haushaltes nur "das Internet" nutzen will, ist es mir aktuell zuviel Aufwand ULAs zu konfigurieren, die dann eh niemals genutzt werden, weil die ganzen 0815 Dienste sowieso alle per IPv4 erreichbar sind.

[tiermutter]

Ja stimmt schon, solange noch alles mit v4 erreicht wird, besteht da eigentlich kein großer Bedarf und die Firewall erreicht man via VPN ja trotzdem, auch wenn kein Präfix delegiert werden kann... Also zumindest solange es der Anschluss überhaupt ermöglicht, was bei lte ja selten der Fall ist.
Trotzdem fühlt es sich für mich besser an, wenn v6 ausgehend weiter genutzt werden kann und die ULAs habe ich allein schon fürs DNS überall verteilt...

[tiermutter]

Aufgrund aktueller Umstände habe ich mich spontan dafür entschieden die ULAs zu NATen um im Failover-Fall v6 Konnektivität zu haben...
Funktioniert tadellos!

Anbei mal Screenshots für die Nachwelt...

1.
Virtuelle IP für die Sense erstellen. Ich nehme gerne Teile der IPv4...


2.
RA konfigurieren und im LAN verteilen. Vorher muss beim LAN Interface die manuelle Konfiguration erlaubt werden (ganz unten). Als DNS die VIP der Sense eintragen.


3.
Outbound NAT Regel für das ULA Netz (nicht die VIP Hostadresse) auf das Failover Interface anlegen.



... und das war es dann auch schon. Hat bei mir gerade eine Minute gedauert, dann wurde mir in Windows wieder v6 Internetzugriff angezeigt (ULA war aber schon verteilt).

[tiermutter]

Noch nicht erprobt ist das Verhalten wenn das primary WAN (wieder) da ist.
Hier habe ich ein wenig Sorge, dass die Clients sporadisch über die ULA statt GUA und somit über das secondary WAN rausgehen... mal schauen wie die sich dann verhalten...

[bimbar]

Das hatte ich mal eine Zeit lang laufen, funktioniert nicht stabil, wenn die public IPv6 sich ändert.

[tiermutter]

Aber die hat doch gar nichts so recht damit zu tun ?!

[bimbar]

Wenn die Firewall es nicht mitbekommt und dementsprechend das SNAT noch auf die alte Public IP geht, schon.

[tiermutter]

In dem Fall gibt es doch gar kein "alt" und "neu"... Hier wird doch dauerhaft die ULA an das Failover genated und es interessiert gar nicht ob das andere Interface da ist oder nicht...