07.11.2024, aktualisiert um 19:10:42 Uhr

1966

WireGuard: Instabile Verbindung zwischen Gateway und Client (über Server)

Hallo zusammen,

ich hoffe, hier auf jemanden zu treffen, der mir bei einem merkwürdigen Problem mit meiner WireGuard-Konfiguration weiterhelfen kann. Vielleicht hat jemand ähnliche Erfahrungen gemacht.

Ausgangssituation:

Server: Externer VPS mit 2.5 Gbit Anbindung
Client: 1 Gbit Down / 100 Mbit Up
Gateway im Heimnetzwerk: Linux-Server mit 1 Gbit Down / 100 Mbit Up

Verbindungen im Detail:

Client ↔ Server: Die Verbindung ist stabil und erreicht die maximale Geschwindigkeit, kein Problem hier.
Gateway ↔ Server: Ebenfalls stabil und schnell.
Problemfall: Gateway ↔ Client über den Server

Hier kommt es zu deutlichen Problemen: Die Verbindung ist extrem schwankend, meist nur 5–50 Mbit und alles andere als stabil. Bei iperf3-Tests zwischen Client und Gateway beobachte ich, dass die Übertragungsrate ständig hoch und runter geht. Oft sind es nur 20 Mbit oder weniger, manchmal steigen sie kurzzeitig auf 50-80 Mbit.

Was ich bereits versucht habe:

MTU-Optimierung: Die besten Ergebnisse konnte ich bisher mit einer MTU von 1280 erzielen. Jedoch ist das Problem damit nicht behoben.
Verschiedene Clients: Getestet habe ich unter Windows, Linux, Android und iOS – das Verhalten ist auf allen Plattformen gleich.
CPU-Auslastung geprüft: Auf allen beteiligten Systemen ist die CPU-Auslastung minimal und dürfte nicht der Grund für die Limitierungen sein.

Mein Ziel:
Ich möchte eine stabile, schnelle Verbindung vom Heimnetzwerk zu meinen Clients erreichen, sodass die Clients dabei auch die Internetverbindung des Heimnetzwerks nutzen können. Grundsätzlich erfüllt die aktuelle Konfiguration dieses Ziel, allerdings ist die Verbindung viel zu instabil, um darüber zu arbeiten.

Habt ihr eine Idee, was hier der Grund sein könnte oder Tipps, wie ich die Verbindung optimieren kann?

Danke vorab für jede Hilfe!

WG-Konfig Server:

[Interface]
Address = 10.22.33.1/24
PrivateKey = XXXX
ListenPort = 51820
MTU = 1280

# IPv4 Forwarding aktivieren
PreUp = sysctl -w net.ipv4.ip_forward=1

# nftables Regeln setzen
PostUp = nft add table ip nat
PostUp = nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
PostUp = nft add rule ip nat postrouting oifname "ens6" ip saddr 10.22.0.0/16 ip daddr != {10.22.0.0/16, 10.22.33.0/24} masquerade  

PostUp = nft add table ip filter
PostUp = nft add chain ip filter forward { type filter hook forward priority 0 \; }
PostUp = nft add rule ip filter forward iifname "wg0" oifname "ens6" ip daddr 10.22.0.0/16 accept  
PostUp = nft add rule ip filter forward iifname "ens6" oifname "wg0" ip saddr 10.22.0.0/16 accept  
PostUp = nft add rule ip filter forward iifname "wg0" oifname "wg0" ip saddr 10.22.33.0/24 ip daddr 10.22.33.0/24 accept  
PostUp = nft add rule ip filter forward iifname "wg0" oifname "wg0" ip saddr 10.22.0.0/16 ip daddr 10.22.0.0/16 accept  

# nftables Regeln entfernen
PreDown = nft delete table ip nat
PreDown = nft delete table ip filter

# Gateway
[Peer]
PublicKey = XXXX
AllowedIPs = 0.0.0.0/0

# Client 1
[Peer]
PublicKey = XXXX
AllowedIPs = 10.22.33.3/32

WG-Konfig Gateway:

[Interface]
Address = 10.22.33.2/24
PrivateKey = XXXX
DNS = 10.22.22.81
ListenPort = 51822
MTU = 1280

# IPv4-Weiterleitung aktivieren
PreUp = sysctl -w net.ipv4.ip_forward=1

# nftables Regeln für Routing
PostUp = nft add table ip filter
PostUp = nft add chain ip filter forward { type filter hook forward priority 0 \; }

# Erlaube Forwarding zwischen WireGuard-Netzwerk (10.22.33.0/24) und lokalem Netzwerk (10.22.0.0/16)
PostUp = nft add rule ip filter forward iifname "wg0" oifname "eth0" ip saddr 10.22.33.0/24 ip daddr 10.22.0.0/16 accept  
PostUp = nft add rule ip filter forward iifname "eth0" oifname "wg0" ip saddr 10.22.0.0/16 ip daddr 10.22.33.0/24 accept  

# Erlaube DNS und andere wichtige Dienste, falls benötigt (optional)
# Hier Beispielregel, um DNS über das Interface zu erlauben
PostUp = nft add rule ip filter forward iifname "wg0" oifname "eth0" ip daddr 10.22.22.81 udp dport 53 accept  

# nftables Regeln beim Herunterfahren löschen
PreDown = nft delete table ip filter

# WireGuard Peer-Verbindung zum Server
[Peer]
PublicKey = XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 10.22.33.0/24
PersistentKeepalive = 25

WG-Konfig Client:

[Interface]
PrivateKey = XXXX
Address = 10.22.33.3/32
ListenPort = 51821
DNS = 10.22.22.81
MTU = 1280

[Peer]
PublicKey =XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 669346

Url: https://administrator.de/contentid/669346

Ausgedruckt am: 21.11.2024 um 09:11 Uhr

13 Kommentare

Neuester Kommentar

Bitte in aller Ruhe das hiesige Wireguard Tutorial lesen und entsprechend umsetzen:
Merkzettel: VPN Installation mit Wireguard

Die gröbsten Fehler im obigen Setup:

Wie leider so oft die falschen Subnetzmasken bei der internen IP Adressierung konfiguriert! Regel für die internen IPs: Verwendete Netzwerk Maske (z.B. /24) am internen Interface aber /32er Hostmasken in den AllowedIPs, andernfalls scheitert das interne Cryptokey Routing. Am Server ist es bis auf das Gateway richtig, am Gateway selber aber falsch!
Das Gateway sollte in jedem Falle Split Tunneling verwenden aber niemals Gateway Redirect!
Es ist wenig zielführend und auch kontraproduktiv die Firewall in die WG Kofig zu integrieren. Die nftables FW Funktion gehört da nicht hin sondern immer statisch in die /etc/nftables.conf! Das Tutorial gibt entsprechende Hinweise dazu. VPN ist VPN only und Firewall bleibt Firewall.

Weiterführende nftables Konfig und wie das umzusetzen ist auch HIER.

Ein mehr oder minder klassisches und einfaches Ruleset für die nftables Firewall (/etc/nftables.conf) in so einem Design sähe z.B. so aus:

#!/usr/sbin/nft -f

flush ruleset

# Interface name
define pub_iface = "eth0"  
# Wireguard port
define wg_port = 55820

table inet drop-bad-ct-states {
	chain prerouting {
		type filter hook prerouting priority -150; policy accept;
		# drop packets in "invalid" connection-tracking state 
		ct state invalid drop
		# drop tcp packets for new connections that aren't syn packets 
		tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
		# drop XMAS packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
		# drop NULL packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
		# drop new connections over rate limit
		ct state new limit rate over 1/second burst 20 packets drop
		}
}

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		# accept any localhost traffic
		iif lo accept

		# accept any wireguard traffic
		iifname "wg0" accept  

		# accept traffic originated from us
		ct state established,related accept

		# accepted ICMP types		
		ip protocol icmp icmp type { time-exceeded, parameter-problem, destination-unreachable } accept

		# accept common local TCP services on public interface
		iif $pub_iface tcp dport { ssh } ct state new accept

		# accept neighbour discovery otherwise IPv6 connectivity fails.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

		# Log and count dropped traffic
		# log prefix "[nftables]Denied: " counter drop 
		# Only count dropped traffic
		counter drop
	}
	chain output {
		type filter hook output priority filter;
	}
}

table ip nat {
        define VPN_NETS = {
	        192.168.2.0/24, 192.168.10.0/24 }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
		oifname $pub_iface ip daddr $VPN_NETS accept
                ip saddr 10.22.33.0/24 oifname $pub_iface masquerade
		}
} 

.2.0 und .10.0 sind hier nur remote Beispiel IP Netze und müssen auf eigene Netze angepasst werden. 10.22.33.0/24 ist hier das interne WG Netz.
Wenn öffentlicher SSH Zugang auf den vServer besteht sollte ggf. zur besseren Sicherung die Authentisierung auf Zertifikate umgestellt werden und zusätzlich noch fail2ban installiert sein.

Das Netzwerk des VPS Hoster hat auch genug Bandbreite und Forward für deine Kiste?

Hier kannst Du iperfen...
https://proof.ovh.net/

@aqui
Wow, vielen Dank für die informativen Tipps. Ich habe mir nun alle mehrfach durchgelesen. Allerdings verstehe ich nicht wie ich das alles auf meinen Anwendungszweck anwenden soll? Es ist immer die Rede davon den Server im heimischen Netzwerk zu betreiben. Aber das möchte ich nicht / geht auch nicht wirklich wegen DS-Light und double NAT.

Aber, wenn ich das richtig verstehe, sollte mein Wireguard Netzwerk nicht im selben IP Bereich wie mein lokales Netzwerk liegen? Also würde ich für mein WG-Netz z.B. 100.22.33.0/24 nehmen, wenn mein Heimnetz 10.22.0.0/16 ist, oder?

Vielen Dank auch für die nftables Konfig. Jedoch verstehe ich auch hier nicht wo ich diese anwenden soll? Server oder Gateway? Oder brauch ich das auf beiden? Das mit dem redirect und NAT versteh ich auch nicht. Wenn ich möchte, dass jeglicher Client traffic über das Heimnetzwerk geht und der Client auch die Inet Verbindung des Heimnetzwerk nutzt, muss ich dann überall bei den AllowedPs 0.0.0.0/0 setzen?

Auf dem VPS ist nur der WG Port geöffnet.

Im Moment steige ich leider noch nicht durch, was ich alles falsch mache. Sorry!

@150631
Du meinst, wenn ich einen iperf3 Test vom WG-Server zu einem öffentlichen iperf3 Server mache? Dann erhalte ich gute Geschwindigkeiten.

Es ist immer die Rede davon den Server im heimischen Netzwerk zu betreiben.

Ist eigentlich auch Unsinn, denn das eine hat mit dem anderen ja nichts zu tun. Bei einem DS-Lite Anschluss bist du zu einem vServer als VPN Jumphost gezwungen. Wenn man es richtig macht das das doch vollkommen normal sowas auf einem vServer zu betreiben. Das machen Millionen weltweit.

Allerdings verstehe ich nicht wie ich das alles auf meinen Anwendungszweck anwenden soll?

Mmmmhhh, das verstehen wir jetzt nicht! 🤔 Oben sind die doch deine Fehler im Setup schon alle explizit genannt worden. Korrigiere die dann kommt das auch alles zum Fliegen. Ist doch ein übliches Prozedere das man Fehler beseitigt. Wozu muss man da nach einer "Anwendung" fragen?

sollte mein Wireguard Netzwerk nicht im selben IP Bereich wie mein lokales Netzwerk liegen?

Das wäre tödlich solltest du das gemacht haben. Ist doch auch logisch, denn so gut wie alle VPN Protokolle werden geroutet, sprich müssen einzigartige Netze haben damit die IP Wegefindung eindeutig ist. IP Grundschule erste Klasse... 😉

Also würde ich für mein WG-Netz z.B. 100.22.33.0/24 nehmen

Oha, es scheitert bei dir schon an den simpelsten Basics.

Dieses Netz ist keine private IP und gehört Amazon:
NetRange: 100.20.0.0 - 100.31.255.255
CIDR: 100.24.0.0/13, 100.20.0.0/14
NetType: Direct Allocation
Organization: Amazon.com, Inc. (AMAZO-4)
RegDate: 2018-01-10
Updated: 2018-01-10
Ref: https://rdap.arin.net/registry/ip/100.20.0.0
Address: Amazon Web Services, Inc.
Address: P.O. Box 81226
City: Seattle
Das zu nutzen ist also keine besonders intelligente Idee!!

Du solltest dir ggf. zuallerst einmal ein paar Tips zur VPN IP Adressierung aneignen bevor du weitermachst. Oder dir jemanden an die Hand nehmen der weiss was er tut?! Die privaten RFC1918 IP Netze in denen gemeinhin sowas gemacht wird sollte man schon kennen.
Da du weder das einfache Firewall Setup noch NAT verstehst wird das eine recht steile Lernkurve für dich. Jemand der dir hilft wäre vermutlich nicht verkehrt.
Nur so viel zu deinen ToDos.

Du musst die IP Adressierung und Masken anpassen in deinem WG Setup. Das Wireshark Tutorial zeigt funktionierende Praxisbeispiele, auch in den weiterführenden Links wie z.B. HIER an denen du dich einfach orientieren kannst.
Das gesamte "PostUP..." Geraffel gehört idealerweise nicht in das VPN Setup sondern einzig und allein ins nftables Firewall Setup unter /etc/nftables.conf
Hilfreich wäre eine kleine Topoligieskizze von dir welches IP Netz wo. Damit könnte man dir zielgerichtet helfen.

So kannst du gucken ob du genug Bandbreite bekommst.
Die günstigen VPS Hoster haben oft ein Bandbreitenprobleme auf den ersten Metern.

@aqui
Danke für die nützlichen Infos. Ich habe nun hoffentlich alle Regeln befolgt und folgende Konfigs erstellt. Dazu auch eine Topologieskizze.

WG-Server

# Server
[Interface]
Address = 10.33.33.1/24
PrivateKey = XXXX
ListenPort = 51820
MTU = 1380

# Gateway
[Peer]
PublicKey = XXXX
AllowedIPs = 10.33.33.2/32, 10.22.0.0/16

# Client 1
[Peer]
PublicKey = XXXX
AllowedIPs = 10.33.33.3/32

Server nftables.config
Hier habe ich absichtlich erstmal nur den NAT teil eingefügt.

# nftables.conf auf Server
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;
    }
    chain forward {
        type filter hook forward priority 0;
    }
     chain output {
         type filter hook output priority 0;
    }
}
table ip nat {
        define VPN_NETS = {
                10.22.0.0/16 }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname ens6 ip daddr $VPN_NETS accept
                ip saddr 10.33.33.0/24 oifname ens6 masquerade
                }
}

WG-Gateway

# Gateway
[Interface]
Address = 10.33.33.2/24
PrivateKey = XXXX
MTU = 1380

[Peer]
PublicKey = XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 10.33.33.1/32, 10.33.33.3/32
PersistentKeepalive = 25

Client

# Client 1
[Interface]
PrivateKey = XXXX
Address = 10.22.33.3/24
DNS = 10.22.22.81
MTU = 1380

[Peer]
PublicKey = XXXX
Endpoint = <Server-IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Mit diesem Setup kann ich von allen WG-Geräten aus auf das Heimnetzwerk zugreifen und umgekehrt. Der WG-Client nutzt die Internetverbindung des VPS (nicht ganz wie gewünscht aber aktuell nicht so wichtig).

Jedoch besteht immer noch das Problem, dass die Übertragung aus dem Heimnetz zum WG-Client sehr instabil und langsam ist. Verbindungen zwischen Client und Server / Gateway und Server sind stabil. Habe auch schon versucht beim Client nur die AllowedIPs: 10.33.33.1/32, 10.22.0.0/16 einzutragen. Leider keine Verbesserung.

@150631
Ich habe den iperf3 Test auf dem Server laufen lassen und erhalte ca. 2Gbit Upload und 1Gbit Download.

Der WG-Client nutzt die Internetverbindung des VPS

Ja, das ist klar weil du hier wieder mal das falsche Gateway Redirect (0.0.0.0) benutzt anstatt Split Tunneling. Da wurdest du oben wiederholt drauf hingewiesen hast es aber schlicht ignoriert.

AllowedIPs = 10.33.33.1/32, 10.22.0.0/16 Wäre hier richtig gewesen im Setup. Danach musst du einen Reboot machen und den Tunnel neu aufbauen damit das greift. Dann geht lediglich Zieltraffic zu den Adressen 10.33.33.1/32, 10.22.x.x/16 in den VPN Tunnel.

Ein paar Tips:

DNS im Client anzugeben ist unsinnig und kannst du komplett weglassen. Das ist ausschliesslich nur dann erforderlich wenn du interne Hostnamen auflösen musst was bei dir aber vermutlich nicht der Fall ist. Folglich kannst du das weglassen, dann benutzt der Client den lokal gelernten DNS Server. Oder befindet sich hinter der .22.81 ein DNS Server? Vermutlich ist das der Fehler beim Client.
MTU Settings solltest du erstmal weglassen. Die WG default MTU ist 1420 und in der Regel völlig ausreichend. Erst wenn du Schwierigkeiten mit Fragmentierung bekommst solltest du das anpassen sonst den Default belassen indem du es weglässt.
Nebenbei: Hat es einen tieferen Sinn ein /16er Netz zu betreiben? 65.534 Endgeräte willst du ja wohl kaum adressieren zumal du ja so oder so nur mit 10.22.22er Adressen arbeitest. Warum also kein 10.22.22.0/24er Netz? Es besteht auch durch die .22.22 der latente Verdacht das du ggf. doch irgendwo eine /24 Maske benutzt und es so zu einem Maskenmissmatch innerhalb des Netzes kommt. Das solltest du nochmal wasserdicht prüfen.

Bis auf das falsche Client Setup also alles richtig gemacht. 👍 Die nft Firewall braucht natürlich noch etwas "Tuning" um den Server sicherer zu machen.

Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?

Ich habe den Thread nicht als gelöst markiert, da das anfängliche Problem immer noch besteht. Egal ob mit Splittunnel oder Gateway redirect. Das hatte ich ja bereits erwähnt und nicht ignoriert.

Hast du die MTU testhalber mal im Default belassen? Kannst du Instabilitäten im Provider Netz sicher ausschliessen?

Ja, habe die default MTU sowie viele andere probiert. Ob es sonst irgendwie an meinem VPS liegt kann ich nicht sagen. Deren Support meint es sollte schneller möglich sein. Und wie gesagt, Client <-> Server / Server <-> Gateway Verbindungen sind gut. Erst wenn es über den Server geht wirds instabil.