PfSense IPv6 Routing

Nein, wieso? Ist doch vollkommen legitim

Da du auf beiden Seiten der Firewall vom Prinzip her identische Netze hast, wirst du ohnehin Probleme bekommen - das könnte auch erklären, weshalb du bereits keinen Ping im internen Netz hinbekommst.
Und die Firewall kann eigentlich das Netz nur routen, wenn sie auch NDP-Proxy ist.
Denn momentan wird der Router des Providers für jede IPv6-Adresse per NDP fragen, wer die Pakete denn haben will - und das müsste dann deine Firewall beantworten.

Um diese beiden Probleme zu vermeiden solltest du den Hoster bitten, dir ein IPv6-Präfix über ein Transfernetz direkt auf die Firewall zu routen - dann hast du an WAN und LAN zwei disjunkte Netze und bekommst vor allen Dingen ein sauberes Routing ohne NDP-Proxy hin.
Bei richtigem Routing entfällt nämlich die Fragerei nach NDP und der Router adressiert alle Pakete des gerouteten Präfix direkt an deine Firewall.



Dass die Autokonfiguration nicht funktioniert, ist bei statisch konfigurierten Adressen doch egal...

Warum ? Ein spannendes und auch aktuelles Thema ! Außerdem entfernen kannst nur du als TO selber oder einer der Moderatoren hier
Das musst du sonst ist logischerweise doch gar kein Routing möglich !
Das ist keine Routing Regel sondern eine Firewall Regel !! Das solltest du nicht verwechseln !
Was meinst du genau damit ?? "Kein Netz" ist ja etwas laienhaft und oberflächlich. Du meinst du kannst keine anderen IPv6 Netze oder Hosts im Internet anpingen ??
Dann stimmen entweder...

• deine Adressierung
• oder deine Firewall regeln nicht !!

Letzteres ist ganz sicher der Fall denn wenn du dir nur einmal eine IP Kommunikation durch den Kopf gehen lässt, kann deine simple IPv6 Regel niemals reichen. Du hast nämlich komplett vergessen das die Antwortpakete aus dem Internet dann an deinem WAN Port hängen bleiben !
Von den v6 Adressierungsfehlern die Kollege @LordGurke schon angesprochen hat mal gar nicht zu reden.

Grundsätzlich solltest du mal mit deinem Provider klären ob die ggf. die v6 Adressen per Prefix Delegation bekommst oder ob diese statisch sind und wenn letzteres der Fall ist welchen Prefix du zugewiesen bekommen hast ?
Meist sind das /56 die du dann entsprechend in /64 subnetten musst intern.
Für v6 PD findest du hier ein paar Infos:
https://docs.netgate.com/pfsense/en/latest/dhcp/dhcpv6-server.html
https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-tele ...

NDP ist das Adressauflösungsprotokoll, was bei IPv4 ARP war - und NDP ist einfach ein ICMPv6-Nachrichtentyp.
Was bei IPv4 zum Teil in eigene Protokolle zerlegt war ist bei IPv6 in ICMPv6 zusammengefasst. Es ist also quasi alles ICMPv6, bis auf DHCPv6, das ist weiterhin UDP
Ein NDP-Proxy ist daher funktionell identisch mit dem ARP-Proxy bei IPv4.

Hintergrund warum du den bei deinem Setup brauchst ist:
Wenn du zwei Geräte im Netzwerk hast (A und B), welche sich beide im selben Subnetz befinden, wird A per NDP/ARP fragen, wer denn diese IP-Adresse hat, damit er die MAC-Adresse herausfindet, an die er dann die Pakete adressieren muss.
B wird dann antworten, wobei sich aus der Antwort dann die eigene MAC-Adresse von B ergibt (denn von dort kommt ja das Paket) und die Kommunikation kann beginnen.

Wenn B nun dein Router ist und dahinter C steht, welcher sich aber im selben Subnetz wie A und B befindet, hast du ein Problem:
Die NDP/ARP-Anfragen erreichen ja nur B und werden von dem nicht weitergeleitet. Wenn A nun mit C kommunizieren will, müsste dein Router B auf die NDP/ARP-Anfragen antworten, damit die Pakete für C bei B ankommen, der das weiterleiten kann.

Das klingt nicht nur kompliziert und unschön, das ist es auch.


Besser wäre, dein Hoster würde dir ein zweites IPv6-Präfix routen. Oder dir ein Transfernetz zuweisen und dann das bestehende IPv6-Präfix über das Transfernetz routen.
Da sieht das Setup dann so aus:

Du hast A, das ist der Router deines Hosters. Dann hast du B, das ist deine Firewall. Und du hast C, das ist einer deiner Server.
Dein Hoster würde dir jetzt ein Transfernetz stellen - sagen wir mal 2001:db8:1:2:3:4::/112.
Daraus nimmt sich dein Hoster die Adresse ::a für sich und du benutzt ::b für deine Firewall.
Auf der WAN-Seite hat B also nun die Adresse 2001:db8:1:2:3:4::b/112.
Die LAN-Seite von B ist mit dem Präfix, welches du vom Provider erhältst, versehen - z.B.: 2001:db8:5678:6543::/64.

Dein Provider konfiguriert auf seinem Router eine statische Route:
2001:db8:5678:6543::/64 -> 2001:db8:1:2:3:4::b

Damit weiß der Router A, dass deine Firewall B das Routing für das Präfix übernimmt. Per NDP wird dann nur noch nach 2001:db8:1:2:3:4::b gefragt (was ja deine Firewall sowieso beantwortet), die Pakete für das geroutete Präfix werden dann an die selbe MAC-Adresse adressiert und der ganze Zirkus mit dem NDP-Proxy entfällt.

DAS wäre übrigens auch das bevorzugte Setup für IPv4-Netze, die hinter einer Firewall erreichbar sein sollen - da kann man sich aber leichter aus der Affäre winden, indem man NAT einsetzt. Sonst wäre auch dort ARP-Proxy notwendig, wenn du eine öffentliche IP direkt auf seinem Server hinter der Firewall ohne NAT haben willst.

Na ja diese Frage kannst du dir doch auch selber beantworten, oder ??
"Ich habe auf der einen Seite des Routers 192.168.1.0 /24 und auf der anderen Seite 192.168.1.0 /24 "
Den Unsinn muss man in einem Admin Forum sicher nicht weiter kommentieren.
Wie bitte soll denn der Router bei doppelter IP Adressierung eine eindeutige Wegefindung sicherstellen ? In der IP Grundschule lernt man doch als Erstes das IP Adressen einzigartig zu sein haben in einem Netzwerk. Dagegen hast du ja mit dem obigen Design fundamental verstoßen und einen Kardinalsfehler im Adressdesign gemacht.
Das diese Grundlagen für IPv6 ebenso gelten ist evident.
Jein ! Generell und in der Theorie ja, hier aber klar NEIN !! Wieder etwas nachdenken...!

Dein Router oder Firewall routet ja auch IPv4 zw. Segment A und B. Wenn du nun Segment A und B als Bridge definierst, dann bridgest du ja gleichzeitig auch IPv4. Das geht aber nicht denn dort nutzt du ja richtigerweise schon 2 unterschiedliche IP Netze wie es sein soll, musst also routen !
Physisch können diese beiden Segmente nicht gleichzeitig als Bridge und Router arbeiten. Leuchtet ein...
Außerdem lernt der Netzwerker ebenso in der IP Grundschule "Route where you can, bridge where you must !".
In einer gerouteten Umgebung wie bei dir, zumal an einer so wichtigen Stelle wie der Kopplung ins öffentliche Internet bridged man niemals, immer Routing.

Fazit also...lass dir von deinem Provider ein 2tes Segment geben wie Kollege @LordGurke schon sagt und gut iss.
Es ist auch völlig unüblich das der Provider dir ein /64 gibt, denn bei Global Unicasts kannst du das nicht weiter segmentieren, dort werden nur /64er minimal geroutet.

Hier solltest du übrigens auch mal dringenst reinsehen:
https://danrl.com/projects/ipv6-workshop/
Kostet nix und wird dir sehr helfen mit dem Thema !

Auch das ist alles wie bei IPv4

Du gibst dem WAN-Interface deiner pfSense die Adresse 2001:xxxx:x:1/64.
Dem LAN-Interface gibst du dann eine Adresse aus dem gerouteten Präfix. Fertig.

Perfekt !
Damit ist das dann ein Kinderspiel !
Beispiel:
Deine /48er Adresse lautet z.B. 2001:dead:beef:: /48
Das subnettest du dann wie oben auch schon richtig gesagt in /64er Segmente.
Das erste /64er Subnetz was zum Routing auf den Provider benutzt wird ist dann
2001:dead:beef:0000::
Wenn hier im Transfer Netz jetzt der Provider Router die 2001:dead:beef::2 /64 hat dann gibst du der pfSense dahinter die 2001:dead:beef::1
Die Default Route :: /0 stellt du dann auf den Provider Router 2001:dead:beef::2 ein.
Fertisch !

Wenn du jetzt in der pfSense ins "Diagnostics" Menü gehst und dann dort unter "Ping" solltest du schon den Provider Router pingen können.
Dann noch deine lokalen LANs als /64er einrichten und gut iss. Z.B.:
2001:dead:beef:affe:: /64
2001:dead:beef:cafe:: /64
2001:dead:beef:bade:: /64
usw. usw.
v6 DNS Server noch einstellen auf den v6DNS des Providers, das wars.
Eigentlich kinderleicht und alles genau wie oben schon gesagt, exakt wie bei IPv4 !!

Hattest du in einem Administrator Forum was anderes erwartet ??
Aber mal ehrlich das sind ja nun banale IP Grundlagen...!
Wo hapert es denn noch mit dem Verständnis ?? Vielleicht können wir da ja noch Licht ins letzte Dunkel bringen ??
In jedem Falle solltest du etwas lesen zu dem Thema:
https://danrl.com/projects/ipv6-workshop/
Jepp, ganz genau ! Stinknormales IP Routing eben....
Etwas verschwurbelt was du da sagst zumal du auch noch 1er und 10er Netze wild durcheinanderbringst (Tippfehler ?!) aber letztlich ja wenn du es so meinst:

(Sorry für den obigen Dreckfuhler. Die optionalen weiteren v6 Netze müssen natürlich 2001:DEAD:BEEF:AFFE:: /64 und 2001:DEAD:BEEF:BADE:: /64 usw. usw. lauten. Die dürfen niemals gleich sein, klar ! Kleiner Cut and Paste Fehler )
Wie bereits gesagt...simpelste IP Routing Grundlagen !

Röchel....war ja eine schwere Geburt mit dir !
Ja !
Da musst du natürlich dringend eine Regel erstellen.
Die einfachste ist inbound, also am Internet Interface, alles zu blocken was kein gesetztes ACK Bit hat !


So können nur v6 Pakete von außen die Firewall passieren die Antwort Pakete auf vom internen Netz initiierte Sessions sind.
So kann dann niemand direkt von außen auf die internen Netze zugreifen ! In die andere Richtung klappt aber alles.
Wäre natürlich Quatsch...weisst du auch selber.
So würden ja auch alle Antwort Pakete hängen bleiben und nix geht mehr. Deshalb das ACK Bit !

@aqui:
Ich bin kein pfSense-Nutzer - aber es muss doch einen Weg geben, das schöner und weniger fehleranfällig zu lösen...
So würden z.B. RST- und FIN-Pakete ohne Grund verworfen (was zu merkwürdigen Verbindungsproblemen führen kann).

Eigentlich müsste die pfSense doch bestimmt stateful arbeiten können und so von alleine herausfinden können, welche Pakete zu einer bestehenden Verbindung gehören und welche nicht...

@LordGurke
Ja du hast natürlich Recht und natürlich ist die pfSense auch Stateful ! Das war nur eine erste Quick and Dirty Lösung für den TO um ihn mal auf die richtige Fährte zu setzen das er auch mit mehr Attributen in der FW spielen kann als sich jetzt alles Netz einzelnd einzutragen.
Wie immer macht es Sinn sich das zuerst zu überlegen und dann in ein Regelwerk zu fassen.