[gelöst] Sinnvolle IPv6 Firewallregeln- Sind meine Regeln konsistent?

[RES217AIII]

Hallo Forum,
gemäß Clemens Schrimpe "Wie mache ich IPv6? - An!" läuft bei mir unkompliziert und stabil IPv6. (siehe Diagramm Netzwerk).

Die Schnitstellen erhalten jeweils eine separate virtuelle IP fdxx::1/64.
Im Router Advertisement der jeweiligen Schnistelle wird die zuvor zugeordnete virtuelle IP als DNS Server eingetragen. AdGuard Home lauscht und leitet die Anfragen zu Unbound Port 53530 weiter (127.0.0.1/53 und ::1/53530).
Funktioniert tadellos.
An dieser Stelle Danke an das Forum mit seinen Beiträgen in denen ich das zusammentragen konnte.

[RES217AIII]

Im Allgemeinen heisst es, dass IPv6 weitgehend gleich zu IPv4 hinsichtlich Firewallregeln behandlet werden kann.
Patrick M. Hausen hat in seinem Post https://forum.opnsense.org/index.php?topic=28447.msg138309#msg138309 mir einen entscheidenen Hinweis gegeben in Interfaces zu "denken".

1. Doch bin ich mir nicht sicher, ob meine Firewallregeln sinnvoll sind.
Ich bin dankbar, wenn ein erfahrenes Forummitglied die Regeln durchgehen kann.

Exemplarisch die Basiskonfiguration der Regeln einer Schnittstelle (siehe Screenshot)

[RES217AIII]

2. Selbst wenn die GUA einer Schnittstelle bekannt würde, kann man von "aussen" auf die WebGUI der OPNsense zugreifen oder wird das wie bei IPv4 verhindert?
Den Port habe ich ohnehin geändert.

[Maurice]

0. Da habe ich nur an den ULAs etwas auszusetzen. Das sollte ein zufällig generiertes /48 sein, das dann in die benötigten Subnetze aufgeteilt wird. So wird verhindert, dass es beim zusammenführen oder verbinden von Standorten zu Konflikten kommt (z. B. bei IPv4 Site-to-Site-VPNs oft ein großes Problem).
1. Sind das die Regeln für das Interface LAN111 oder die Gruppe OPNHomeGruppe?
2. Die "Default Deny"-Regel gilt für IPv6 und IPv4 gleichermaßen und verhindert das.

Grüße
Maurice

[Patrick M. Hausen]

2. Selbst wenn die GUA einer Schnittstelle bekannt würde, kann man von "aussen" auf die WebGUI der OPNsense zugreifen oder wird das wie bei IPv4 verhindert?
Den Port habe ich ohnehin geändert.

Wie soll das gehen? Pakete von außen kommen zum WAN Interface rein. Wenn du auf WAN keine expliziten "allow" Regeln hast, dann kommt da natürlich nichts durch. Wüsste nicht, was das mit den Adressen zu tun hat.

Ein Paket, das zum WAN hereinkommt wird nach den Regeln auf WAN und nur nach diesen bearbeitet. Jedenfalls dann, wenn man wie empfohlen nur "in" Regeln verwendet und ebenfalls keine Floating Regeln.

[RES217AIII]

0. Da habe ich nur an den ULAs etwas auszusetzen. Das sollte ein zufällig generiertes /48 sein, das dann in die benötigten Subnetze aufgeteilt wird. So wird verhindert, dass es beim zusammenführen oder verbinden von Standorten zu Konflikten kommt (z. B. bei IPv4 Site-to-Site-VPNs oft ein großes Problem).
1. Sind das die Regeln für das Interface LAN111 oder die Gruppe OPNHomeGruppe?
2. Die "Default Deny"-Regel gilt für IPv6 und IPv4 gleichermaßen und verhindert das.

Grüße
Maurice

Danke für die Durchsicht.
0. Meine Intention ist es jeder Schnittstelle mit dem /64 Präfix ein eindeutig identifizierbares Subnetz zuzuordnen. Die Adressvergabe erfolgt über RA der jeweiligen Schnittstelle, SLAAC. So wie ich es verstanden habe, generiert sich jeder Client selber eine Adresse und prüft, ob diese bereits vergeben ist (DAD).Ggfs. generiert er sich eine neue Adresse aus einem /64 Adressraum, was, soweit ich auch dies verstanden habe, doppelt soviel Adressmöglichkeiten wie im gesamten existierenden IPv4 Adressraum bedeutet.
Macht das Sinn?
1. LAN111

Viele Grüße

[RES217AIII]

Wie soll das gehen? Pakete von außen kommen zum WAN Interface rein. Wenn du auf WAN keine expliziten "allow" Regeln hast, dann kommt da natürlich nichts durch. Wüsste nicht, was das mit den Adressen zu tun hat.

Ein Paket, das zum WAN hereinkommt wird nach den Regeln auf WAN und nur nach diesen bearbeitet. Jedenfalls dann, wenn man wie empfohlen nur "in" Regeln verwendet und ebenfalls keine Floating Regeln.

Vielen Dank

[Patrick M. Hausen]

Ein /64 ist nicht doppelt so groß wie das gesamte IPv4 Internet sondern das gesamte IPv4 Internet zum Quadrat. Und von diesen /64 Prefixen existieren wiederum genau so viel Stück. Also neues Internet = Legacy Internet hoch vier.

[RES217AIII]

Ja, stimmt natürlich!
Hatte mich falsch erinnert. Hätte man sich aber auch herleiten können.
Wie krass.

An alle übrigen, die sich für IPv6 interessieren kann ich nur Clemens Schrimpe empfehlen und vor allem den Podcast, der hier im Forum bereits verlinkt wurde:
https://requestforcomments.de/archives/412

Viele Grüße und Danke

[Maurice]

0. Das geht am Punkt vorbei. RFC 4193 spezifiziert, wie ULAs aufgebaut werden sollten: fd + 40 zufällige Bits (Global ID) ergeben ein global eindeutiges /48-Präfix. Die verbleibenden 16 Bits (Subnet ID) werden zur Unterteilung in Subnetze verwendet, in deinem Fall also z. B. fdxx:xxxx:xxxx:11::/64, fdxx:xxxx:xxxx:12::/64 etc. Bei einem Präfix wie fd11::/64 besteht die Gefahr, dass andere das selbe verwenden und es zu Routing-Konflikten kommt, wenn Standorte z. B. per VPN verbunden werden. Bei IPv4 (RFC 1918) ist das ein großes Problem und es gibt keinen Grund, dieses in IPv6 einzuschleppen.

1. Die Firewall-Regeln sind in Ordnung, meiner Meinung nach aber unnötig kompliziert. Geschmacksache.

[RES217AIII]

0. Dann werde ich es so einrichten. Wie ist die konkrete Schreibweise als virtuelle IP, dass OPNsense weiss die ersten 40 bits zufällig zu ermittelt? Im Moment sieht es bei mir folgendermassen aus fd00:111::1/64 entsprechend dem LAN111. Ein Rechner im Netz ermittelt dann folgende IP: fd00:111::ceb:fb90:a62f:1974.

1. Wie ginge es den einfacher?

Vielen Dank

[Patrick M. Hausen]

0. Dann werde ich es so einrichten. Wie ist die konkrete Schreibweise als virtuelle IP, dass OPNsense weiss die ersten 40 bits zufällig zu ermittelt?

Du sollst die zufällig auswürfeln und dann einmal fix vergeben laut Standard!

[Maurice]

0. Wie Patrick sagt. Google mal "ULA generator" für einen geeigneten Würfel. ;)
1. Was ist denn das Ziel? Deine Regeln wirken so, als solle das LAN111 auf alles zugreifen dürfen, außer externe DNS-Server. Warum dann den Zugriff auf jedes LAN einzeln freigeben? Und wozu die Block-Regeln danach?

[RES217AIII]

Den "Würfel" habe ich gefunden und schon fleissig "gespielt.

Die Blockregeln am Ende sollen dafür sorgen, so meine Idee, dass ich explizit den anderen Schnittstellen gestatten muss Zugriff auf die jeweilige Schnittstelle zu bekommen.
Insofern ist LAN111 ein schlechtes Beispiel, als dass ich diese Schnittstelle im Moment brauche, um Zugriff auf alle weiteren Schnittstellen zu bekommen.
Wenn ich mein Problem mit TP Link gelöst habe und auch getaggte VLAN wieder per WLAN erreichbar sind, wird das Privileg auf alle Schnittstellen zuzugreifen nur noch der Management- Schnittstelle zuteil werden und auch dort nur bestimmten Clients.

[dumbo]

Wenn ich mein Problem mit TP Link gelöst habe und auch getaggte VLAN wieder per WLAN erreichbar sind, wird das Privileg auf alle Schnittstellen zuzugreifen nur noch der Management- Schnittstelle zuteil werden und auch dort nur bestimmten Clients.

Hast Du Probleme mit TP-Link EAPs und IPv6? Falls ja, dann bist Du nicht alleine. TP-Link hat damit generell große Probleme. Man findet in den TP Link Foren dazu diverse Berichte und die bekommen es seit ewig nicht hin, dass das Problem richtig gelöst wird. Aktuell gibt es da Beta-Firmware-Versionen welche das Problem angehen und wohl auch beheben (zumindest zum Teil). Aber Achtung: Beta Versionen bei TP-Link bedeutet sehr viel Tracking etc.