Wireguard MTU

    Es geht um das leidige Thema Wireguard MTU. Ich habe hier sehr langsame und teilweise recht schwankende Werte. Die erstmal die Konfig:




    Der Client hängt an einem Telekom DSL (500Mbit Download, 100Mbit Upload). Folgende Ergebnis bekomme ich per iperf:





    Ich habe mich so langsam an die "passenden" MTU Werte herangetastet.


    Laut Rechnung wären ja die optimalen Werte:


    Server: 1500 - 20 Bytes (IPv4) - 8 Byte (UDP) - 32Byte (WG) = 1440

    Client: 1492 - 20 Bytes (IPv4) - 8 Byte (UDP) - 32Byte (WG) = 1432


    Mit dieser Kombination funktioniert es ebenfalls nicht zufriedenstellend. Welche Möglichkeiten gäbe es noch?

    Zitat von Hille

    Server: 1500 - 20 Bytes (IPv4) - 8 Byte (UDP) - 32Byte (WG) = 1440

    Client: 1492 - 20 Bytes (IPv4) - 8 Byte (UDP) - 32Byte (WG) = 1432

    Sind in den 32 Byte schon die zusätzlichen IP Header drin? IP und UDP muss man ja doppelt übertragen. Und bei IPv6 werden die Header entsprechend größer.


    Den Speedtest hast du auf dem Client gestartet? Was passiert bei mehreren parallelen Verbindungen?

    den Header habe ich unter IPv4 (20Byte) hinzugerechnet. Ein weitere Header wäre mir nicht bekannt. Ja, bei IPv6 wäre der Header 40Byte.

    Den Test habe ich vom Server aus gestartet. Vom Client aus sind die Werte ähnlich. Mehrere parallele Verbindungen müsste ich noch testen. Vermutlich werden die Werte aber nicht besser :)

    Zitat von Hille

    Den Test habe ich vom Server aus gestartet. Vom Client aus sind die Werte ähnlich.

    Was heißt "ähnlich"? Der gezeigte Test hat langsamen Upload und schnellen Download. D.h., der Server sendet langsam, der Client schnell. Ist das noch genau so, wenn der Client den Test startet? Oder ist es dann anders herum? Der Sender hat die "Arbeit" mit der Verschlüsselung, der Empfänger muss nur entschlüsseln. Die entsprechenden Wireguard Kernel Module sind auf beiden Seiten aktiv?


    Zitat von Hille

    Mehrere parallele Verbindungen müsste ich noch testen. Vermutlich werden die Werte aber nicht besser :)

    Dann lass dich überraschen. Ich könnte mir durchaus vorstellen, dass das signifikant Einfluss hat.


    Mach parallel mal einen iperf3 UDP Test zwischen beiden Systemen ohne VPN Tunnel. Ich hab schon Anbindungen gesehen, da gab es unerklärliche Paketverluste bei UDP Verbindungen.

    Zitat von frank_m

    Sind in den 32 Byte schon die zusätzlichen IP Header drin? IP und UDP muss man ja doppelt übertragen. Und bei IPv6 werden die Header entsprechend größer.


    Den Speedtest hast du auf dem Client gestartet? Was passiert bei mehreren parallelen Verbindungen?

    Ich habe wireguard etwas aus den Augen verloren. Geht es hier immer noch um UDP mit nicht-hardwareunterstützem ChaCha20Poly1305?

    Wenn musst du die MTU auf beiden Seiten auf den kleinsten gemeinsamen Nenner setzen, da du ja in beide Richtungen die Pakete nicht größer machen kannst, als die "dünnste" Stelle zulässt. Wenn der Server ohne PPPoE 8 Byte mehr in den Tunnel stopfen kann als der Client, kommt es beim Client im besten Fall ja dann trotzdem fragmentiert an, aber wahrscheinlich eher einfach gar nicht. Somit hast du Packetloss oder Out-Of-Order Packets in den Tunnel eingebaut, was dann bspw. TCP wieder kompensieren muss. Pendelt sich irgendwann ein, ist aber schlechter, als die MTU einfach sicherheitshalber etwas (oder auch deutlich) kleiner zu wählen als das theoretische Optimum und das Problem so zu vermeiden. Ich hab als Erfahrungswert mittlerweile 1200 lieben gelernt...


    /e: bei iperf ohne parallele Verbindungen dürfte die Latenz auch eine große Rolle spielen, daher schließe ich mich der Empfehlung das mal zu testen an.


    Ich würde an deiner Stelle auch mal statt iperf etwas praxisnähere Tests fahren. Zieh z.B. mal auf dem Server einen kleinen Webserver hoch, schreib aus /dev/urandom ein GB oder so in ein File, und ruf das vom Client ab.

    Zitat von eripek

    man pMTUd

    https://en.wikipedia.org/wiki/Path_MTU_Discovery


    Das Ungute an manuell gesetzter MTU ist, dass das Verhältnis von Nutzdaten zu Overhead sich dadurch nicht gerade verbessert.

    Die hat aber bei VPNs so ihre Probleme. Das Overlay kann ggf. gar nicht mitbekommen, wenn im Underlay fragmentiert wird, wenn die Implementierung da nicht einiges tut.


    Im Prinzip muss die VPN Implementierung irgendwelche Annahmen über die Topologie des Underlays treffen um innerhalb des Tunnels PMTUD irgendwie zu ermöglichen, oder selbst ständig eine PMTUD zwischen den Endpunkten machen um dann die MTU des Tunnelinterface dynamisch anzupassen.

    Theoretisch geht da einiges, meine persönliche Erfahrung, egal ob mit StrongSwan IPSec, OpenVPN oder Wireguard ist: Wenn es irgendeine dieser Implementierungen überhaupt macht, dann funktioniert es jedenfalls nicht.

    Zitat von marcquark

    Die hat aber bei VPNs so ihre Probleme. Das Overlay kann ggf. gar nicht mitbekommen, wenn im Underlay fragmentiert wird, wenn die Implementierung da nicht einiges tut.


    Im Prinzip muss die VPN Implementierung irgendwelche Annahmen über die Topologie des Underlays treffen um innerhalb des Tunnels PMTUD irgendwie zu ermöglichen, oder selbst ständig eine PMTUD zwischen den Endpunkten machen um dann die MTU des Tunnelinterface dynamisch anzupassen.

    Theoretisch geht da einiges, meine persönliche Erfahrung, egal ob mit StrongSwan IPSec, OpenVPN oder Wireguard ist: Wenn es irgendeine dieser Implementierungen überhaupt macht, dann funktioniert es jedenfalls nicht.

    Bei OpenVPN kann man zumindest den Parameter fragment auf MTU auf 20-8-4 setzen (minus 4 für etwaige compression header).
    Was wireguard anbelangt - wird die interface MTU automatisch gesetzt oder muss ich die angeben?

    PMTUd funktioniert in der Regel nur dann nicht, wenn einer der Endpunkte kein IMCP spricht, weil es entweder geblockt oder gar nicht geroutet wird (etwa CGNAT und vergleichbare Situationen).

    ich habe in den letzten Tage mich mal ausführlich mit dem Thema befasst, viel gelesen und auch viel getestet. Eine saubere Lösung habe ich leider nicht gefunden. Ich habe mich mit einem befreundeten Admin auch mal unterhalten, der mir die Wireguard Probleme bestätigt hat. Das interessante ist halt, dass der Tunnel zu unbestimmten Zeiten recht stabil läuft, dann aber halt wieder auch nicht. Hier mal meine Ergebnisse. Zur Ergänzung, Wireguard Server RS1000, Wireguard Client Raspi4. MTU auf beiden Systemen 1400



    Diese Test liefen über mehrere Stunden stabil.


    Hier nun mit 4 Streams


    Ebenfalls stabiles Ergebnis. Hier ein Test von heute morgen



    Hier fällt auf, dass der Retr (Retransmitted TCP packets) Wert relativ hoch ist.

    Mich würde auch mal interessieren, ob es User gibt, bei denen Wireguard auf Dauer stabil läuft.

    Zitat von Hille

    Hier ein Test von heute morgen

    Da wäre natürlich der Test mit den parallelen Verbindungen wichtig gewesen. Wenn alles klappt, ist es easy, aber wenn es Probleme gibt, dann wird es interessant.



    Zitat von Hille

    Hier fällt auf, dass der Retr (Retransmitted TCP packets) Wert relativ hoch ist.

    Das deutet auf Paketverluste hin, weshalb ich oben schon geschrieben habe, mal einen UDP Test zwischen Server und Client ohne Wireguard zu machen.


    Ich habe eine Wireguard Verbindung zwischen einem Raspi4 und einem RS2000 laufen, über eine Deutsche Glasfaser Verbindung mit 400/200 MBit/s. Keinerlei Probleme, die Verbindung ist über Monate stabil. Ich habe teilweise Uptimes von über 40 Tagen am Stück, bevor dann wieder irgendein Software Update einen Reboot erfordert. Kein Problem.

    Man muss iperf3 mit "-u" starten und eine Bandbreite angeben, da iperf sonst nur mit 1 MBit/s arbeitet. Bei der Bandbreite muss man sich rantasten an die Bandbreite, die problemlos geht. Das sollte recht nah an der maximalen Bandbreite des Anschlusses sein. Wenn es schon bei deutlich niedrigeren Bandbreiten zu regelmäßigen Paketverlusten kommt, ist das ein Problem. Noch viel schwieriger wird, herauszufinden, wo die Pakete auf dem Weg zwischen Quelle und Ziel verloren gehen. Und um es deutlich zu sagen: Eine Lösung für so ein Problem hab ich noch nie gesehen. Wenn man feststellt, dass man es hat, kann man eigentlich nur drumzu arbeiten.

    UDP Test:


    vom Wireguard Server zum lokalen Telekom Glasfaser



    vom Wireguard Client (lokaler Telekom Anschluss) zum Wireguard Server


    Hier auch nochmal ein Test zu google vom Wireguard Server

    Code
    mtr -u -s 1000 -r -c 200 8.8.8.8
Start: 2023-12-08T09:42:43+0100
HOST: gw0                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 193.30.0.0                 4.5%   200    0.6   2.1   0.3  65.1   6.5
  2.|-- ae3-4019.bbr02.anx84.nue.  1.5%   200    0.7   2.3   0.6  46.6   4.7
  3.|-- ae0-0.bbr01.anx84.nue.de.  0.5%   200    4.3   5.1   3.9  32.3   3.2
  4.|-- ae2-0.bbr02.anx25.fra.de.  2.5%   200    4.0   4.7   3.8  26.5   2.6
  5.|-- 209.85.149.86              2.5%   200    5.0   5.9   4.5  27.6   2.3
  6.|-- ???                       100.0   200    0.0   0.0   0.0   0.0   0.0
  7.|-- dns.google                94.0%   200    3.8   3.9   3.7   4.2   0.1


    Sehe ich das richtig, dass die Paketverluste bei Netcup liegen?

    Hier nochmal iperf udp