FritzBox 5590: Wireguard nutzt nur einen Bruchteil des möglichen Uploads

[ABCD.]

Hallo zusammen,

ich hoffe, ihr könnt mir bei meinem Problem weiterhelfen.

Meine Daten:

• Standort A: Glasfaser: 600 Mbps Download; 300 Mbps Upload
• Standort B: Kabel: 250 Mbps Download; 150 Mbps Upload
• Am Standort A ist Wireguard auf einer FritzBox 5590 (Firmware v7.81) eingerichtet
• Eine Wireguard-Verbindung für einen PC am Standort B ist konfiguriert, um sich mit Standort A zu verbinden
• Alle verwendeten Geräte sind per Kabel verbunden. Der Down- und Upload wurde an beiden Standorten über mehrere Minuten kontinuierlich geprüft, um eine konstante Übertragung sicherzustellen

Zum Problem:

Wenn ich mich am Standort B per Wireguard-Client (Windows) ins Netzwerk von Standort A verbinde, pendelt sich der Datentransfer von A nach B immer bei genau 30 Mbps ein. Das ist auch in der Echtzeitanzeige der FritzBox ersichtlich, wo der Upload bei 30 Mbps schwankt.

Verwende ich mein Handy über Mobilfunk mit Wireguard, erreiche ich etwa 70 Mbps. Ohne Wireguard beträgt der Download 180 Mbps. Wenn ich eine Datei von meinem selbstgehosteten Clouddienst im Netzwerk A über Mobilfunk auf mein Handy herunterlade (ohne Wireguard), wird die maximale Downloadgeschwindigkeit des Mobilfunks von 170 Mbps ausgereizt. Also liegt es an Wireguard.

Laut diesem Video sollte die FritzBox 5590 problemlos über 600 Mbps Upload per Wireguard erreichen können. Die Geschwindigkeit erreiche ich jedoch nicht annähernd.

Habt ihr eine Idee, wie ich den vollen Upload von Standort A über Wireguard ausreizen kann? Irgendetwas scheint hier nicht zu stimmen :/.

 

[DLMttH]

Welcher Provider ist es denn jeweils? Dass gewisse Großkonzerne gerade ihre Peerings zwischen Providernetzen recht schmal halten, ist ja kein Geheimnis mehr.

 

[ABCD.]

A: Telekom
B: Vodafone

Mobilfunk: O2

Können die Provider vpn Verbindung erkennen und drosseln?

 

[till69]

Denke, dass das Peering von A Dein Problem ist

 

[DLMttH]

Müsste man natürlich erst einmal nachweisen, aber ja, genau diese Upload-Schwäche in Providernetze ist ein typisches Telekom Public-Peering-Engpass-Symptom, welches ich hier nicht zum ersten Mal sehe.

Leider sind solche Leute von einem Fluch belegt, denn nach dem Wechsel zu o2 melden die sich in aller Regel nicht zurück, um zu berichten, dass es geholfen hat.

 

[riversource]

Wenn ich mich am Standort B per Wireguard-Client (Windows) ins Netzwerk von Standort A verbinde, pendelt sich der Datentransfer von A nach B immer bei genau 30 Mbps ein.

Wie hast du die Geschwindigkeit denn ermittelt? Denn ggf. spielen da auch Server und Client eine Rolle, und nicht nur VPN.

 

[Alexander2]

Ja, die können vieles bis alles erkennen.
https://netzpolitik.org/2014/waschm...deep-packet-inspection-als-feature-verkaufen/
Das ist nur ein Beispiel. Wireguard zu erkennen dürfte simpel sein, simpler als bestimmte Dateien explizit, die übertragen werden.

 

[ABCD.]

@riversource ich habe einfach auf eine Ordner Freigabe von einem PC im Netz A zugegriffen und eine 60 GB Datei kopiert.

Ihr schreibt von peering Engpass. Was ist damit gemeint? Das betrifft ja scheinbar nur explizit wireguard Verbindungen. Greife ich auf meinen cloud Speicher (aus dem Netz A) von einem anderem Standort und Provider zu (ohne wireguard), gibt es keine Geschwindigkeitsbeschränkung.

 

[Alexander2]

Wireguard iat auch ein Rechenaufwand, da kann es Rechenseitig eben bei einem der Punkte (einer deiner Beiden Rechner) auch einen engpass geben.

 

[riversource]

@riversource ich habe einfach auf eine Ordner Freigabe von einem PC im Netz A zugegriffen und eine 60 GB Datei kopiert.

SMB ist für einen VPN Test ungeeignet. Das einzige, was man aus einer schlechten SMB Performance ableiten kann, sind ggf. MTU Probleme. Ansonsten ist SMB sehr empfindlich, vor allem gegen Jitter, wie es bei VPN oft vorkommt. Die Empfehlung ist, auf ein anderes Protokoll zu wechseln, wie FTP oder NFS.

Mache mal Tests mit iperf3 auf beiden Seiten, auch mit mehreren parallelen Verbindungen.

 

[ABCD.]

Kann man das irgendwie verschleiern, das man wireguard nutzt? Andere ports?

Ich glaube der Rechenaufwand sollte nicht das Problem sein.

 

[riversource]

Ich kann dir versichern, dass kein Provider in Europa Wireguard Verbindungen drosselt. Das wäre aufgefallen.

Wenn es kein generelles Peering Problem gibt, hat dein individuelles Setup ein Problem.

 

[Alexander2]

Ich kann dir versichern

Wie das?

 

[riversource]

Wie viele Wireguard Verbindungen werden täglich genutzt? Und du glaubst, niemand hätte sich gemeldet, wenn die Provider nur 20% der Bandbreite zulassen?

 

[Alexander2]

Also doch nur weils so wahrscheinlich ist.

 

[Ikebana]

Ich habe hin und wieder Performanceprobleme für SMB Verbindungen gehabt aufgrund der MTU für den VPN Tunnel. Vor allem wenn der Client über Kabel (Vodafone z.B.) verbunden war und der Server an einem DSL Anschluss war.
Wireguard nutzt eine MTU von 1420, das könnte zu groß sein, sodass Pakete fragmentiert werden müssen, was die Performance einschränken kann.
Probiere mal eine MTU von 1412 oder weniger. Einige Leute schreiben, dass z.B. 1380 ein guter wert für den VPN Tunnel war.
Hier kannst du sehen wo man das einträgt:
https://wiki.archlinux.org/title/WireGuard#Adjusting_the_MTU_value

Ein vielleicht hilfreicher Artikel:
https://schroederdennis.de/vpn/wireguard-mtu-size-1420-1412-best-practices-ipv4-ipv6-mtu-berechnen/

Unter OpenVPN gibt es auch das Problem mit der MTU, da gibt es die Option mssfix die das lösen kann.

 

[ABCD.]

@Ikebana muss ich dann auf der fritzbox Seite in wireguard was einstellen? Auf den ersten Blick konnte ich da nicht wirklich was einstellen. Die config ist fix. Auf Client Seite kann ich einen manuellen mtu Wert festlegen.

 

[riversource]

Also doch nur weils so wahrscheinlich ist.

Sagen wir mal so: wenn das die Hoffnung ist, auf die wir uns stützen, dann sieht es echt duster aus.

 

[Ikebana]

Du kannst das auf Client Seite festlegen, die Fritzbox sollte sich dann ebenso an den MTU Wert halten.

 

[rezzler]

Müsste man natürlich erst einmal nachweisen, aber ja, genau diese Upload-Schwäche in Providernetze ist ein typisches Telekom Public-Peering-Engpass-Symptom, welches ich hier nicht zum ersten Mal sehe.

Dagegen spricht, das es via o2-Mobilfunk besser funktioniert. Und Vodafone hat ja mit Überlastungen an den Übergaben zur Telekom auch mindestens eine Hintergrundgeschichte.