NAT64 und PF

Mrothyr

Member
Hi,

also irgendwie stehe ich auf dem Schlauch.

Ich hab ein OpenBSD 5.3 als Access-Router mit Kernel-PPPoE für Telekom DSL16000, einen Sixxs-Tunnel mit einem öffentlichen IPv6-Segment und noch ein bissel Kleinzeug rundrum.

Nach ein bissel IPv6-Test (also das Setzen der sysctl-Variablen und Aktivierung von route6d und rtadvd) hab ich festgestellt, daß aller ausgehender Verkehr über den Tunnel läuft, sofern ein AAAA-Eintrag für den öffentlichen Server zur Verfügung steht - was nicht wirklich gewollt ist. Der Tunnel ist zum Testen (solang noch kein natives IPv6 bei den Providern ausgerollt ist), nicht für Alltagsnutzung.

Nun wollte ich NAT64 und DNS64 installieren. Flugs gemacht, unbound-1.4.20 als DNS, Patches für den DNS64-Flavour, ein wenig Sourcecode-Studium, compiliert und den undokumentierten Config-Eintrag dns64-synthall gesetzt (damit der unbound grundsätzlich eine NAT64-Adresse auf AAAA-Anfragen zurückgibt). Funktioniert auch einwandfrei.

Das Problem liegt in PF. Ich bekomm die NAT64 nicht zum Spielen. In meiner pf.conf steht:

pass in log on rl0 inet6 from any to 64:ff9b::/96 af-to inet from 192.168.242.251

Ohne den Eintrag in der pf.conf versucht er Router, die Pakete über den Tunnel zu routen. Das ist nachvollziehbar. Mit dem Eintrag verenden die Pakete im Router. Ersetze ich den Eintrag mit der IP des pppoe0, also der öffentlichen Adresse vond er Telekom verenden die Pakete ebenfalls im Router.

Irgendwo muß ich einen Denkfehler haben oder betriebsblind sein. Leider ist NAT64 extrem schlecht dokumentiert, die meisten gegoogelten Dokumentationen beziehen sich noch auf die alten Patches von Ecdysis. Teilweise wirft pf Syntax-Fehler auf entsprechende Beispiele. Hat jemand Hinweise oder ein funktionierendes Setup für NAT64 mit pf?

CU
 

mark05

Well-Known Member
hi

aeh ., dir ist klar da das routing provider seitg (t-offline) mit deinen sixxs ips nix anfangen kann ? da hilft auch kein nat64

der sixxs ipv6 traffic muss durch den tunnel laufen , das geht routing technisch gar nicht anders.

holger
 

Mrothyr

Member
hi
der sixxs ipv6 traffic muss durch den tunnel laufen , das geht routing technisch gar nicht anders.
holger

Ja natürlich. Ich will ja auch nicht, daß der Traffic über das IPv6-Netz geht. Ich will NAT64 einsetzen, damit die v6-only-Hosts intern die Rechner draußen per IPv4 ansprechen, um den Tunnel (der nur Testzwecken dienen soll) zu entlasten. Mir ist schon klar, daß der v6-Traffic über den Tunnel gehen muß, das ist auch gar nicht das Thema.

Der normale Traffic soll per IPv4 passieren - und auf dem BSD-Router mittels NAT64 für die internen v6-Hosts auf ein v6-Netz gemappt werden (was ja der Zweck von NAT64 ist). Deswegen ja auch DNS64, was ja den A-Record auf einen AAAA-Record mappt (sonst würde ich die echten AAAA-Einträge ja nicht ausfiltern).

CU
 

mark05

Well-Known Member
hi

dann schaut mal in die aiccu.conf , normalerweise setzt er eine Default route fuer ipv6 zum tunnel hin, das musst du abschalten, da dass default gw auch via ra an die clients verteilt wird.

als Default ipv6 gw dann den ipv6 router selber angeben , danach sollte dann auch das nat klappen.

Holger
 

Mrothyr

Member
hi

dann schaut mal in die aiccu.conf , normalerweise setzt er eine Default route fuer ipv6 zum tunnel hin, das musst du abschalten, da dass default gw auch via ra an die clients verteilt wird.

als Default ipv6 gw dann den ipv6 router selber angeben , danach sollte dann auch das nat klappen.

Holger

Njet, tuts nicht. Per RA wird die fe80-Adresse des Routers als Default-Gateway verteilt (zumindest bei mir). Auch logisch, weil Aiccu (zumindest bei mir) gar keine Konfiguration des zugewiesenen Netzsegmentes macht, sondern ich das händisch erledigen mußte. Aiccu trägt nur das Tunnelende des PoP als Default-Gateway bei der OpenBSD-Box ein. Die Router Advertisements konfigurierst normalerweise in der rtadvd.conf. Ist nebenbei auch logisch, da das Default-Gateway des Tunnels, das Aiccu bekommt für die Rechner im internen Segment ohne Routing gar nicht erreichbar ist (es liegt außerhalb des zugewiesenen Netzsegmentes).

CU
 

mark05

Well-Known Member
hi link local addressen werden nicht verteilt.
wenn du selber eine Default router verteilen willst musst du das den rtadvd sagen
Holger
 

Mrothyr

Member
hi link local addressen werden nicht verteilt.
wenn du selber eine Default router verteilen willst musst du das den rtadvd sagen
Holger

Naja, hab nur nachgesehen - die Default Route steht halt auf die LL-Adresse des Routers. Ob die nun per RA gekommen ist oder der Rechner einfach die Default Route auf den Rechner gesetzt hat, der ein RA verteilt hat - keine Ahnung. Mit Aiccu hat das jedenfalls nichts zu tun. Und die korrekte Adresse ist es ja letztendlich.

Ich denk immer noch, daß es an der pf.conf liegt.

CU
 

Mrothyr

Member
Abschließend (wen es interessiert, schließlich nutzt man zuallererst die SuFu).

In meiner pf.conf steht Folgendes:

# NAT64 rules
set limit states 40000
pass in on $int_if inet6 from any to 64:ff9b::/96 \
af-to inet from (egress)

NAT64 funktioniert damit, abgesehen vom Router selbst.

CU
 

Bummibaer

Registered Schwarzbär
Hoi,

da müsst`s was in rc.conf mit ip6addrctl_policy geben wo Du sagen kannst v4 bevorzugen. Dann würde er generell bei dual stack erstmal v4 nehmen. Für Deine Tests kannst Du natürlich was anderes festlegen.

Gruß Bummibär
 
Oben