Clientspezifische Firewallregeln mit IPv6

[n3]

Hey Zusammen, ich stelle aktuelle mein Netzwerk auf IPv6 um. Ich habe mehrere physisch von einander getrennte Netzwerke und aktuell ist WAN und LAN auf IPv4 und IPv6. Meine Clients aus dem LAN Netzwerk haben standartmäßig Privacy Extension aktiviert.

Mit IPv4 konnte ich in der opnsense Dank DHCP sehen, welche Clients im Netzwerk ist. Mit IPv6 geht das nicht mehr, oder übersehe ich etwas?
Ich habe dann z.B. auch eine Regel, dass nur mein PC und Handy auf die Wallboxen aus einem anderen Netzwerk (OUTDOOR) zugreifen kann. Das geht nun Aufgrund der Privacy Extension nicht mehr. Ich habe ein wenig Recherchiert und man kann scheinbar mit IPv6 nur noch auf LAN Segmente Regeln anwenden. Wenn das der Fall ist, dann ist das doch ein Rückschritt zu IPv4, oder übersehe ich hier auch etwas? Ist die Lösung, dass ich mein LAN in weitere virtuelle LANs unterteile. Z.B. LAN, LAN_DEVICES, LAN_ADMIN, etc. und eine Regel Definiere, die LAN_ADMIN erlaubt auf OUTDOOR zuzugreifen?

so long...

[Zapad]

Die Fragen hatte ich mir auch gestellt und als Antwort auf mene Bedenken,
ULA mit NAT eingerichtet.

Eventuell ist auch NPTv6 Hilfreich,

Ich schätzre das ist auch mit der Grund warum IPv6 immernoch Schattendasein führt.

[Bob.Dig]

dass ich mein LAN in weitere virtuelle LANs unterteile.

Absolut. Es wäre auch von Anfang an angebracht gewesen, da zumindest theoretisch "jemand" einfach die IP-Adresse einer Maschine hätte ändern können.

[meyergru]

@n3: Nicht ganz richtig. IPv6 nutzt privacy extensions nur ausgehend. Man kann mit IPv6 ja jedem Client mehrere Adressen zuweisen und das geschieht normalerweise auch. Beispielsweise wissen weder SLAAC noch DHCPv6 etwas von privacy extension Adressen, die immer zusätzlich vergeben werden.

Deswegen ist die "ursprüngliche" IPv6 auch weiter verfügbar und kann für eingehende Verbindungen als Ziel genutzt werden - deshalb gibt es ja auch den Firewall-Alias-Typ "Dynamischer IPv6 Host". Per SLAAC ist sie sogar aus der MAC errechenbar (EUI-64) und taucht als solche auf in der NDP Tabelle (Interfaces: Diagnostics: NDP Table) auf.

Es stellt sich aber die Frage, inwiefern es sinnvoll ist, IPv6 abseits von ausgehenden Verbindungen überhaupt einzusetzen, siehe auch: https://forum.opnsense.org/index.php?topic=45822.0 bzw. genauer diesen Post: https://forum.opnsense.org/index.php?topic=47243.msg238466#msg238466

[n3]

Die Fragen hatte ich mir auch gestellt und als Antwort auf mene Bedenken,
ULA mit NAT eingerichtet.

Eventuell ist auch NPTv6 Hilfreich,

Ich schätzre das ist auch mit der Grund warum IPv6 immernoch Schattendasein führt.

Danke für den Hinweis. Das was ich bisher darüber gelesen habe ist, dass man ULA am besten nicht benutzen sollte:

Es gilt die Empfehlung mit Unique Local Addresses (ULAs) gar nicht erst zu arbeiten. Eine Ausnahme ist in einem Management-Netz, bei dem man durch Renumbering den Zugriff verlieren würde. Hier machen ULAs ausnahmsweise Sinn.

dass ich mein LAN in weitere virtuelle LANs unterteile.

Absolut. Es wäre auch von Anfang an angebracht gewesen, da zumindest theoretisch "jemand" einfach die IP-Adresse einer Maschine hätte ändern können.

Ich glaube ich muss es etwas genauer Beschreiben. Mein Heimserver hat 5 Netzwerkkarten:

admin   192.168.1.1/24
outdoor 192.168.2.1/29
cam     192.168.3.1/29
LAN     192.168.4.1/24
        IPv6/64
WAN     IPv4/32
        IPv6/64

Ich habe dann über meinen managed Router von ubi Eingestellt, dass zum Beispiel die WLAN AP an Port 1-2 dem LAN zugeordnet sind und zum Beispiel die Wallboxen an Port 3 zu Outdoor gehört. Die IPs werden dann auch statisch per MAC vergeben. Nur im LAN gibt es freie dynamische IP Adressen. Ich nutze dann in opnsesen alias wie "Admin-Clients", die dann aus dem LAN z.B. Zugriff auf das Admin-Netzwerk erhalten. Oder z.B. das nur HomeAssistant aus Admin Zugriff auf OUTDOOR hat. Was ich z.B. noch einrichten will ist, dass OUTDOOR nur auf die Updateserver der Wallboxen Zugriff hat. Derzeit ist es noch nicht ganz so restriktiv.

@n3: Nicht ganz richtig. IPv6 nutzt privacy extensions nur ausgehend. Man kann mit IPv6 ja jedem Client mehrere Adressen zuweisen und das geschieht normalerweise auch. Beispielsweise wissen weder SLAAC noch DHCPv6 etwas von privacy extension Adressen, die immer zusätzlich vergeben werden.

Jetzt wenn man das so ließt, klingt es logisch. Hab es ja selber mit ipconfig -all gesehen.

Deswegen ist die "ursprüngliche" IPv6 auch weiter verfügbar und kann für eingehende Verbindungen als Ziel genutzt werden - deshalb gibt es ja auch den Firewall-Alias-Typ "Dynamischer IPv6 Host". Per SLAAC ist sie sogar aus der MAC errechenbar (EUI-64) und taucht als solche auf in der NDP Tabelle (Interfaces: Diagnostics: NDP Table) auf.

TOP Danke für den Hinweis. Schade das in der NDP Tabelle keine Hostnamen angezeigt werden. So eine Art Join aus der DHCPv4 Leases und der NDP basierend auf der MAC.
Muss mich mal in den dynamischen IPv6 Host einlesen...

Es stellt sich aber die Frage, inwiefern es sinnvoll ist, IPv6 abseits von ausgehenden Verbindungen überhaupt einzusetzen, siehe auch: https://forum.opnsense.org/index.php?topic=45822.0 bzw. genauer diesen Post: https://forum.opnsense.org/index.php?topic=47243.msg238466#msg238466

Verstehe ich das Richtig, dass ich eigentlich meine Netzwerk jetzt so lassen kann und nur noch eine Firewallregel einfügen soll, damit die IPv6 raus können und für die interne Kommunikation würde ich dann nur noch IPv4 verwenden? Ich wollte nämlich für meine anderen Netzwerke (admin, outdoor, cam) auch noch IPv6 einrichten und eigentlich IPv4 einstellen. Ist schon irgendwie komisch, dass man nicht voll auf IPv6 setzen kann.
Oder sollte ich auf allen Netzwerken IPv6 einrichten, jedoch nur für die Kommunikation ins Internet und intern die FW-Regeln auf IPv4 belassen?

[Bob.Dig]

IPv4 einstellen

Das wäre unklug. So gut wie alle Websites sind über IPv4 erreichbar, aber selbst einige der wichtigsten Sites sind nicht über IPv6 erreichbar.

[meyergru]

Um IPv6 auch für interne Kommunikation zu nutzen, müsstest Du ja basierend auf den vergebenen IPv6-Adressen Firewallregeln, die Du für IPv4 schon hast, doppeln. Wenn Deiner interne IPv4-Kommunikation bereits mit separierten (V)LANs läuft, warum solltest Du Dir den Aufwand machen? Und IPv4 kann man eben nicht abschalten.

• Die Link-Local-IPv6 sind sowieso nur jeweils im selben (V)LAN erreichbar - genau wie IPv4.
• GUA-IPv6 könntest Du anhand des Präfixes separieren. Andererseits willst Du normalerweise auch aus dem WAN maximal einige wenige Geräte erreichen können - wenn überhaupt, haben die auch externe DNS-Namen (d.h. FQDN). Unter diesen wären sie ja auch von anderen VLANs aus erreichbar.

Wenn man also intern kommunizieren will, würde ich das mit IPv4 machen (IPv6 können einige IoT-Geräte auch gar nicht).
Kommunikation nach außen per IPv4 mit NAT und per IPv6 direkt - wobei diejenigen Geräte, die privacy extensions beherrschen (was beileibe nicht alle sind), das tun sollten. Richtig anonym werden sie aufgrund der Präfix aber sowieso nicht.

Und für Freigaben, die aus dem Internet erreichbar sein sollten, bietet sich sowieso ein Reverse Proxy an, der dann über die WAN-IPv6 und -IPv4 erreichbar ist, die interne Weiterleitung erfolgt dann aber per IPv4.