Best practise für IPv6-Funktionalität im Heimnetz

[cgone]

Mein Hauptproblem bei der IPv6-Konfiguration im Heimnetz ist, dass der Provider nach der Zwangstrennung ein neues Prefix
herausgeben kann und, wenn ich für mein Heimnetz (LAN) "Track Interface WAN" eingestellt habe, dieses in das Heimnetz durchschlägt.

Ich müsste nach jeder Prefix-Änderung die Konfiguration von dhcpv6 und radvd anpassen, wenn ich z.B. ein individuellen DNS-Server
(pihole) nutzen möchte, weil die automatische Konfiguration stets auf die Adresse der Heimnetzes (LAN) verweist.
Außerdem kann ich keine IPv6-Adressen in NAT-/Rule-Definitionen verwenden, weil auch diese vom Prefix abhängen.

Kann mir jemand ein Tipp geben, wie ich meinen Clients volle IPv6-Funktionalität bieten kann, aber mir nicht beim DNS, NTP und bei der Firewall handlungsunfähig werde, wenn der Prefix wechseln kann?

[Mks]

Hi,

Bin auch nicht der ipv6 Experte, aber soweit ich verstanden habe.

Unique Local Address für die interne LAN Adressierung, mit einem "random" Präfix aus der fd00::/8 Range.
Zusätzlich die globalen Addressen von deinem Provider für Internet.

NAT und IPv6 ist ja so eine Sache und sollte nur in Ausnahmefällen verwendet werden

Lg

[theq86]

Leider kommt OPNsense nicht damit zurecht a) ein dynamisches Präfix zu tracken UND b) gleichzeitig über ne Virtual IP ne ULA Adresse zu haben. Die kommt dann durcheinander, wenn ein neues dynamisches präfix kommt.

[Mks]

Hi.

a) ein dynamisches Präfix zu tracken

Das wurde in einem anderen Thread schon erwähnt, wenn ich mich recht entsinne wird daran gearbeitet.

b) gleichzeitig über ne Virtual IP

Mehrere IPv6 IPs sollte eigentlich kein Problem sein, da bei IPv6 ja so vorgesehen. Ich hab intern IPv6 so aufgesetzt. Die Interfaces haben jeweils eine (fixe) ULA sowie eine Link local Addresse. Per SLAAC und DHCP werden dann die IPs und zusätzliche Infos für die Clients bereitgestellt.

Aber ich hab das auch nur Testweise im Einsatz.

lg

[cgone]

Mittlerweile habe ich es geschafft "Track Interface" mit "Virtual IP" zu kombinieren.

Wenn ich ein "IP Alias" mit der ULA für das Interface weglasse und das ULA-Netz per "Other" Virtual IP dem LAN-Interface zuordnet, baut OPNsense die Konfiguration für radvd korrekt.

Den relevanten Servern, d.h. in diesem Fall pihole, habe ich explizit Adressen aus dem ULA-Netz zugewiesen,
so dass alle Clients darauf zugreifen konnten.

Router Advertisements hatte ich auf "Assistet", so dass leider alle Clients die Stateless Autoconfiguration durchgeführt haben, so dass ich weder in pihole noch auf der Firewall nachvollziehen könnte, welcher Client was im Netz macht hat.

Mit Router Advertisements auf "Managed" habe ich leider auch kein Client mehr zu DHCPv6 überredet bekommen.

Solange die Clients lieber Wildsau im Netz spielen wollen, wäre meine Empfehlung heute, dass IPv6 nur auf der Firewall selbst zu nutzen und LAN etc. nur IPv4 spielen zu lassen.

[Maurice]

Moin,

"Other" Virtual IP funktioniert zwar momentan stabiler als "IP Alias", die OPNsense selbst ist dann aber nicht unter der ULA erreichbar. Was die bessere Lösung ist hängt auch davon ab, wie oft der ISP tatsächlich ein neues Präfix vergibt. Bei Kabelnetzbetreibern ist das z. B. nur alle paar Monate der Fall, da kann man ganz gut mit den Unzulänglichkeiten von "IP Alias" leben.

Einzelne Clients zu tracken wird durch Privacy Extensions erschwert. It's not Wildsau spielen, it's a feature. Hat auch nichts mit OPNsense oder dynamischem Präfix zu tun.
Im LAN kann man aber einfach über NDP die MAC-Adresse zu einer fraglichen IPv6-Adresse ausfindig machen (siehe auch NDP Table in OPNsense).
Für ganz spezielle Anforderungen: Privacy Extensions auf den Clients deaktivieren oder stateful DHCPv6 verwenden. Wird aber nicht von allen Clients unterstützt (z. B. Android). Warum in deinem Fall stateful DHCPv6 nicht funktioniert müsste man sich näher anschauen; grundsätzlich funktioniert das.

Grüße

Maurice

[christian.uhlmann]

Hi zusammen,

leider finde ich den Punkt "Other" Virtual IP nicht.
Gibt's nen Trick um den zu aktiveiren?

Alternativ, gibt es schon bessere Lösungen mit einem fixen ULA Prefix?

Die beiden Issues dazu:
- https://github.com/opnsense/core/issues/2821
- https://github.com/opnsense/core/issues/2189
Sind ja geschlossen aber bei mir klappt es nicht mit 2 ipv6 prefixen (dynamisch per Track Interface vom WAN als auch ULA über Firewall Virtual IP).


Danke und Grüße

Christian

[Maurice]

Moin,

Grundsätzlich sind die Infos aus meinem letzten Beitrag noch aktuell. Die ULA kann man als 'IP Alias' oder 'Other' anlegen. Beides funktioniert grundsätzlich, allerdings mit Einschränkungen:
Bei 'Other' ist die OPNsense selbst (Webinterface, Unbound etc.) nicht über die ULA erreichbar. Das ist "by Design", daran wird sich nichts ändern.
Bei 'IP Alias' bricht die GUA weg, wenn sich das delegierte Präfix ändert oder man die OPNsense rebootet. Dann muss man die Virtual IP löschen und wieder hinzufügen, damit wieder beide Adressen aktiv sind. Das ist ein Bug (Issue #3310), der hoffentlich irgendwann gefixt wird.

leider finde ich den Punkt "Other" Virtual IP nicht.

Wenn Du eine Virtual IP hinzufügst stehen als 'Mode' zur Auswahl: 'IP Alias', 'CARP', 'Proxy ARP' und 'Other'. Nicht?

bei mir klappt es nicht mit 2 ipv6 prefixen (dynamisch per Track Interface vom WAN als auch ULA über Firewall Virtual IP)

Läuft hier genau so (ULA als 'IP Alias'). Woran scheitert es denn? Wichtig: Nach dem Anlegen der Virtual IP radvd neu starten, damit das neue Präfix auch advertised wird.

Grüße

Maurice

[christian.uhlmann]

Ahh ok, Virtual IP Mode Other ist gemeint.
Bei other habe ich sofort an Interfaces -> Other gedacht und dort nichts gefunden. Aber Danke für die Erklärung, dann sollte alles passen. Ich teste das nachher mal.

[tom.goes.open]

Hallo,

ich hänge mich hier mal dran 

Ich habe gerade nach dem Update auf 19.7.3 festgestellt, dass folgendes Problem auch auftritt, wenn man die ULA als 'Other' anlegt. Ich hatte heute definitiv keine GUA auf den Clients.

Bei 'IP Alias' bricht die GUA weg, wenn sich das delegierte Präfix ändert oder man die OPNsense rebootet. Dann muss man die Virtual IP löschen und wieder hinzufügen, damit wieder beide Adressen aktiv sind. Das ist ein Bug (Issue #3310), der hoffentlich irgendwann gefixt wird.

Gibt es bei 'Other' noch irgendetwas zu beachten?