8
WireGuard Datenverkehr Problem
Es gibt Einträge in meinem Pi-Hole-Protokoll, die mich vermuten lassen, dass meine WireGuard-Verbindung von meinem Laptop (Gecko) aus nicht richtig funktioniert.
Meine Netzwerkkonfiguration ist wie folgt:
Ich habe eine FritzBox, an der ein Raspberry Pi über Ethernet angeschlossen ist. Auf diesem Raspberry Pi laufen mehrere Dienste: Pi-hole, Unbound und WireGuard.
Den WireGuard-Server habe ich korrekt eingerichtet, so dass die VPN-Verbindung zu meinem Laptop, auf dem Windows 11 installiert ist, und meinem Handy funktioniert - sowohl intern, lokal im Netzwerk (NAT-Pinning) als auch von außen (DynDNS).
Sobald die VPN-Verbindung zwischen meinem Laptop und dem WireGuard-Server aufgebaut ist, gehe ich davon aus, dass der gesamte Datenverkehr zwischen dem Laptop und dem WireGuard-Server durch den VPN-Tunnel geleitet wird. Dem ist aber nicht so, wie die Logs von Pi-Hole zeigen; in diesem Beispiel greife ich auf die Seite test.de zu:
Man sieht, dass die Anfragen von zwei Schnittstellen kommen: einmal von der IP (192.168.178.23), die meinem Laptop von der FritzBox zugewiesen wurde, und von der IP (10.100.0.3), die dem Laptop vom WireGuard-Server zugewiesen wurde.
Dies widerspricht meinen Erwartungen. Sollte der Datenverkehr nach erfolgreichem Aufbau der VPN-Verbindung nicht nur über die IP 10.100.0.3 geleitet werden?
Wenn ich den gleichen Test mit meinem Android-Telefon durchführe, sieht das Pi-Hole-Protokoll wie folgt aus:
Obwohl ich mit dem Handy lokal in meinem WLAN-Netz verbunden bin, wie mein Laptop, erscheint keine Anfrage von der IP, die meine FritzBox meinem Handy zugewiesen wurde, im Log, sondern die Abfrage wird nur innerhalb des VPN-Tunnels aufgelöst.
Mögliche Lösungen:
Da der Kill-Switch des WireGuard-Clients nicht richtig zu funktionieren scheint, muss ich Windows 11 so konfigurieren, dass der gesamte Verkehr durch den VPN-Tunnel (10.100.0.3) geleitet wird.
Ich wäre sehr dankbar, wenn mir jemand helfen könnten, dieses Problem mit meiner WireGuard-Einrichtung unter Windows 11 zu verstehen und zu lösen.
Meine Netzwerkkonfiguration ist wie folgt:
Ich habe eine FritzBox, an der ein Raspberry Pi über Ethernet angeschlossen ist. Auf diesem Raspberry Pi laufen mehrere Dienste: Pi-hole, Unbound und WireGuard.
Den WireGuard-Server habe ich korrekt eingerichtet, so dass die VPN-Verbindung zu meinem Laptop, auf dem Windows 11 installiert ist, und meinem Handy funktioniert - sowohl intern, lokal im Netzwerk (NAT-Pinning) als auch von außen (DynDNS).
Sobald die VPN-Verbindung zwischen meinem Laptop und dem WireGuard-Server aufgebaut ist, gehe ich davon aus, dass der gesamte Datenverkehr zwischen dem Laptop und dem WireGuard-Server durch den VPN-Tunnel geleitet wird. Dem ist aber nicht so, wie die Logs von Pi-Hole zeigen; in diesem Beispiel greife ich auf die Seite test.de zu:
May 4 23:06:54: query[A] test.de from 192.168.178.23
May 4 23:06:54: forwarded test.de to 127.0.0.1#5335
May 4 23:06:54: query[A] test.de from 10.100.0.3
May 4 23:06:54: reply test.de is 128.65.209.28
May 4 23:06:54: query[A] test.de from 192.168.178.23
May 4 23:06:54: cached test.de is 128.65.209.28
May 4 23:06:54: query[A] test.de from 10.100.0.3
May 4 23:06:54: cached test.de is 128.65.209.28
May 4 23:06:54: query[AAAA] test.de from 192.168.178.23
May 4 23:06:54: forwarded test.de to 127.0.0.1#5335
May 4 23:06:54: query[AAAA] test.de from 10.100.0.3
May 4 23:06:54: reply test.de is NODATA-IPv6
May 4 23:06:54: query[A] www.test.de from 192.168.178.23
May 4 23:06:54: forwarded www.test.de to 127.0.0.1#5335
May 4 23:06:54: query[A] www.test.de from 10.100.0.3
May 4 23:06:54: reply www.test.de is 128.65.209.28
May 4 23:06:54: query[A] www.test.de from 192.168.178.23
May 4 23:06:54: cached www.test.de is 128.65.209.28
May 4 23:06:54: query[A] www.test.de from 10.100.0.3
May 4 23:06:54: cached www.test.de is 128.65.209.28
May 4 23:06:54: query[AAAA] www.test.de from 192.168.178.23
May 4 23:06:54: forwarded www.test.de to 127.0.0.1#5335
May 4 23:06:54: query[AAAA] www.test.de from 10.100.0.3
May 4 23:06:54: query[A] cdn.test.de from 192.168.178.23
May 4 23:06:54: forwarded cdn.test.de to 127.0.0.1#5335
May 4 23:06:54: query[A] cdn.test.de from 10.100.0.3" Man sieht, dass die Anfragen von zwei Schnittstellen kommen: einmal von der IP (192.168.178.23), die meinem Laptop von der FritzBox zugewiesen wurde, und von der IP (10.100.0.3), die dem Laptop vom WireGuard-Server zugewiesen wurde.
Dies widerspricht meinen Erwartungen. Sollte der Datenverkehr nach erfolgreichem Aufbau der VPN-Verbindung nicht nur über die IP 10.100.0.3 geleitet werden?
Wenn ich den gleichen Test mit meinem Android-Telefon durchführe, sieht das Pi-Hole-Protokoll wie folgt aus:
May 4 23:11:41: query[A] test.de from 10.100.0.2
May 4 23:11:41: cached test.de is 128.65.209.28
May 4 23:11:41: query[A] www.test.de from 10.100.0.2
May 4 23:11:41: cached www.test.de is 128.65.209.28
May 4 23:11:42: query[A] cdn.test.de from 10.100.0.2
May 4 23:11:42: cached cdn.test.de is <CNAME>
May 4 23:11:42: cached swliveweb.azureedge.net is <CNAME>
May 4 23:11:42: cached swliveweb.afd.azureedge.net is <CNAME>
May 4 23:11:42: cached azureedge-t-prod.trafficmanager.net is <CNAME>
May 4 23:11:42: cached shed.dual-low.part-0017.t-0009.t-msedge.net is <CNAME>
May 4 23:11:42: cached part-0017.t-0009.t-msedge.net is 13.107.246.45
May 4 23:11:42: cached part-0017.t-0009.t-msedge.net is 13.107.213.45
May 4 23:11:42: query[A] experience-eu.piano.io from 10.100.0.2
May 4 23:11:42: cached experience-eu.piano.io is 104.16.144.111
May 4 23:11:42: cached experience-eu.piano.io is 104.16.143.111
May 4 23:11:42: query[A] cdn-eu.piano.io from 10.100.0.2
May 4 23:11:42: cached cdn-eu.piano.io is 104.16.143.111
May 4 23:11:42: cached cdn-eu.piano.io is 104.16.144.111
May 4 23:11:43: query[A] c2-eu.piano.io from 10.100.0.2
May 4 23:11:43: cached c2-eu.piano.io is 104.16.144.111
May 4 23:11:43: cached c2-eu.piano.io is 104.16.143.111
May 4 23:11:46: query[A] buy-eu.piano.io from 10.100.0.2
May 4 23:11:46: cached buy-eu.piano.io is 104.16.143.111
May 4 23:11:46: cached buy-eu.piano.io is 104.16.144.111Obwohl ich mit dem Handy lokal in meinem WLAN-Netz verbunden bin, wie mein Laptop, erscheint keine Anfrage von der IP, die meine FritzBox meinem Handy zugewiesen wurde, im Log, sondern die Abfrage wird nur innerhalb des VPN-Tunnels aufgelöst.
Mögliche Lösungen:
Da der Kill-Switch des WireGuard-Clients nicht richtig zu funktionieren scheint, muss ich Windows 11 so konfigurieren, dass der gesamte Verkehr durch den VPN-Tunnel (10.100.0.3) geleitet wird.
Ich wäre sehr dankbar, wenn mir jemand helfen könnten, dieses Problem mit meiner WireGuard-Einrichtung unter Windows 11 zu verstehen und zu lösen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82351592094
Url: https://administrator.de/forum/wireguard-datenverkehr-problem-82351592094.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
8 Kommentare
Neuester Kommentar
Das hiesige Wireguard Tutorial hast du genau gelesen und entsprechend in deinem Setup auch richtig umgesetzt?? 🤔
Merkzettel: VPN Installation mit Wireguard
Dort sind alle Details beschrieben die für ein korrektes WG Setup relevant ist. Ein Kapitel behandelt zusätzlich die nicht Standard konforme Wireguard Implementation von AVM in den Fritzboxen.
Leider hast du deine Konfig Dateien hier nicht gepostet was ein sinnvolles Troubleshooting dann zur Kristallkugelei macht. Ohne dein Setup zu kennen ist eine zielführende Hilfe schwer möglich.
Alle Schritte zu einem korrekten WG Setup sind im o.a. Tutorial und den weiterführenden Links beschrieben.
Lesen und verstehen...
Siehe o.a. Tutorial, dort ist der Unterschied zw. Split Tunneling und Gateway Redirect genau beschrieben!!
Merkzettel: VPN Installation mit Wireguard
Dort sind alle Details beschrieben die für ein korrektes WG Setup relevant ist. Ein Kapitel behandelt zusätzlich die nicht Standard konforme Wireguard Implementation von AVM in den Fritzboxen.
Leider hast du deine Konfig Dateien hier nicht gepostet was ein sinnvolles Troubleshooting dann zur Kristallkugelei macht. Ohne dein Setup zu kennen ist eine zielführende Hilfe schwer möglich.
Alle Schritte zu einem korrekten WG Setup sind im o.a. Tutorial und den weiterführenden Links beschrieben.
Lesen und verstehen...
Laptop und dem WireGuard-Server aufgebaut ist, gehe ich davon aus, dass der gesamte Datenverkehr zwischen dem Laptop und dem WireGuard-Server durch den VPN-Tunnel geleitet wird.
Nein! Es sei denn du hast ein Gateway Redirect konfiguriert. (Allowed IPs mit 0.0.0.0)Siehe o.a. Tutorial, dort ist der Unterschied zw. Split Tunneling und Gateway Redirect genau beschrieben!!
Die config von meinem WireGurad Clienten auf windows:
Und das ist hier die wg0.conf:
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxx
Address = 10.100.0.3/32
DNS = 192.168.178.22
MTU = 1460
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxx
PresharedKey = xxxxxxxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = xxxxxxxxxxxxxxxxxxxxxx
PersistentKeepalive = 25Und das ist hier die wg0.conf:
root@pi5:/etc/wireguard# cat wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 47894
MTU = 1460
PrivateKey = xxxxxxxxxxxxxx
[Peer]
PublicKey = xxxxxxxxxxxxxxx
PresharedKey = xxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.100.0.2/32
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxx
PresharedKey = xxxxxxxx
AllowedIPs = 10.100.0.3/32
Mehrere Fehler begangen
1. Die MTU ist zu hoch, bei Wireguard liegt die maximale MTU mit IPv6 Traffic im Tunnel bei 1420 bytes, ohne IPv6 Traffic über den Tunnel kann man sie auf max. 1440 setzen wenn PPPoE nicht im Spiel ist, 1460 ist also schon mal way too much und wird zu Fragmentierung und dadurch zu sehr schlechtem Durchsatz und anderen Problemen führen.
2. Du versuchst mit ::/0 IPv6 Traffic über den Tunnel zu schicken obwohl du den Endpunkten keine IPv6 IP-Adressen vergibst, das kann verständlicherweise nicht funktionieren. Das führt dazu das wenn eine weitere IPv6 Default-Route im lokalen Netz des Laptops extistiert der IPv6 Traffic weiterhin lokal raus geht.
Da Windows IPv6 bevorzugt und wenn bei DNS Anfragen AAAA Records zurückgeliefert werden, versucht Windows das Ziel immer zuerst per IPv6 zu erreichen.
Wenn du also IPv6 auch über den Tunnel schubsen willst dann konfiguriere auch IPv6 Adressen auf den Tunnel Endpunkten und stelle sicher das der IPv6 Traffic auch vom Server aus weiterlaufen kann, z.B. über ein SRC-NAT auch auf IPv6 falls du nur dynamische IPv6 Adressen vom Provider erhältst, oder aber deaktiviere die IPv6 Bindung des Clients am LAN oder WLAN Interface zur Fritzbox.
Gruß
1. Die MTU ist zu hoch, bei Wireguard liegt die maximale MTU mit IPv6 Traffic im Tunnel bei 1420 bytes, ohne IPv6 Traffic über den Tunnel kann man sie auf max. 1440 setzen wenn PPPoE nicht im Spiel ist, 1460 ist also schon mal way too much und wird zu Fragmentierung und dadurch zu sehr schlechtem Durchsatz und anderen Problemen führen.
2. Du versuchst mit ::/0 IPv6 Traffic über den Tunnel zu schicken obwohl du den Endpunkten keine IPv6 IP-Adressen vergibst, das kann verständlicherweise nicht funktionieren. Das führt dazu das wenn eine weitere IPv6 Default-Route im lokalen Netz des Laptops extistiert der IPv6 Traffic weiterhin lokal raus geht.
Da Windows IPv6 bevorzugt und wenn bei DNS Anfragen AAAA Records zurückgeliefert werden, versucht Windows das Ziel immer zuerst per IPv6 zu erreichen.
Wenn du also IPv6 auch über den Tunnel schubsen willst dann konfiguriere auch IPv6 Adressen auf den Tunnel Endpunkten und stelle sicher das der IPv6 Traffic auch vom Server aus weiterlaufen kann, z.B. über ein SRC-NAT auch auf IPv6 falls du nur dynamische IPv6 Adressen vom Provider erhältst, oder aber deaktiviere die IPv6 Bindung des Clients am LAN oder WLAN Interface zur Fritzbox.
Gruß
2- Vergessen wurde noch die falsche Subnetzmaske bei der internen WG IP Adresse des Clients!
- Zudem ist ein zusätzlicher Preshared Key sinnloser Overhead wenn man eh schon mit Keys arbeitet. Den Gürtel zum Hosenträger braucht es nicht...
- Zumindestens unsauber ist auch die Verwendung eines Ports der außerhalb der empfohlenen Ephemeral Ports liegen.
- Ob man mit Gateway Redirect statt Split Tunneling arbeitet und damit Performance opfert muss jeder nach Anwendung selber entscheiden.
Die MTU muss man ohne Not auch erstmal nicht verfummeln in einem WG Setup!
Zum Rest ist ja schon alles gesagt. Steht übrigens auch so im o.a. Tutorial (IPv6 Client Kapitel) wenn man denn nur einmal liest und es richtig umsetzt...
Hallo,
Und warum soll der Datenverkehr zwischen deinen (lokalen) Laptop und deinen (lokalen) extra laufenden Wireguard Server Verschlüsselt sein ausser die normalen https? Wireguard läuft erst ab punkt wo auch wireguard Installiert ist, und dein Laptop weiss davon nichts...
Gruss,
Peter
Zitat von @xeiko30:
Den WireGuard-Server habe ich korrekt eingerichtet, so dass die VPN-Verbindung zu meinem Laptop, auf dem Windows 11 installiert ist, und meinem Handy funktioniert - sowohl intern, lokal im Netzwerk (NAT-Pinning) als auch von außen (DynDNS).
Dieses NAT-Pinning? https://medium.com/@cyberrohan07/nat-pinning-the-cyber-attack-that-can-s ...Den WireGuard-Server habe ich korrekt eingerichtet, so dass die VPN-Verbindung zu meinem Laptop, auf dem Windows 11 installiert ist, und meinem Handy funktioniert - sowohl intern, lokal im Netzwerk (NAT-Pinning) als auch von außen (DynDNS).
Sobald die VPN-Verbindung zwischen meinem Laptop und dem WireGuard-Server aufgebaut ist, gehe ich davon aus, dass der gesamte Datenverkehr zwischen dem Laptop und dem WireGuard-Server durch den VPN-Tunnel geleitet wird. Dem ist aber nicht so, wie die Logs von Pi-Hole zeigen; in diesem Beispiel greife ich auf die Seite test.de zu:
Wireshark sagt es dir genau, zu 100% Kabelhai da braucht es dann auch kein "ich gehe davon aus, ich Vermute usw"Und warum soll der Datenverkehr zwischen deinen (lokalen) Laptop und deinen (lokalen) extra laufenden Wireguard Server Verschlüsselt sein ausser die normalen https? Wireguard läuft erst ab punkt wo auch wireguard Installiert ist, und dein Laptop weiss davon nichts...
Gruss,
Peter
Kein Feedback des TO ist natürlich auch ein Feedback! 😡
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?
Danke 13034433319 für deine Antwort. Ich habe den von mir gesetzte MTU-Wert überprüft
und bekam eine fragmentierlose Übetragung:
Diesen Test habe ich auf meinem Handy über das mobile Netz mit VPN durchgeführt.
IPv6 ist Serverseitig abgestelllt.
Sogar ein MTU-Wert von 1472 verlief Fragmentierungslos. Kannst du mir das erklären?
und bekam eine fragmentierlose Übetragung:
ping -c 8 -s 1460 -M do 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 1460(1488) bytes of data.
1468 bytes from 192.168.178.1: icmp_seq=1 ttl=63 time=215 ms
1468 bytes from 192.168.178.1: icmp_seq=2 ttl=63 time=79.0 ms
1468 bytes from 192.168.178.1: icmp_seq=3 ttl=63 time=91.3 ms
1468 bytes from 192.168.178.1: icmp_seq=4 ttl=63 time=81.5 ms
1468 bytes from 192.168.178.1: icmp_seq=5 ttl=63 time=80.6 ms
1468 bytes from 192.168.178.1: icmp_seq=6 ttl=63 time=77.7 ms
1468 bytes from 192.168.178.1: icmp_seq=7 ttl=63 time=76.6 ms
1468 bytes from 192.168.178.1: icmp_seq=8 ttl=63 time=74.7 ms
--- 192.168.178.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 74.709/97.187/215.777/45.067 msDiesen Test habe ich auf meinem Handy über das mobile Netz mit VPN durchgeführt.
IPv6 ist Serverseitig abgestelllt.
Sogar ein MTU-Wert von 1472 verlief Fragmentierungslos. Kannst du mir das erklären?
PING 192.168.178.1 (192.168.178.1) 1472(1500) bytes of data.
1480 bytes from 192.168.178.1: icmp_seq=1 ttl=63 time=112 ms
1480 bytes from 192.168.178.1: icmp_seq=2 ttl=63 time=123 ms
1480 bytes from 192.168.178.1: icmp_seq=3 ttl=63 time=144 ms
1480 bytes from 192.168.178.1: icmp_seq=4 ttl=63 time=104 ms
1480 bytes from 192.168.178.1: icmp_seq=5 ttl=63 time=101 ms
1480 bytes from 192.168.178.1: icmp_seq=6 ttl=63 time=182 ms
1480 bytes from 192.168.178.1: icmp_seq=7 ttl=63 time=109 ms
1480 bytes from 192.168.178.1: icmp_seq=8 ttl=63 time=110 ms
--- 192.168.178.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7014ms
rtt min/avg/max/mdev = 101.813/123.539/182.355/25.507 ms
