WireGuard gilt gemein hin als schnelles und schlankes VPN-Protokoll, dennoch kann es Szenarien und Situationen geben in denen es nicht so ist wie erwartet.
Ich mag nicht meckern, WireGuard funktioniert für uns und einen Teil unserer Kunden sehr gut. Schneller Verbindungsaufbau, leicht einzurichten, läuft (meistens). Eine Sache ist mir allerdings schon vor geraumer Zeit aufgefallen und zwar das eingehender Datenverkehr unter Windows irgendwie bei um die 10 Mbit/s rumdümpelt. Es spielt dabei keine Rolle wie schnell die Gegenseite ist, da kann ein Upload von 10, 40 oder 100 Mbit/s möglich sein, es kommt einfach nicht mehr durch.
Der erste Gedanke “liegt an der MTU” war’s leider nicht, wenn gleich das durchaus einen Einfluss haben kann. Allerdings ist das Problem nur auf den Empfang unter Windows beschränkt, Versenden wiederum geht schnell. Um die Sache weiter einzugrenzen wurde mal mit verschiedenen Anschlüssen und Gegenstellen getestet. Das zugrundeliegende Szenario ist dabei immer das Selbe und das wäre: Roadwarrior-VPN. Also ein Mitarbeiter oder in diesem Testlauf eben ich selbst, verbindet sich und lädt eine große Datei von einem Server herunter.
An Gegenstellen gibt es folgendes:
- Securepoint UTM (RC100 und RC300)
- AVM FRITZ!Boxen (7590)
- WireGuard-Server unter Windows Server 2022
Auf Roadwarrior-Seite gibt es Windows 10 Pro und Windows 11 Pro mit dem zu diesem Zeitpunkt aktuellem WireGuard 0.5.3 an einem Glasfaser 600/300-Anschluss. An Anschlüssen ist alles von VDSL50/10 bis Glasfaser 300/100 dabei. Sofern kein QoS oder irgendein Speedlimit zum tragen kommt, sollte also immer pro Anschluss die maximale Upload-Bandbreite ausgenutzt werden können, bei VDSL100 wären das beispielsweise um die 40 Mbit/s.
Hier die Ergebnisse:
- GF100/40 – Securepoint UTM RC100 – ca. 10 Mbit/s
- GF300/100 – Securepoint UTM RC300 – ca. 13 Mbit/s
- VDSL100/40 – AVM FRITZ!Box 7590 – ca. 6 Mbit/s
- VDSL50/10 – Windows Server mit WireGuard – ca. 7 Mbit/s
Beim letzten Anschluss könnte man noch sagen, der kann nur 10 Mbit/s maximal im Upload, die Leitung gibt die sogar her, aber es kommt einfach nicht mehr durch. Anders sieht die Sache aus wenn man Site-to-Site VPN nutzt. Für alle habe ich das kurzfristig nicht testen können, beim ersten Anschluss in der Liste ist es allerdings in der Tat so, das dann die 40 Mbit/s ausgenutzt werden.
Bei der Recherche nach diesem Verhalten fand sich dieser etwas ältere Beitrag:
serverfault – Wireguard slow but only for windows upload
Allerdings geht es dort um die falsche Richtung (Upload statt Download), ferner spricht für das in meinem Beitrag aufgezeigte Verhalten dagegen, das es eben auch mit einem Windows-basierten WireGuard-Server genau so ist.
Für die bei uns durchschnittliche Roadwarrior-Verbindung spielt das aktuell keine Rolle, meist werden eh nur RDP-Verbindungen darüber gemacht. Dennoch seltsam und es wäre wünschenswert wenn man das gelöst bekommt.
Kennt ihr dieses Verhalten? Habt ihr eine Idee oder gar eine Lösung dazu? Dann her damit, schreibt mir einfach ein Kommentar.
Update 21.08.2023
Nachdem in den Kommentaren der Hinweis kam, man solle mal mit Securepoint sprechen wurde entsprechend ein Ticket eröffnet, das Problem ist dort nicht bekannt und intern konnte man dies auch nicht nachstellen. Da es der Testreihe nach auch nicht auf Securepoint-Gegenstellen begrenzt ist, scheint das auch eher ein WireGuard/Windows-Thema zu sein.
Ferner wurde mal mit der älteren WireGuard-Version 0.4.7 getestet, auch hier zeigt sich das genannte Verhalten.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Guten Morgen
das gleiche Problem hatten wir.
Lösung von Securepoint Workerprozesse erhöhen
Hallo Andreas,
vielen Dank für den Tipp, hab’ das in Lüneburg mal angefragt.
Hallo Andreas,
Securepoint hat gerade zurück gerufen und sich das angeschaut. Im Moment wüsste man jetzt nicht, woran das liegt und was man da tun kann, man klärt das intern ab. Mit Worker Prozessen war dem Supporter jetzt nur was wegen dem Proxy bekannt.
Hast du evtl. noch mehr Infos?
Securepoint hat sich heute nochmal gemeldet und mitgeteilt, das sie das Problem nicht kennen und intern auch nicht reproduzieren konnten.
Ich vermute mal, da es im Test ja auch mit Nicht-Securepoint-Gegenstellen aufgetreten ist, das es eine Angelegenheit zwischen WireGuard und Windows ist.
Moin,
wie ist misst du den eingehenden und ausgehenden Traffic bei Wireguard?
VG
aadursun
Explizit gemessen habe ich das nicht, lediglich eine Datei kopiert und das Ganze im Task-Manager beobachtet.
Ich habe in vier Ländern WireGuard Site-to-Site VPNs auf pfSense eingerichtet. Alle Verbindungen funktionieren einwandfrei, außer in einem Standort, wo die Geschwindigkeit auf Windows-Rechnern eingeschränkt ist.
Die maximale Geschwindigkeit beträgt nur 15 Mbit/s, anstatt der erwarteten 100 Mbit/s.
Ich hoffe, dass Sie mir bei der Lösung dieses Problems helfen können.
leider habe ich Probleme mit dem WireGuard Site-to-Site-VPN auf pfsense. Es gibt Geschwindigkeitsprobleme mit dem VPN auf allen Windows-Rechnern.
vpn speedtest auf Widnows
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 3.88 MBytes 3.25 Mbits/sec sender
[ 4] 0.00-10.00 sec 3.79 MBytes 3.18 Mbits/sec receiver
vpn speedtest auf Linux
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 167 MBytes 140 Mbits/sec 12 sender
[ 5] 0.00-10.16 sec 166 MBytes 137 Mbits/sec receiver
Bei Site-to-Site habe ich das Problem noch nicht beobachtet.
Befinden sich auf beiden Seiten pfSensen?
Ein Thema könnte sein, das man die MTU anpassen muss.
Danke für deine Antwort.
Ich habe bereits mit den neuen MTU-Werten getestet, aber leider keine Änderung festgestellt. Ich habe sogar einen Test mit einem Windows-Rechner durchgeführt, auf dem VirtualBox installiert ist und darauf Linux betrieben wird. Die Geschwindigkeit auf Linux war sehr gut, jedoch auf Windows 10 und 11 sehr schlecht.
Eine Seite verwendet pfSense auf Proxmox und die andere auf ihrem Firewall – 6 Port Intel® i3-8130U.
Hallo Andy,
Nachdem ich die folgenden Befehle als Administrator ausgeführt habe, um die MTU auf einem Windows-System einzustellen und anschließend das System neu zu starten, erhalte ich weiterhin den Fehler “Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt”, wenn ich die MTU erneut überprüfe:
ping 192.168.50.10 -f -l 1290
Ping wird ausgeführt für 192.168.50.10 mit 1290 Bytes Daten:
Antwort von 192.168.50.10: Bytes=1290 Zeit=77ms TTL=63
Antwort von 192.168.50.10: Bytes=1290 Zeit=32ms TTL=63
netsh interface ipv4 set subinterface “Ethernet” mtu=1290 store=persistent
ok
PS C:Windowssystem32> netsh interface ipv4 show subinterfaces
MTU Medienerkennungsstatus Bytes eingehend Bytes ausgehend Schnittstelle
—— ————— ——— ——— ————-
4294967295 1 0 62868 Loopback Pseudo-Interface 1
1500 1 3541064 163144393 LAN-Verbindung
1270 1 592958388 183757860 WLAN
Es scheint, dass die MTU erfolgreich auf 1290 geändert wurde, wie im Befehlsverlauf gezeigt. Dennoch zeigt die erneute Überprüfung der MTU nach dem Neustart weiterhin den Fragmentierungsfehler an.
Damit unter Windows die Änderung dauerhaft ist, muss man “store=persistent” anhängen. Siehe
https://www.ibm.com/support/pages/how-do-you-change-mtu-value-linux-and-windows-operating-systems
Ansonsten gibt es hier noch das zu MTU und WireGuard:
https://keremerkan.net/posts/wireguard-mtu-fixes/
Hoffe das hilft weiter.