Hallo yuzu,
ich nutze Wireguard von FREETZ zwar nicht, experimentiere hier aber mit der AVM-Lösung von Wireguard auf einer (zugegebenenmaßen unveränderten) 7590 mit der offiziellen Original-50-ger Firmware, die es seit Dezember gibt. Ich kannte Wireguard bis dato gar nicht und musste tatsächlich viel darüber über "learning by doing" lernen. Wenn man früher "die alte" VPN-Lösung von AVM benutzt hat oder gar noch aus der Welt von OpenVPN kommt, muss man sich an vielen Stellen gedanklich "umorientieren" bzw. "umdenken". Denn Wireguard ist an einigen Stellen vom Gedankeneinsatz her anders ausgelegt, als die anderen (nennen wir die mal "klassische") VPN-Lösungen.
Hier ein Paar von meinen Erfahrungen damit, die zwar aus der AVM-Umsetzung von Wireguard stammen, allerdings auch zum Teil allgemeiner Natur sind und daher für dich von Interesse sein könnten:
1. Wireguard behauptet zwar von sich selbst "einfacher" und "schlanker" zu sein, als die herkömmlichen VPN-Lösungen, das kommt aber oft auf Kosten der "idiotensicherheit" dieser Lösung, wenn man sie mit anderen VPN-Lösungen vergleicht. Meine Erfahrung damit ist, dass man zwar vermutlich mit Wireguard viel schneller zu so einem "stehenden Tunnel" kommt, aber das Ganze "rumherum" mit dem Routing, Stabilität der Verbindung, dem Handling usw. gestaltet sich dafür viel schwieriger, wie du es ja auch selbst siehst. Und da muss man viel mehr aufpassen, dass man da an der Stelle keine Fehler macht. Wenn es bei OpenVPN dazu schon gute und erprobte Lösungen im Netz leicht zu finden sind, sieht es bei Wireguard damit derzeit noch nicht so aus
2. Ich hatte mit dem AVM-Wireguard mal "geschafft", das komplette DNS der Box lahm zu legen, dass es mit der Box gar nichts mehr ging, sobald eine Wireguard-Verbindung vom Client zur Box aufgebaut wurde. Das nennt sich beim AVM-Assistenten als "das gesamte Verkehr vom Client über VPN leiten" oder ähnlich. Seitdem klicke ich diesen Punkt beim Erstellen der Konfiguration mit dem AVM-Assistenten gar nicht mehr an. Das war meine "Lernkurve" dabei und ist meine logische Konsequenz dazu gewesen. Welche Config da Box-seitig von AVM dazu erstellt wird, weiß ich nicht genau. Bzw. kann man es mit Original-Firmware nur schlecht nachvollziehen, was da alles dazu im Hintergrund passiert und warum so ein falsch konfigurierter Wireguard-Client das komplette DNS der Box lahm legen kann. Das spricht aber nicht gerade für eine gute "Idiotensicherheit" der Lösung
3. Wireguard-Client für Windows ist gerade eine Katastrophe, wenn sich das jemand bereits angeschaut hat. Ich habe zwar mit Ach, Krach und viel Lesen im Internet es endlich geschafft, dass man so ein Tunnel als Normaluser (nicht Admin!) bequem starten und stoppen kann und es auch angezeigt bekommt, es ist aber keine Stadard-Lösung von Wireguard selbst, sondern ist mit viel rumbastelei cmd-Aufrufen, Drittanbieter-App usw. verbunden. Wenn Interesse besteht, könnte ich es hier posten, wäre aber für IPPF eigentlich offtopic
4. Wireguard ist vom Konzept her nicht idiotensicher gegen konkurrenter Verbindungen. Musste ich auch erstmal lernen. Als durch meine Experimente mit dem Windows-Client eine Wireguard-Verbindung aufgebaut war und im Hintergrund weiter lief, ohne, dass ich es bemerkt hatte, hatte ich eine zweite Verbinung PARALLEL von einem RaspberryPi-Client zur gleichen Box aufgebaut und mich über die ständigen Abbrüche der Verbindung gewundert. Bis ich rein zufällig darüber irgendwo im Netz was gelesen hatte: Ja, das ist eine Konzept-Macke von Wirguard. Wenn man von zwei Clients gleichzeitig eine Verbindung zum gleiche Server aufbaut und typischerweise in der Config eine "keepalive"-Einstellung von etwa 30 Sekunden hat, führt es dann dazu, dass die beiden Clients sich alle 30 Sekunden die Verbindung gegenseitig "klauen". Und ja, es wird leider weder von Clients noch vom Server erkannt. Muss man also selbst dafür sorgen, dass es nicht passiert
5. Das Thema MTU ist bei Wireguard auch noch nicht abschließend gelöst. Wenn man im Internet danach sucht, findet man ganze Studien dazu, wie man mit den MTU-Parametern an beiden Seiten rumgespielt hat, um die beste Übertragungsrate im Tunnel zu bekommen. Wenn man einer der Quellen glaubt, wäre die optimale Einstellung, wenn die Werte im Server und Client leicht unterschiedlich sind und nicht, wie sie per default da auf gleichem Wert stehen. Dieses Thema würde ich aber eher in die Ecke "Optimierungen" verlagern, wenn alles andere bereits läuft. So meine praktische Erfahrung damit
6. AVM hat eine eigenartige Art damit, die IP-Adressen bei den VPN Clients zu vergeben. Und zwar, wenn die Box als Beispiel interne IPV4-Adressen aus dem Bereich 192.168.178.xxx hat, dann kriegen die Tunnels und die verbundenen Clients dann z.B. Adressen der Art 192.168.178.201 usw. Liegt irgendwo am Ende des IP-Bereiches und ist vermutlich irgendwie lösbar, wenn AVM es tut, aber in meinen Augen sehr unschön. Bei OpenVPN hatte man dafür einen extra Bereich von z.B. 10.0.0.x oder ähnlich genommen und somit es IP-technisch als Tunnel gelöst. So wird es auch in den Beispielen zu Wireguard im Netz empfohlen. Die Lösung von AVM mit den Adressen der Art 192.168.178.201 hat einige Schwierigkeiten in der Umsetzung vom Routing, wenn man das 178-Netz sowohl als Client-Netz, aber gleichzeitig als Tunnel-Netz nutzen muss. Es scheint zwar trotzdem irgendwie zu funktionieren, gut ist es aber in meinen Augen nicht
7. wg0 beim client als default-Route setzen. Solche Experimente hatte ich bei mir auch auf meinem RaspberryPi Client gemacht, weil ich darüber auch was im Netz gelesen hatte. Meine Erfahrung damit: Finger Weg davon, wenn man es ohne Bedacht macht. Der Client braucht meistens seine default-Route, um die Verbindung zum Server aufzubauen. Wenn man sie ihm dadurch weg nimmt, muss man routing-technisch dafür separat sorgen, dass der Client den Server "findet". Das sind dann sehr unschöne Lösungen, wo man die IP-des Servers in die Routing-Tabelle eintragen muss. Bei dynamischen IPs ist es keine gute Lösung. Man kann damit vielleicht "rumspielen", um etwas temporär zu erreichen, ich würde es aber nicht als eine dauerhafte Lösung ansehen
Und jetzt noch eine konkrete Frage an dich
@yuzu : Bist du denn inzwischen weiter gekommen? Was sind denn deine konkreten Probleme mit dem Wireguard? Was funktioniert und was funtioniert nicht? Aus deinem kurzen Posting konnte ich es leider nur zum Teil nachvollziehen.
