Portmapping mit IPv6 via public IPv6 funktioniert nicht (WG Tunnel funktioniert, IPv4 Portmapping funktioniert)

[Eric_o_O]

Hi zusammen,

erstmal ein großes Dankeschön für eure Arbeit und die ganzen Services hier
Ich nutze ipv64 jetzt schon eine Weile und muss wirklich sagen: Gerade der Cloud Router und die ganzen Tunnel-/Portmapping-Geschichten sind super hilfreich und machen vieles überhaupt erst möglich – echt top Dennis!

Zu meiner Situation:
Ich habe zuhause einen DS-Lite Anschluss von Deutsche Glasfaser. Die Fritzbox hängt bei mir als Router hinter dem DG-Modem, wodurch ich leider ein bisschen an Workarounds gebunden bin. Deshalb bin ich auch bei ipv64 gelandet.

Aktuell nutze ich den WireGuard-Tunnel über den Cloud Router und der läuft einwandfrei.
Ich komme damit problemlos auf mein Heimnetzwerk und kann auch IPv4-Adressen über das Portmapping direkt erreichen. Heißt: IPv4-Portmapping über den WG-Tunnel funktionieren ohne Probleme.
Als nächsten Schritt:
Ich würde z. B. gerne einen NGINX-Server direkt von außen erreichbar machen und das möglichst ohne zusätzliche Portmappings.

Dafür habe ich folgendes ausprobiert:
Unter „Manage Public IPs“ habe ich mir eine IPv6-Adresse erstellt und diese dann im Portmapper des Cloud Routers ausgewählt. Als Ziel habe ich testweise eine interne IPv6-Adresse von einem Webdienst bei mir im Netzwerk angegeben.

Das Ergebnis:

• Im lokalen Netzwerk kann ich die interne IPv6 ganz normal im Browser aufrufen

• Wenn ich allerdings die zugewiesene öffentliche IPv6 aus dem Portmapper nutze, bekomme ich im Browser keine Antwort

• Portmapping für die IPv6 Adresse:

  

• im WG Tunnel wird in der Routing Tabelle mein lokales IPv6 auch gemapped

  

Jetzt die Frage:
Hat jemand eine Idee, woran es liegen könnte, dass die IPv6 von außen nicht erreichbar ist bzw. „nicht aufgelöst“ wird?

Bin für jeden Hinweis dankbar

Viele Grüße
ERIC

[The_eagle]

@Eric_o_O

Unter „Manage Public IPs“ habe ich mir eine IPv6-Adresse erstellt und diese dann im Portmapper des Cloud Routers ausgewählt. Als Ziel habe ich testweise eine interne IPv6-Adresse von einem Webdienst bei mir im Netzwerk angegeben.

Wozu der ganze Aufwand? IPv6-GUA’s kannst du Server direkt auch bei CGNAT erreichbar machen! Einfach Port (z.B. tcp 443 für https) in der FW der Fritteuse öffnen und schon biste auf den NGINX-(Web)Server. Was ist zu tun?

1. IPv6 im Router aktivieren
2. per DHCPv6-PD eine öffentliche IPv6-Adresse für den Server konfigurieren
3. Router-Firewall für den Port (tcp 443) öffnen
4. IPv6-fähiger DynDNS-Dienst für die perDHCPv6-PD zugewiesene IPv6 einrichten

fertig!

PS:

@Eric_o_O

Portmapping für die IPv6 Adresse:

und mit einer Link-Local IPv6 Unicast Adresse (LLA) als Destination geht das eh nicht, denn die gilt nur für das jeweilige Netzwerksegment. Der Link-Local-Scope reicht nur bis zum nächsten Router, ist also darüber hinaus nicht routbar.

Lies dich in die IPv6-Thematik ein !!

[Eric_o_O]

Hi,

vielen Dank für den Hinweis
Es gibt allerdings ein paar Gründe, warum ich IPv6 gerne über den Cloud Router mappen würde, deshalb würde ich gern nochmal auf mein ursprüngliches Thema zurückkommen.

Wenn ich es richtig verstanden habe, nutze ich aktuell vermutlich die falsche IPv6-Adresse.
Allerdings habe ich auch schon testweise eine IPv6 mit dem Prefix „2a00“ verwendet und leider werde ich darüber ebenfalls nicht geroutet bzw. erreiche meinen Dienst nicht.

Vielleicht habe ich da noch einen Denkfehler?

Kleiner Zusatz: Auch wenn ich die fdba:448:495a:0:9e6b:ff:fea3:f5a2 ULA verwende gehts nicht.

LG
ERIC

[The_eagle]

Vermutlich mehr als nur einen Denkfehler. Der 1. Denkfehler ist, dass du meinst mit IPv6 arbeiten zu können ohne das erforderlichen Grundlagenwissen zu besitzen. Dazu gehört es zwingend die IPv6-Address-Scopes (Gültigkeitsbereiche) zu kennen.

IPv6 unterscheidet sich von IPv4 nicht nur durch längere Adressen, sondern auch durch Gültigkeitsbereiche (Address Scopes) für diese Adressen. Das heißt, jede IPv6-Adresse hat einen sogenannten Scope bzw. Gültigkeitsbereich. Der Scope ist der Teil eines Netzwerks in dem die zugehörige Adresse als gültig anerkannt und geroutet wird.

Quelle: Elektronik Kompendium

Warum sage ich das? Weil du

1. mal eine LLA nimmst, die aber nicht geroutet werden kann und
2. dann eine GUA, die gar nicht geroutet werden braucht, da es eine öffentliche IPv6 ist.

Du musst die GUA von extern erreichbar machen, damit das was du willst klappt. Nur dann kannst gleich machen was ich vorgeschlagen habe, du aber aus „ein paar Gründen“ nicht willst. Unverständliche Gründe sind das für mich aber!

Also nochmal: Lies dich ein. Die Infos sind alle im Netz verfügbar. Wenn du die Grundlagen verstanden hast und auf Basis des neu erworbenen Grundlagenwissens weitere Fragen hast, helfe ich gern weiter.

[Eric_o_O]

Hi,
danke für die nette Erklärung.

Gründe: Ganze einfach ich möchte mich geschützt über den Cloud Rounter mit dem lokalen Netz verbinden und bei DG funktioniert IPv6 GUA am laufenden Band nicht stabil. (ist leider auch ein bekanntest Problem)

Ich habe es auch noch einmal über eine ULA-Adresse versucht, allerdings ebenfalls ohne Erfolg. Dabei sollte diese ja zumindest im lokalen Netzwerk über den WG Tunnel geroutet werden.

LG
ERIC

[The_eagle]

Wenn du sowieso nur über den CR gehen willst bleib bei IPv4. Dann gibt es keine wirklich guten Gründe IPv6 zu nutzen.

Das IPv6 GUA bei DG nicht stabil läuft halte ich für ein Gerücht. Es wird das selbe Problem sein, wie bei fast allen ISP auch: die regelmäßige Zwangstrennung und Beglückung der Kundschaft mit einem neuen IPv6-Präfix. Dafür gibt es aber bewährte Lösungen.

ULA’s sind in der Tat das Mittel der Wahl für lokale aber über Netzwerksegmente hinweg routbare IPv6-Adressen. Diese sind das Äquivalent zu den IPv4-Adressen aus den privaten Klasse A-, B- und C-Netzen.

Nachtrag:
Du willst ja einen NGINX-Server erreichbar machen. Zeig mal die Ausgabe von ip a hier als Vorformatierter Text damit wir sehen welche IPv6-Adressen der überhaupt von der Fritte bekommt.

[Eric_o_O]

Leider geht es mit der ULA Adresse auch nicht.
Danke für das schnelle Feedback, ja leider habe ich einen Highport bei IPv4 via CR und würde gerne meine Domains ohne diese Ports aufrufen mittels CNAME. (für einen NGINX Server)

[Eric_o_O]

Anbei der Auszug aus shell:

enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:a3:f5:a2 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.200/24 brd 192.168.178.255 scope global secondary enp2s0
valid_lft forever preferred_lft forever
inet6 fdba:448:495a:0:9e6b:ff:fea3:f5a2/64 scope global deprecated dynamic mngtmpaddr proto kernel_ra
valid_lft 6958sec preferred_lft 0sec
inet6 2a00:6020:4731:8e00:9e6b:ff:fea3:f5a2/64 scope global deprecated dynamic mngtmpaddr proto kernel_ra
valid_lft 3358sec preferred_lft 0sec
inet6 fe80::9e6b:ff:fea3:f5a2/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

[The_eagle]

Soweit ich das sehen kann ist bei dir Lokal aber ein DHCPv6-Server aktiv und der Server nutzt auch den DHCPv6-Client und kein SLAAC, was gut und richtig ist.

[Eric_o_O]

Ich muss ehrlich gestehen, dass ich ursprünglich mit der ULA angefangen habe, dann aber irgendwann etwas verzweifelt bin und heute Morgen aus lauter Frust die LLA kopiert und konfiguriert habe. (und dann war alles etwas durcheinander)

Das ist meine aktuelle Port Mapping table im CR.

[2a01:4f8:c014:956f::26dc:e989]:80 –> fdba:448:495a:0:9e6b:ff:fea3:f5a2:80

Im lokalen Netzwerk lässt sich die fdba:448:495a:0:9e6b:ff:fea3:f5a2:80 über den Browser öffnen

Kannst du dir vielleicht erklären, warum die IPv6 (GUA) nicht über den Cloud Router geroutet wird?
LG
ERIC

[The_eagle]

@Eric_o_O

Das ist meine aktuelle Port Mapping table im CR.

Ich verstehe nicht wie du da auf einen Port 80 als Quelle kommst!? Der CR Portmapper kennt doch nur Random Ports. srv06.vpn64.de:63540 2001:aaa:bbb:cccc:123:ff:fe11:2222:443

[Eric_o_O]

Nicht bei IPv6, deswegen kann mit damit sauber auf dem Port Routen auf dem man möchte. (zurück zum Thema Gründe die ich nicht alle ausführen wollte)

[The_eagle]

Zu wem gehört die 2a01:?

[Eric_o_O]

Das ist die öffentliche Adresse die automatisch vom CR erteilt wurde via “Manage Public IPs”

Diese verwende ich dann für das mapping:

(Bei IPv4 sind es dann solche Adressen wie aus deinem vorherigen Post)

[The_eagle]

Also bei mir klappt das auf Anhieb mit der GUA meiner Nextcloud. Eine ULA kann ich nicht testen, da ich lokal keine verwende. Ich kann aber grundsätzlich nur den srv08.vpn64.de auswählen und auch nur Random-Ports nutzen. Siehe:

Rufe ich nun aus dem Mobilfunknetz die Adresse https://srv08.vpn64.de:61728 lande ich in der zu erwartenden Sicherheitswarnung des FF. Die Domain passt nun ja nicht zum Let’s Encrypt Zertifikat. Siehe:

Das muss aber dann auch so sein.

[Eric_o_O]

Damit du dort auch eine IPv6 auswählen kannst, musst du dir vorher eine öffentlich IPv6 im CR erstellen:

1. Im CR findest du oben rechts einen Botton “Actions Cloud Router”
2. Dann “Manage Public IPs”
3. Darüber kannst du dir eine öffentliche IPv6 erzeugen lassen

4) Die IPv6 findest du dann im Port Mapping

[The_eagle]

Okay, mit dem Hinweis auf:

@Eric_o_O

“Manage Public IPs”

geht es bei mir nun auch mit GUA:443 → GUA:443. Die Firewall erlaubt bei mir aber eben standardmäßig sowieso den Zugriff auf die GUA:443 meiner NC über IPv6. Das wird bei dir anders sein und daher der Grund warum es bei dir nicht geht.

[The_eagle]

Ja, hatte ich bereits verstanden und umgesetzt. Das war mit dem

@The_eagle

Okay, mit dem Hinweis auf:

@Eric_o_O

“Manage Public IPs”

gemeint gewesen. Zu deinem Problem nun. Um die GUA zu nutzen musst du den passenden Port in deiner Firewall öffnen. Dann klappt es auch.

[Eric_o_O]

Bist du dir da sicher?
Ich befinde mich über den Tunnel ja schon im lokalen Netzwerk über den WG Tunnel des Cloud Router. (IPv4 funktioniert auch ohne irgendwelche Portfreigaben.)

GUA (public IPv64) → ULA (lokal IPv6) ist das Ziel über den Tunnel.

LG
ERIC

[The_eagle]

Ich sprech ja jetzt von der GUA. ULA’s hab ich nicht im LAN. GUA’s gehen übers WAN, es sei denn du routest explizit sämtlichen IPv6-Traffic über den Cloud Router.Dann muss der CR aber auch wissen wohin er was genau routen soll und darf dann seinerseits nicht denken, dass die GUA fürs WAN bestimmt ist.

@Eric_o_O

GUA (public IPv64) → ULA (lokal IPv6) ist das Ziel über den Tunnel.

Und ja, darum sagte ich ja bereits am Anfang du muss ULA’s nehmen und weder GUA’s noch die LLA’s