11
PfSense IPv6 - einzelne Clients einschränken
Moin,
ich schlage mich jetzt schon länger mit dem Thema IPv6 herum und schaffe es nicht folgende Anforderungen parallel zu IPv4 umzusetzen.
Der parallel Betrieb und Zuweisung über DHCPv6 ist kein Thema.
Möchte ich allerdings einzelne Clients auf dem gleichen Interface einschränken fehlt mir die statische Adresse um darauf aufbauend Regeln zu definieren. Wahrscheinlich habe ich nur noch keine Lösung gefunden.
Die Anforderungen an diese speziellen Clients sind folgende:
Für IPv4 habe ich das ganz simpel über einen Alias mit den RFC 1918 Subnetzen erreicht und kann genau definieren was der Client darf.
Mit der IPv6 Konfig ändert sich allerdings gerne das zugeordnete Präfix und ich kann keine festen Adressen in einer Regel definieren.
Ein LAN Interface ist dann per "Track Interface" an das WAN Interface angebunden. Ich kann zwar per DHCPv6 ein local Präfix mitgeben aber darauf keine Regel aufbauen, oder habe es eben noch nicht gefunden.
Ich denke es ist verständlich was mein Ziel ist. Bin gespannt wie Ihr solch ein Konstrukt gelöst habt.
Die IPv4 Adressen in den Beispielen sind irrelevant. Es geht nur um die Funktionalität. Ich benötige als Source quasi das IPv6 pendant auch wenn ein Client mehrere Adressen zugewiesen bekommen hat um den Client für eine Regel zu identifizieren.
##Beispiel A wurde angepasst.
Gruß
Spirit
ich schlage mich jetzt schon länger mit dem Thema IPv6 herum und schaffe es nicht folgende Anforderungen parallel zu IPv4 umzusetzen.
Der parallel Betrieb und Zuweisung über DHCPv6 ist kein Thema.
Möchte ich allerdings einzelne Clients auf dem gleichen Interface einschränken fehlt mir die statische Adresse um darauf aufbauend Regeln zu definieren. Wahrscheinlich habe ich nur noch keine Lösung gefunden.
Die Anforderungen an diese speziellen Clients sind folgende:
- Client A darf nur local kommunizieren. Auch Interface übergreifend. Sprich das IPv4 pendant zu den RFC 1918 ist erlaubt.
- Client B darf nirgend wo hin. Muss aber aus den anderen Interfaces aus erreichbar sein.
- Client C darf nur Richtung WAN und keine localen Clients erreichen können.
Für IPv4 habe ich das ganz simpel über einen Alias mit den RFC 1918 Subnetzen erreicht und kann genau definieren was der Client darf.
Mit der IPv6 Konfig ändert sich allerdings gerne das zugeordnete Präfix und ich kann keine festen Adressen in einer Regel definieren.
Ein LAN Interface ist dann per "Track Interface" an das WAN Interface angebunden. Ich kann zwar per DHCPv6 ein local Präfix mitgeben aber darauf keine Regel aufbauen, oder habe es eben noch nicht gefunden.
Ich denke es ist verständlich was mein Ziel ist. Bin gespannt wie Ihr solch ein Konstrukt gelöst habt.
Die IPv4 Adressen in den Beispielen sind irrelevant. Es geht nur um die Funktionalität. Ich benötige als Source quasi das IPv6 pendant auch wenn ein Client mehrere Adressen zugewiesen bekommen hat um den Client für eine Regel zu identifizieren.
##Beispiel A wurde angepasst.
Gruß
Spirit
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 518994
Url: https://administrator.de/contentid/518994
Ausgedruckt am: 23.11.2024 um 07:11 Uhr
11 Kommentare
Neuester Kommentar
Die erste Anforderung ist etwas verwirrend ??
Vermutlich Letzteres, oder ?
Die Regel ist ganz einfach. PASS auf die lokalen IP Netze (Alias) oder größerer CIDR Maske die alle Netze umfasst und dann ein DENY Client IP nach ANY, fertisch.
Dann kommt Client B von selbst nirgendwo hin, wenn er aber von anderen Netzen angesprochen wird ist das ACK Bit gesetzt und diese Pakete können dann passieren.
Ist es die Erreichbarkeit nur des Internet aber nichts lokales ist die Regel einfach...
Du machst zuerst ein DENY auf alle deine lokalen IP Netze (Alias) oder nur eine Regel mit einer CIDR Maske die alle deine lokalen IP Netze umfasst und danach dann ein PASS mit der Client C IP Adresse nach ANY, fertisch.
Letzteres geht nicht mit der Firewall !
Ist ja auch logisch, denn in einer Routing Umgebung kann die Firewall rein nur gerouteten Traffic filtern. Die Kommunikation der Clients untereinander in den lokalen IP Segmenten passiert doch völlig ohne Beteiligung der Firewall rein auf Layer 2 bzw. Mac Adressen. An diesem Forwarding ist die Firewall überhaupt nicht beteiligt und kann folglich auch niemals diesen Traffic kontrollieren.
Bei IPv6 ist das mit dynmaischen Prefixe natürlich alles nicht machbar.
https://forum.netgate.com/topic/104695/firewall-rules-for-ipv6-when-pref ...
https://redmine.pfsense.org/issues/6626
Sieht eher nach einem upcoming feature aus...?!
"Client A darf nur local kommunizieren. Auch Interface übergreifend"
Ja was denn nun ?? Nur lokal in seinem IP Segment oder auch in andere IP Segmente an der Firewall ??Vermutlich Letzteres, oder ?
Die Regel ist ganz einfach. PASS auf die lokalen IP Netze (Alias) oder größerer CIDR Maske die alle Netze umfasst und dann ein DENY Client IP nach ANY, fertisch.
Client B darf nirgend wo hin. Muss aber aus den anderen Interfaces aus erreichbar sein.
Das erreichst du indem du von Client B in die lokalen IP Netze einzig nur Pakete mit gesetztem ACK Bit (Extra Options --> Advanced Options) von der Client B Adresse passieren lässt !Client C darf nur Richtung WAN und keine localen Clients erreichen können.
Was ist mit "lokalen" Clients genau gemeint ?? Auch die Clients innerhalb seines eigenen IP Netzes ??Ist es die Erreichbarkeit nur des Internet aber nichts lokales ist die Regel einfach...
Du machst zuerst ein DENY auf alle deine lokalen IP Netze (Alias) oder nur eine Regel mit einer CIDR Maske die alle deine lokalen IP Netze umfasst und danach dann ein PASS mit der Client C IP Adresse nach ANY, fertisch.
Letzteres geht nicht mit der Firewall !
Ist ja auch logisch, denn in einer Routing Umgebung kann die Firewall rein nur gerouteten Traffic filtern. Die Kommunikation der Clients untereinander in den lokalen IP Segmenten passiert doch völlig ohne Beteiligung der Firewall rein auf Layer 2 bzw. Mac Adressen. An diesem Forwarding ist die Firewall überhaupt nicht beteiligt und kann folglich auch niemals diesen Traffic kontrollieren.
Bei IPv6 ist das mit dynmaischen Prefixe natürlich alles nicht machbar.
https://forum.netgate.com/topic/104695/firewall-rules-for-ipv6-when-pref ...
https://redmine.pfsense.org/issues/6626
Sieht eher nach einem upcoming feature aus...?!
Moin aqui,
das Problem sind nicht die Regeln an sich, sondern wie ich eine Konfiguration schaffe um pro Client eine feste source IP zu haben.
Wie muss hierfür die IPv6 Konfig an der Sense aussehen?
Oder gibt es eine Andere Lösung um einen Client zu identifizieren?
Gruß
Spirit
das Problem sind nicht die Regeln an sich, sondern wie ich eine Konfiguration schaffe um pro Client eine feste source IP zu haben.
Wie muss hierfür die IPv6 Konfig an der Sense aussehen?
Oder gibt es eine Andere Lösung um einen Client zu identifizieren?
Gruß
Spirit
um pro Client eine feste source IP zu haben.
Das ist auch einfach wenn die pfSense dein DHCP Server ist. Das geht dann über die Mac Adresse:
Bei v6 mit dynmaischen Prefix und zusätzlicher aktiver Adress Anonymisierung wohl eher dann nicht.
Ich brauche ja gerade für IPv6 eine Lösung.
Mit IPv4 läuft das ganze tadellos.
Mit IPv4 läuft das ganze tadellos.
Das wird schwierig bei v6 denn mit dynamischer Prefix Delegation und zusätzlich noch der dynamischen Anonymisierung bei derzeit allen Betriebssystemen hast du gleich 2 dynamische Komponenten die sowas sicher verhindern. Da fällt mir so auf die Schnelle erstmal auch nix ein....
Genau, das habe ich soweit auch herausgefunden.
Ich bin schon kurz davor für diese Clients ein eigenes VLan anzulegen, da ich diese sonst nicht sauber abschirmen kann.
Oder ich baue mir hierfür ein v6NAT Konstrukt. Das lässt sich mit einer PfSense anscheind nicht schön realisieren und sieht obendrein noch absolut sch**ße aus.
Ich bin schon kurz davor für diese Clients ein eigenes VLan anzulegen, da ich diese sonst nicht sauber abschirmen kann.
Oder ich baue mir hierfür ein v6NAT Konstrukt. Das lässt sich mit einer PfSense anscheind nicht schön realisieren und sieht obendrein noch absolut sch**ße aus.
Das ist aber ein sehr guter Punkt. Ich habe auch keine Ahnung wie andere Firewalls mit sowas umgehen und ob das netztechnisch überhaupt möglich ist.
Mal sehen ob da noch Feedback von anderen v6 Usern kommt... ?!
Mal sehen ob da noch Feedback von anderen v6 Usern kommt... ?!
Ich dachte die ganze Zeit ich würde es einfach nur nicht sehen.
Des weiteren kommen dann ja auch noch Regeln für Server, die von außen erreichbar sein müssen, hinzu.
Ohne einen festen intern Bezugspunkt kann ja schlecht einfach ein Port von extern aufgerissen werden.
Des weiteren kommen dann ja auch noch Regeln für Server, die von außen erreichbar sein müssen, hinzu.
Ohne einen festen intern Bezugspunkt kann ja schlecht einfach ein Port von extern aufgerissen werden.
Das stimmt. Dazu gab es mal einen ct' Artikel. Der Aufwand das mit dynmaischer Prefix Delegation zum Fliegen zu bekommen ist aber horrend.
https://www.heise.de/ratgeber/DynDNS-Serverbetrieb-mit-dynamischen-IPv6- ...
https://www.heise.de/ratgeber/DynDNS-Serverbetrieb-mit-dynamischen-IPv6- ...
Hier ist die gleiche Thematik diskutiert worden.
Ebenfalls ohne Ergebnis.
https://forum.netgate.com/topic/141567/bestimmten-clients-nur-ipv4-zuwei ...
Das Ende vom Lied scheint wohl zu sein die Clients in einzelne VLans zu packen.
Ebenfalls ohne Ergebnis.
https://forum.netgate.com/topic/141567/bestimmten-clients-nur-ipv4-zuwei ...
Das Ende vom Lied scheint wohl zu sein die Clients in einzelne VLans zu packen.
Als Idee:
Halte zwei Adresspools per DHCPv6 vor - einen für die Global-Unicast-Adressen und einen für ULA.
Jedes VLAN muss dann natürlich seinen eigenen ULA-Pool haben
Dann kannst du per Firewall beschränken:
Client A, der nur lokal kommunizieren darf: Bekommt per DHCPv6 nur eine ULA-Adresse -> Keine Firewall-Regel notwendig, denn mit der kann er eh nicht ins Internet. Kann man aber sicherheitshalber natürlich per Firewall droppen: Von fc00::/7 -> 2000::/3 = DROP.
Client B, der nirgendwohin darf, aber erreichbar sein soll: Bekommt per DHCPv6 auch nur eine ULA-Adresse, da diese aber einen statischen Präfix hat, kannst du hier Firewallregeln erzeugen.
Client C, der nur ins Internet darf aber nicht lokal: Bekommt eine Global-Unicast-Adresse - und du legst zur Sicherheit eine Firewall-Regel an, die die Kommunikation zwischen Global-Unicast und ULA generell unterbindet (hast du ja optimalerweise schon).
Alle anderen Clients: Bekommen aus beiden Pools je eine Adresse
Du solltest zur Sicherheit dann per RA eine Route für die ULA-Präfixe resp. das aggregierte Supernetz dafür advertisen lassen.
Allerdings solltest du möglichst nicht fc00::/7 announcen - denn das schließt fe80 mit ein und damit kannst du dann Clients verwirren, die dann nicht wissen, wann sie welche Source-Adresse nutzen sollen. Lieber dann etwas kleineres - z.B. /16, welches fe80 nicht mit einschließt
Das ist jetzt ungetestet und ich weiß nicht, ob das mit jedem Client so funktioniert - aber rein vom Prinzip her müsste das eigentlich klappen.
Halte zwei Adresspools per DHCPv6 vor - einen für die Global-Unicast-Adressen und einen für ULA.
Jedes VLAN muss dann natürlich seinen eigenen ULA-Pool haben
Dann kannst du per Firewall beschränken:
Client A, der nur lokal kommunizieren darf: Bekommt per DHCPv6 nur eine ULA-Adresse -> Keine Firewall-Regel notwendig, denn mit der kann er eh nicht ins Internet. Kann man aber sicherheitshalber natürlich per Firewall droppen: Von fc00::/7 -> 2000::/3 = DROP.
Client B, der nirgendwohin darf, aber erreichbar sein soll: Bekommt per DHCPv6 auch nur eine ULA-Adresse, da diese aber einen statischen Präfix hat, kannst du hier Firewallregeln erzeugen.
Client C, der nur ins Internet darf aber nicht lokal: Bekommt eine Global-Unicast-Adresse - und du legst zur Sicherheit eine Firewall-Regel an, die die Kommunikation zwischen Global-Unicast und ULA generell unterbindet (hast du ja optimalerweise schon).
Alle anderen Clients: Bekommen aus beiden Pools je eine Adresse
Du solltest zur Sicherheit dann per RA eine Route für die ULA-Präfixe resp. das aggregierte Supernetz dafür advertisen lassen.
Allerdings solltest du möglichst nicht fc00::/7 announcen - denn das schließt fe80 mit ein und damit kannst du dann Clients verwirren, die dann nicht wissen, wann sie welche Source-Adresse nutzen sollen. Lieber dann etwas kleineres - z.B. /16, welches fe80 nicht mit einschließt
Das ist jetzt ungetestet und ich weiß nicht, ob das mit jedem Client so funktioniert - aber rein vom Prinzip her müsste das eigentlich klappen.
