Problem mit einer Fritz 6490 Cable

Hallo,

Ja, wird funktionieren (je nach was du konfigurierst bzw. in welcher Fritte du welche Einstellungen vornimmst). Die 6490 braucht nur ne IP für dein VOIP und deine TK am So Port. Kein LAN, kein WLAN, kein VPN usw., also alles weitestgehend Deaktivieren. Ob sich der Stromverbrauch trotzdem rechnet, wissen wir nicht

Gruss,
Peter

Nein, nicht wenn du einen einfachen Jumphost benutzt mit der bestehenden 6490.
Damit rennt das völlig problemlos.
Nur zur Theorie:
Eine kaskadierte 6670 oder 6690 davor wird dir das VPN Problem bei CG-NAT deshalb NICHT lösen können, weil es generell technisch nicht möglich ist per IPv4 von außen auf einen DS-Lite oder CG-NAT Anschluss zuzugreifen. Egal welches (VPN) Protokoll.
Per IPv6 klappt das natürlich, erzwingt dann aber auch gleichzeitig das der Client sich in einem IPv6 fähigen Netz befinden muss was leider nicht immer gegeben ist.
Aus VPN Sicht in einem CG-NAT Szenario also mehr oder minder rausgeschmissenes Geld mit einer Router Kaskade die das eigentliche Problem in so einem Fall nicht lösen kann.
Letztendlich aber nicht das Problem bei dir, da du selbst ja keinen CG-NAT Anschluss hast mit der 6490.

Du redest ja davon das NUR der Client (VPN Initiator) an einem CG-NAT Anschluss hängt. Sprich also deine eigene 6490 der VPN Server (VPN Responder) ist und der explizit eine öffentliche v4 WAN IP hat.
Wenn das der Fall ist und deine 6490 von Vodkafön eine öffentliche IPv4 Adresse am Internet Port bekommt, dann hast du keinerlei Probleme und kannst das IPsec VPN mit dem CG-NAT Client problemlos weiternutzen.
Das obige Jumphost Szeanrio gilt ausschliesslich nur dann, wenn deine Fritte, also der VPN Responder (Server), an einem CG-NAT Provider hängt was ja (vermutlich) bei dir nicht der Fall ist?!
Auch hier ist in dem Falle dann eine Kaskade überflüssig!

Immer gerne... 😊
OK, zeigt das die Konfig und Erreichbarkeit der Fritte dann grundsätzlich OK ist.
Das bedeutet dann primär erstmal keinen Fehler des VPNs an sich. Die Fehlermeldung besagt das der Tunnelaufbau schon pe se daran scheitert das die IP Adresse (77.21.xxx.xxx) der 6590er Fritte schon gar nicht erreichbar ist von diesem Anschluss aus.
Hast du mal versuch die 77.21.xxx.xxx direkt zu pingen von der Location? Wenn das schon scheitert hast du erstmal ein generelles IP Connectivity Problem zwischen den beiden Providern. Zugegeben wäre das sehr selten.
Es gibt aber 2 Gründe warum es dennoch scheitert.

• Löst du das Ziel zu deiner 6590 Fritzbox über einen DDNS Hostnamen (myFritz etc.) auf oder direkt über die IP? Prüfe auf dem Client immer vorab mit nslookup <ddns_name> ob der Name auf die aktuell deiner Vodafone Fritte vergebenen IP WAN Adresse aufgelöst wird. Bei DDNS ist oftmals ein Zeitfenster zw. dem Update und der realen IP. Stimmt der aufgelöste Hostname nicht mit der aktuellen IP überein scheitert logischerweise der VPN Tunnelaufbau mit der o.a. Fehlermeldung. Bei Verwendung der nackten IP als Zieladresse entfällt diese Problematik natürlich.
• Die IPsec IKEv1 Verbindung muss auf der DS-Lite Seite mit aktivem NAT-T (NAT Traversal, UDP 4500) initiiert werden weil sie eben durch ein CG-NAT Gateway eines solchen Providers muss. Normalerweise machen IKEv1 Clients (Initiators) das automatisch bei einigen muss es aber explizit angehakt sein. Das solltest du im Shrew und seinem VPN Setup nochmal genau überprüfen.
• Es kann sein das im Router oder Firewall auf der CG-NAT Client Seite einmal versucht wurde ein IPsec VPN zu konfigurieren und Reste einer solchen Konfig vorhanden sind. Das ist dann in sofern fatal als das so ein Router dann keinen IPsec Traffic mehr an den dahinterliegenden Client forwardet was dann in einem solchen Fehlerbild mündet. Hier ist es also wichtig alle solche ggf. vorhandenen IPsec Reste aus der Konfig zu entfernen und auch User die z.B. darauf bezogen sind wie z.B. bei einer Fritzbox. Letztere hat auch eine Paket Sniffer Funktion wo man sehen kann ob überhaupt IKE Traffic UDP 500 oder NAT Traversal UDP 4500 von der Server Fritzbox, deiner 6590, zurückkommt. Alternativ kann man das auch mit einem Wireshark Trace sehr einfach direkt am Client sehen! Dort lohnt also einmal so einen Trace zu ziehen. Glücklicherweise hast du ja immer die Option das an einem funktionierenden Anschluss zu testen.
• Eine sinnvolle Test Alternative ist hier auch immer mit deinem Test PC über einen Smartphone Hotspot ins Internet zu gehen. Aus dem Mobilfunknetz wird in der Regel bei IPv4 auch immer über ein CG-NAT Gateway gearbeitet. Wenn du dort mit dem Shrew eine Verbindung aufbauen kann liegt der Fehler dann auch de facto nicht am NAT Traversal oder NAT generell. Dieser Test ist also sehr hilfreich fürs Troubleshooting um die Client Situation zu simulieren.
• Möglich wäre (wenn der Smartphone Hotspot Test klappen sollte) auch das an dem DS-Lite Anschluss der dortige Provider IPsec VPN Traffic generell blockiert und das nur teuren Business Traifen vorenthält. Das ist aber eher die seltene Ausnahme. Dennoch sollte man das über die Provider Hotline zur Sicherheit abklären. Das gilt natürlich auch ggf. für lokale Firewall Einträge die UDP 500 und 4500 blocken. Der o.a. "Smartphone Check" umgeht auch sowas.

Das hat nichts mit einer "Freigabe" zu tun. Funktionieren tut der Client dort auch.
Die bordeigenen VPN Clients von Windows 10 und 11 supporten ausschliesslich nur noch IKEv2 VPNs was die Fritzbox nicht supportet.
Ein IKEv1 VPN supporten die Windows VPN Clients ausschliesslich nur noch in der Kombination mit L2TP nicht aber nativ. L2TP support die Fritte ebenfalls nicht.
Du benötigst für die Fritte also immer einen nativen IKEv1 Client wie den Shrew.

Wenn du dich aus der Fritten Falle befreien willst dann musst du in Kaskade dahinter einen VPN Server platzieren der diese bordeigenen (und auch fremde) VPN Protokolle in allen Betriebssystemen und Endgeräten supportet.
Viele Beispiele für solche Lösungen findest du hier im Forum:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
L2TP VPN Server mit preiswertem Mikrotik Router
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Wenn du dennoch an Wireguard festhalten willst reicht es einen einfachen Wireguard Router wie einen Mikrotik oder eine der o.g. Firewalls hinter der Fritte zu kaskadieren. Eine Fritte für Wireguard zu kaskadieren ist keine gute Idee wenn man flexibel agieren will, da die WG Implementation von AVM proprietär ist und nicht dem WG Standard entspricht was bei klassischen WG Equipment immer einige Klimmzüge erfordert. Manches ist auch schlicht nicht supportet bzw. durch Konfig Vorgaben limitiert.
Diese negativen Punkte solltest du bei der Anschaffung von Hardware dafür auf dem Radar haben.
Bedenke auch das nur ein anderes VPN Protokoll ein evtl. vorhandenes IP Connectivity Problem auf die lokale 77.21.xxx.xxx IP nicht lösen wird. Das solltest du also nochmal genau prüfen. (Ping, Traceroute etc.)

Die o.a. Firewalls supporten dies alles parallel. Damit würdest du quasi einen universellen VPN Server realisieren können der so gut wie alles, nämlich alle so oder so überall vorhandenen bordeigenen VPN Clients supportet und gleichzeitig auch WG oder das antike OpenVPN.
Alle Details dazu, wie immer, im hiesigen Wireguard Tutorial.