[Sammlung] Wireguard VPN von AVM ab FW 7.39

[PeterPawn]

Er importiert die von einer anderen Box erstellte Konfiguration für ein "Einzelgerät" in seine zweite Box und läßt sich dort (in diese importierte wg_config.conf) noch eine weitere Verbindung einbauen (ob als LAN-LAN-Verbindung zur ersten Box oder erneut nur als einzelnes Gerät, verstehe ich auch nicht so richtig - ich tippe anhand der gezeigten Konfiguration auf letzteres, wegen der beiden IP-Adressen in Address = 192.168.20.201/24,192.168.40.201/24) und erwartet dann, daß die dabei erzeugte wg_config.conf am Ende auf dem Gerät, welches als "road warrior" fungiert, für eine Verbindung zu BEIDEN FRITZ!Boxen tauglich wäre (so habe ich das jedenfalls verstanden).

Ein Szenario, was bei AVM so gar nicht geplant sein dürfte, wenn man sowohl in der Online-Hilfe (https://fritzhelp.avm.de/help/de/FRITZ-Box-7590/avm/021/hilfe_wireguard) als auch in den jeweils beim Import angezeigen Seiten liest und dabei auch das "Kleingedruckte" nicht ignoriert, was sich immer hinter dem kleinen i im blauen Kreis verbirgt - der läßt sich ja tatsächlich auch anklicken und offenbart dann zusätzlichen "Erklärtext". Ich finde in der (Online-)Hilfe jedenfalls bei keinem beschriebenen Szenario der Einrichtung für ein "Einzelgerät" irgendeinen Hinweis darauf, daß man bei der "Abarbeitung" der Anweisungen irgendwo eine (fremde) Konfigurationsdatei importieren soll (jedenfalls nicht auf der FRITZ!Box, max. die erzeugte Konfiguration auf dem Einzelgerät).

Da es bei WireGuard® nun mal keinen syntaktischen Unterschied zwischen einer Konfiguration für den "Server" (definieren wir das mal als einen Endpoint, hinter dem sich ein ganzes Netzwerksegment befindet) und der für einen "Client" (hier definieren wir mal ein einzelnes Gerät, was seinerseits die WireGuard®-Verbindung mit niemandem teilt bzw. in diesem Falle dann NAT auf die eigene (VPN-)Adresse machen würde) gibt, läßt sich halt auch die falsche Konfiguration bei diesem Vorgehen importieren ... einer importierten Konfiguration sieht man es im Interface-Abschnitt beim Parameter Address eben auch nicht mehr an, ob es sich um ein entferntes Netz oder nur um ein einzelnes Gerät handelt.

---

Was ich aber generell in der Online-Hilfe von AVM spannend finde ... nach den dort enthaltenen Texten:

Das Mobilgerät leitet zusätzlich alle IPv4-Internetanfragen über die VPN-Verbindung
an Ihre FRITZ!Box weiter. So können Sie in öffentlichen WLAN-Hotspots sensible Dienste wie E-Mail oder
Online-Banking genauso sicher nutzen, als wären Sie zuhause direkt per WLAN mit Ihrer
FRITZ!Box verbunden. IPv6-Internetanfragen werden nicht über die VPN-Verbindung geleitet.

bzw. auch

Der Computer leitet zusätzlich alle IPv4- Internetanfragen über die VPN-Verbindung
an Ihre FRITZ!Box weiter. So können Sie in öffentlichen WLAN-Hotspots sensible Dienste wie z. B. E-Mail
oder Online-Banking genauso sicher nutzen, als wären Sie zu Hause direkt per WLAN
mit Ihrer FRITZ!Box verbunden. IPv6-Internetanfragen werden nicht über die VPN-Verbindung geleitet.

(aus den beiden Hilfe-Seiten für die Verbindungen mit "Einzelgeräten")
unterstützt WireGuard® bei AVM gar keinen IPv6-Traffic INNERHALB des Tunnels.

Per se kann WireGuard® natürlich auch IPv6-Pakete per Tunnel durch die Gegend schicken ... nur bei der AVM-Implementierung dann doch nicht? Ich habe es noch nicht probiert ... aber wenn das stimmen sollte, was da in der Hilfe steht, muß man schon (sofern man wirklich sicher sein und auch keinen IPv6-Traffic in unsicheren Umgebungen "leaken" will) IPv6 deaktivieren auf seinem Client, wenn man eine vom FRITZ!OS generierte Konfiguration verwendet. Wobei mich auch mal interessieren würde (aber auch das nur theoretisch und ohne eigenen Antrieb, das jetzt GENAU auszutesten - ich wüßte ja noch nicht einmal, wie man das anstellen sollte), was die FRITZ!Box mit IPv6-Traffic anstellt, der dann doch (entgegen einer automatisch erstellten Konfiguration, denn das kann man ja auch "von Hand" nachbearbeiten) über den WireGuard®-Tunnel eintrifft. Der kann ja sowohl für lokale Ziele sein, als auch für "das Internet", wenn die Zieladresse auf der WAN-Seite der FRITZ!Box zu finden ist.

Da gäbe es ja mehrere Optionen, wie man reagieren kann ... von "unreachable" bis "administratively down" oder auch schlichtes Droppen der Pakete. Jedenfalls habe ich diese EXPLIZITE Aussage, daß IPv6-Traffic NICHT über die WireGuard®-Verbindung geroutet wird (und das verstehe ich so, daß es auch bei Wahl von Gesamten Netzwerkverkehr über die VPN-Verbindung senden dabei bleibt), so bisher auch noch nirgendwo gelesen ... oder zumindest keine Diskussionen mitbekommen, welche Konsequenzen das am Ende hat, wenn ein "Einzelgerät" dann doch beide IP-Adressierungen verwendet und ggf. sogar IPv6 präferiert wird (das läßt sich bei den meisten OS ja einstellen). Da kann man dann das "Verstecken" des eigenen Traffics (z.B. vor dem Betreiber eines unsicheren Hotspots) vergessen, wenn es um IPv6-Traffic geht.

 

[frank_m24]

unterstützt WireGuard® bei AVM gar keinen IPv6-Traffic INNERHALB des Tunnels.

Bezieht sich das auf jeden IPv6 Traffic, oder nur auf den "Internetverkehr"?

 

[eDonkey]

Jörg ..... (AVM)

8. Dez. 2022, 14:38 MEZ

Guten Tag Herr XXXXXX XXXXXXXXXX,

vielen Dank für Ihre Geduld.

Mir liegen jetzt neue Informationen vor. Demnach wird mit WireGuard VPN derzeit nur IPv4 getunnelt.

Ich habe Ihren Wunsch darüber auch IPv6 zu tunneln daher gern als Verbesserungsvorschlag an unser Produktmanagement weitergeleitet.

Bei der Weiterentwicklung unserer Produkte stehen die Wünsche und Bedürfnisse unserer Kunden stets im Mittelpunkt und wir konnten in der Vergangenheit bereits zahlreiche Verbesserungsvorschläge umsetzen.

Nachnamen des AVM Mitarbeiters entfernt by stoney

 

[PeterPawn]

Ich habe NICHTS getestet, bin nur beim (gründlicheren) Lesen der Online-Hilfe auf diesen Satz gestoßen. Vielleicht steht etwas in der Richtung auch schon in den Texten zu den jeweiligen Release-Versionen (also der info.txt), das weiß ich ebenfalls nicht, weil ich nicht zu denen gehöre, die solche Threads zu neuen Versionen anlegen.

Aber ich habe davon bisher noch NIRGENDWO gelesen und eigentlich würde ich erwarten, daß man beim Formatieren eines "Was ist neu?"-Textes zwangsläufig auch Kenntnis von dessen Inhalt nehmen müßte - also wird es VERMUTLICH dort nicht erwähnt sein. Und auch in der Online-Hilfe steht es nur an den zwei Stellen, die ich oben zitiert habe - damit gehe ich davon aus, daß bei einer LAN-LAN-Verbindung und auch bei der Anbindung an einen VPN-Service auch IPv6 getunnelt wird, wobei auch die Angaben in den Hilfe-Seiten das bei DIESEN Verbindungen nicht ausschließen.

Die Tatsache, daß die Maske keine Felder für die Eingabe von IPv6-Adressen enthält, muß ja noch nichts bedeuten ... IPv6-Adressen per SLAAC sind im LAN üblicherweise ohnehin "link-local" und bei einer ULA sagt ja schon der Sinn der Abkürzung (Unique Local Address), daß diese per Definition lokal ist. Aber das Senden von IPv6-Paketen an öffentliche Adressen über den Tunnel und die FRITZ!Box als Edge-Router, wäre ja durchaus denkbar (vorausgesetzt die Apps bzw. der Daemon Routing-Prozess auf den Peers unterstützen das), wenn man das mit dem "Gesamten Netzwerkverkehr ..." regelt - dann muß man keine weiteren IPv6-Adressen (lokal) kennen/verwenden.

Nur darf man bei einem solchen Szenario auch nicht übersehen, daß dafür das FRITZ!OS dann tatsächlich auch noch NAT6 "lernen" müßte ... denn die (IPv6-)Pakete, die über die WireGuard®-Verbindung bei ihm ankommen würden, trügen ja als Absender weiterhin die IPv6-Adresse des Peers (ohne IPv6-Adresse aktiviert der auch die Benutzung von IPv6 nicht, er MUSS also eine haben) und wenn die beim Adressaten dann ankommt, geht dessen Antwort naturgemäß auch wieder DIREKT an diese Adresse.

Die Alternative, wenn man IPv6 ebenfalls tunneln wollte, wäre die Konfiguration des Tunnels auch mit einer dedizierten IPv6-Adresse (für ein Einzelgerät) - nur ändert sich DIESE Adresse dann auch wieder, wenn ein neues IPv6-Präfix verwendet wird (die IPv4-Adresse ist wg. NAT ja "statisch" konfigurierbar) und das macht die Sache schon wieder komplizierter.

Und selbst bei LAN-LAN-Verbindungen bin ich mittlerweile nicht mehr sicher (bei Verbindungen zu einem VPN-Provider kommt es sicherlich auf die importierte Konfiguration an - eine andere Option hat man da bei der Einrichtung ohnehin nicht), denn da würde für eine "catch all"-Verbindung natürlich dasselbe gelten, was IPv6 und NAT anbelangt. Alternative wäre hier (vielleicht) noch ein DHCP-Proxy, der auch IPv6-Adressen aus einem entfernten Netz verteilen kann - nur ist das alles auch nichts mehr, was mit AVM's Konzept der "einfachen Bedienung" irgendwie vereinbar wäre.

---

Offenbar war man sich beim AVM-Support (siehe #383) ja auch eine Weile nicht darüber im Klaren, was nun mit IPv6-Paketen AUS DEM Tunnel passiert - das ist ja der Grund für meine "Frage" (es ist ja eher ein Vorschlag zum Testen) im letzten Absatz von #381.

Liest man ein wenig herum im Netz, soll ja für eine "IPv6 catch-all"-Verbindung bei AllowedIPs auch noch die Angabe einer IPv6-Adresse erforderlich sein (::/0), die sich in den von der FRITZ!Box erzeugten Konfigurationsdateien aber nicht finden läßt. Wenn das FRITZ!OS dann aber nicht auch für IPv6-Pakete eine NAT-Übersetzung der IP-Adresse (des Absenders) macht, nutzt es auch nichts, wenn man das von Hand selbst ändert ... außer man will Verbindungen, bei denen die "Request"-Pakete eines IP-Hosts einen anderen Weg nehmen, als die Antworten.

Nun ist das bei HTTP-Verbindungen per IPv6 auch nicht AUTOMATISCH ein Problem, denn heutzutage kommt dabei ja dann üblicherweise noch eine TLS-Verschlüsselung auf der Transport-Schicht (Layer 4) zum Einsatz - und neuere Protokolle ERZWINGEN dann sogar die Verwendung einer solchen. Aber andere Informationen, z.B. die per DNS gesuchten Domain-Namen, können dann immer noch "leaken", wenn diese Abfragen nicht ebenfalls über ein gesichertes Protokoll (wie DNS over TLS oder DNS over HTTP(S)) erfolgen und das gilt dann auch nicht nur für irgendwelche (Web-)Browser, die das inzwischen intern ja unterstützen mögen, sondern auch für alle anderen DNS-Abfragen ebenso, z.B. die des verwendeten OS auf dem Peer.

Wer also mit dem Smartphone (mit DS und (präferierter) IPv6-Adresse) irgendwelches Banking betreibt, der ist nicht automatisch in höchster Gefahr ... aber der aus den oben zitierten Hilfe-Seiten stammende Satz:

So können Sie in öffentlichen WLAN-Hotspots sensible Dienste wie E-Mail oder
Online-Banking genauso sicher nutzen, als wären Sie zuhause direkt per WLAN mit Ihrer
FRITZ!Box verbunden.

relativiert sich in so einem Kontext schon etwas, denn von einem prinzipiellen Unterschied zwischen einer IPv4- und einer IPv6-Verbindung wäre mir jetzt nichts bekannt.

 

[KunterBunter]

@eDonkey: Warum hast du "Guten Tag Herr XXXXXX XXXXXXXXXX," geschrieben?

 

[eDonkey]

@eDonkey: Warum hast du "Guten Tag Herr XXXXXX XXXXXXXXXX," geschrieben?

Das war eine, an mich persönlich gerichtete Antwort.
Meine Frage lautete:

Ich richte schon seit den Beta-Versionen mit IPSec (für die 7170) durch Import der manuell editierten Configs meine VPNs ein.
Habe mich mit der neuen Syntax beschäftig, soweit alles gut. Würde gern auch IPv6 über den Wireguard tunneln.
Das funktioniert unter Linux sehr gut, dazu benötige ich auf den Endpunkten allerdings virtuelle IPv6-Adressen. Leider gibt es ja (noch) keine Dokumentation für die Fritzbox, so wie sie für IPSec vorliegt.
Bin für jeden Hinweis dankbar.

 

[stoney]

Aber den vollständigen Namen des AVM Mitarbeiters veröffentlichst Du einfach so?

Hab da mal nachgebessert

 

[eDonkey]

Vollzitat gemäß Boardregeln entfernt by stoney

Ein Mitarbeiter vom Support von AVM, quasi jemand mit einem Job mit Bezug zu Öffentlichkeitsarbeit, sollte damit wohl eher kein Problem haben. Ansonsten wäre er fehl am Platz. Außer er wäre "stone(y)d"!

 

[stoney]

no comment - sry - da fehlen mir die Worte..... btt plz - es muss hier keine Grundsatzdiskussion entsehen - ist ja bereits "geregelt".

gn8

 

[buddsoup]

Wenn man sich das alles hier durchliest macht es da nicht Sinn auf die AVM Wireguard Anbindung ganz zu verzichten und sich lieber einen eigenen Wireguard Server (Raspi o.ä.) ins Netz zu hängen und das dann darüber zu machen?

Das Statement seitens AVM ist wirklich irreführend.

Weiterhin merkwürdig ist auch, dass die Fritz.Box (vgl. Screenshot) schreibt, dass er nicht den kompletten IPv4 Verkehr tunnelt, was sie aber mit der Standard-Schnell-Konfiguration doch macht, wenn man sich die erzeugte WG-Config Datei anschaut, oder liege ich da falsch?

 

[frank_m24]

Wenn man sich das alles hier durchliest macht es da nicht Sinn auf die AVM Wireguard Anbindung ganz zu verzichten und sich lieber einen eigenen Wireguard Server (Raspi o.ä.) ins Netz zu hängen und das dann darüber zu machen?

Kommt drauf an, was man machen will und ob die Performance der jeweils vorhandenen Fritzbox ausreicht.

Weiterhin merkwürdig ist auch, dass die Fritz.Box (vgl. Screenshot) schreibt, dass er nicht den kompletten IPv4 Verkehr tunnelt, was sie aber mit der Standard-Schnell-Konfiguration doch macht, wenn man sich die erzeugte WG-Config Datei anschaut, oder liege ich da falsch?

Da glaube ich auch an einen Bug, siehe weiter vorne im Thread. Das hatte ich schon beschrieben.

 

[buddsoup]

Da glaube ich auch an einen Bug, siehe weiter vorne im Thread. Das hatte ich schon beschrieben.

Ja - das wird es wohl irgendwie sein. Aber schon verdammt verwirrend der Part.

Kommt drauf an, was man machen will und ob die Performance der jeweils vorhandenen Fritzbox ausreicht.

Hier im Grunde nur sicherstellen, dass auch IPv6 über den Wireguard geht, wenn ich mit einem Client von extern aus zugreifen will. Finde das schon sehr krass, dass AVM das nicht wirklich ganz klar herausstellt, dass IPv6 Traffic "nicht" über den WG Tunnel geht.

 

[erik]

Ich nutze ja, außer bei meiner Bastel-7520, Wireguard mit openWRT und einem Raspberry. Da ich bei der Koppelung zweier Netze mit Masquerading keine Tonübertragung beim Telefon hatte, habe ich darauf verzichtet und stattdessen statische Routen im jeweiligen Hauptrouter gesetzt, was auch gut funktioniert und die Integration eines weiteren Netzes auch sehr einfach gemacht hat. Mein Tunnel wird über IPv6 aufgebaut, tunnelt aber nur IPv4-Traffic. Nach mehreren Wochen und Versuchen, auch IPv6 zu übertragen, habe ich das aufgegeben. Offenbar fehlen mir dafür die Grundlagen.

Ein Handy, welches sich am Wireguard anmeldet, erkennt, dass keine IPv6-Verbindung vorhanden ist und "sendet" nicht über IPv6 am Tunnel vorbei. Die Sicherheit scheint also nicht beeinträchtigt zu sein.

 

[frank_m24]

Also, ich kann verstehen, wenn man IPv6 pusht und vor allem in öffentlichen Netzen vorantreibt. Ich bin selbst glühender Verfechter davon. Aber für den Anwendungsfall des AVM VPNs macht IPv6 tatsächlich nur selten Sinn. Zum einen hat man bei IPv6 üblicherweise öffentliche IPs - die kann man im Zweifel direkt übers Internet adressieren (ok - Sicherheitsbedenken). Öffentliche IP-Adressen über ein VPN zu nutzen, macht hingegen wenig Sinn - dann hätte der VPN Client plötzlich 2 öffentliche Adressen. Geht zwar, erfordert aber Aufwand (bis hin zu policy based Routing). Denn seine eigene öffentliche IPv6 kann der VPN Client ja nicht fürs VPN nutzen - die wird ja über seinen Provider geroutet.

Und mal ehrlich: Wer zieht denn im LAN eine private IPv6 Adressierung neben einer IPv4 Adressierung durch? Das dürfte die absolute Ausnahme sein - und ein wirklicher Anwendungsfall fällt mir auch nicht dafür ein.

Bleibt für einen Roadwarrior Client der Zugriff ins Internet über die heimische Fritzbox. Das ist das einzige, was fehlen könnte. Aber das ist wieder nicht im Fokus der AVM Lösung, die ja dafür gedacht ist, Clients von außen den Zugriff ins Heimnetz zu gewähren - Internetzugriff haben die dann schon.

 

[Peter_Lehmann]

Hallo @buddsoup!

Ich teile voll und ganz deine in #390 gepostete Meinung. Nur dann nicht mit einem RasPi (habe ich vor drei Jahren auch mal probiert), sondern gleich mit in der Bucht billig zu bekommenden F!B 7412 oder 4040. Wer einmal ein "richtiges und vollwertiges" WireGuard unter OpenWrt konfiguriert und betrieben hat (bzw. eh umsteigen will), nimmt keinen RasPi und selbstverständlich auch keine (für ONU kastrierte) AVM-Version dazu.

vy 73 de Peter

 

[erik]

Die 4040 ist leider nicht ganz so billig zu bekommen Ansonsten würde ich zustimmen, kommt aber drauf an was man vorhat. Um einfach nur Zugriff aufs andere Netz zu bekommen, muß man keine zusätzlichen Stromverbraucher anschaffen, wenn die Fritzbox ein geeignetes VPN integriert hat.
Übrigens stört mich bei der aktuellen openWRT-Version, dass die Wlan-LED der 7412 (und der 7312) nicht mehr korrekt funktioniert. Aber das gehört hier ja nicht hin.

 

[Mariomaster]

Ich brauche eure Hilfe weil ich komme leider nicht weiter...

Ich habe eine Wireguard Verbindung erstellt und über entfernte Fritzbox kompletten traffic "umgeleitet" weil ich über ausländische IP surfen möchte. Es funktioniert ohne Probleme nun leider meine Festnetznumer von o2 muss lokal angemeldet seiin. Wie kann ich VOIP von VPN ausschliessen? o2 lässt Zugriff auf "sip.alice-voip.de" nur aus dem eigenen Netz zu. Eigentlich sind nur zwei Geräte freigegeben (192.168.1.13, 192.168.1.14) die den kompletten Traffic umleiten aber VOIP versucht sich auch über entfernte Fritzbox anzumelden.

                enabled = yes;
                editable = yes;
                use_ikev2 = no;
                conn_type = conntype_wg;
                name = "Wireguard_Ausland";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = ::;
                remoteip = ::;
                local_virtualip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 0.0.0.0;
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip any 0.0.0.0 0.0.0.0";
                allowed_vpn_clients {
                        ipaddr = 192.168.1.13;
                        mask = 255.255.255.255;
                } {
                        ipaddr = 192.168.1.14;
                        mask = 255.255.255.255;
                }
                landevice_uids = "landevice9861", "landevice1407";
                app_id = 0;
                wg_public_key = "XXXXX";
                wg_preshared_key = "YYYYY";
                wg_allowed_ips = "192.168.2.0/24",
                                 "0.0.0.0/0";
                wg_persistent_keepalive = 25;
                wg_dnsserver = "192.168.2.1";
                wg_dyndns = "aaaaaaa.myfritz.net";
                wg_slave_network = 0.0.0.0;
                wg_slave_mask = 0.0.0.0;
                wg_hide_network = no;
                wg_fulltunnel = yes;
                wg_configured = yes;

[CODE] TAG [/CODE] gesetzt by stoney

 

[PeterPawn]

Der Tunnel läßt sich auf bestimmte Clients im LAN beschränken. Wenn dabei dennoch Daten von anderen Clients durch den Tunnel gehen, ist das ein Software-Problem bei AVM, was behoben werden muß.

 

[frank_m24]

Der Tunnel läßt sich auf bestimmte Clients im LAN beschränken.

Das funktioniert für eingehende VPN Verbindungen, aber nicht für ausgehende, oder? Die Diskussion hatten wir kürzlich schon: Die Kombination, "gesamten Traffic über VPN leiten" und "Einschränken auf bestimmte Geräte" funktioniert nicht zusammen.

 

[PeterPawn]

Soweit ich das sehe, sind beide Optionen im GUI unabhängig voneinander auswählbar - das ist dann für mich ein offenes Problem in der Firmware, solange das bei AVM nicht entsprechend dokumentiert ist und ich kann mich (obwohl ich das mittlerweile alles recht gründlich gelesen habe, s. IPv6 im Tunnel) nicht an etwas in dieser Richtung erinnern.

Allerdings bin ich auch noch beim (gründlichen) Testen und dort noch nicht angekommen. Im Moment versuche ich noch, die vielen verschiedenen Fälle beim Einrichten zu verstehen (und zu dokumentieren mit den Ergebnissen im Hintergrund) - aber das ist ein anderer Thread.