Dual-WAN mit pfSense, IPv6 und dynamischen Prefixes
Hallo zusammen,
ich bräuchte bitte mal eure Hilfe bei folgendem Sachverhalt:
Gegeben ist eine pfSense in der aktuellsten Version auf einer Protecli-Firewall.
Die pfSense ist mit zwei WAN-Interfaces konfiguriert:
WAN1 - Verbunden per Starlink
WAN2 - Verbunden mit einem 5G-Router
Beide Interfaces bekommen sowohl eine IPv4-Adresse, als auch in IPv6-Subnet zugewiesen.
Auf der IPv4-Ebene funktioniert das Failover mit NAT problemlos.
Nach meinen rudimentären IPv6-Kenntnissen, müsste ich für ein Failover im IPv6-Bereich intern Adressen aus einem ULA-Segment vergeben und diese dann per nPt für die jeweiligen WAN-Interfaces übersetzen.
In der nPt-Konfiguration müsste ich dafür allerdings die Subnetze konkret angeben. Das funktioniert aber leider nicht, da diese hin und wieder wechseln.
Gibt es da einen Weg den ich bisher übersehen habe?
Danke und beste Grüße
ich bräuchte bitte mal eure Hilfe bei folgendem Sachverhalt:
Gegeben ist eine pfSense in der aktuellsten Version auf einer Protecli-Firewall.
Die pfSense ist mit zwei WAN-Interfaces konfiguriert:
WAN1 - Verbunden per Starlink
WAN2 - Verbunden mit einem 5G-Router
Beide Interfaces bekommen sowohl eine IPv4-Adresse, als auch in IPv6-Subnet zugewiesen.
Auf der IPv4-Ebene funktioniert das Failover mit NAT problemlos.
Nach meinen rudimentären IPv6-Kenntnissen, müsste ich für ein Failover im IPv6-Bereich intern Adressen aus einem ULA-Segment vergeben und diese dann per nPt für die jeweiligen WAN-Interfaces übersetzen.
In der nPt-Konfiguration müsste ich dafür allerdings die Subnetze konkret angeben. Das funktioniert aber leider nicht, da diese hin und wieder wechseln.
Gibt es da einen Weg den ich bisher übersehen habe?
Danke und beste Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1772119595
Url: https://administrator.de/forum/dual-wan-mit-pfsense-ipv6-und-dynamischen-prefixes-1772119595.html
Ausgedruckt am: 25.12.2024 um 13:12 Uhr
7 Kommentare
Neuester Kommentar
Bei "nPT" scheiterte leider auch die Wikipedia... 🤔
Warum wechseln bei dir statisch konfigurierte v6 Netze?? Normal ja nicht üblich.
Den rudimentären v6 Kenntnissen kann man immer mit etwas kostenloser Lektüre auf die Sprünge helfen.
https://danrl.com/ipv6/
Warum wechseln bei dir statisch konfigurierte v6 Netze?? Normal ja nicht üblich.
Den rudimentären v6 Kenntnissen kann man immer mit etwas kostenloser Lektüre auf die Sprünge helfen.
https://danrl.com/ipv6/
Die sind ja nicht statisch, sondern werden vom Provider dynamisch zugewiesen.
Dann klappt das natürlich nicht. Du kannst dir ja nicht wechselweise v6 Prefixes intern zuweisen lassen die der jeweils andere Provider nicht routet.Verwende intern statische ULA Netzwerk Adressen und mache das bei v6 ungeliebte und unschöne NAT. Quasi also das gleiche Verfahren wie v4...
AFAIK bieten weder Starlink noch die Telekom bei normalen Handykarten ein statisches Prefix an.
In teuren Business Verträgen schon...
Wenn du bei den Clients eh keine eingehenden IPv6 Verbindungen erwartest, NATe einfach sämtlichen IPv6 Traffic auf die öffentliche IPv6-Adressen am jeweiligen WAN, dann jucken die internen IPv6 Adressen nicht, ist zwar nicht so schön und widerspricht dem Gedanken von IPv6, funktioniert aber auch im Failoverfall.
Bei dynamischen Prefixes bräuchtest du wohl ein Skript was bei einem Failover den Prefix des alten Interfaces per RA mit einer PreferredLifeTime auf 0 setzt und dann das neue Prefix per RA im LAN propagiert, eine deartige Funktion bietet die Sense halt nicht von Haus aus.
Gruß.
Bei dynamischen Prefixes bräuchtest du wohl ein Skript was bei einem Failover den Prefix des alten Interfaces per RA mit einer PreferredLifeTime auf 0 setzt und dann das neue Prefix per RA im LAN propagiert, eine deartige Funktion bietet die Sense halt nicht von Haus aus.
Gruß.
Korrektur, da ein Bekannter gerade dasselbe Problem hatte: ::/56 funktioniert wohl nicht, sondern es müssen alle /64-Netze einzeln auf ::/64 übersetzt werden. Außerdem ist zumindest ein Interface mit Adressvergabe per Tracking erforderlich, sonst wird die NAT-Regel nicht erneuert nach einer Zwangstrennung.