Der Eifelsachse
New member
Hallo Freunde!
Zuerst eine zugegebenermaßen etwas längere Einleitung, welche ich aber als erforderlich betrachte.
Ich betreibe seit 2019 ein, für rein private Nutzung schon etwas größeres WireGuard-Netz, bestehend aus neun aktiven in drei Ländern stationierten WG-Routern. Als Hardware nutze ich sowohl den Cudy WR3000E v1, aber auch F!B 4040 und 7412. Insgesamt sind es, einschließlich der an den entferntesten Punkten zusätzlich stationierten (voll geklonten) Reserverouter 15 derartige Geräte.
Das Betriebssystem ist selbstverständlich OpenWrt in der ggw. aktuellsten Version 25.12.3 und als DDNS-Provider wird mit sehr großer Zufriedenheit dynv6.com genutzt. Alle 9 aktiven WG-Router und die dazugehörenden Internetrouter sind alle auf einem dortigen Konto eingerichtet.
Ich lege großen Wert auf durchgehende Dualstack-Fähigkeit, schon deshalb, weil ich davon überzeugt bin, dass IPv6 das bessere Protokoll ist. Der DDNS-Provider löst mir für jedes der Geräte sauber und ordentlich den (erklärenden) Namen in seine IPv6 und IPv4 auf - wobei in der Regel fast immer die IPv6 genutzt wird. Und die Nutzer der jeweiligen Heimnetze können auch alle ihre aushäusig genutzten Geräte wie Smartphones und Laptops direkt mit ihrem (oder bei Bedarf auch meinem) Hausnetz verbinden.
Dieses ganze Konstrukt hat sich alle die Jahre sehr gut bewährt und läuft und läuft und läuft (wie mal zum Auto einer bekannten dt. Marke gesagt wurde).
Mein "Problerm":
Ich nutze von Anfang an für die internen Tunnel je Verbindung eine IPv4 (aus einem sonst nicht genutzten Netzbereich des jeweiligen Heimnetzes bspw. 192.168.20.0) und eine durch ULA bereitgestellte IPv6, bspw. fd00:: .
Jetzt stellte ich zur Zufall (beim Betrachten des Logfileviewers des internen DDNS-Clients) fest, dass ab und an (nicht immer!) versucht wird, eben jene ULA an Stelle der "offiziellen" IPv6 (200: ) an den DDNS-Provider zu melden - was selbstverständlich fehlschlägt. Der DDNS-Client nimmt also die falsche, nicht routingfähige IPv6.
Das sieht dann im Log so aus:
Betrieblich ist diese Störung nicht zu bemerken. Schlimmstenfalls wird mal kurzzeitig IPv4 genutzt, aber meistens bleibt es trotzdem bei IPv6. Und irgendwann erkennt der Client wieder die richtige IPv6.
Ich habe die Einstellungen des DDNS-Clients schon x-mal überprüft (kann sie bei Bedarf, wenn mir jemand helfen möchte, gern auch posten). Und ja, ich schließe einen Level 8-Fehler auch keinesfalls aus.
Und nun bitte ich die echten Wissensträger um Unterstützung.
Freundlicher Grüße aus der Eifel!
Zuerst eine zugegebenermaßen etwas längere Einleitung, welche ich aber als erforderlich betrachte.
Ich betreibe seit 2019 ein, für rein private Nutzung schon etwas größeres WireGuard-Netz, bestehend aus neun aktiven in drei Ländern stationierten WG-Routern. Als Hardware nutze ich sowohl den Cudy WR3000E v1, aber auch F!B 4040 und 7412. Insgesamt sind es, einschließlich der an den entferntesten Punkten zusätzlich stationierten (voll geklonten) Reserverouter 15 derartige Geräte.
Das Betriebssystem ist selbstverständlich OpenWrt in der ggw. aktuellsten Version 25.12.3 und als DDNS-Provider wird mit sehr großer Zufriedenheit dynv6.com genutzt. Alle 9 aktiven WG-Router und die dazugehörenden Internetrouter sind alle auf einem dortigen Konto eingerichtet.
Ich lege großen Wert auf durchgehende Dualstack-Fähigkeit, schon deshalb, weil ich davon überzeugt bin, dass IPv6 das bessere Protokoll ist. Der DDNS-Provider löst mir für jedes der Geräte sauber und ordentlich den (erklärenden) Namen in seine IPv6 und IPv4 auf - wobei in der Regel fast immer die IPv6 genutzt wird. Und die Nutzer der jeweiligen Heimnetze können auch alle ihre aushäusig genutzten Geräte wie Smartphones und Laptops direkt mit ihrem (oder bei Bedarf auch meinem) Hausnetz verbinden.
Dieses ganze Konstrukt hat sich alle die Jahre sehr gut bewährt und läuft und läuft und läuft (wie mal zum Auto einer bekannten dt. Marke gesagt wurde).
Mein "Problerm":
Ich nutze von Anfang an für die internen Tunnel je Verbindung eine IPv4 (aus einem sonst nicht genutzten Netzbereich des jeweiligen Heimnetzes bspw. 192.168.20.0) und eine durch ULA bereitgestellte IPv6, bspw. fd00:: .
Jetzt stellte ich zur Zufall (beim Betrachten des Logfileviewers des internen DDNS-Clients) fest, dass ab und an (nicht immer!) versucht wird, eben jene ULA an Stelle der "offiziellen" IPv6 (200: ) an den DDNS-Provider zu melden - was selbstverständlich fehlschlägt. Der DDNS-Client nimmt also die falsche, nicht routingfähige IPv6.
Das sieht dann im Log so aus:
Code:
161054 : Update needed - L: 'fd00:0000:0000:0000:82af:caff:fe82:18fb' <> R: '2001:09e8:4581:7000:82af:caff:fe82:18fb'
161054 ERROR : No or private or invalid IP 'fd00:0000:0000:0000:82af:caff:fe82:18fb' given! Please check your configuration
161054 ERROR : No update send to DDNS Provider
161054 : Waiting 600 seconds (Check Interval); Next check at 2026-05-08 16:20Ich habe die Einstellungen des DDNS-Clients schon x-mal überprüft (kann sie bei Bedarf, wenn mir jemand helfen möchte, gern auch posten). Und ja, ich schließe einen Level 8-Fehler auch keinesfalls aus.
Und nun bitte ich die echten Wissensträger um Unterstützung.
Freundlicher Grüße aus der Eifel!
