Wireguard Verständnisfrage

    "DDOS-Protection" ... da müsste - wie der Name schon sagt - von vielen verschiedenen Endpunkten viel UDP-Traffic einlangen.

    Die Wireguard UDP-Verbindungen betreffen aber klarerweise nur die vernetzten Endpunkte. Im Falle der Wireguard-Einbindung Heimnetzwerk mit vServer also 2 bis n ... aber das wars auch schon. Ich denke diese These ist nicht zutreffend. Man könnte auch den UDP-Port auf etwas legen was "well known" UDP-Traffic in großer Menge üblicherweise liefert, z.B. 443 (für dtls üblich bei anderen VPN-Clients wie z.B. Cisco).

    Habe sowas auch noch nicht gehabt und habe eine Falschannahme der Netcup-FW auch bisher nicht für möglich eingeschätzt, weil bei Standard-dDoS schon deutlich höhere Lasten erzeugt werden.

    Hatte mal ein wenig Zeit, um mit einem etwas leistungsfähigen VPS zu testen. Der Client ist mit 10Gb/s angebunden. Max Speed per WireGuard rund 1GB/s. Dabei ist mir aufgefallen, dass ein Kern auf dem WireGuard Server bei 100% lag, die restlichen 11 Kerne bei rund 8%. WireGuard sollte doch pro Peer Multi Cores fähig sein oder woher kommt die hohe Auslastung von einem Kern ?

    Quote from Hille

    Der Client ist mit 10Gb/s angebunden. Max Speed per WireGuard rund 1GB/s.

    1 Gigabyte pro Sekunde wäre doch gar nicht so schlecht bei einer 10 Gigabit Anbindung? :/


    Oder war das große "B" ein Tippfehler?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Like 2
    Quote from cltrmx

    Ich habe mal eine ganz andere Frage an die Leute unter euch, die WireGuard auf einem VPS/Root Server verwenden, um Traffic nach hause und umgekehrt zu tunneln: Selbst verwende ich auch einen solchen Tunnel um Services, die ich zu Hause hoste, von außen erreichbar zu machen. Das führt aber unter Umständen dazu, dass NetCups DDOS-Protection anschlägt, weil eben ein paar hundert Mbps UDP-Traffic auf den VPS einprasseln.


    Habt ihr so etwas auch schon beobachtet und falls ja, gibt es eine Abhilfe dafür?

    Ich beobachte dasselbe, wenn ich per Wireguard VPN von meinem Firmennetzwerk etwas herunterladen will und es ist extrem ärgerlich, denn die Blockade ist irrational, weil es offensichtlich kein Angriff ist, sondern ein fortlaufender Datenstrom von einer einzigen IP Adresse (des VPN Servers). Netcup drosselt dann auf 10Mbit/s, nach 5 Minuten gibt es ein Update per Mail, manchmal noch ein zweites nach 10 Minuten und nach ca. 15 Minuten wird die Blockade aufgehoben, bis sie wieder anspringt.


    Das sieht dann folgendermaßen aus:

    Screenshot_2025-09-24_14-04-43.png


    Die Mail sieht dann so aus:

    Der Support ist leider auch nicht hilfreich, ich habe gebeten, den DDoS Schutz zu deaktivieren weil es offensichtlich kein DDoS ist, der von einer einzigen IP ausgeht, doch das scheint nicht zu gehen. Auf 10Mbit/s kann man ja offensichtlich begrenzen, die 1Gbit/s gehen nicht, auch wenn bei mir nur maximal diese ankommen. Leider kenne ich mich nicht im Detail mit dem Wireguard Protokoll aus, kann mir aber nicht vorstellen, dass der Gegenpart mit angeblich bis zu 20Gbit/s verschickt, wenn mein RS nur 1Gbit/s entgegennehmen kann.

    Quote

    Guten Tag *****,

    vielen Dank für Ihre Anfrage.

    Der DDoS-Filter dient dem Schutz unserer Infrastruktur und kann daher nicht deaktiviert werden. Sie können lediglich versuchen, den Datenstrom so zu verändern, dass der DDoS-Filter nicht mehr auslöst, z.B. durch eine Bandbreitenbegrenzung.

    Mit freundlichen Grüßen,

    netcup Team

    Ich habe auch schon manuell versucht, die Bandbreite Serverseitig zu begrenzen, doch es nützt nichts...

    Bash
    #!/bin/bash
export IF_INET=eth0
export LIMIT=1000Mbit

tc qdisc add dev ${IF_INET} ingress

tc filter add dev ${IF_INET} protocol ip ingress prio 2 u32 match ip dst 0.0.0.0/0 action police rate ${LIMIT} burst ${LIMIT}
tc filter add dev ${IF_INET} protocol ip ingress prio 2 u32 match ip src 0.0.0.0/0 action police rate ${LIMIT} burst ${LIMIT}

    Mittlerweile tippe ich auf einen Bug im Reporting seitens Netcup.

    Quote from m-k

    Auf 10Mbit/s kann man ja offensichtlich begrenzen, die 1Gbit/s gehen nicht, auch wenn bei mir nur maximal diese ankommen. Leider kenne ich mich nicht im Detail mit dem Wireguard Protokoll aus, kann mir aber nicht vorstellen, dass der Gegenpart mit angeblich bis zu 20Gbit/s verschickt, wenn mein RS nur 1Gbit/s entgegennehmen kann.

    Wireguard läuft i.d.R. über UDP. Die Senderseite muss hier dann den Traffic begrenzen. Ein Limit (Hard & Softwareseitig) auf Empfängerseite führt jetzt nicht automatisch dazu, dass die Senderseite die Senderate reduziert. D.h. wenn deine Sendeseite ein 10Gbit Anschluss hat, machst im Zweifel dein 10Gbit Link voll wenn die Sende-CPU das schafft.

    ~ RS4000 9.5G ; VPS 200 G10s ; 2 x ; VPS nano G11s ; 3 x VPS 3000 ARM G11 ; 6 x VPS 2000 ARM G11 (200% SSD)

    Nicht auszuschließen, dass irgendwo Bits und Bytes verwechselt werden, aber die Paketanzahl passt schon zu der exzessiven Bandbreite. Wenn du die Trafficbegrenzung auf dem Server machst, der angeblich zu viel schickt, dann ist die für die falsche Richtung konfiguriert (ingress). Wenn du sie auf dem Server machst, der den Traffic empfangen soll, dann ist die Begrenzung auf der falschen Seite der Verbindung.


    Um zu sehen, ob die Begrenzung wirklich greift, solltest du die erstmal deutlich unterhalb der verfügbaren Bandbreite festsetzen.


    Normalerweise sollte das im Tunnel verwendete Protokoll dafür sorgen, dass die Sendebandbreite an die real verfügbare Bandbreite angepasst wird, aber wenn du da z.B. mit iPerf draufballerst, dann kannst du auch mehr senden, als das Ziel empfangen kann. Monitore doch mal, was aus der angeblichen DoS-Quelle rausgeht.

    Ich habe die Begrenzung auf Empfängerseite gemacht, daher ingress.

    Quote from NaN

    Normalerweise sollte das im Tunnel verwendete Protokoll dafür sorgen, dass die Sendebandbreite an die real verfügbare Bandbreite angepasst wird, aber wenn du da z.B. mit iPerf draufballerst, dann kannst du auch mehr senden, als das Ziel empfangen kann. Monitore doch mal, was aus der angeblichen DoS-Quelle rausgeht.

    Leider habe ich keinen Einfluss auf die Senderseite, nur einen Account, über den ich leider nichts einstellen kann... Beim Heimanschluss (Kabel) mit 1Gbit/s gibts aber nie Probleme, mein ISP hat sich noch nie beschwert und da habe ich schon etliche Stunden mit vollen 1Gbit/s über denselben Wireguard Tunnel geladen.

    Ich rate mal ins Blaue: Läuft da eine Seedbox und der Traffic im Tunnel sind Torrents, die bekanntlich mit sehr vielen Verbindungen eine Herausforderung für QoS sind?


    Vorschlag zum Testen: Begrenze die Bandbreite inbound auf einen kleinen Wert, der klar unterhalb der zur Verfügung stehenden Bandbreite ist. Dann schau nach, wie viel Bandbreite inbound auf dem Device ankommt, also vor der bremsenden Queue. Wenn das signifikant mehr als hinter der Queue ist, dann funktioniert das Traffic Management ausgehend dort nicht.

    Quote from NaN

    Ich rate mal ins Blaue: Läuft da eine Seedbox und der Traffic im Tunnel sind Torrents, die bekanntlich mit sehr vielen Verbindungen eine Herausforderung für QoS sind?


    Vorschlag zum Testen: Begrenze die Bandbreite inbound auf einen kleinen Wert, der klar unterhalb der zur Verfügung stehenden Bandbreite ist. Dann schau nach, wie viel Bandbreite inbound auf dem Device ankommt, also vor der bremsenden Queue. Wenn das signifikant mehr als hinter der Queue ist, dann funktioniert das Traffic Management ausgehend dort nicht.

    Nein, keine Torrents, eine einzige statische Quelle, gemounted als Laufwerk per rclone.

    Ich werde die Bandbreitenbeschränkung mal auf 500Mbit setzen und schauen, was passiert...