Kuriose Probleme Wireguard Site-to-Site mit Geschwindigkeit bei Windows?
Moin, ich habe hier ein für mich kurioses Problem.
Seit neustem habe ich folgendes Setup:
Bei mir Zuhause und bei meinen Eltern habe ich jeweils einen Rasberry Pi als Wireguard Client. Diese verbinden sich zu einem vServer mit öffentlicher IP, zu dem ich mich auch von überall mit meinem Handy bzw. Laptop verbinden kann. Dazu wurde natürlich ipv4 forwarding überall aktiviert und die passende Route in die Fritzbox eingetragen.
Diese Verbindung funktioniert wunderbar. Die Wireguard Clients können problemlos alle Geräte in den beiden Netzwerken erreichen.
Aus Interesse wollte ich dann mal eine "richtige" Site-to-Site Verbindung aufbauen. Mir ist klar, dass man das eigentlich über die Router lösen sollte und auch die Sicherheit ist hier denke ich fraglich. Ich möchte das ganze nur ausprobieren um mein Wissen und Horizont zu erweitern.
So habe ich dann jeweils in die Fritzboxen eine neue Route eingetragen die Anfragen an das jeweils andere Netz an den Pi schicken. Dies Funktioniert auch direkt. Ich kann von beiden Seiten Geräte aus dem anderen Netz anpingen.
Jetzt zum kuriosen Problem:
Von der Seite meiner Eltern funktioniert alles Problemlos. Ich komme vom Handy, Tablet oder PC auf das NAS bei mir oder verschiedene Web-Interfaces von eigenen Services.
Wenn ich allerdings von meiner Seite aus versuche z.B. das Web Interface der Fritzbox oder meines Proxmox Backup-Servers (der bei meinen Eltern steht) aufzurufen, laden die Interfaces extrem langsam bzw. gar nicht. (Teils mehrere Minuten bis die Anmeldemaske der Fritzbox erscheint.
Ping, Traceroute oder Curl zu der Seite funktionieren problemlos im Bereich zwischen 50 und 60ms.
Ich habe bereits alle Router, PCs, und Pis neugestartet. Immernoch das selbe Problem.
Das Komische: Von meinem Linux Laptop aus, funktioniert das Laden der Websites problemlos und schnell.
Alle anderen Geräte die ich hier habe, haben das gleiche Problem wie mein Windows Rechner. Getestet wurde mit Windows 10, 11, iOS 17.5, iPadOS 16.2.2, Android 12 und Arch Linux. Auch in einer Ubuntu VM laden die Interfaces ohne Probleme.
Iperf3 zeigt vom Linux PC zu einer VM bei meinen Eltern ca 10-20 mbits.
Iperf3 zeigt von verschiedenen Windows PCs eine Geschwindigkeit von ab und zu 1.4 KBs.
Ich kann mir wirklich nicht erklären wie das zustande kommt. In eine Richtung funktioniert alles wunderbar und von meiner Seite gehen nur Linux Maschienen bzw. alles andere nur mit einer sehr sehr langsamen Verbindung wo zwar Pings funktionieren aber mehr auch nicht?? Gibt es da irgendeine bestimmte Fritzbox Einstellung? Ich kann mir da echt keinen Reim draus machen. Hatte vielleicht jemand schonmal ähnliche Probleme oder ist es mal wieder ein random Bug der Fritzbox? Anders kann ich es mir echt nicht erklären.
Grüße
MrSNA
Seit neustem habe ich folgendes Setup:
Bei mir Zuhause und bei meinen Eltern habe ich jeweils einen Rasberry Pi als Wireguard Client. Diese verbinden sich zu einem vServer mit öffentlicher IP, zu dem ich mich auch von überall mit meinem Handy bzw. Laptop verbinden kann. Dazu wurde natürlich ipv4 forwarding überall aktiviert und die passende Route in die Fritzbox eingetragen.
Diese Verbindung funktioniert wunderbar. Die Wireguard Clients können problemlos alle Geräte in den beiden Netzwerken erreichen.
Aus Interesse wollte ich dann mal eine "richtige" Site-to-Site Verbindung aufbauen. Mir ist klar, dass man das eigentlich über die Router lösen sollte und auch die Sicherheit ist hier denke ich fraglich. Ich möchte das ganze nur ausprobieren um mein Wissen und Horizont zu erweitern.
So habe ich dann jeweils in die Fritzboxen eine neue Route eingetragen die Anfragen an das jeweils andere Netz an den Pi schicken. Dies Funktioniert auch direkt. Ich kann von beiden Seiten Geräte aus dem anderen Netz anpingen.
Jetzt zum kuriosen Problem:
Von der Seite meiner Eltern funktioniert alles Problemlos. Ich komme vom Handy, Tablet oder PC auf das NAS bei mir oder verschiedene Web-Interfaces von eigenen Services.
Wenn ich allerdings von meiner Seite aus versuche z.B. das Web Interface der Fritzbox oder meines Proxmox Backup-Servers (der bei meinen Eltern steht) aufzurufen, laden die Interfaces extrem langsam bzw. gar nicht. (Teils mehrere Minuten bis die Anmeldemaske der Fritzbox erscheint.
Ping, Traceroute oder Curl zu der Seite funktionieren problemlos im Bereich zwischen 50 und 60ms.
Ich habe bereits alle Router, PCs, und Pis neugestartet. Immernoch das selbe Problem.
Das Komische: Von meinem Linux Laptop aus, funktioniert das Laden der Websites problemlos und schnell.
Alle anderen Geräte die ich hier habe, haben das gleiche Problem wie mein Windows Rechner. Getestet wurde mit Windows 10, 11, iOS 17.5, iPadOS 16.2.2, Android 12 und Arch Linux. Auch in einer Ubuntu VM laden die Interfaces ohne Probleme.
Iperf3 zeigt vom Linux PC zu einer VM bei meinen Eltern ca 10-20 mbits.
Iperf3 zeigt von verschiedenen Windows PCs eine Geschwindigkeit von ab und zu 1.4 KBs.
Ich kann mir wirklich nicht erklären wie das zustande kommt. In eine Richtung funktioniert alles wunderbar und von meiner Seite gehen nur Linux Maschienen bzw. alles andere nur mit einer sehr sehr langsamen Verbindung wo zwar Pings funktionieren aber mehr auch nicht?? Gibt es da irgendeine bestimmte Fritzbox Einstellung? Ich kann mir da echt keinen Reim draus machen. Hatte vielleicht jemand schonmal ähnliche Probleme oder ist es mal wieder ein random Bug der Fritzbox? Anders kann ich es mir echt nicht erklären.
Grüße
MrSNA
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 21444201805
Url: https://administrator.de/contentid/21444201805
Ausgedruckt am: 14.11.2024 um 05:11 Uhr
22 Kommentare
Neuester Kommentar
Moin.
Sofern du mit "Protokoll" Wireguard selbst meinst, nein, definitiv nicht. Hier laufen diverse Tunnel auf externen 1GBit/s Anbindungen fast mit Wirespeed. Wireguard ist wesentlich effizienter wie bspw. OpenVPN und liegt etwa auf dem Niveau wie IPSec wenn nicht noch besser.
Das Bild spricht für sich
Quelle: https://blog.ordix.de/wireguard
Solche Fehler rühren meist daher das entweder die MTU im Tunnel zu groß gewählt wird, oder die beteiligten Firewalls (Router als auch Client-Firewalls) die PMTU Ermittlung behindern wodurch es zu Paketfragmentierung und dadurch zu wiederholten Übermittlungen der Daten kommt. Passiert auch dann wenn kein durchgehendes ICMP Typ 3 mit Code 4 für die PMTU bis zum Client möglich ist.
Schön sehen kann man das mittels Wireshark und massiver Anzahl an TCP Retransmissions.
Auch ein gern gemachter Fehler ist wenn IPv6 über den Tunnel geschickt wird und die MTU ebenfalls zu groß ist.
Bei einer Ethernet-Leitung mit 1500bytes wäre die max. MTU bei IPv4 Only über den Tunnel bei max. 1440 bytes und bei IPv4+IPv6 über den Tunnel bei 1420, wegen des 40 byte IP Headers bei IPv6.
Wie gesagt das sind max. Werte, bei zusätzlichem PPPoE über DSL bspw. muss die MTU natürlich noch geringer ausfallen (-8 bytes), +evt. zusätzliche Dinge wie VLAN tags etc.
Eine Ping Ermittlung mit gesetztem do not fragment bit hilft hier die max. mögliche MTU zu ermitteln.
Etwas zu lesen
Die benutzte Hardware auf der die Wireguard-Endpunkte liegen sollte man auch nicht außer Acht lassen. Bevorzugt nutzt man hier CPUs die Hardware beschleunigte AES Unterstützung bietet. Denn wenn schon die CPU beim de-/encoding schlapp macht bringt die schnellste Internet-Leitung nichts.
Auch ein gern gemachter Fehler für geringen Durchsatz ist das aktivieren der Hardware-Unterstützung für TCP-RSS und Hardware-Offloading für die NICs in VMs wo es nicht supported ist.
Unter Windows haut auch gerne mal ein aktiviertes "LargeSendOffload" auf der NIC die Handbremse für VPN Links rein.
Bei pfSense/OPNSense &Co. sollte man auch die erweiteren Optionen für die Firewall-Optimization prüfen, die sind auch oft ein Faktor der einem den Durchsatz verschlechtern können, besonders das "Scrubbing" bei der pfSense ist gerne mal ein Übeltäter
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat. ...
Beachtet man diese Dinge ist Wireguard mit eines der effizientesten VPN Protokolle auf dem Markt. Fehler im Durchsatz sind meist immer hausgemacht, in wenigen Fällen kann aber auch der Internet-Provider schuld sein was man vorher durch entsprechende UDP Tests mit iperf auf dem selben Port den man mit Wireguard nutzen möchte ausschließen sollte.
Gruß hempel
Sofern du mit "Protokoll" Wireguard selbst meinst, nein, definitiv nicht. Hier laufen diverse Tunnel auf externen 1GBit/s Anbindungen fast mit Wirespeed. Wireguard ist wesentlich effizienter wie bspw. OpenVPN und liegt etwa auf dem Niveau wie IPSec wenn nicht noch besser.
Das Bild spricht für sich
Quelle: https://blog.ordix.de/wireguard
Solche Fehler rühren meist daher das entweder die MTU im Tunnel zu groß gewählt wird, oder die beteiligten Firewalls (Router als auch Client-Firewalls) die PMTU Ermittlung behindern wodurch es zu Paketfragmentierung und dadurch zu wiederholten Übermittlungen der Daten kommt. Passiert auch dann wenn kein durchgehendes ICMP Typ 3 mit Code 4 für die PMTU bis zum Client möglich ist.
Schön sehen kann man das mittels Wireshark und massiver Anzahl an TCP Retransmissions.
Auch ein gern gemachter Fehler ist wenn IPv6 über den Tunnel geschickt wird und die MTU ebenfalls zu groß ist.
Bei einer Ethernet-Leitung mit 1500bytes wäre die max. MTU bei IPv4 Only über den Tunnel bei max. 1440 bytes und bei IPv4+IPv6 über den Tunnel bei 1420, wegen des 40 byte IP Headers bei IPv6.
Wie gesagt das sind max. Werte, bei zusätzlichem PPPoE über DSL bspw. muss die MTU natürlich noch geringer ausfallen (-8 bytes), +evt. zusätzliche Dinge wie VLAN tags etc.
Eine Ping Ermittlung mit gesetztem do not fragment bit hilft hier die max. mögliche MTU zu ermitteln.
Etwas zu lesen
- https://de.m.wikipedia.org/wiki/Path_MTU_Discovery
- https://de.m.wikipedia.org/wiki/Internet_Control_Message_Protocol
- https://www.msxfaq.de/netzwerk/grundlagen/mtu.htm
Die benutzte Hardware auf der die Wireguard-Endpunkte liegen sollte man auch nicht außer Acht lassen. Bevorzugt nutzt man hier CPUs die Hardware beschleunigte AES Unterstützung bietet. Denn wenn schon die CPU beim de-/encoding schlapp macht bringt die schnellste Internet-Leitung nichts.
Auch ein gern gemachter Fehler für geringen Durchsatz ist das aktivieren der Hardware-Unterstützung für TCP-RSS und Hardware-Offloading für die NICs in VMs wo es nicht supported ist.
Unter Windows haut auch gerne mal ein aktiviertes "LargeSendOffload" auf der NIC die Handbremse für VPN Links rein.
Bei pfSense/OPNSense &Co. sollte man auch die erweiteren Optionen für die Firewall-Optimization prüfen, die sind auch oft ein Faktor der einem den Durchsatz verschlechtern können, besonders das "Scrubbing" bei der pfSense ist gerne mal ein Übeltäter
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat. ...
Beachtet man diese Dinge ist Wireguard mit eines der effizientesten VPN Protokolle auf dem Markt. Fehler im Durchsatz sind meist immer hausgemacht, in wenigen Fällen kann aber auch der Internet-Provider schuld sein was man vorher durch entsprechende UDP Tests mit iperf auf dem selben Port den man mit Wireguard nutzen möchte ausschließen sollte.
Gruß hempel
Wie leider sehr oft hat der TO zudem versäumt seine WG Konfig Dateien zum Thread zu posten was das ganze dann eher in Richtung Kristallkugelei abdriften lässt weil, man nicht beurteilen kann ob es ggf. noch Konfig Fehler im Crypto Routing usw. gibt was ja häufig aus Unkenntnis vorkommt.
In der Tat ist zu mindestens auf Seiten der Fritzbox 4060 ein separater WG Client völlig überflüssig und sinnfrei da dieses Modell die Firmware Verison 7.57 supportet und damit auch Wireguard.
Eine direkte Anbindung dieser FB an den Jumphost wäre da deutlich sinnvoller sofern man die AVM Eigenheiten der nicht ganz Standard konformen WG Implementation beim Setup beachtet!
Ein externer Jumphost ist auch nur dann erforderlich wenn beide! Anschlüsse DS-Lite Anschlüsse sind. Ist zumindestens der auf 4060er Seite (VPN Responder) dies nicht, wäre der externe Jumphost ebenso überflüssig...
Zum Rest hat Kollege @13034433319 schon alles gesagt!
Wie man das alles richtig macht erklärt das hiesige Wireguard Tutorial und seine weiterführenden Links im Detail und auch mit bunten Bildern...
Merkzettel: VPN Installation mit Wireguard
Lesen und verstehen...
In der Tat ist zu mindestens auf Seiten der Fritzbox 4060 ein separater WG Client völlig überflüssig und sinnfrei da dieses Modell die Firmware Verison 7.57 supportet und damit auch Wireguard.
Eine direkte Anbindung dieser FB an den Jumphost wäre da deutlich sinnvoller sofern man die AVM Eigenheiten der nicht ganz Standard konformen WG Implementation beim Setup beachtet!
Ein externer Jumphost ist auch nur dann erforderlich wenn beide! Anschlüsse DS-Lite Anschlüsse sind. Ist zumindestens der auf 4060er Seite (VPN Responder) dies nicht, wäre der externe Jumphost ebenso überflüssig...
Zum Rest hat Kollege @13034433319 schon alles gesagt!
Wie man das alles richtig macht erklärt das hiesige Wireguard Tutorial und seine weiterführenden Links im Detail und auch mit bunten Bildern...
Merkzettel: VPN Installation mit Wireguard
Lesen und verstehen...
An die MTU habe ich überhaupt nicht gedacht.
Muss man in der Regel auch nicht weil die im Default auf 1420 bei Wireguard gesetzt ist, was auch hinreichen niedrig für PPPoE Zugänge ist (1492 bzw. 1452 als LAN MSS Wert).Hier muss man also nur in seltenen Ausnahmefällen, wie dem doch sehr exotischen und gruselig niedrigen Wert bei den Eltern, aktiv werden.
Auf die Wireguard Funktion der Fritzbox wollte ich bewusst verzichten, da ich kein Bock auf die von dir erwähnten AVM Eigenheiten habe.
Was man gar nicht muss und auch etwas Torschlusspanik ist, denn bei einer einfachen Initiator Konfig zum externen Jumphost wie in deinem Szenario ist das lediglich ein popeliger Parameter der angepasst werden muss.Damit erhält man ein deutlich besseres Setup was einem die gesamte zusätzliche, stomfressende HW erspart. Aber, wie immer, letztlich eine individuelle und persönliche Entscheidung. Beide Optionen führen zum Erfolg.
Dir zuliebe kann ich sie hier aber anonymisiert posten.
Das machst du NUR zuliebe des Forums und der Teilnehmer die dir hier alle uneigennützig helfen wollen. Sie hat erfreulich wenige Fehler, nur wieder den - Im Gegensatz zum Server wo die internen AllowedIPs korrekt als /32er Masken angegeben sind hast du es bei den Client Peer Definitionen wieder prompt falsch gemacht und dort fälschlicherweise /24er Masken für interne IPs definiert. Damit funktioniert das Crypto Key Routing im Wireguard nicht korrekt! Das Tutorial weist explizit darauf hin...wenn man es denn mal in Ruhe liest und verinnerlicht!
Keepalives auf dem Server (Responder) zu konfigurieren ist völlig sinnfrei. Wenn, gehören die Keepalives einzig und allein NUR auf die WG Clients (Initiator). Nur die initiieren die Tunnelverbindungen und NUR die müssen dafür sorgen das diese mit UDP Keepalives offen bleiben.
Mir fallen aber keine auf.
Uns diese 2 üblichen Fehler natürlich sofort! Die o.a. Probleme resultieren aus dem fehlerhaft konfigurierten Crypto Key Routing bei den Client Setups.HIER findest du ein ähnliches Beispiel zur Orientierung.
Wo siehst du den KeepAlive beim Server?
Ich nehme alles zurück und behaupte das Gegenteil! Sorry... 🙈nur dass ich von den Wireguard Clients jetzt nicht mehr in das WG Netzwerk pingen kann.
Kein Wunder wenn du vergisst die WG Client IPs die in Tunnel geroutet werden müssen auch als /32 Host IPs einträgst. Sie das Beispiel von oben! Da kommt man aber eigentlich mit etwas Nachdenken auch selber drauf. #Zuhause:
[Interface]
PrivateKey = asdasd
Address = 10.1.1.2/24
MTU = 1300
[Peer]
PublicKey = asdasd
Endpoint = asd.asd:51820
AllowedIPs = 10.1.1.1/32, 10.1.1.6/32, 192.168.6.0/24
PersistentkeepAlive = 25
#Eltern:
[Interface]
PrivateKey = asdasd
Address = 10.1.1.6/24
MTU = 1300
[Peer]
PublicKey = asdasd
Endpoint = asd.asd:51820
AllowedIPs = 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24
PersistentkeepAlive = 25
Bedenke auch wenn du mit Winblows Clients agierst das dort die Windows Firewall generell im Default ICMP (Ping) Traffic blockiert!
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Gleiches gilt generell ebenso für aus fremden IP Netzen eingehenden Traffic. Auch der wird per Default immer geblockt sofern man die lokale Winblows Firewall nicht entsprechend customized.
Nur das du das auf dem Radar hast wenn du mit "nicht Linux" Clients arbeitest!!
funktioniert aber auch bei zwei anderen unabhängigen VPN Servern problemlos.
Funktioniert vielleicht ist aber de facto nach den Wireguard Vorgaben grundsätzlich falsch konfiguriert. (Siehe Wireguard Page)Wie sollte sonst auch ein spezifisches Routing unter WG möglich sein wenn man nicht präzise die Endgeräte Adressen vorgibt?!
Die Spurious Retransmissions und ausbleibenden TCP ACKs sehen für mich danach aus das einer der Raspis oder der vServer fälschlicherweise SRC-NAT über den Tunnel macht statt korrekterweise Routing zu verwenden.
Das wiederspräche aber dem das es unter Linux normal läuft, hmm. Mach unter Linux doch auch mal einen Trace und am vServer ebenfalls, nur mit Wireshark Bildern ist das hier leider etwas schwierig .
Firewall-Settings des vServer wären hier auch hilfreich.
Was ist alles auf den Windows Kisten installiert ,irgend ne Security Suite oder Firewall die da mist Baut? Alles was nicht nötig ist deaktivieren und aus dem Speicher schmeißen.
Das wiederspräche aber dem das es unter Linux normal läuft, hmm. Mach unter Linux doch auch mal einen Trace und am vServer ebenfalls, nur mit Wireshark Bildern ist das hier leider etwas schwierig .
Firewall-Settings des vServer wären hier auch hilfreich.
Was ist alles auf den Windows Kisten installiert ,irgend ne Security Suite oder Firewall die da mist Baut? Alles was nicht nötig ist deaktivieren und aus dem Speicher schmeißen.
aber rein logisch müsste es ja gehen und mach für mich auch Sinn.
Logisch geht es aber Sinn macht es nicht, denn ein individuelles Crypto Key Routing für die dedizierten internen Clients wird damit unmöglich. Für die müssen es verständlicherweise immer dedizierte Hostrouten sein. Das ist mit einer Schrotschussmaske technisch nicht möglich. Würde aber hier den Rahmen sprengen dir die Routing Grundlagen alle en Detail zu erklären.Sollte ich nochmal mit der MTU rumprobieren
Nein! Probieren ist in der IT keine wirklich gute Option...weisst du auch selber. Besser mit einem Test die maximale MTU wasserdich herausfinden das ist zielführender!!https://kb.netgear.com/de/19863/Ping-Test-zur-Ermittlung-der-optimalen-M ...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Usw. usw.
Zum Rest hat Kollege @13034433319 schon alles gesagt.
Die Firewall wird von dem IONOS System gemacht
Oha, keine gute Idee, wenn ich das höre klingeln bei mir die Ohren. Bei IONOS vServern erst recht, aber das ist ne andere Geschichte .NAT sollte ich eigentlich nicht haben
Sollte, hätte, könnte 🙃Iptables ist leer
Auch die nat table im POSTROUTING?
Diese virtuellen 1 Euro IONOS Kisten haben meist Probleme mit aktivem Hardware-TCP-Offloading auf den NICs. Das GenericReceiveOffloadHardware sollte man da generell abschalten. Das lassen die IONOS-Tuppen bei den Default-Images leider aktiviert, vermutlich damit die User genötigt werden größere Tarife zu buchen und der Traffic gering bleibt. You get what you pay 😉. Der Windows TCP-Stack reagiert leider oft zickig im Gegensatz zu den Linux Derivaten.
Des weiteren sollte man auch den TCP-Receive-Buffer bei erhöhter Latenz wie es hier der Fall ist auf dem vServer und den Raspis per sysctl.conf erhöhen sonst kommt es da quasi zum "Stau". Der ist standardmäßig optimiert für LAN Betrieb und nicht für Traffic mit Gegenstellen mit schwankender Latenz.
Des weiteren sollte man auch den TCP-Receive-Buffer bei erhöhter Latenz wie es hier der Fall ist auf dem vServer und den Raspis per sysctl.conf erhöhen sonst kommt es da quasi zum "Stau". Der ist standardmäßig optimiert für LAN Betrieb und nicht für Traffic mit Gegenstellen mit schwankender Latenz.
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Schade das die Jugend heute kein Durchhaltevermögen mehr besitzt.
Ich habe mir frührer die Nächte um die Ohren geschlagen und so lange weiter geforscht bis ein Problem gelöst war, dabei lernt man nämlich so viel mehr ....
Ich habe mir frührer die Nächte um die Ohren geschlagen und so lange weiter geforscht bis ein Problem gelöst war, dabei lernt man nämlich so viel mehr ....