[Sammlung] Wireguard VPN von AVM ab FW 7.39

[Stukas]

Darf dir die Datei von protonvpn privat mal zu kommen lassen!

 

[erik]

Darfst Du, ich bin aber selber erst beim Erkunden der Eigenheiten beim Fritzbox-Wireguard. Wie man z.B. den kompletten Traffic durch den Tunnel bekommt, was bei Dir ja nötig wäre, habe ich auch noch nicht herausgefunden.

 

[Stukas]

ok bin auch nicht weiter habe sogar die CFG Sicherung bearbeitet aber ohne Erfolg.
Das stimmt hinten und vorne nicht. oder?

So habe es in Bild 2 hinbekommen, baut aber keine Verbindung auf nach japan


Also er ist verbunden, aber Mann Mus die Software auf jedem Geräte installieren, was etwas schwachsinnig ist in meine Augen.

Da kann ich gleich die Proton-VPN App nutzen, die besser funktioniert, weil über WireGuard Fritz!Box und PC geht entweder TS3 nicht oder der Browser geht nicht. Mann kann nur 1 eins verwenden von den zwei Programmen (alsbeispiel).

 

[vusolo2]

Hallo ich versuche seit längerem zwei Fritzboxen miteinander zu verbinden über Wireguard. Es funktioniert aber bei mir nur in eine Richtung. Wenn ich von der Fritzbox im Deutschen Glasfaser Netz auf die andere Fritzbox zugreifen will funktioniert alles wie es soll, aber wenn ich von der anderen Fritzbox aus dem Netz von NetAachen zugreifen will dann habe ich kein zugriff aber der ping geht. Gibt es bei Wireguard noch spezifische Probleme mit Unterschiedlichen Netzanbieter? Ahja wenn ich danach noch ein zusätzliche Verbindung für mein Handy erstelle und mich Verbinde habe ich vom Handy auf beide Netzwerke Zugriff. Ipsec funktioniert ohne Probleme als ersatz, aber würde gerne auf Wireguard umsteigen.

 

[Benares]

Mit "funktioniert nicht" meinst du da den Aufbau des VPN-Tunnels oder die Kommunikation hinterher?
Beim Anschluss der Deutschen Glasfaser dürftest du keine öffentlich erreichbare IPv4 haben (CG-Nat), daher geht es wohl nur umgekehrt. Aber mit IPv6 sollte es klappen.

 

[frank_m24]

dann habe ich kein zugriff aber der ping geht

Der Ping geht auf alle Geräte? Dann ist der VPN Tunnel raus, und Firewalls oder ähnliches spielen dir einen Streich.

 

[vusolo2]

Vom NetAachen Netz kann ich das Deutsche Glasfaser Netz anpingen aber wenn ich im Browser auf die Frtiz Box zugreifen will geht das nicht . Umgekehrt von Deutsche Glasfaser aus kann man die andere Fritz Box erreichen. Die Verbindung ist eigentlich aufgebaut und bricht auch nicht ab nur ich habe kein zugriff auf meine geräte im anderen Netzwerk. Im Anhang sind die Bilder von den beiden Netzen.

Vorher habe ich 2 Raspberry PIs verwenden mit OpenVPn um beide Netze zu verbinden, vielleicht liegt es auch daran. Der openvpn Server war im Netz von Deutsche Glasfaser. Die beiden Raspberrys sind raus habe beide Heruntergefahren und keine Besserung.

Wäre es möglich das in die eine Richtung die Wireguard Verbindung Versucht über IPV4 zu verbinden aber es geht nicht wegen DS Lite?

 

[frank_m24]

Vom NetAachen Netz kann ich das Deutsche Glasfaser Netz anpingen

Das heißt, du erreichst alle Geräte im Netz der Fritzbox am DG Anschluss? Wie gesagt, dann ist die VPN Verbindung raus. Pings sind aus Sicht des Tunnels nichts anderes, als andere Pakete, wie TCP oder HTTP Übertragungen.

Wenn du nicht alle Geräte erreichst, sondern z.B. nur die Fritzbox, dann könnte es was im Umfeld Allowed IPs sein, oder vielleicht auch Reste der alten OpenVPN Installation (statische Routen z.B.).

 

[erik]

Hast Du die bei der Raspberry-Verwendung notwendigen statischen Routen gelöscht?

 

[PeterPawn]

Hat eigentlich schon mal jemand getestet, ob die AVM-Konfigurationsdatei (für den Import von WG-Einstellungen) auch die MTU-Option enthalten kann/darf?

Denn für mich hört sich das (mal wieder) nach einem MTU-Problem an (DS-Lite auf einer Seite, kurze Pakete (ICMP) funktionieren, längere (HTTP(S)) nicht mehr) und ich würde hier (in der Konfigurationsdatei auf der Seite, die vom Provider nur DS-Lite kriegt) mal die MTU entsprechend beschränken (zumindest versuchsweise) bzw. das zunächst mal genauer testen.

---

EDIT:
Der gestrichene Einschub ist natürlich Unsinn - hoffe ich zumindest. Denn auf DIESER Seite dürfte es per se auch dem FRITZ!OS klar sein, welche zusätzlichen Faktoren bei der maximalen Größe der Pakete zu berücksichtigen sind ... schließlich WEISS das FRITZ!OS von der konkreten Konfiguration (DS-Lite, IPv4 nur über AFTR-Server beim Provider) und zeigt das sogar richtig an - daher wird (hoffentlich!) wohl auch die MTU DORT entsprechend verringert werden. Nur weiß eben die Gegenstelle (also der DG-Anschluß) davon nichts und von DORT werden dann wohl die zu großen Pakete gesendet ... das macht auch wieder mehr Sinn, denn einen HTTP-Request(!) kriegt man i.d.R. noch in ein einzelnes TCP-Paket gepresst (mit Glück sogar noch einen TLS-Handshake zuvor) - aber bei einer HTTP-Response ist es dann doch sehr wahrscheinlich, daß da mal ein Paket dabei ist, das die komplette MTU ausnutzen möchte.

---

Man sollte zwar annehmen, daß in dieser Konstellation automatisch "native IPv6" verwendet würde, aber wenn da irgendwo die DNS-Auflösung klemmt und für den Peer kein AAAA-Record gefunden wird, ist man auch schnell wieder bei IPv4 und dann fehlt auf der Übertragungsstrecke plötzlich doch wieder der Platz in den Paketen.

Wobei das hoffentlich (wenn es so sein sollte) von AVM bis zum Release noch nachgebessert wird ... eigentlich könnte man (unter Inkaufnahme eines stets etwas geringeren Durchsatzes) per se die MTU (immer) so einstellen, daß auch noch Platz für einen zusätzlichen "IPv4 in IPv6"-Overhead bleibt und das am besten auch noch unter (ständiger) Berücksichtigung der Tatsache, daß in D (und anderen Ländern, in denen die FRITZ!Boxen häufig anzutreffen sind) auch noch ein PPPoE-Overhead hinzukommen kann (und das an vielen Anschlüssen auch tut), der ebenfalls zu berücksichtigen wäre. Es gibt zwar auch einen Standardisierungsvorschlag für die Aushandlung/Erkennung dieses zusätzlichen Overheads (RFC 4638), aber hier geht es ja obendrein noch um zwei "kleinere" Provider und man kann (ohne Untersuchungen) nicht wissen, ob diese das auch umsetzen (es ist kein "richtiger" Standard, nur ein "informational"-Dokument).

Denn in der Kombination aus DS-Lite UND PPPoE kann es dann zu einer Konstellation kommen, in der die Standard-MTU von WireGuard (1420 Bytes) nicht mehr paßt und (mind.) auf 1412 Bytes heruntergeschraubt werden muß. Ich empfehle dazu die Suche im Internet - es gibt genug Stellen, wo das (gerade auch im WG-Kontext) thematisiert wird und da findet man dann auch Beispiele, wie man (vor dem Anpassen der MTU in der WG-Konfiguration) mit passenden Kommandos (zum Aussenden von (ICMP-)Paketen mit definierter Größe und gesetztem "don't fragment"-Flag (DF)) erst einmal testen kann, ob es sich tatsächlich - wie von mir vermutet - um ein MTU-Problem handelt. Wobei die beschriebenen Symptome schon sehr, sehr typisch sind ... und ich fast wetten würde, daß die Ursache irgendwo in dieser Richtung zu suchen ist.

 

[vusolo2]

Vollzitat gemäß Boardregeln entfernt by stoney

Ja weil die Fritz Box sonst ein Fehler ausgibt wenn man eine Verbindung im Assistenten erstellen will. Was auch geht ist eine SSH Verbindung zum Rasberry aber solbald ich ein befehl eingebe und bestätige bricht die SSH Verbindung zusammen.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln entfernt by stoney

Ich erreiche alle per ping aber wenn ich 192.168.178.1 oder 192.168.178.36 im Browser eingebe kommt nichts das 192.168.178.0 Netz ist von der Fritz Box 7590 im DG Netz.

 

[frank_m24]

das 192.168.178.0 Netz ist von der Fritz Box 7590 im DG Netz.

Es wundert mich, dass das geht. Früher war zwingend Voraussetzung, dass bei Box-2-Box Verbindungen keine Box das 178er Netz verwenden durfte.

Wie dem auch sei, der Hinweis von Peter Pawn klingt vielversprechend. Dort solltest du als erstes ansetzen.

 

[vusolo2]

Ich habe meine config auf beiden Fritzboxen jetzt so angepasst ohne Änderung.

[Interface]
PrivateKey = aKi0gLGKxxxxxxxxxxxxxxxxxxHGz2+rqKhflVI=
ListenPort = 53705
Address = 10.1.1.1/24
MTU = 1412
DNS = 10.1.1.1,192.168.178.1
DNS = fritz.box

[Peer]
PublicKey = 6SmxxxxxxxxxxxxxxxxxxxxxxxxxxxaSkXtx2k=
PresharedKey = CzfUxxxxxxxxxxxxxxxxxx8t8fMwdLjYfAhRtQ=
AllowedIPs = 192.168.178.0/24
Endpoint = xxxxxxxxxxxxxxx.myfritz.net:56795
PersistentKeepalive = 25

 

[PeterPawn]

ohne Änderung

Ohne Änderung?

Vielleicht übernimmt AVM den MTU-Wert tatsächlich NICHT in die gespeicherte VPN-Konfiguration ... zumindest gibt es wohl keinen "ausdrücklichen" Parameter wg_something dafür im neuen Format der vpn.cfg. Die Frage wäre jetzt halt, WIE die neuen Dateien vpn.cfg in den jeweiligen Boxen aussehen ... ich hatte/habe die Vermutung bzw. Hoffnung, daß solche "Zusätze" irgendwie in den Parametern wg_master_config und/oder wg_slave_config als Zeichenketten auftauchen würden.

Aber das war (eigentlich) auch nicht der primäre Vorschlag ... eine Änderung ohne GENAUES Wissen, was da einzutragen wäre, ist (auch wenn das Setzen notwendiger Parameter funktionieren sollte) ja eher suboptimal.

Ich würde also (und sei es nur zur "Absicherung der Diagnose") noch mit den entsprechenden ping-Kommandos ausloten, ob es ab bestimmten Größen NICHT mehr funktioniert und welche das genau sind bzw. ob sich diese Limits je nach Richtung der Übertragung anders darstellen.

Wobei mich auch mal interessieren würde (wenn das Setzen der MTU für ein WG-Interface über die (WG-)Konfigurationsdatei nicht funktioniert), was sich AVM da noch (bis zum Release) ausdenkt. Ein Weg wäre ja die oben bereits erwähnte "vorsorgliche" Verringerung der MTU auf "sichere Werte" (solange der physikalische Transportweg eine MTU-Size von 1500 Bytes verkraftet) unter Verzicht auf "maximalen Durchsatz" und ein anderer die Möglichkeit zur (notfalls optionalen) MTU-Einstellung, die dann auch irgendwo gespeichert werden muß (wenn die Annahme, daß das in den o.a. Werten möglich wäre, nicht zutreffen sollte). Dazu müßte man aber erst mal ermitteln, was da "im Normalfall" für die WG-Interfaces im FRITZ!OS verwendet wird und ob das wirklich (korrekt) dynamisch geändert wird, wenn die PMTU (ob mit oder ohne Discovery) geringer ist als der Standardwert.

Eine alternative Möglichkeit zur Diagnose wäre ein Paketmitschnitt bei einem nicht funktionierenden HTTP-Request. Wenn da keine größeren Antwortpakete im HTTP-Strream auftauchen, dann wurden die wohl irgendwo unterwegs (beim Einpacken in weitere Transportprotokolle) verworfen - was auch ein (sicheres) Zeichen für zu große Pakete - aufgrund einer zu groß angenommenen MTU-Size - wäre.

Auch das irgendwo weiter vorne mittlerweile noch zu lesende Problem mit SSH-Verbindungen ist dafür relativ typisch ... beim Handshake und der Anmeldung (EDIT: und der - zeichenweisen - Eingabe mit Echo vom Server) wird dann die max. Größe noch nicht ausgenutzt, aber bei irgendwelchen Kommandos (z.B. einem simplen ls, solange da nur genug Dateien anzuzeigen sind) dann schon, wenn die Antwort/Ausgabe übertragen werden soll.

 

[Benares]

Was liefert "nslookup xxxxxxxxxxxxxxx.myfritz.net"? Eine 10er Adresse? Schau mal hier.
Private IPs sind nicht öffentlich erreichbar.

 

[erik]

auf beiden Fritzboxen

Du hast aber nicht auf beiden Boxen dieselbe Datei importiert?
Warum muss denn eine der Boxen unbedingt im 10.x.x.x Netz arbeiten? Man kann doch für solche Versuche erst mal "normale" übliche interne Adressen wie 192.168.20.0/24 und 192.168.30.0/24 verwenden. Damit vermeidet man ggf. Konflikte mit den bei CGN bzw. DS-lite vergebenen Adressen.

 

[vusolo2]

Ich vermute mal das die config Datei den Wert MTU = 1412 nicht übernimmt. Ich habe auch das problem, wenn ich noch keine wireguard client eingerichtet habe in der fritz box und dann die oben genanten config importiere ändert die fritz box einfach immer ListenPort = 53705 auf einen anderen Port. Erst wenn bereits ein client vorhanden ist kann ich den port nehmen und der wird dann auch übernommen ansonsten funktioniert der import nicht weil der port immer ein anderer ist und nicht passt. Deswegen kann ich mir gut vorstellen das da nochmehr nicht übernommen wird. Ich habe nur gedacht das die Kinderkrankheiten nach der langen zeit mal ausgemerzt sind weil es wurde schon länger nicht mehr im changelog von Wireguard Verbesserungen berichtet. Ich probiere mal aus einen ping zusenden der einen größeren wert hat.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln entfernt by stoney

Nein natürlich für jede Box die passende die Verbindung steht ja auch nur nicht so wie es soll. Ich habe mit 10.1.1.0 die kürzest mögliche Variante gewählt ich dachte die wäre ausserhalb jeder Problme.

 

[Benares]

Bevor jetzt alle hier nur noch weiterraten, sag mal welchen internen IP-Range und welche externen IPv4s (erst 2 Stellen) beide Boxen verwenden, und ob auch IPv6 mit im Spiel ist.

 

[PeterPawn]

Ich würde auch den Mitschnitt noch mal machen ... denn es ist ja schon "komisch", wenn bei Zugriffen vom DG-Anschluß auf den bei NetAachen ALLES problemlos funktioniert. Eine mögliche Erklärung dafür wäre zwar noch "MSS clamping" (auf der Box mit der kleineren MTU-Size), aber das sollte dann in so einem Mitschnitt sichtbar sein, wenn die Pakete bei den funktionierenden Verbindungen entsprechend kleiner sind als bei den "fehlerhaften".

 

[vusolo2]

Bevor jetzt alle hier nur noch weiterraten, sag mal welchen internen IP-Range und welche externen IPv4s (erst 2 Stellen) beide Boxen verwenden, und ob auch IPv6 mit im Spiel ist.

Was genau heiß ob ipv6 mit im Spiel ist?

DG Netz
FritzBox 7590 mit 192.168.178.1
Unter Online-Monitor
IPv4-Adresse: 100.112.38.XXX
IPv6-Adresse: 2a00:6X2X:XXXX:46::XXXX/64
IPv6-Präfix: 2a00:6X2X:XXXX:XXXX::/56

NetAachen
FritzBox 7530 mit 10.1.1.1
Unter Online-Monitor
FRITZ!Box verwendet einen DS-Lite-Tunnel, NetCologne / NetAachen Anschluss ohne Splitter
AFTR-Gateway: 2001:XXXX:af:1::af

IPv6-Adresse: 2001:4dd0:af19:62e8:XXXX:XXXX:fXXX:XXXX/64, Gültigkeit: 2591972/604772s
IPv6-Präfix: 2a0a:XXXX:XXXX::/48, Gültigkeit: 84517/84517s