IPv6-Freigabe mit einer FritzBox Cable - Wo liegt der Fehler?

Hallo zusammen,

ich versuche mich gerade mit der Bereitstellung eines VPN-Servers hinter einer Cable-Fritzbox (DS-Lite) zu beschäftigen. Um die Komplexität aus der Sache zu nehmen, möchte ich als erstes einen simplen Ping bzw. HTTP-Aufruf von extern nach intern herstellen. Hierbei scheitere ich bereits. Habt ihr Tipps für mich woran es liegen könnte?

Mir steht folgende Hardware zu Verfügung:

Fritzbox 6591 Cable (vom Provider zu Verfügung gestellt)

IPv6-Adresse: 2a02:340d:8000:a:94aa:6c8e:e4b:7ced
IPv6-Präfix: 2a02:340d:8500:b84::/62

RaspberryPi

IPv4-Adresse: 192.168.178.40
IPv6-Adresse 1: fe80::b86a:833a:48aa:12d2
IPv6-Adresse 2: 2a02:340d:8500:b84:da62:7699:e113:259

Gemieteter Root-Server mit statischen Adressen

IPv4-Adresse: 185.84.80.147
IPv6-Adresse 1: fe80::5054:ff:fe80:662
IPv6-Adresse 2: 2a02:248:2:40e6:5054:ff:fe80:662

Was ich bereits getestet / überprüft habe:

IP-Adressen für diesen Beitrag leicht abgeändert
Einstellungen gemäß "https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/573_IPv6-Unterstutzung-in-FRITZ-Box-einrichten/" überprüft
Eine Freigabe über "Internet -> Freigaben -> Portfreigaben" eingerichtet

"PING6 freigabe"
testweise TCP-Port 80 freigegeben

"Ping -6 raspberrypi" von intern -> Antwort von "2a02:340d:8500:b84:da62:7699:e113:259"
Ping IPv6-Adresse der Fritzbox vom Root-Server (2a02:340d:8000:a:94aa:6c8e:e4b:7ced) -> Antwort von "2a02:340d:8000:a:94aa:6c8e:e4b:7ced"
Ping IPv6-Adresse des PIs vom Root-Server (2a02:340d:8500:b84:da62:7699:e113:259) -> Nichts passiert
Ping IPv6-Präfix der Fritzbox + IPv6-Suffix des PIs vom Root-Server (2a02:340d:8500:b84:b86a:833a:48aa:12d2) ...

-> Antwort im Root-Server-Terminal: "Destination unreachable: Address unreachable"
-> TCPDUMP auf dem PI: "fe80::464e:2dff:fee4:8c5e > ff02::1:ffaa:12d2: ICMP6, neighbor solicitation, who has 2a02:340d:8500:b84:b86a:833a:48aa:12d2"

Meine Vermutung

Im Prinzip ist die Verwendung von IPv6-Präfix der Fritzbox + IPv6-Suffix vom PI die richtige Kombination. Nur auf diesem Weg, erkenne ich mit TCPDUMP überhaupt Netzwerkverkehr. Allerdings deute ich den einseitigen NDP-Verkehr so, dass die Fritzbox keinen Schimmer hat, an wenn das ICMP6-Paket gerichtet ist. Der PI wird zwar kontaktiert, fühlt sich jedoch nicht angesprochen und sendet keine Antwort zurück.

Entweder müsste ich dem PI beibringen, auch auf genau diese neighbor solicitations zu antworten oder aber die Fritzbox müsste dies selbstständig machen und tut es nicht. Korrigiert mich gerne

. So ein "ping" sollte doch zu schaffen sein.

Vielen Dank im Voraus.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 587019

Url: https://administrator.de/forum/ipv6-freigabe-mit-einer-fritzbox-cable-wo-liegt-der-fehler-587019.html

Ausgedruckt am: 21.04.2025 um 14:04 Uhr

8 Kommentare

Neuester Kommentar

Wenn du TCP-Port 80 freigibst, ist ein Ping nicht der richtige Weg das zu prüfen. Du hast ja schließlich einen TCP-Port und nicht ICMP6-Echo-Req freigegeben

Teste doch mal von dem externen Server mit

traceroute -T -p 80 -6 2a02:340d:8500:b84:da62:7699:e113:259

Damit müsstest du hinter die Fritzbox gelangen, wenn die Freigabe funktioniert.

Zitat von @LordGurke:

Wenn du TCP-Port 80 freigibst, ist ein Ping nicht der richtige Weg das zu prüfen. Du hast ja schließlich einen TCP-Port und nicht ICMP6-Echo-Req freigegeben

Teste doch mal von dem externen Server mit

traceroute -T -p 80 -6 2a02:340d:8500:b84:da62:7699:e113:259

Stimmt natürlich. Das dachte ich, erledigt aber der Haken bei "PING6". Habe deine Lösung natürlich trotzdem einmal ausprobiert und hatte leider keinen Erfolg. Bei "30 * * *" ist traceroute dann fertig. Parallel dazu, konnte ich via TCPDUMP keinerlei Aktivität auf dem PI erkennen (tcpdump -ni eth0 tcp port 80 or icmp6). Habe es danach auch mal vom Browser meines eigenen PCs aus getestet. Wird an einem klassischen Privatkunden IPv4 Anschluss der Telekom betrieben. Keinen Erfolg. Bist du dir sicher, dass ich für eine erfolgreiche Verbindung die im PI eingetragene IPv6-Adresse 1:1 nehmen muss?

Im Freigabewizard der FB wird dort, wo ich die freigegebenen Ports eintrage angezeigt, dass die aus dem Internet erreichbare IPv6-Adresse "2a02:340d:8500:b84:b86a:833a:48aa:12d2" lautet. Also Netzwerk-Präfix/64 der Fritzbox + Interface Identifier/64 des PIs.

Viele Grüße.

Schau doch mal auf dem Pi nach, welche Adresse er hat und vergleiche das mal zur Sicherheit.
Aber in der Tat: Die Adresse, die der Pi hat ist so öffentlich erreichbar, sofern sie freigegeben wird. Kein NAT.

Zitat von @Starbase12:

Im Freigabewizard der FB wird dort, wo ich die freigegebenen Ports eintrage angezeigt, dass die aus dem Internet erreichbare IPv6-Adresse "2a02:340d:8500:b84:b86a:833a:48aa:12d2" lautet. Also Netzwerk-Präfix/64 der Fritzbox + Interface Identifier/64 des PIs.

Hat der Pi überhaupt eine fest eingestellte statische Adresse oder würfelt er seine dauernd neu aus, wie das wegen der privacy meist Standard ist?

Tatsächlich hat der Pi bislang keine statische ipv6 von mir bekommen. Habe ipv4 sowie ipv6 auf dhcp belassen und in der FB nur die ipv4 Adresse statisch setzen lassen.

Habe jedoch bereits in einem ähnlichen Beitrag hier gelesen, wie ich den identifier-teil wieder mac-based setzen kann. Somit dürfte sich dieser dann nicht mehr ändern.

Zitat von @LordGurke:

Schau doch mal auf dem Pi nach, welche Adresse er hat und vergleiche das mal zur Sicherheit.
Aber in der Tat: Die Adresse, die der Pi hat ist so öffentlich erreichbar, sofern sie freigegeben wird. Kein NAT.

Ich habe das noch einmal verglichen. Meine Angaben sind soweit korrekt. Der raspberry pi hat ja laut ifconfig zwei ipv6-adressen zugewiesen. Ich glaube deiner Aussage und bin jedoch gleichzeitig verwundert, wieso bei der fritzbox dann eine vermischte Adresse als "Adresse von extern" angezeigt wird.

Schade, dass der Provider capture.html deaktiviert hat und soweit ich weiß auch nur selten Updates bereit stellt. Sonst würde ich natürlich dort mal nachgucken was ankommt und was nicht.

Zitat von @Starbase12:

Schade, dass der Provider capture.html deaktiviert hat und soweit ich weiß auch nur selten Updates bereit stellt. Sonst würde ich natürlich dort mal nachgucken was ankommt und was nicht.

Dann gib das Ding zurück und kauf Dir einen eigene unkastrierte Fritte.

lks