wireguard sehr langsam

[thaistatos]

Hallo,

trotz Upgrade der Fritz 7490 zur 7590 ist der Wireguard Zugang (momentan) sehr langsam bis fast gar nicht zu gebrauchen..
Nach dem Umsteig funktionierte die neu erstellte conf Datei gar nicht, daher jetzt nochmal eine neue Wireguard conf Datei angelegt.
Die verbindet sich auch, das Heimnetz ist auch sehr langsam erreichbar. (Die lokale Webseite der Heizungssteuerung lässt sich erreichen).
Der Zugriff auf IObroker (der als lxc in Proxmox läuft) funktioniert nicht bzw. ist so langsam, dass der Seitenaufbau abbricht.
Bei der Heizungsseite tröpfeln wenige Byte rüber, mehr geht nicht.
Das Heimnetz/Fritzbox hängt an einem Deutsche Glasfaseranschluss mit ca. 600/200 Mbit.
Der entfernte Rechner hängt in einem Apartment mit WLAN Versorgung, ca. 15/5 Mbit, vermutlich ein Glasfaser Anschluss, der dann auf die Nutzer aufgeteilt wird.
(In der anderen Haupt Wohnung funktionierte wireguard mit der 7490 zumindest so, dass man auf Iobroker zugreifen konnte, die Verbindung kam aber manchmal nicht zustande, was u.a. der Grund für das Upgrade 7490 --> 7590 war).


In der Wireguard config habe ich die anderen Adressen gelöscht, so dass nur noch lokale Adressen über VPN laufen sollten:
...
AllowedIPs = 192.168.178.0/24
.....

anstelle von:
AllowedIPs = 192.168.178.0/24,0.0.0.0/0,fdd6:6cca:eb4a::/64,::/0

Wo könnte man noch etwas ändern oder weitersuchen bzw. fehlen Daten?

Fritz empfiehlt ipsec eigentlich nicht mehr, speziell wohl wegen fehlender IPv4 Erreichbarkeit, sonst hätte ich das probiert.
Mit Wireguard auf Proxmox habe ich mich noch nicht beschäftigt, aber evtl. fraglich, ob es das Problem löst.

Ich will darüber nichts streamen oder große Datenmengen bewegen, es geht nur stabilen Zugriff auf die Hausautomatisierung.
Andere schreiben ja teilweise von Datenraten im 2 stelligen MBit Bereich, da bin ich meilenweit von entfernt.

Bild(er) als Vorschaubild(er) (siehe https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ ) eingebunden by stoney

 

[Hagen2000]

Die ULA deines Heimnetzes (Adresse beginnend mit fdd6:xxxx) solltest Du m. E. nicht rausnehmen, nur die beiden 0-Einträge.
Wie schauen die DNS-Zeilen deiner Konfigurationsdatei aus?

 

[thaistatos]

die Konfig sieht so aus:
[Interface]
PrivateKey = XXX
Address = 192.168.178.203/24,fdd6:6cca:eb4a::203/64
DNS = 192.168.178.1,fdd6:6cca:eb4a::4a5d:35ff:fecf:4b07
DNS = fritz.box

[Peer]
PublicKey = YYY
PresharedKey = ZZZ
AllowedIPs = 192.168.178.0/24,0.0.0.0/0,fdd6:6cca:eb4a::/64,::/0
Endpoint =AAA.myfritz.net:53508
PersistentKeepalive = 25

nach Änderung dann:
AllowedIPs = 192.168.178.0/24,fdd6:6cca:eb4a::/64

Die Änderung hat aber leider auch nichts gebracht.

Bei Zugriff z.B. auf IObroker unter 192.168.178.61:8006 sieht man, dass einfach gar keine Daten übertragen werden.
Bei Zugriff auf die Heizung über http://192.168.178.65/ funktioniert es (hinreichend schnell).
Wenn ich die Nullen wieder aus der Konfig nehme, würde ja alles über WG laufen, dann funktioniert aber gar nichts mehr.

 

[Hagen2000]

Wenn ich die Nullen wieder aus der Konfig nehme

Ist klar, Du möchtest einen Split-Tunnel. Aber normal ist das dennoch nicht.
Welche Adresse hat denn das Netz, aus dem heraus Du den Tunnel aufbaust? Das darf natürlich nicht auch die Adresse 192.168.178.0/24 haben.
Und hast Du dort auch eine FRITZ!Box?

 

[thaistatos]

der PC hier hängt am WLAN der Appartment Anlage.
IPv6-Adresse: 2001:...
fdb8:...
Verbindungslokale IPv6-Adresse: fe80::...
IPv6-DNS-Server: fdb8:...
2001:...
IPv4-Adresse: 192.168.179.5
IPv4-DNS-Server: 192.168.179.1

Ich habe mir zum Spass wireguard auf dem Handy eingerichtet, was auch im gleichen WLAN hängt. Da scheint es zu funktionieren.

 

[Hagen2000]

Hm, schwierig. Das Netz 192.168.179.0/24 ist ja typischerweise das Gastnetz einer FRITZ!Box. Das kann eventuell auch zu den Problemen führen, da deine FRITZ!Box eventuell nicht richtig zwischen eigenem Gastnetz und deinem Appartment-WLAN unterscheiden kann (obwohl normalerweise zwischen Heimnetz und Gastnetz nicht geroutet wird, das sollte also eindeutig sein).
Andererseits läuft es mit deinem Handy, das deutet dann mehr in Richtung „Problem mit dem PC“.
Bleibt noch die Frage, ob das Appartment-WLAN etwas blockt. Hast Du auf dem Handy die selbe WG-Config verwendet wie auf dem PC?

 

[Erforderlich]

Deswegen bietet es sich immer an, die Standard-IP-Bereiche der eigenen Fritzbox (rechtzeitig) zu ändern.
Man findet immer genug Bekannte/Freunde/Firmen, aus deren 178er Haupt- (und? 179-Gast-)Netz das VPN nicht routen kann.

 

[thaistatos]

jetzt nochmal WG auf einem Tablett installiert, auch da funktioniert es.
Die conf Datei ist bei allen gleich (aber nicht parallel aktiv).
Alle drei Geräte hängen im .179. WLAN des Apartment.
Es funktioniert ja auch nicht gar nicht, sondern vom PC aus stark eingeschränkt. Bei harten Konflikten hätte ich keinerlei Funktion erwartet.

Kann man an dem Broadcom 802.11ac Network Adapter noch etwas einstellen, es scheint ja ausschließlich am PC zu liegen.

 

[Hagen2000]

Gibt es auch die Möglichkeit, über Kabel ins Appartment-LAN zu gehen? Oder kannst Du den PC mal in einem anderen WLAN (Büro oder bei Freunden) versuchsweise betreiben?
Das Problem mit dem kollidierenden Gastnetz trat mal beim Einrichten einer IPSec-Verbindung zwischen zwei FRITZ!Boxen auf, aber das ist auch schon einige Jahre her und dabei lief dann auch wirklich gar keine Kommunikation über den Tunnel. Deine Tests mit Mobilgeräten sprechen ja auch gegen diese Theorie.

 

[thaistatos]

Leider gibt es im Apartment keinen LAN Anschluss.
Der Tip scheint es aber gewesen zu sein:
Der Rechner steht jetzt wieder kurzfristig an seinem Hauptwohnsitz (Unitymedia/Vodafone Kabelanschluss).
Speedtest über LAN: 500/25
Wireguard mit LAN: 100/25
Speedtest über WLAN: 7/25
Wireguard mit WLAN: 6/25

Die WLAN Verbindung sagt: 866/173 (steht direkt nebem der Unitymedia Box)

Also nächster Schritt: anderen WLAN Stick oder Karte besorgen.

 

[Hagen2000]

Um Treiberprobleme auszuschließen könntest du den PC mal mit einem Live-Linux booten und damit das WLAN testen.

 

[thaistatos]

ich werd noch verrückt.
Jetzt steht der Rechner im Haus, auf das die WG Verbindung zielt.
Da hängt er im WLAN AX 1200 Repeater, der per LAN an die Fritzbox 7590 angebunden ist.
Down/Up: 135/132.
Hier funktioniert also WLAN wieder, nur eben nicht an der Unitymedia Box und im Apartment im vermutlchen Gäste WLAN einer Fritzbox (oder was auch immer).
Auch wenn das WLAN Modul somit eher nicht defekt zu sein schein, bleibt mangels Alternativen da kein anderer Weg als eine andere WLAN Verbindung.
Dazu:
Hier liegen noch ein 1750 Repeater und die alte Fritzbox 7490 rum.
Könnte man den Repeater per LAN anbinden, um die zweifelhafte Verbindung des Broadcom WLAN Moduls zu umgehen.
Oder die FB 7490 als Repeater einsetzen (ohne sie wie üblich an die andere FB zu koppeln (an die komme ich nicht dran).
Dritte Möglichkeit wäre ein WLAN USB Stick oder PCIe Karte.

 

[thaistatos]

jetzt im Apartment die Fritzbox 1750e als LAN Brücke angeschlossen. (Also Rechner--> LAN--> 1750--> WLAN --> vermutlich Fritzbox Apartment)
speedtest: 55/5 sollte also reichen.

Wireguard funktioniert trotzdem nur wieder langsam, also einfache SEite der Heizung lässt sich aufrufen, komplexere Seite von Proxmox gar nicht, Speedtest bricht ab, weil der Seitenaufbau zu langsam ist.

Da es in der anderen (Haupt)-Wohnung funktionierte und mobile Geräte im WLAN hier auch, muss es irgendwas am Rechner sein. Nur funktioniert der Rechner auch mit WG, wenn er in einem anderen LAN/WLAN hängt.

Wenn ich WG so konfiguriere, dass nur lokale Adressen über WG laufen, funktioniert der Speedtest, also kann es eigentlich auch nicht an der WLAN Konfig liegen.

Also alles ausgeschlossen, was mir einfällt, funktioniert trotzdem nicht.....

edit: es wird immer verrückter:
manche Seiten kann ich auch mit WG aufrufen, z.B. tagesschau.de, da werden beim surfen auch 50-60 MiB übertragen. Andere Seiten hingegen funktionieren gar nicht. Bei den nicht funktionierenden Internetseiten meldet firefox: TLS handshake wird durchgeführt, danach kommt Abbruch wegen Zeitüberschreitung.

 

[Hagen2000]

Vielleicht liegt es an der MTU - Du könntest mal in der Richtung recherchieren. Beispiel (erster Treffer aus Google „Wireguard MTU“): https://schroederdennis.de/vpn/wireguard-mtu-size-1420-1412-best-practices-ipv4-ipv6-mtu-berechnen/

 

[thaistatos]

scheint auf den ersten Blick leider auch nichts zu bringen.

Momentan sieht es so aus, bei aktiver WG Verbindung:

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
9 35 1300 disconnected Drahtlosnetzwerkverbindung
66 0 1420 connected wireguard1
21 25 1500 disconnected LAN-Verbindung* 12
2 25 1500 disconnected LAN-Verbindung* 4
1 75 4294967295 connected Loopback Pseudo-Interface 1
10 35 1500 connected VMware Network Adapter VMnet1
19 65 1300 disconnected Bluetooth-Netzwerkverbindung
6 35 1500 connected VMware Network Adapter VMnet8
20 25 1280 connected LAN-Verbindung
25 5 1300 disconnected LAN-Verbindung 2

LAN-Verbindung (Idx 20) war auch wie alle anderen 1300, Änderung auf 1280 oder 1200 hat nichts gebracht.
Größer geht auch nicht.

(Nebenschauplatz: auch ohne WG kommen manchmal beim Ping nur 75% an).

Fragen dazu:
1. Müssen die WG und die (in dem Fall) LAN Verbindung beide geändert werden? Hatte nur die LAN geändert.
2. Können die VMware Verbindungen stören? Da ist nichts im Hintergrund aktiv/es läuft keine VM.

EDIT:
das könnte die Lösung gewesen sein: die WG auch auf 1280 begrenzt, jetzt funktioniert es.
und die Frage, warum die 1280 funktionieren, die 1300 (beide, also WG und LAN) aber nicht mehr?

Wo die scheinbar normalen 1300 herstammen, weiß ich nicht. Allerdings passen sie, ping -f -l 1272 www.google.de (ohne WG) funktionierte, mit 1274 geht es nicht mehr.
Und wo die 1420 von WG herstammen, ist auch unbekannt. (vielleicht funktionieren die, wenn sonst 1500 genutzt wird)

 

[Hagen2000]

Eigentlich sollte die MTU automatisch ermittelt werden durch das Verfahren "Path MTU Discovery". Es kann vorkommen, dass das nicht funktioniert, weil an irgendeiner Stelle dafür benötigte ICMP-Pakete gefiltert werden. Dann muss man die MTU händisch anpassen (und sonst sollte man m. E. da nicht dran rumfummeln).

Und klar, Du musst natürlich die MTU für die WG-Verbindung anpassen und nicht die der LAN-Verbindung.

Dass Pings nicht zu 100% durchkommen, ist normal. Wenn Router belastet sind, dann ignorieren sie auch mal die eine oder andere Ping-Anfrage. Ping ist kein zuverlässiges "Messgerät".

Zur MTU-Größe findest Du im Netz und auch auf Wikipedia viele Informationen. Sie variiert mit dem IP-Protokoll (IPv4 oder IPv6), ob beim Internetanschluss ein externes Modem per PPoE angebunden wurde, ob ein IPSec-Tunnel dazwischen hängt usw. Jede Protokollschicht schneidet sich ein bisschen von der maximalen Paketgröße ab.

Problematisch wird das insbesondere bei VPN-Verbindungen, die in der Regel über UDP laufen, da UDP-Pakete nicht fragmentiert werden. Sind sie größer als die MTU, werden sie verworfen und wenn dann die Path MTU Discovery nicht funktioniert, entstehen die von Dir beschriebenen Probleme.

 

[Erforderlich]

Path MTU Discovery

... hatte beim nativen L2TP/IPsec wohl regelmäßig gut funktioniert, aber nach/mit einer meiner letzten frischen Win11/25H2-Installation gar nicht mehr richtig. Nach einem der folgenden Updates war es dann nicht mehr reproduzierbar, aber ich habe dann den manuell angepassten TunnelMTU-Wert trotzdem nicht mehr gelöscht/geändert. Man kann sich also nicht mehr auf Path MTU Discovery verlassen, auch wenn man beide Enden des Tunnels "unter Kontrolle" hat.
Die über VPN aufgetretenen Probleme waren übrigens nicht die üblichen, SMB lief nur etwas langsamer, aber HTTP/HTTPS-Verbindungen wollten überhaupt nicht.

Für das Testen und/oder "Herausfinden" der passenden MSS und MTU der L2TP/IPsec- und nun auch der Wireguard-Tunnel benutze ich mtupath.exe und mturoute.exe und natürlich nicht mit irgendwelchen sondern mit den Ziel-Servern.