OpenBSD Tekeom IPv6

jmt

Well-Known Member
Hallo,

ich bin irgendwie zu blöd für IPv6 über PPPoe. Ich habe eine VDSL-Leitung der Telekom und dahinter einen OpenBSD Router. Der konnte daran auch mal IPv6 machen. Aber dann ging es nicht mehr und ich habe das ruhen lassen. Jetzt bekomme ich das nicht mehr ans Laufen. Benutzt jemand von euch IPv6 mit OpenBSD bei der Telekom und kann mir auf die Sprünge helfen?

Danke!
 

jmt

Well-Known Member
Ich taste mich langsam vorwärts. Der slaacd kann eine Verbindung aufbauen und Adressen beziehen. wenn ich die Firewall ausschalte. Bleibt nun die Frage, was man dort freischalten muss, damit es wieder funktioniert.
 

jmt

Well-Known Member
Das Problem lag im ICMP6. Wenn das global erlaubt ist, dann läuft es. Wäre nur interessant zu wissen, ob man das einschränken sollte und wenn ja, wie?
 

Andy_m4

Well-Known Member
Wäre nur interessant zu wissen, ob man das einschränken sollte und wenn ja, wie?
Eher nicht. IPv6 reagiert empfindlicher auf "kaputtes" icmp als IPv4.
Generell würde ich aber sagen man sollte es eher nicht machen wenn man nicht genau weiß, was man tut. Wie oft hatte ich schon Ärger mit Anwendungen die nicht richtig funktionieren weil der paranoide Admin alles abdreht was er in die Finger kriegt. Und der Sicherheitsgewinn ist dabei auch meist eher überschaubar.
 

Andy_m4

Well-Known Member
icmp6 ist so empfindlich , als auch unempfindlich , wie icmp4
Ähm nein. IPv6 ist sehr viel mehr auf funktionierendes ICMP angewiesen als IPv4. Das schon angesprochene Neighbor Discovery Protocol (NDS) - also kurz gesagt der Autoconfig-Kram basiert darauf das das funktioniert.
IPv6 kennt auch keine Fragmentierung. Das heißt aber auch, man muss vor dem verschicken eines IPv6-Paketes nachgucken, was die größtmögliche Paketgröße ist. Dieses Path MTU Discovery funktioniert halt nur mit funktionierenden ICMP.

Gibt es denn einen Grund ICMP für IPv4 einzuschränken?
Nicht wirklich. Klar kann man solche Spielereien machen wie "ICMP/Echo" zu droppen, damit man von außen nicht angepingt werden kann (wird ja von manchen Routern marketing-wirksam als Stealth-Mode beworben :) ). Aber selbst das ist mehr oder weniger witzlos.

Was wirklich wichtig ist ist in bezug auf IPv6 das jetzt Deine LAN-Hosts von außen direkt erreichbar sind, weil da (üblicherweise) kein NAT gemacht wird wie bei IPv4. Da sich drum zu kümmern und zu gucken wäre 1000 Mal wichtiger als irgendwelches halbseidene ICMP-Filtern.
 

jmt

Well-Known Member
Glücklicherweise verwende ich momentan NAT auch bei IPv6. Das funktioniert gut und ich kann den Traffic zentral filtern.
 

CommanderZed

OpenBSD User
Teammitglied
Glücklicherweise verwende ich momentan NAT auch bei IPv6. Das funktioniert gut und ich kann den Traffic zentral filtern.

Das kannst du ja auch auch ohne NAT.

Kann ich eigentlich bei IPv6 bei nem "normalen" Provider (Telekom, Deutsche Glasfaser) das Netz lokal aufsplitten in unternetze um z.B. ein Client-Netz, ein Gast-Netz, ein dubiose-geräte-netz e.t.c. zu erstellen?
 

mark05

Well-Known Member
hi

vielleicht habe ich mich ds etwas "undefiniert" ausgedrückt.
icmp6 ist ebenso robust wie icmp4 ,es gibt halt mehr zu beachten.

ein icmp path disccovery ist fuer ipv4 ebenso wichtig wie bei ipv6 ,
die folgen des nicht beachten sind unterschiedlich.

icmp ist ein protocol und sollte grundsätzlich deny'ed werden, es sollten
nur die notwendigen typen in die jeweilige richtig erlaubt werden.

falls mal icmp generell erlaubt kann es auch zu einem missbrauch kommen.

ich habe auf die schnelle nicht mehr gefunden


Holger
 

Andy_m4

Well-Known Member
Glücklicherweise verwende ich momentan NAT auch bei IPv6. Das funktioniert gut und ich kann den Traffic zentral filtern.
Der Vorteil bei IPv6 ist ja gerade, das Du Krücken wie NAT nicht mehr brauchst. Die dann trotzdem zu verwenden ist .... lustig. :-)

Kann ich eigentlich bei IPv6 bei nem "normalen" Provider (Telekom, Deutsche Glasfaser) das Netz lokal aufsplitten in unternetze um z.B. ein Client-Netz, ein Gast-Netz, ein dubiose-geräte-netz e.t.c. zu erstellen?
Du kriegst ja im Prinzip ein IPv6-Prefix. Wie Du dann intern bei Dir das verwendest ist sozusagen Dein Bier.
Bei Anbietern (wie der Telekom) kriegst Du üblicherweise ein 56-Netz. Die letzten 64 Bit sind ja sowieso (falls nicht anders konfiguriert; was man aber ohne hin nicht machen sollte) Hosts. Die ersten 64-Bit sind die Subnetz-Adresse, wovon Du dann quasi 8 Bits frei verwenden kannst um intern bei Dir Subnetze zu realisieren.

ein icmp path disccovery ist fuer ipv4 ebenso wichtig wie bei ipv6
Ähm nein. Kommt natürlich immer auf den konkreten Fall an, aber IPv6 kriegst Du erst gar nicht "ans laufen", wenn das nicht funktioniert.

ich habe auf die schnelle nicht mehr gefunden
Ist schon immer ein schlechtes Zeichen wenn jemand nicht in der Lage ist die Probleme selbst zu benennen, sondern schnell mal googeln muss um wenigstens irgendwas ins Forum zu kippen. :-)
 

mark05

Well-Known Member
die zeichen der zeit nennt man alter , da hat man nicht mehr alles im detail im kopf.
es dann zu wissen das man icmp auch fuer "normale" host zu host kommunikation
missbrauchen kann.

holger
 

schorsch_76

FreeBSD Fanboy
Zu Ipv6 und NAT: Das ipv6 Präfix ändert sich jeden Tag. Das Präfix der ULA nicht. Das macht Dinge wie Bind9 viel einfacher zu konfigurieren.

Falls jemand weiß, wie man Zonendateien über ein geändertes Präfix automatisch aktualisieren kann, bitte her damit :)
 

mapet

Active OpenBSD User
Das kannst du ja auch auch ohne NAT.

Kann ich eigentlich bei IPv6 bei nem "normalen" Provider (Telekom, Deutsche Glasfaser) das Netz lokal aufsplitten in unternetze um z.B. ein Client-Netz, ein Gast-Netz, ein dubiose-geräte-netz e.t.c. zu erstellen?
Ich hab das bei mir mit dhcpcd gelöst. Der holt per Präfix Delegation v6 Präfixe für mein normales Netz, Gäste vlan und Medien vlan ab und stellt es intern per rad zur Verfügung. Bei DG sind die Präfixe auch solange stabil, bis sich die Client id ändert. Ggf. macht die Telekom es anders. Mehr als die drei Präfixe hab ich bisher nicht gebraucht, aber ich denke, man hat ein /56 als endkunde (dürften dann 64 /64 sein).
Bitte bitte bitte macht mit v6 kein NAT mehr. Das ist bei v4 schon massiv kaputt. Ihr habt routebare Adressen hinter eurem Router, mit dem ihr prima Pakete Filtern könnt, ohne das Netz zu verfrickeln. Nutzt lieber die Freiheit, auf Hosts hinter eurem Router ohne irgendwelche Kücken auf selbigem von außen zuzugreifen und die Dienste anzusprechen.
 

morromett

Well-Known Member
Bitte bitte bitte macht mit v6 kein NAT mehr. ....
Ja, kein NAT mit v6.

BTW: Wie ist das bei einem v6-traceroute aus dem Internet auf die externe IPv6-Adresse eines Hosts hinter dem Router, wird in diesem v6-traceroute auch die externe IPv6-Adresse des Routers gesehen und wenn ja, dann mit einer statischen (EUI64-basierten) Interface-ID oder benutzt der Router privacy extensions für seine externe IPv6-Adresse?
 

jmt

Well-Known Member
Ich hab das bei mir mit dhcpcd gelöst. Der holt per Präfix Delegation v6 Präfixe für mein normales Netz, Gäste vlan und Medien vlan ab und stellt es intern per rad zur Verfügung. Bei DG sind die Präfixe auch solange stabil, bis sich die Client id ändert. Ggf. macht die Telekom es anders. Mehr als die drei Präfixe hab ich bisher nicht gebraucht, aber ich denke, man hat ein /56 als endkunde (dürften dann 64 /64 sein).
Bitte bitte bitte macht mit v6 kein NAT mehr. Das ist bei v4 schon massiv kaputt. Ihr habt routebare Adressen hinter eurem Router, mit dem ihr prima Pakete Filtern könnt, ohne das Netz zu verfrickeln. Nutzt lieber die Freiheit, auf Hosts hinter eurem Router ohne irgendwelche Kücken auf selbigem von außen zuzugreifen und die Dienste anzusprechen.
Also zunächst habe ich noch nicht ein Problem damit, Dienste auch über NAT bereit zu stellen. Könnt ihr mir eine gute Dokumentation zu IPv6 in Heimnetzen nennen. Wie binde ich z.B. einen internen Host an eine IP, damit ich passende Regeln in PF erstellen kann?
 

schorsch_76

FreeBSD Fanboy
Bitte bitte bitte macht mit v6 kein NAT mehr.
Das sagen viele, aber für das Problem bsp. mit bind9 und dem Update der Zonen gibt es bei änderndem Präfix keine Lösung.

Edit: Du meinst man sollte also einen internen dyndns Dienst betreiben? Daran hab ich noch gar nicht gedacht .... Interessante Idee!
 

mapet

Active OpenBSD User
Also zunächst habe ich noch nicht ein Problem damit, Dienste auch über NAT bereit zu stellen. Könnt ihr mir eine gute Dokumentation zu IPv6 in Heimnetzen nennen. Wie binde ich z.B. einen internen Host an eine IP, damit ich passende Regeln in PF erstellen kann?
Falls du keine EUI-64 Adresse verwenden möchtest, gibt es "Semantically Opaque Interface Identifiers" (RFC7217), manchmal auch "stable privacy" genannt (in NetworkManagersprech ;)). Damit wird ein zufälliger Hostteil (die hinteren 64bit deiner v6 Adresse) generiert und dieser ist per Präfix immer gleich (vgl. https://labs.ripe.net/author/johanna_ullrich/ipv6-addresses-security-and-privacy/). Problematisch wird's natürlich, wenn sich der Prefix wieder ändert, da sich damit dann auch die Hostteil wieder ändert. Da müsste man dann was drumrum skripten, was anschließend einen reload der /etc/pf.conf triggert. Ggf. hilft hierbei aber auch eine Netzsegmentierung, die ein generischeres Ruleset erlaubt. Kommt dabei allerdings dann ein wenig auf die verwendete Hardware an, ob es alles so unterstützt wird.
 

TCM

Well-Known Member
Mein öffentliches, dynamisches /56 mappe ich per binat auf ein /56 in fd00::

Verbindungen auf mein eigenes öffentliches /56 gehen dann halt einmal bis nach außen zum Router und werden so umgemappt, dass die Verbindung wieder von meinem öffentlichen /56 reinkommt, NAT-Reflection eben.

Den Prefix irgendwie dynamisch über 3 Router per OSPF[1] und sonstwas zu reichen - von DNS ganz zu schweigen - hab ich mir nicht angetan.

Ein statisches /48 liegt außerdem an und wird 1:1 geroutet.

Edit: Das sollte nicht heißen, dass das dazu nötig wäre. Das ist nur aus Gründen der Zustand hier.
 

jmt

Well-Known Member
Mein öffentliches, dynamisches /56 mappe ich per binat auf ein /56 in fd00::

Verbindungen auf mein eigenes öffentliches /56 gehen dann halt einmal bis nach außen zum Router und werden so umgemappt, dass die Verbindung wieder von meinem öffentlichen /56 reinkommt, NAT-Reflection eben.

Den Prefix irgendwie dynamisch über 3 Router per OSPF[1] und sonstwas zu reichen - von DNS ganz zu schweigen - hab ich mir nicht angetan.

Ein statisches /48 liegt außerdem an und wird 1:1 geroutet.

Edit: Das sollte nicht heißen, dass das dazu nötig wäre. Das ist nur aus Gründen der Zustand hier.
Kannst Du das mal erläutern? Es klingt als wäre es das, was mir vorschwebt. Ich habeIntern ein fc00 Netz und vergebe statische Adressen an Server mit Diensten. Bei mir liegt das NAT momentan aber auf einer (den) IPv6 Adresse(n) am Router.
 

TCM

Well-Known Member
Ich habe in meiner pf.conf:

Code:
anchor "binat6_int" quick on $int_if inet6
anchor "binat6_ext" quick on $ext_if inet6

und dann ein Script, was bei Präfixwechseln mit dem /56 aufgerufen wird (zB 2003:d7:123:a00::/56):

Code:
PROG=$(basename ${0})

binatnet=${1}

siteid=fd00:0:0
sitenet=${siteid}::/48
intnet=${siteid}:fd00::/56

natnet=$(
        slaacctl show interface pppoe0 \
        | grep prefix: \
        | egrep -o '[[:xdigit:]:]+/[0-9]+$' \
        | head -n 1
)

[ -z "${natnet}" ] && { logger -t ${PROG} 'slaacctl returned no prefix?'; return 1; }

pfctl -a binat6_ext -f - <<-EOF
        pass  in quick   to ${binatnet} modulate state (if-bound) rdr-to   ${intnet} bitmask
        pass out quick from   ${intnet} modulate state (if-bound) nat-to ${binatnet} bitmask static-port
        pass out quick from  ${sitenet} modulate state (if-bound) nat-to   ${natnet} port 49152:65535 random
EOF
pfctl -a binat6_int -f - <<-EOF
        pass  in quick   to ${binatnet} tag    BINAT6 modulate state (if-bound) rdr-to   ${intnet} bitmask
        pass out quick from   ${intnet} tagged BINAT6 modulate state (if-bound) nat-to ${binatnet} bitmask static-port
        pass out quick from  ${sitenet} tagged BINAT6 modulate state (if-bound) nat-to   ${natnet} port 49152:65535 random
EOF

logger -t ${PROG} "configured new binat network: ${binatnet} <-> ${intnet}"

Das macht aber irgendwie noch mehr, sehe ich grade. Das /56 wird 1:1 auf ein /56 gemappt, gleichzeitig wird aber ein größeres /48 noch ausgehend in das kleinere /56 reingemappt, so dass jede neue ausgehende Verbindung eine neue Adresse benutzt. Ist ziemlicher Schnickschnack und normal wohl nicht nötig. Das betrifft jede Zeile, die ${sitenet} verwendet. Die kann man weglassen. Edit: Es gibt Seiten, bei denen sind Logins noch an Quelladressen gekoppelt. Da funktioniert das nicht so gut. ;)

Edit: Jetzt weiß ichs wieder. Das kleine Netz, in das alle sonstigen ausgehenden Verbindungen mit einer random Adresse reingemappt werden, ist das /64er Transfernetz, was man zusätzlich kriegt.

Also zusammenfassend:

fd00:0:0:fd00::/56 <-> public /56
fd00:0:0::/48 -> NAT auf public /64 mit randomisierten Quelladressen
Rest hat keinen Internetzugriff

Edit: Der zweite Anker auf dem internen Interface sorgt für die vollständig transparente Reflektion. Man sieht Verbindungen intern dann wie von außen kommen, nur mit seinem eigenen /56 als Quelle, inkl. der o.g. Random-Magic.
 
Zuletzt bearbeitet:
Oben