Wireguard Durchsatz instabil

MCKraemer · Jun 11th 2025

Quote from TBT

Unabhängig von den Paketverlustproblemen zum Setup: genau beim geschilderten Problem (bevor mans selbst strickt) kann Pangolin helfen. Pangolin wird auf dem Internet Server installiert, die zugehörige Plug-and-Play Komponente Newt kommt auf den CGNAT Server. Supersimpel und schnell einzurichten, zudem kann Pangolin Zugangsrechte verwalten und auch an andere ID Provider angeschlossen werden. SSO kanns auch.

Kurz zu meinem Verständnis, Pangolin nutzt doch Wireguard unter der Haube, inwiefern soll es hier also einen Unterschied geben?

MCKraemer · Jun 13th 2025

Quote from frank_m

iperf3 Tests hast du zu deinem Server ja schon gemacht. Auf Client Seite kannst du durch ein einfaches "-u" UDP Tests durchführen. Bedenke, dass du dabei eine Geschwindigkeit mit angeben musst, sonst findet der Test nur mit 1 MBit/s statt. Ich würde mit 100 MBit/s anfangen und mich dann nach oben unten vortasten, bis die Paketfehlerrate in der Schlussstatistik bei maximal 2% ist. Das ist dann die etwa zu erwartende UDP Datenrate zwischen deinen Systemen.

iperf3 -c <server> -u -b 100M

Code

Connecting to host 10.8.0.1, port 5201
[  5] local 10.8.0.2 port 42779 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  35.8 MBytes   300 Mbits/sec  27199
[  5]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  27175
[  5]   5.00-6.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   6.00-7.00   sec  35.8 MBytes   300 Mbits/sec  27174
[  5]   7.00-8.00   sec  35.8 MBytes   300 Mbits/sec  27173
[  5]   8.00-9.00   sec  35.8 MBytes   300 Mbits/sec  27175
[  5]   9.00-10.00  sec  35.8 MBytes   300 Mbits/sec  27174
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   358 MBytes   300 Mbits/sec  0.000 ms  0/271764 (0%)  sender
[  5]   0.00-10.02  sec   219 MBytes   183 Mbits/sec  0.079 ms  0/271763 (0%)  receiver

Display More

Das sieht für mich überraschend gut aus, wie kann denn TCP so schlecht performen über den Tunnel während UDP keinerlei Probleme macht.

frank_m · Jun 15th 2025

Du hast offenbar über den VPN Tunnel gemessen. Das ist natürlich wenig hilfreich, wenn du die Paketfehlerraten des Anschlusses feststellen willst. Du musst natürlich über die direkte Verbindung messen, wenn es dir darum geht.

Aber du erreichst mit UDP über den Tunnel 183 MBit/s, das ist bei 200 MBit/s Upload genau der Wert, der zu erwarten ist. Bei mir sind es 187 MBit/s, das passt also. Was komisch ist, obwohl du mit 300 MBit/s sendest und nur 180 ankommen, ist die Paketfehlerrate 0. Die ist bei mir 37% in einer Messung mit den gleichen Parametern.

Wie dem auch sei, der VPN Tunnel scheint perfekt zu funktionieren. Alles andere ist dein Applikationssetup. Wenn du mit TCP schwankende Bandbreiten feststellt, kommen wieder MTU und MSS ins Spiel. Funktioniert die Path MTU Discovery auf der Strecke?

headnail · Wednesday, 9:15 pm

Im Buschfunk war mal zu hören, das Wireguard in Kombination mit einigen Routern und mit UDP Paketen Probleme machen soll.

Mal eine Idee: vielleicht mal einen zweiten Testserver mit Wireguard und TCP Paketen probieren, wie es da mit der Geschwindigkeit aussieht?

svenn · Wednesday, 10:28 pm

Das DG-Problem mit VPNs aller Art ist mir (leider aus eigener Erfahrung) ein bekanntes Thema

Was du aus meiner Sicht dagegen tun kannst: Dein Glück versuchen und nach einer dynamischen / statischen v4 bei der DG fragen

oder

- per IPv6 zum Rootserver verbinden

- Clients die kein IPv6 besitzen und auf das NAS zugreifen sollen, hingegen per v4 des Rootservers zum WireGuard Interface anbinden

---

Kurz und knapp: CGNAT ist generell "böse" was VPNs, VOIP, Games und co. anbetrifft - wird aber leider immer mehr eingesetzt um dem allseits bekannten IPv4-Mangel entgegenzuwirken. Das schlimmste an CGNAT: Du siehst je nach Tech-Stack der hintendran werkelt nicht zwingend wie viele Stufen an NAT durchgeführt werden, bis du im Internet landest. Teilweise kann das schon gute 3-4x NAT44 sein

Dein spezifisches TCP Problem klingt für mich aber stark nach fehlerhafter TCP-MSS. Schonmal ein Tracepath gemacht um zu validieren dass die MTU an sich stimmt?

svenn · Wednesday, 10:31 pm

Quote from headnail

Im Buschfunk war mal zu hören, das Wireguard in Kombination mit einigen Routern und mit UDP Paketen Probleme machen soll.

Mal eine Idee: vielleicht mal einen zweiten Testserver mit Wireguard und TCP Paketen probieren, wie es da mit der Geschwindigkeit aussieht?

Eigentlich nicht - zumindest habe ich mit verschiedensten Distributionen, Herstellern und Overlay-Kombinationen wie z.B. + VXLAN das noch nicht gehabt. Meistens ist eher eine asymmetrische / zu hohe MTU oder ein fehlerhaftes MSS-Clamping die Ursache

headnail · Wednesday, 10:41 pm

Quote from svenn

Eigentlich nicht

Da muss ich passen, ich habe leider kein Wireguard im Einsatz.

Was ich aber weiß: mein openVPN am Smartphone spuckt gerne bei einigen öffentlichen Wifi Netzen rum, wenn man UDP als Standard einstellt.

Nachdem mein VServer eh wegen einer Störung neu eingerichtet werden musste, habe ich es spaßeshalber auf TCP umgestellt. Seit dem habe ich kaum bis keine Probleme mehr.

svenn · Wednesday, 10:45 pm

Quote from headnail

Da muss ich passen, ich habe leider kein Wireguard im Einsatz.

Was ich aber weiß: mein openVPN am Smartphone spuckt gerne bei einigen öffentlichen Wifi Netzen rum, wenn man UDP als Standard einstellt.

Nachdem mein VServer eh wegen einer Störung neu eingerichtet werden musste, habe ich es spaßeshalber auf TCP umgestellt. Seit dem habe ich kaum bis keine Probleme mehr.

Das darfst du einigen restriktiven Firewalls in Gäste-WiFis verdanken die z.B. nur TCP Port 80,443 oder nur TCP erlauben. In Frankreich beim Euroairport wird sogar TCP-OpenVPN inzwischen gefiltert

Gibt ein paar WiFi-Betreiber die mit "Nix ausser Port 80, 443" versuchen z.B. Torrenting usw. zu "blockieren".

headnail · Thursday, 12:19 am

Quote from svenn

Gibt ein paar WiFi-Betreiber die mit "Nix ausser Port 80, 443" versuchen z.B. Torrenting usw. zu "blockieren"

Das kann ich ausschließen. Prinzipiell funktioniert beides. Nur, wenn ich UDP verwende, habe ich vermehrt Aussetzer in der Verbindung.

Würde dort eine Firewall das blockieren, würde ich gar keine Verbindung bekommen. Und das ist bei beiden (TCP und UDP) auch nicht der Fall.

(Wobei ich dir da aber schon prinzipiell glaube, das es Wifis gibt, bei denen unliebsame Ports gesperrt sind)

svenn · Thursday, 2:16 am

Quote from headnail

Das kann ich ausschließen. Prinzipiell funktioniert beides. Nur, wenn ich UDP verwende, habe ich vermehrt Aussetzer in der Verbindung.

Sorry, hatte das in deinem vorherigen Beitrag irgendwie falsch rausgelesen. Jetzt verstehe ich - in deinem Fall klingts durchaus nicht danach

frank_m · Thursday, 9:28 pm

Quote from svenn

Das DG-Problem mit VPNs aller Art ist mir (leider aus eigener Erfahrung) ein bekanntes Thema

Kann ich überhaupt nicht bestätigen.

Quote from svenn

Was du aus meiner Sicht dagegen tun kannst: Dein Glück versuchen und nach einer dynamischen / statischen v4 bei der DG fragen

Das hat DG noch nie gemacht.

Quote from svenn

Kurz und knapp: CGNAT ist generell "böse" was VPNs, VOIP, Games und co. anbetrifft

Zumindest für VPN ist das Unsinn. CGNAT wird nur zum Problem, wenn PPTP strikt ausgelegt wird und nur eine Verbindung pro Quell-IP zulässt. Aber PPTP nutzt eh niemand mehr. Für IPSec gibt es NAT-T. Auf OpenVPN oder Wireguard hat es gar keinen Einfluss.

Tags