PfSense Firewall IPv6 mit /64 Netz

jokabo

Hallo,
ich habe bei meinem Server Anbieter zwei Server, auf einem läuft mein pfSense auf meinem anderen die Anwendungen.

Folgendes Setup habe ich mit IPv4:
Ich habe ein /28 Subnet von meinem Anbieter bekommen: WAN Port hat eine IP + Gateway.
Im LAN habe ich das Subnet 192.168.1.0/24.

Anschließend werden die via NAT "verbunden".

Das funktioniert super!

Jetzt wollte ich meinen Server IPv6 ready machen, leider habe ich dabei ein paar Schwierigkeiten. Ich lese ständig hier im Forum, dass pfSense keine IPv6 NAT Funktion bietet.

Ich habe das ganze dennoch mal probiert:

Ich habe..

ein /64 IPv6 Netz von meinem Anbieter erhalten
dem LAN Interface die Adresse: fd00::1 zugewiesen
dem WAN Interface eine IPv6 Adresse + Gateway eingetragen
meinem Server hinter der Firewall eine IPv6 aus dem Lokalen IPv6 Netz gegeben: fd00::3
Eine NAT Outbound Regel erstellt: (Soruce: fd00::/8, NAT-Address: WAN IPv6)
Firewall Rule erstellt, dass der Server (fd00::3) in und out komplett offen ist (Nur zum testen!)
Anschließend habe ich eine 1:1 Rule erstellt: (External subnet IP: Zweite Public IPv6, Internal IP: Single Host: fd00::3)
–> Hier ist auch ein Problem, ich kann kein Subnetzmask angeben, daher stellt der beide IPs auf /32.

Wie im Forum gelesen funktioniert das ganze so nicht.

In den Logs finde ich diese beiden Fehler:

	send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr [ISP-Public]:49::1 bind_addr [ISP-Public]:49::10 identifier "WANGWv6 "

	WANGWv6 [ISP-Public]:49::1: Alarm latency 0us stddev 0us loss 100%

Das ist kein Problem! Auch wenn ich NAT toll finde, würde ich auch eine andere Lösung annehmen!

Was also wäre die korrekte Methode das ganze einzurichten? Ich stehe da leider komplett auf dem Schlauch. Sicherlich: Ich könnte einfach jedem Server eine IPv6 + Gateway von dem /64 Netz geben, das funktioniert dann auch: Aber mein Ziel ist es, dass der ganze Traffic über die Firewall geht und nicht direkt zum Netzwerk von meinem Anbieter.

Vielen Dank schonmal für eure Hilfe!

Hier nochmal ein Zitat von meinem Anbieter:

also, wir haben ja ein /64 IPv6 Netz zugewiesen. Man kann die IPv6 Adressen direkt auf den Server hochfahren, das ist normal kein Problem. Mit Pfsense arbeiten wir leider nicht, daher kann ich hier nicht sagen wie man ein Full NAT einrichtet. Wir arbeiten normal mit Sophos als Firewall, dort klappt das mit IPv6 NAT meines Erachten.

blex

Hallo,

du brauchst eine IPv6 Adresse für den pfSense auf dem WAN Interface. Nicht aus der /64 Range. Das /64iger Netzwerk wird dann von einem Provider zu der IP Adresse geroutet. Dann kannst du im LAN (also auf der pfSense LAN Seite + dem zweiten Server ips aus der /64iger Range vergeben.

Bei dem Server trägst du die IPv6 WAN der pfSense als Gateway ein. Dann läuft alle Traffic geroutet (nicht mehr per NAT) über pfSense und du kannst immer noch alles filtern.

Gruß blex

JeGr

Jetzt wollte ich meinen Server IPv6 ready machen, leider habe ich dabei ein paar Schwierigkeiten. Ich lese ständig hier im Forum, dass pfSense keine IPv6 NAT Funktion bietet.

Das hat nichts mit "Keine Funktion" zu tun. Es gibt kein NAT mehr mit IPv6. Deshalb wurde v6 überhaupt erst gepusht.

Wie im Forum gelesen funktioniert das ganze so nicht.

Nein, weil - siehe oben. Es gibt kein NAT in IPv6.

Auch wenn ich NAT toll finde, würde ich auch eine andere Lösung annehmen!

Dann bist du einer der wenigen ;)

Was also wäre die korrekte Methode das ganze einzurichten?

Wenn dein Hoster Hetzner heißt - gar nicht. Die Mädels da möchten nämlich nicht wirklich v6 spielen (hat man dein Eindruck). Wenn man hier ein zweites v6 Prefix mit /64 ordert und möchte das geroutet haben - möp geht nicht.

Ansonsten wäre genau das die korrekte Möglichkeit, was blex schreibt. Prefix 2 wird auf Prefix 1 geroutet, beide /64 Prefix Länge. Prefix 1 kommt also aufs WAN und Prefix 2 wird dann aufs LAN konfiguriert. Das wäre die schön zu haben Variante.

Grüße

jokabo

@blex - Super! Ich habe direkt meinen Anbieter angeschrieben und einen gerouteten Block bekommen. :)

@JeGr - Da habe ich aber anderes gehört. Es gibt sogar IPv6 NAT in aktion, wird also so verwendet. Dass das nicht mehr üblich ist und nicht mehr verwendet werden sollte ist natürlich was anderes. :)

Dann bist du einer der wenigen ;)

Einer der wenigen die das toll finden oder einer der wenigen die eine andere Lösung annehmen würden? :D

Ich werde versuchen das ganze mal zu konfigurieren und bei Erfolg nochmal genau schreiben, was ich wie gemacht habe - Vielleicht hilft es dem ein oder anderen. :)

Danke euch beiden auf jeden Fall für eure Hilfe!

JeGr

@JeGr - Da habe ich aber anderes gehört. Es gibt sogar IPv6 NAT in aktion, wird also so verwendet. Dass das nicht mehr üblich ist und nicht mehr verwendet werden sollte ist natürlich was anderes. :)

Nein. Es gibt kein NAT. Punkt. Was du vielleicht gehört haben meinst ist NPt. Network Prefix translation, was im ersten Moment wie ein übergroßes 1:1 NAT aussieht, aber für einen anderen Zweck und Grund gebaut worden und funktioniert auch anders als 1:1 NAT. Hier wird nämlich nur das Prefix ausgetauscht, bei dir also die ersten 64bit. Der Rest bleibt gleich, also der Identifier Bereich, die letzten 64Bit.
Das ist schlußendlich für Corner Cases gebaut worden, generell verwendet werden sollte es schon die ganze Zeit nicht, da - s.o. - NAT sterben soll. Weil es einfach zu viele und zu große Einschränkungen und Probleme mit sich bringt. Jeder der schon mit den neueren Techniken wie SIP, IPSec NAT-T und Co herumgeschlagen hat weiß inzwischen NAT zu hassen und würde keine Träne nachweinen. ;)

Dann bist du einer der wenigen ;)

Die das gut finden :) Oder du hast noch nie ein etwas komplexeres Szenario mit NAT bauen müssen, dann lernst du es inbrünstig hassen. Spätestens mit NAT Reflektion und solchem Irrsinn ist dann der Wahnsinn komplett. ;)

Sollte dein Hoster kein 2. IP6 routen, dann wäre IP6 NPT wahrscheinlich tatsächlich die letzte Hoffnung das irgendwie sauber hin zu bekommen. Leider.

Gruß

jokabo

@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::/64

Das 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?

JeGr

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ß

jokabo

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?

JeGr

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

jokabo

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?

blex

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.

@jokabo:

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

JeGr

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

blex

@JeGr:

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.

@JeGr:

(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.

@JeGr:

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

JeGr

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.

jokabo

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. :)