Ich habe folgende Konfiguration am Laufen bei ip64.net:
Deutsche Giganetz CGNAT IPv6 only.
Fritz!Box mit DynDNS Update (IPv6 Adresse + zusätzlich Prefix) bei ipv64.net.
CDN Full Proxy mit Portmapper für Wireguard auf der Fritz!Box.
Das Ganze funktioniert soweit auch wie es soll. Das Problem tritt auf, wenn meine Fritz!Box zwischen 3:00 und 4:00 Uhr morgens die IP-Verbindung trennt, um der Zwangstrennung durch die Giganetz zuvorzukommen. Danach funktioniert in 90% der Fälle die Wireguard Verbindung nicht mehr, der Client auf dem Smartphone bekommt keine Verbindung.
Was ich sehen kann: die neue IPv6 Adresse ist richtig im DynDNS angekommen. Auch im CDN steht die neue IPv6 Adresse richtig drin. Scheinbar bekommt die Proxy Software die Adressänderung nicht mit und eine Wireguard Verbindung ist nicht möglich. Als Abhilfe kann man im CDN den Proxy ausschalten und wenn die Änderung von IPv64 in der GUI bestätigt ist wieder einschalten. Danach funktioniert das Wireguard wieder bis zur nächsten morgendlichen Trennung. Und das Spiel beginnt von vorne.
Liegt da bei ipv64.net ein Problem vor oder habe ich da irgendwas übersehen?
Schade. Aber ich habe Deinen Tipp umgesetzt und den Cloud Router eingerichtet. Funktioniert auch. Ergänzend zu der Anleitung auf Youtube habe ich auch IPv6 Anfragen konfiguriert, so dass das Smartphone auch über IPv6 mit den Hosts in meinem Netzwerk/Homelab sprechen kann. Habe ich auch hinbekommen. Wäre aber schön wenn die komplette Anleitung zum Einrichten auch auf der Webseite verfügbar wäre.
Das aber macht doch nur dann Sinn, wenn du keine IPv6 Global Unique Addressen (GUA) verwendest. Bei GUA’s ändert sich doch nach jeder Zwangstrennung der IPv6-Prefix und das Routing passt nicht mehr.
Interessant. Ich nutze keine Fritte, sondern eine pfsense und da ist die gleichzeitige Verwendung einer ULA und GUA nicht vorgesehen. Es gibt neben GUA’s dann nur noch LLA’s und gelten bekanntlich nur für das jeweilige Netzwerksegment.
Hab das grad mal gegoogelt und einen Beitrag im Web gefunden, dessen Autor es über Umwege hinbekommen hat ULA und GUA gleichzeitig zu nutzen. Aber den Nutzen für mich kann ich nicht erkennen, denn die Server in der DMZ sind ja per FQDN → GUA ohnehin direkt aus dem WAN erreichbar. Wozu also der Umweg über den Cloud Router!?
Den Cloud Router habe ich ja nur verwendet weil das CDN Update nach Zwangstrennung nicht ordentlich funktioniert. Ich benutze den Router nur für das VPN und habe keine Hosts nach außen. Und alles nur wg. CGNAT und IPv6 only von meinem Glasfaseranschluß. Und in meinem Fall ist das mit dem ULA praktisch. Wenn die Fritte so was schon anbietet kann ich meine Geräte die IPv6 können eben auch über VPN/IPv6 ansprechen. Ist eben ein nice-to-have.
Jetzt habe ich nur das Problem, dass alle paar Minuten die Fritte die S2S Verbindung zum Cloud Router verliert und wieder neu aufbaut. Ich habe aber das Keep-Alive auf 2 Minuten, sollte also eigentlich nicht passieren. Ob das jetzt an der Fritz!Box oder am Cloud Router liegt kann ich noch nicht sagen. Meine Fritzbox hat Firmware 8.20. Da ist aber noch eine Labor Version in Arbeit auf vermutlich 8.24. Da haben sie wohl noch ein paar Bugs gefunden. Mal sehen ob das beim Wireguard was ändert.
Ich meine mich zu erinnern, dass Dennis im Video zur Fritte und Cloud Router etwas zum Keep-Alive sagt. Sieh es dir nochmal an. Bei meiner sense ist kein Keep-Alive erforderlich. Die Verbindung steht dennoch.
Dennis hat 15 Sekunden bei der Fritz WG Conf angegeben. Ich fand das aber ein bisschen zu kurz und habe das auf 2 Minuten gesetzt. Das führte aber zu den ständigen Tunnel Trennungen. Ich habe das dann mal ohne den Keep Alive Parameter probiert, dann baut die Fritzbox aber den Tunnel nicht auf. Nach Recherchen im Internet habe ich entdeckt, dass die Fritzbox wohl immer einen Keepalive von 25 Sekunden macht. Also habe ich den Paramter mal auf 25 Sekunden gesetzt und die Wireguard Verbindung in der Fritzbox neu importiert. Das scheint jetzt zu funktionieren, der Tunnel steht seit 30 Minuten ohne Unterbrechung. Ich lasse das mal so und beobachte weiter.
was ich gemacht hatte als ich eine Fritzbox hatte ist folgendes
ich habe sie bei Myfritz angemeldet und habe diese URL in ein Skript gepackt und habe diese dann mit dig ausgelesen, anschließend gespeichert und damit die URL in ipv64 angepasst.
Deine Lösung bezieht sich doch aber auf das DynDNS, richtig? Das war aber nie ein Problem, das hat immer funktioniert. Auch beim CDN stand immer richtig die neue IP drin. Aber irgendwie wurde das CDN damit dann nicht aktualisiert.
Korrekt, allerdings musste ich das leider so umsetzen weil das Update teilweise von der Fritzbox durchgefürht wurde aber nie die VPN wieder verbunden hat. Erst als das so umgebaut hatte funktionierte das