PfSense Firewall IPv6 mit /64 Netz
-
@JeGr - Vielen Dank für deine Antwort. Mit etwas Glück und Geschick komme ich irgendwann mal in den Genuss ein größeres Netzwerk zu Administrieren. :-)
Nur nochmal zum Mitschreiben:
Ich habe zwei /64 Netze. Beide sind meinem VLan zugewiesen.
1. XXXX:A::/64
2. XXXX:B::/64Das eine /64 Netz geht auf das WAN Interface XXXX:A:10 mit den passenden Gateway vom RZ XXXX:A:1
Auf dem LAN mache ich mein zweites /64 Netz: XXXX:B:5 ohne Gateway.
Meinem Server gebe ich die IP: XXXX:B:6 mit dem Gateway XXXX:A:10 der WAN Adresse.
Das habe ich so gemacht. Muss ich da jetzt noch irgendwelche Firewall-Regeln freigeben? Wenn ja, wie müssten die aussehen?
Auf dem Server kann ich mit den Einstellungen mein LAN Interface problemlos anpingen, jedoch nicht mein WAN oder sogar google.com.
Habe ich da jetzt noch etwas falsch gemacht?
-
Ich habe zwei /64 Netze. Beide sind meinem VLan zugewiesen.
Nope. Gehen wir vom Optimalfall aus: Du bekommst 2 /64er Prefixe und der ISP routet dir freundlich das eine /64er auf eine Adresse des anderen /64er. Dann bekommst du:
- 2001:DB8:DC:1::/64 mit bspw. 2001:DB8:DC:1::1 als Gateway vom ISP und mit 2001:DB8:DC:1::2 bspw. als die Adresse, worauf der Provider dir das zweite Netz routet:
- 2001:DB8:DC:2::/64 als zweites für dich voll nutzbares Prefix.
Einstellungen sind dann 1:1 wie bei IPv4:
WAN: 2001:DB8:DC:1::2/64 als Adresse, 2001:DB8:DC:1::1/64 als Gateway
LAN: 2001:DB8:DC:2::1 als Adresse, KEIN Gateway da kein WAN.Im LAN vergibst du dann entweder manuell beliebige Adressen aus 2001:DB8:DC:2::/64 oder kannst Mechanismen wie SLAAC nutzen, die man mit DHCP6 um bspw. NTP und DNS Einstellungen ergänzt.
Freigegeben werden muss dann in den Regeln selbstverständlich auf WAN/LAN jeweils 2001:DB8:DC:2::abcd als IP6. Auf dem 1er Prefix wirst du per se nichts annehmen müssen, das dient lediglich als Transfernetz/Uplink zum ISP. Manchmal - wenn klar ist, dass es lediglich ein Transfernetz ist und der ISP weiß, dass das bei dir statisch konfiguriert wird und du nicht zwingend ein /64er brauchst als Uplink, dann kann er auch ein /112er Prefix oder so vergeben, je nachdem was günstig bei den Boundaries ist, macht man aber höchst selten, da das dann bereits in den Identifier Bereich reingeht (die zweiten 64bit) und nicht mehr im Prefix Bereich liegt. Deshalb ist das Kleinste eigentlich /64 was vergeben wird. Auch wenns nur ein Transfernetz ist.
Gruß
-
Hi,
vielen Dank nochmal für deine Erklärung. Damit ich meinem Anbieter jetzt nicht unnötig stress machen, kannst du die Aussage einmal bestätigen? Dann würde ich dem das ok geben.
Ok, also sollen wir ein Next Hop Routing einrichten, weil das pfsense nicht anders kann. Dann brauche ich die Information, welches IP Subnetz auf welche einzelne IP als Next Hop konfiguriert werden soll.
Ich würde dem jetzt entsprechend wie du es beschrieben hast die IP Netze geben. Wäre das dann ein korrektes Setup?
-
weil das pfsense nicht anders kann
Das lasse ich mal unkommentiert ;) denn können vielleicht schon, aber wollen nicht.
Soweit ich das sehe, wird dann genau das gemacht wie oben beschrieben, nur dass du nicht selbst die Daten vorgegeben bekommst, sondern selbst nennen kannst. Würde wie in meiner Erklärung oben verfahren. Aus dem Prefix, das auf dem WAN liegt, nimmst du dir eine IP6 raus und sagst ihnen, dass sie darauf bitte das andere Prefix routen mögen. Und dann sollte alles weitere s.o. funktionieren.
Grüße
-
Guten Morgen,
ich habe den letzten Beitrag mal gelöscht, ich habe eingesehen dass es bullshit war, was ich da geschrieben habe.
Dennoch habe ich noch ein Problem.
Ich habe wie besprochen folgendes gemacht:
WAN: 2001:DB8:DC:1::2/64 als Adresse, 2001:DB8:DC:1::1/64 als Gateway
LAN: 2001:DB8:DC:2::1 als Adresse, KEIN Gateway da kein WAN.Auf die WAN Adresse wurde das zweite Netz vom Anbieter erfolgreich geroutet.
Jetzt habe ich bei den clients dahinter folgendes gemacht:
Eine Adresse aus dem Netz 2001:DB8:DC:2::/64 und als Gateway 2001:DB8:DC:2::1
Da war mein Problem, dass ich wie @blex beschriebe hat bei den clients die IPv6 des WAN Interfaces als Gateway genommen habe. Da hat es nicht geklappt - Mit der LAN Adresse hingegen schon. Ist das dann jetzt so richtig?Ich kann jetzt zumindest nach außen pingen und den Outgoing Traffic via Firewall konfigurieren.
Jetzt geht es ums ingoing. Ich habe auf dem WAN und LAN mal Testweise ALLEN Traffic erlaubt: Also keine Einschränkungen gemacht. Trotzdem kann ich keine der Adressen aus dem Netz 2001:DB8:DC:2::/64 anpingen. Also Ingoing traffic geht einfach nicht rein.
Ich dachte, damit genau das geht, wurde das Netz über die IP des anderen Netzes geroutet - Oder irre ich mich da?
Wo kann ich ansetzten um die Lösung zu analysieren?
-
Hallo,
@jokabo:Ich habe wie besprochen folgendes gemacht:
WAN: 2001:DB8:DC:1::2/64 als Adresse, 2001:DB8:DC:1::1/64 als Gateway
LAN: 2001:DB8:DC:2::1 als Adresse, KEIN Gateway da kein WAN.Auf die WAN Adresse wurde das zweite Netz vom Anbieter erfolgreich geroutet.
Jetzt habe ich bei den clients dahinter folgendes gemacht:
Eine Adresse aus dem Netz 2001:DB8:DC:2::/64 und als Gateway 2001:DB8:DC:2::1
Da war mein Problem, dass ich wie @blex beschriebe hat bei den clients die IPv6 des WAN Interfaces als Gateway genommen habe. Da hat es nicht geklappt - Mit der LAN Adresse hingegen schon. Ist das dann jetzt so richtig?Kurz: JA! Ist jetzt korrekt.
Erklärung: Wie soll das LAN Netzwerk auch mit dem WAN Netzwerk reden wenn das Gateway im WAN liegt. Sprich ohne Routing nicht erreicht werden kann und du ihm aber sagst der Router für dich steht im anderen Netzwerk.
Sprich: Das GATEWAY muss IMMER eine IP aus dem Netzwerksegments des Geräts sein.
Ich kann jetzt zumindest nach außen pingen und den Outgoing Traffic via Firewall konfigurieren.
Jetzt geht es ums ingoing. Ich habe auf dem WAN und LAN mal Testweise ALLEN Traffic erlaubt: Also keine Einschränkungen gemacht. Trotzdem kann ich keine der Adressen aus dem Netz 2001:DB8:DC:2::/64 anpingen. Also Ingoing traffic geht einfach nicht rein.
Ich dachte, damit genau das geht, wurde das Netz über die IP des anderen Netzes geroutet - Oder irre ich mich da?
Wo kann ich ansetzten um die Lösung zu analysieren?
Also hier betreten wir jetzt ein neue Welt…
Generell kannst du jetzt den Traffic auf der pfSense filtern. Bei IPv6 solltest du IMMER eine deny all Regeln auf dem Router haben. (Ist ja kein NAT mehr dazwischen, sprich hier MUSST du filtern, sonst ist alles hinter deinem Router direkt erreichbar!
Sprich du musst die NAT Weiterleitungsregeln jetzt nicht mehr anlegen wohl aber Firewall Regeln die den Trafficfluss erlauben der vorher durch die NAT Weiterleitungen ermöglicht wurden.Ich würde am Ende deiner Firewall Regeln für die Schnittstellen WAN, LAN eine Regel Deny ANY ANY setzen mit der Option aktiviert Logge die Pakete. Dann siehst du recht einfach ob deine Firewall etwas weg filtert.
Eine andere Fehlerquelle ist ja immer noch, die Pakete müssen über das Internet zu deinem Provider / Hoster und dann noch korrekt bei deinem Rechner ankommen. Dazwischen gibt es viele Fehlerquellen. Ich würde die empfehlen erst mal ein traceroute6 (traceroute gibt es für ipv4 und ipv6) von dem Rechner aus machen von wo du testest und schauen auf welchen Wegabschnitt es nicht mehr weiter geht.
Gruß blex
-
Generell kannst du jetzt den Traffic auf der pfSense filtern. Bei IPv6 solltest du IMMER eine deny all Regeln auf dem Router haben
Falsch. Block ANY ist bei pfSense IMMER STANDARD. Wenn also nichts anderes konfiguriert ist, gilt immer sofort BLOCK. Somit muss diese Regel nicht vorhanden sein, diese Mär lese und sehe ich immer wieder in Konfigurationen und die Leute glauben es nie, bis ich ihnen die pf.conf im System zeige, wo dann zwei Mal alles geblockt wird :)
(Ist ja kein NAT mehr dazwischen, sprich hier MUSST du filtern, sonst ist alles hinter deinem Router direkt erreichbar!
Hat auch nicht NAT nichts zu tun, filter muss/soll man so oder so und "block any" war vorher ebenfalls bereits aktiv.
Trafficfluss erlauben der vorher durch die NAT Weiterleitungen ermöglicht wurden.
Hier muss ich auch korrigieren, auch wenn ich weiß, dass es wahrscheinlich korrekt gemeint ist: Traffic wurde auch vorher durch eine Port Forward oder NAT Regel NIE erlaubt. Lediglich durch das letzte Feld (automatisches Erstellen einer Filterregel) wurde diese FirewallRegel automatisch hinzugefügt. Aber Regeln sind IMMER notwendig, egal ob geNATtet wird oder nicht!
Ich würde am Ende deiner Firewall Regeln für die Schnittstellen WAN, LAN eine Regel Deny ANY ANY setzen mit der Option aktiviert Logge die Pakete. Dann siehst du recht einfach ob deine Firewall etwas weg filtert.
Das ist unnötig da Standard Verhalten der Firewall - egal ob v4 oder v6.
Ich würde die empfehlen erst mal ein traceroute6 (traceroute gibt es für ipv4 und ipv6) von dem Rechner aus machen von wo du testest und schauen auf welchen Wegabschnitt es nicht mehr weiter geht.
Da stimme ich aber zu. Wenn jokabo sagt, es geht von Innen nach Außen jetzt durch, würde ich auf einem Client der mit v6 jetzt nach draußen kommt einen "mtr" (wenn Linux/BSD) oder traceroute6 machen lassen um zu sehen, welcher Weg nach draußen abläuft. Anders herum wäre es praktisch einen externen Knoten mit v6 zu haben, von dem aus man gezielt testen kann, ob man überhaupt bis zur pfSense kommt oder ob das Routing/Filtering des Providers vielleicht vorher zuschlägt. Machen wir in den Audits auch so, dass wir vorher ein Prefix/IP Range kommunizieren und man somit sehen kann/weiß, ja die Zugriffe kommen bis zum Router überhaupt durch.
Das würde ich sicher stellen, momentan liest es sich so, als ob der Weg nach draußen läuft, aber seltsamerweise das Routing von draußen rein vom LAN Prefix nicht sauber ist. Aber ohne hier selbst zu debuggen ist das schwer zu sehen.
Gruß Jens
-
Generell kannst du jetzt den Traffic auf der pfSense filtern. Bei IPv6 solltest du IMMER eine deny all Regeln auf dem Router haben
Falsch. Block ANY ist bei pfSense IMMER STANDARD. Wenn also nichts anderes konfiguriert ist, gilt immer sofort BLOCK. Somit muss diese Regel nicht vorhanden sein, diese Mär lese und sehe ich immer wieder in Konfigurationen und die Leute glauben es nie, bis ich ihnen die pf.conf im System zeige, wo dann zwei Mal alles geblockt wird :)
Das ist Absolut richtig. Ich nenne es immer das "implizite" deny any. Ich finde es aber übersichtlicher einfach noch ein "explizites" deny any zu haben wo ich auch eventuell spezielle filter optionen und Kommentare setzen kann.
(Ist ja kein NAT mehr dazwischen, sprich hier MUSST du filtern, sonst ist alles hinter deinem Router direkt erreichbar!
Hat auch nicht NAT nichts zu tun, filter muss/soll man so oder so und "block any" war vorher ebenfalls bereits aktiv.
Stimmt das hier wieder das implizite "block any" greift. Aber gerade für Jemand der sich mit dem Thema Firewall beschäftigt muss klar werden das man hier ran DENKEN muss. Bei pfSense ist das block any schon mal ein Sicherheitsnetz.
Trafficfluss erlauben der vorher durch die NAT Weiterleitungen ermöglicht wurden.
Hier muss ich auch korrigieren, auch wenn ich weiß, dass es wahrscheinlich korrekt gemeint ist: Traffic wurde auch vorher durch eine Port Forward oder NAT Regel NIE erlaubt. Lediglich durch das letzte Feld (automatisches Erstellen einer Filterregel) wurde diese FirewallRegel automatisch hinzugefügt. Aber Regeln sind IMMER notwendig, egal ob geNATtet wird oder nicht!
Genau so meinte ich es. Man muss den "genatten" Traffic erlauben. Die GUI ist besser geworden früher konnte man recht einfach die Regeln welche MIT der NAT Rule erstellt wurde (default) löschen bearbeiten und es somit kaputt machen.
Okay ich glaube wir sind uns hier jetzt alle einig :D
Ich bin mal gespannt was dein traceroute6 oder welches tool zu Routenverfolgung du verwendest als Ergebnis liefert.Gruß blex
-
Okay ich glaube wir sind uns hier jetzt alle einig :D
Aye :D Super. Bin auch mal gespannt was der Trace von innen nach außen zeigt, hört sich definitiv seltsam an.
-
Guten Tag,
kurzes Feedback: Es funktioniert seit dem Wochenende, juhu! Leider hatte ich noch keine Gelegenheit zu antworten - Es waren sehr stressige Tage.
Problem war, dass ich unter NAT noch ein 1:1 Mapping mit der IPv6 aktiv hatte. Das hatte für Fehler bei der Firewall gesorgt, weil die public IPs mit den lokalen IPs übersetzt wurden (Zumindest was ich in den logs gesehen habe). Da aber keine VM mehr die lokale IP hatte und die Firewall Regel auf die öffentliche Adresse ausgelegt war, ist nie etwas angekommen. Der traceroute6 ist beim Gateway des anbieters dann abgebrochen.
Naja, nach dem löschen der NAT 1:1 regel hatte dann alles funktioniert. Jetzt mache ich nach und nach die Server mit IPv6 ready.
Ich danke euch beiden nochmal! Großartige Arbeit. :)