IPsec IPv6
-
Hallo!
Mit der Umstellung auf IPv6 möchte ich nun auch meine IPsec Verbindung darüber in Betrieb nehmen. Das Testendgerät ist ein iPhone mit Dual Stack (DT). Der Verbindungsaufbau klappt und ich weiße einen virteullen IPv6 Adresspool in Form von fc00:10::/64 zu. Das kommt so auch beim Client an. Dieser kann auch IPv6 nach außen hin sprechen. Wie es scheint finden die Pakete jedoch nicht zu ihm zurück.
Konfiguration, Remotegateway steht auf Dual Stack:
So sieht ein Ping im Firewall log z.B. aus:
Der IPsec Log füllt sich jedoch mit folgender Meldung:
Oct 9 07:43:53 charon 09[ENC] <con-mobile|1> parsed INFORMATIONAL response 20 [ ] Oct 9 07:43:53 charon 09[NET] <con-mobile|1> received packet: from 2a01:xxx[4500] to 2a02:xxx[4500] (80 bytes) Oct 9 07:43:53 charon 10[NET] <con-mobile|1> sending packet: from 2a02:xxx[4500] to 2a01:xxx[4500] (80 bytes) Oct 9 07:43:53 charon 10[ENC] <con-mobile|1> generating INFORMATIONAL request 20 [ ] Oct 9 07:43:53 charon 10[IKE] <con-mobile|1> sending DPD request Oct 9 07:43:24 charon 10[ENC] <con-mobile|1> parsed INFORMATIONAL response 19 [ ] Oct 9 07:43:24 charon 10[NET] <con-mobile|1> received packet: from 2a01:xxx[4500] to 2a02:xxx[4500] (80 bytes) Oct 9 07:43:24 charon 10[NET] <con-mobile|1> sending packet: from 2a02:xxx[4500] to 2a01:xxx[4500] (80 bytes) Oct 9 07:43:24 charon 10[ENC] <con-mobile|1> generating INFORMATIONAL request 19 [ ] Oct 9 07:43:24 charon 10[IKE] <con-mobile|1> sending DPD request Oct 9 07:43:14 charon 11[ENC] <con-mobile|1> parsed INFORMATIONAL response 18 [ ] Oct 9 07:43:14 charon 11[NET] <con-mobile|1> received packet: from 2a01:xxx[4500] to 2a02:xxx[4500] (80 bytes) Oct 9 07:43:14 charon 11[NET] <con-mobile|1> sending packet: from 2a02:xxx[4500] to 2a01:xxx[4500] (80 bytes) Oct 9 07:43:14 charon 11[ENC] <con-mobile|1> generating INFORMATIONAL request 18 [ ] Oct 9 07:43:14 charon 11[IKE] <con-mobile|1> sending DPD request Oct 9 07:43:04 charon 11[ENC] <con-mobile|1> parsed INFORMATIONAL response 17 [ ]Wo habe ich etwas übersehen? Die Firewallregeln im IPsec sind natürlich komplett offen.
-
OK ganz unschuldig gefragt: du weist dem Client nach der Einwahl eine fc00:: Adresse zu korrekt? Und pushst dann aber die Default Route über IPSec an den Client raus damit alles über die pfSense läuft?
Mit welcher IP6 soll denn der Client via IPSec jetzt über deine pfSense ins Internet sprechen? Hast du da noch ein NPt konfiguriert oder was ähnliches? Ansonsten wäre das in etwa das Gleiche als ob du ne 10er IP dem Client zuweist und ohne NAT dich wunderst warum die IP Pakete von 10.0.8.2 ins Internet gesendet nicht zurück kommen? fc00::/ ist doch ein local unicast address range, noch dazu ist fc00::/8 undefiniert. Es war mal geplant, dass Prefixe daraus vergeben werden aber da wurde noch nichts entschieden, daher undefiniert. fd00::/8 ist dagegen für Vergabe von /48er Prefixen gedacht, wobei die Adressen fdxx:xxxx:xxxx randomized ausgewählt werden sollen damit möglichst wenig Überlappung stattfindet. Beide sollen zwar nicht geroutet werden (daher ist random eigentlich! egal), allerdings könnten solche Netze bei Tunneln zusammenkommen (Site2Site bspw.), weswegen hier durch Zufallsvergabe es vermieden werden kann, dass das typische 192.168.1.x auf beiden Seiten Szenario eintrifft ;)
Nichts desto weniger: wenn dein Client nach der Einwahl ein fc00::/7 IP6 hat, wird die wohl eher nie geroutet werden und dementsprechend auch nicht zurückkommen. Genau dafür hat man aber im Normalfall ja nicht nur 1 /64 Prefix auf seiner pfSense, sondern mindestens ein /56er Prefix wenn nicht gar eine /48er Zuteilung. Wenn du für die Einwahl also ein anderes globales Prefix aus deiner Zuteilung nimmst, sollte das klappen :)
Gruß
-
Im Grunde alles logisch was Du sagst. Problem ist dass in D die Prefixe dynamisch sind und ich daher lieber mit der fc arbeite. Einen NPt habe ich natürlich nicht laufen. Ohne weiteres Hintergrundwissen ging ich davon aus, dass sämtlicher IPsec Traffic über das WAN Interface, welches eine IPv6 hat geroutet wird und auch wieder zurück kommt. Immerhin geht das Paket ja auch dort rüber raus.
In meinem Fall habe ich wohl also keine Chance ohne statisches Prefix etwas zu erreichen.
-
@mrsunfire Mit IPSec könnte das in der Tat schwierig werden, für OpenVPN hätte ich allerdigns tatsächlich ein paar Ideen in petto.
