22
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 21444201805
Url: https://administrator.de/contentid/21444201805
Printed on: June 20, 2024 at 12:06 o'clock
22 Comments
Latest comment
Ich schließe mich diesem Problem an.
Allerdings haben wir einen Wireguard Site to Site Tunnel mit pfSense an beiden Endpunkten.
Liegts am Protokoll an sich??
Allerdings haben wir einen Wireguard Site to Site Tunnel mit pfSense an beiden Endpunkten.
Liegts am Protokoll an sich??
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
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
1
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 @hempel 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 @hempel 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...
Moin,
danke @hempel ! An die MTU habe ich überhaupt nicht gedacht. Musste ich bisher noch nie ändern.
Ich hab also fix mit dem Powershell Cmdlet Test-Connection -MtuSize die Verbindungen überprüft.
Ergebniss zu meiner Fritzbox: 1472, also alles OK.
Die Ergebnisse zu Clients im Netz meiner Eltern: 1392, auch das macht Sinn.
Das Ergebniss zu der Fritzbox meiner Eltern ist allerdings 1172. Woher diese niedrige Zahl kommt erschließt sich mir noch nicht. Ich habe dann versucht die MTU in den Wireguard Configs bei den beiden Clients und dem Server zu ändern. Von 1100 bis 1390 habe ich in 10/20er Schritten fast alles ausprobiert. Immer überall geändert und dann per wg-quick down bzw up neugestartet. Über einen Ping mit definierter Größe konnte ich auch das Ergebnis sehen. An der Situation hat dies allerdings leider nichts geändert. Auch deaktiviertes LargeSendOffload ändert nichts. Aber das Problem besteht ja weiterhin, auch auf dem iPhone. Gestern habe ich noch nach schreiben der Frage gemerkt, dass die Verbindung von einer Windows 10 (Tiny10) VM auf meinem Proxmox Host zu meinem Eltern ohne Probleme klappt; komisch. Wie auf den Linux Kisten.
Achso und auch an der Hardware liegt es nicht die ist zu max 2% ausgelastet. Laut htop.
So nun zu @aqui
auf deine CopyPasta à la "les meine Wireguard Anleitung" habe ich schon gewartet. Hier wird das Einstellen der MTUs leider nicht behandelt bzw. in einem verlinkten Artikel nur OpnSense spezifisch.
Du hast erkannt, beide Fritzboxen haben nur einen DS-Lite Anschluss sonst wäre alles viel einfacher. Auf die Wireguard Funktion der Fritzbox wollte ich bewusst verzichten, da ich kein Bock auf die von dir erwähnten AVM Eigenheiten habe.
Die Wireguard configs hatte ich bewusst nicht gepostet, das ich den Thread nicht so zuspammen wollte und es sich auch um eine default config ohne NAT und iptables Regeln handelt. Der Tunnel an sich funktioniert ja auch. Dir zu liebe kann ich sie hier aber anonymisiert posten. (jetzt mit Beispiel einer MTU von 1300):
Hier habe ich auch nochmal die Routen in den jeweiligen Fritzboxen. Vielleicht hilft das ja bei der Fehlersuche. Mir fallen aber keine auf. Wie gesagt, Verbindung grundsätzlich geht ja.
Bei mir:
Bei meinen Eltern:
Sobald ich mich mit meinem PC in das WG-Netzwerk einbinde geht alles ohne Probleme. Auch von RasPi zu Raspi macht ein iperf ca. 100mbit+. Auch von meinem Raspi zu einem normalen Client bei meinen Eltern geht der iperf in beide Richtungen mit 100mbit+. Sobald es aber dann von einem anderen Client aus meinem Netz probiert wird und dieser nicht Linux ist, bricht der Test ab. Mit meinem Arch Laptop geht der iperf auch mit 100mbit+. Ich sehe hier einfach keinen Zusammenhang. Die Fritzbox unterscheidet doch nicht zwischen Betriebssystemen?? Und auch komisch dass es dann von der einen Windows VM von meinem Proxmox aus geht. Das grenzt ja schon an Willkürlichkeit...
Vielleicht hat ja noch wer Ideen.
Im nächsten Schritt werde ich wohl mal den Traffic mit Wireguard analysieren und gucken ob das mit der Packetgröße soweit ok ist.
Gruß
MrSNA
danke @hempel ! An die MTU habe ich überhaupt nicht gedacht. Musste ich bisher noch nie ändern.
Ich hab also fix mit dem Powershell Cmdlet Test-Connection -MtuSize die Verbindungen überprüft.
Ergebniss zu meiner Fritzbox: 1472, also alles OK.
Die Ergebnisse zu Clients im Netz meiner Eltern: 1392, auch das macht Sinn.
Das Ergebniss zu der Fritzbox meiner Eltern ist allerdings 1172. Woher diese niedrige Zahl kommt erschließt sich mir noch nicht. Ich habe dann versucht die MTU in den Wireguard Configs bei den beiden Clients und dem Server zu ändern. Von 1100 bis 1390 habe ich in 10/20er Schritten fast alles ausprobiert. Immer überall geändert und dann per wg-quick down bzw up neugestartet. Über einen Ping mit definierter Größe konnte ich auch das Ergebnis sehen. An der Situation hat dies allerdings leider nichts geändert. Auch deaktiviertes LargeSendOffload ändert nichts. Aber das Problem besteht ja weiterhin, auch auf dem iPhone. Gestern habe ich noch nach schreiben der Frage gemerkt, dass die Verbindung von einer Windows 10 (Tiny10) VM auf meinem Proxmox Host zu meinem Eltern ohne Probleme klappt; komisch. Wie auf den Linux Kisten.
Achso und auch an der Hardware liegt es nicht die ist zu max 2% ausgelastet. Laut htop.
So nun zu @aqui
auf deine CopyPasta à la "les meine Wireguard Anleitung" habe ich schon gewartet. Hier wird das Einstellen der MTUs leider nicht behandelt bzw. in einem verlinkten Artikel nur OpnSense spezifisch.
Du hast erkannt, beide Fritzboxen haben nur einen DS-Lite Anschluss sonst wäre alles viel einfacher. Auf die Wireguard Funktion der Fritzbox wollte ich bewusst verzichten, da ich kein Bock auf die von dir erwähnten AVM Eigenheiten habe.
Die Wireguard configs hatte ich bewusst nicht gepostet, das ich den Thread nicht so zuspammen wollte und es sich auch um eine default config ohne NAT und iptables Regeln handelt. Der Tunnel an sich funktioniert ja auch. Dir zu liebe kann ich sie hier aber anonymisiert posten. (jetzt mit Beispiel einer MTU von 1300):
#Server:
[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = asdasd
MTU = 1300
[Peer]
PublicKey = asdasd
AllowedIPs = 10.1.1.2/32, 192.168.1.0/24
[Peer]
PublicKey = asdasd
AllowedIPs = 10.1.1.6/32, 192.168.6.0/24
#Zuhause:
[Interface]
PrivateKey = asdasd
Address = 10.1.1.2/24
MTU = 1300
[Peer]
PublicKey = asdasd
Endpoint = asd.asd:51820
AllowedIPs = 10.1.1.0/24, 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.0/24, 192.168.1.0/24
PersistentkeepAlive = 25Hier habe ich auch nochmal die Routen in den jeweiligen Fritzboxen. Vielleicht hilft das ja bei der Fehlersuche. Mir fallen aber keine auf. Wie gesagt, Verbindung grundsätzlich geht ja.
Bei mir:
Sobald ich mich mit meinem PC in das WG-Netzwerk einbinde geht alles ohne Probleme. Auch von RasPi zu Raspi macht ein iperf ca. 100mbit+. Auch von meinem Raspi zu einem normalen Client bei meinen Eltern geht der iperf in beide Richtungen mit 100mbit+. Sobald es aber dann von einem anderen Client aus meinem Netz probiert wird und dieser nicht Linux ist, bricht der Test ab. Mit meinem Arch Laptop geht der iperf auch mit 100mbit+. Ich sehe hier einfach keinen Zusammenhang. Die Fritzbox unterscheidet doch nicht zwischen Betriebssystemen?? Und auch komisch dass es dann von der einen Windows VM von meinem Proxmox aus geht. Das grenzt ja schon an Willkürlichkeit...
Vielleicht hat ja noch wer Ideen.
Im nächsten Schritt werde ich wohl mal den Traffic mit Wireguard analysieren und gucken ob das mit der Packetgröße soweit ok ist.
Gruß
MrSNA
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.
1
Yo ok habe die Config geändert. Wo siehst du den KeepAlive beim Server? Die habe ich doch nur bei den Clients?
Hier ist die neue Config mit den korrigierten AllowedIPs. Ich erhalte so genau das gleiche Ergebnis wie vorher nur dass ich von den Wireguard Clients jetzt nicht mehr in das WG Netzwerk pingen kann. Bzw. nur noch zum Server. Das sagt das /32 ja. Vorher konnte ich ja mit einem Ping zur 10.1.1.6 prüfen ob die Verbindung steht. Das mit dem /24 (nur in der client config) auf das gesamte WG Netzwerk funktioniert aber auch bei zwei anderen unabhängigen VPN Servern problemlos.
Oder habe ich dich falsch verstanden?
Hier ist die neue Config mit den korrigierten AllowedIPs. Ich erhalte so genau das gleiche Ergebnis wie vorher nur dass ich von den Wireguard Clients jetzt nicht mehr in das WG Netzwerk pingen kann. Bzw. nur noch zum Server. Das sagt das /32 ja. Vorher konnte ich ja mit einem Ping zur 10.1.1.6 prüfen ob die Verbindung steht. Das mit dem /24 (nur in der client config) auf das gesamte WG Netzwerk funktioniert aber auch bei zwei anderen unabhängigen VPN Servern problemlos.
#Server:
[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = asdasd
MTU = 1300
[Peer]
PublicKey = asdasd
AllowedIPs = 10.1.1.2/32, 192.168.1.0/24
[Peer]
PublicKey = asdasd
AllowedIPs = 10.1.1.6/32, 192.168.6.0/24
#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, 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, 192.168.1.0/24
PersistentkeepAlive = 25Wo 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?!
1
Das einzelne Eintragen mit den /32 er Adressen wollte ich durch die /24 vermeiden bzw. es mir einfacher machen face-wink. Jaja ich bin faul. Auf dem Server gibt es noch 8 weitere Clients die auch untereinander kommunizieren (habe ich zum testen rausgenommen). Mit dem 10.1.1.0/24 wollte ich sagen, dass einfach alle 256 IPs des WG-Netzes erlaubt sind (auch wenn es faktisch weniger sind). Es geht ja auch wenn man einfach nur 0.0.0.0/0 macht um den kompletten Traffic durchzuleiten. Wenn man theoretisch 255 Peers hätte wäre es ja egal ob ich die 255 Adressen einzeln mit /32 eintrage oder einmal /24 mache. Ist vielleicht nicht nach Best-Practice Anleitung, aber rein logisch müsste es ja gehen und mach für mich auch Sinn. Auf Serverseite MUSS natürlich die /32 stehen. Sonst kommt es zum Konflikt.
Das probieren mit deiner Config bestätigt meine Theorie. Ping zum Client geht wieder. Das ist klar. Problem besteht weiterhin.
Pings funktionieren mit Windows übrigens wunderbar. Danke trotzdem für den Tipp. Habe das aber vor Ewigkeiten schon mal eingestellt. Ich überprüfe meistens aber immer nochmal mit WSL Debian, einer Ubuntu VM und einem Mobilgerät.
Habe btw. jetzt mit Wireshark den Traffic ein bisschen angeguckt. Ich habe mal Screenshots angehängt. Es gibt ne menge Retransmissions. Zeigt ja glaube ich auch wieder dass da der Speed wieder mal nicht da ist. Iperf hat ja schon gezeigt, dass dieser meistens zwischen 0 und ab und zu im kb/s-Bereich liegt. Auf der Win10 VM gibt es das nicht. Da geht ja alles, obwohl die genau wie mein PC ein ganz "normaler" PC im Netz meiner Fritzbox ist.
Sollte ich nochmal mit der MTU rumprobieren und mal einen ganz niedrigen Wert z.b. 800 nehmen? Das bisherige experimentieren hat ja leider nicht geholfen.
Oder gibts noch andere Dinge oder Einstellungen die ich einfach gar nicht beachtet habe?
Sonst würde ich wohl oder übel doch nochmal die Variante über die Fritzboxen direkt probieren. Mir schaudert es nur davor, da es bei jeder Änderung mehrere Minuten braucht, bis die Box wieder Internet hat.
Wenn gar nichts hilft, kann ich ja zur Not immer noch auf den 5 Clients die miteinander kommunizieren sollen den WG-Client einzeln installieren. Fände ich nur ein bisschen doof und unnötig.
Gruß
MrSNA
Das probieren mit deiner Config bestätigt meine Theorie. Ping zum Client geht wieder. Das ist klar. Problem besteht weiterhin.
Pings funktionieren mit Windows übrigens wunderbar. Danke trotzdem für den Tipp. Habe das aber vor Ewigkeiten schon mal eingestellt. Ich überprüfe meistens aber immer nochmal mit WSL Debian, einer Ubuntu VM und einem Mobilgerät.
Habe btw. jetzt mit Wireshark den Traffic ein bisschen angeguckt. Ich habe mal Screenshots angehängt. Es gibt ne menge Retransmissions. Zeigt ja glaube ich auch wieder dass da der Speed wieder mal nicht da ist. Iperf hat ja schon gezeigt, dass dieser meistens zwischen 0 und ab und zu im kb/s-Bereich liegt. Auf der Win10 VM gibt es das nicht. Da geht ja alles, obwohl die genau wie mein PC ein ganz "normaler" PC im Netz meiner Fritzbox ist.
Sollte ich nochmal mit der MTU rumprobieren und mal einen ganz niedrigen Wert z.b. 800 nehmen? Das bisherige experimentieren hat ja leider nicht geholfen.
Oder gibts noch andere Dinge oder Einstellungen die ich einfach gar nicht beachtet habe?
Sonst würde ich wohl oder übel doch nochmal die Variante über die Fritzboxen direkt probieren. Mir schaudert es nur davor, da es bei jeder Änderung mehrere Minuten braucht, bis die Box wieder Internet hat.
Wenn gar nichts hilft, kann ich ja zur Not immer noch auf den 5 Clients die miteinander kommunizieren sollen den WG-Client einzeln installieren. Fände ich nur ein bisschen doof und unnötig.
Gruß
MrSNA
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.
2aber 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 @hempel schon alles gesagt.
So ok
Das ist der Trace von einer unabhängigen Linux Maschiene bei mir:
Das von meinem PC:
Und das von dem vServer:
Da ich auch von einem fresh install getestet hatte gibts da keine Programme die dazwischenfunken. Wie gesagt geht es ja auch von iOS und Android Clients genauso wenig.
Firewall ist auf dem vServer direkt keine. Alles aus bzw. Ubuntu Server default. Die Firewall wird von dem IONOS System gemacht. Da ist nur der Wireguard Port, ICMP und ssh offen. Auch die WG-Clients sind frische Ubuntu Installationen.
NAT sollte ich eigentlich nicht haben. Iptables ist leer und auf default ACCEPT settings. ipv4 forwarding ist natürlich überall an. Auch route -n zeigt die korrekten von wireguard erstellten routen auf den clients bzw. server.
Gruß
MrSNA
Das ist der Trace von einer unabhängigen Linux Maschiene bei mir:
root@proxy-manager:~# traceroute 192.168.6.1
traceroute to 192.168.6.1 (192.168.6.1), 30 hops max, 60 byte packets
1 fritz.box (192.168.1.1) 0.260 ms 0.227 ms 0.366 ms
2 SNA-wireguardclient.fritz.box (192.168.1.16) 0.433 ms 0.421 ms 0.408 ms
3 10.1.1.1 (10.1.1.1) 39.374 ms 39.361 ms 39.350 ms
4 10.1.1.6 (10.1.1.6) 57.767 ms 57.557 ms 58.432 ms
5 192.168.6.1 (192.168.6.1) 58.673 ms 58.417 ms 58.572 msDas von meinem PC:
PS C:\Users\silas> tracert 192.168.6.1
Routenverfolgung zu 192.168.6.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms fritz.box [192.168.1.1]
2 <1 ms <1 ms <1 ms SNA-wireguardclient.fritz.box [192.168.1.16]
3 40 ms 42 ms 40 ms 10.1.1.1
4 57 ms 59 ms 57 ms 10.1.1.6
5 58 ms 57 ms 59 ms 192.168.6.1
Ablaufverfolgung beendet.Und das von dem vServer:
root@ubuntu:~# traceroute 192.168.6.1
traceroute to 192.168.6.1 (192.168.6.1), 30 hops max, 60 byte packets
1 10.1.1.6 (10.1.1.6) 17.928 ms 18.071 ms 18.470 ms
2 192.168.6.1 (192.168.6.1) 18.459 ms 18.669 ms 18.655 msDa ich auch von einem fresh install getestet hatte gibts da keine Programme die dazwischenfunken. Wie gesagt geht es ja auch von iOS und Android Clients genauso wenig.
Firewall ist auf dem vServer direkt keine. Alles aus bzw. Ubuntu Server default. Die Firewall wird von dem IONOS System gemacht. Da ist nur der Wireguard Port, ICMP und ssh offen. Auch die WG-Clients sind frische Ubuntu Installationen.
NAT sollte ich eigentlich nicht haben. Iptables ist leer und auf default ACCEPT settings. ipv4 forwarding ist natürlich überall an. Auch route -n zeigt die korrekten von wireguard erstellten routen auf den clients bzw. server.
Gruß
MrSNA
Oh gerade erst gesehen, dass @aqui auch noch kommentiert hatte. Danke nochmal für die Erklärung. Ich werd mich da bei Zeiten mal reinfuchsen.
Aber warum sollte ich hier nicht rumprobieren dürfen?? Hier geht es ganz klar um ein Freizeit-/Spaß- und Lernprojekt. Es geht überhaupt nicht um irgendwelche wichtigen Daten oder so etwas. Selbst wenn mir hier jeder Server abraucht und ich alle PCs und Fritzboxen resetten müsste wäre das kein Problem. Das was ich hier habe sind ein paar unwichtige Daten, Gameserver und Spielereien. Alles was wirklich wichtig ist, ist so gesichert, dass es nicht kaputt gehen kann.
Gruß
Aber warum sollte ich hier nicht rumprobieren dürfen?? Hier geht es ganz klar um ein Freizeit-/Spaß- und Lernprojekt. Es geht überhaupt nicht um irgendwelche wichtigen Daten oder so etwas. Selbst wenn mir hier jeder Server abraucht und ich alle PCs und Fritzboxen resetten müsste wäre das kein Problem. Das was ich hier habe sind ein paar unwichtige Daten, Gameserver und Spielereien. Alles was wirklich wichtig ist, ist so gesichert, dass es nicht kaputt gehen kann.
Gruß
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?2Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 2564K packets, 5762M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationWenn alles richtig funktioniert könnte ich mich auch mal um ne richtige Firewall config kümmern. Hab halt alles auf Standard gelassen um es so einfach wie möglich zu halten für den Moment und mir nicht irgendwelche "Programme die dazwischenfunken" einzubauen.
Ich hätte auch noch ne Kiste bei Oracle (Free Tier) in Frankfurt. Das Routing dort ist allerdings dermaßen kompliziert, dass ich da mit VPN erstmal nicht ran wollte.
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.
3
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?
Gab keine Lösung. Thema geschlossen!
PEBKAC Problem!!
1
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 ....
1
Full ACK 👍
Die „richtige“ Lösung ist es ja die Site2Site Verbindung über die Gateways also die Fritzboxen laufen zu lassen. Das funktioniert. Und ja, tatsächlich ist mein Durchhaltevermögen nach 2 Wochen nahezu durchgehender Recherche auch mal erschöpft und ich habe auch keine Lust den ganzen Tag vor dem Computer zu sitzen. Dazu ist mir dann meine Zeit doch zu schade, denn ich habe auch noch ein Leben außerhalb des Internets. Danke nochmal für die Tipps. Einiges habe ich dadurch dazugelernt.
Warum jetzt hier wieder auf „der Jugend“ rumgehackt wird verstehe ich dann nicht. Ich sehe es auf jeden Fall nicht ein mehrere Wochen für ein Spaßprojekt zu investieren, was am Ende für mich keinen Mehrwert hat.
Wenn ihr das anders seht ist das eure Meinung.
Gruß
Warum jetzt hier wieder auf „der Jugend“ rumgehackt wird verstehe ich dann nicht. Ich sehe es auf jeden Fall nicht ein mehrere Wochen für ein Spaßprojekt zu investieren, was am Ende für mich keinen Mehrwert hat.
Wenn ihr das anders seht ist das eure Meinung.
Gruß
Du musst dich hier auch nicht für mangelnde Fachkenntnisse rechtfertigen. Wenn du die Zeit nicht investieren willst und lernen willst dann ist es halt so. Punkt. Das wird hier auch jeder verstehen.
Fakt ist nur das es an der HW bei einem richtigen VPN Setup natürlich nicht liegt.
Fakt ist nur das es an der HW bei einem richtigen VPN Setup natürlich nicht liegt.