xeiko30
May 28, 2024, updated at 21:53:58 (UTC)
view902
view8
0
Goto Top

WireGuard Datenverkehr Problem

GermanQuestionWindows 11ProtocolsRouters, RoutingVPN
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:

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.111

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.
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 82351592094

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

Printed on: June 23, 2024 at 02:06 o'clock

8 Comments
Latest comment
Goto Top
Member: aqui
aqui May 28, 2024 at 20:07:19 (UTC)
Goto Top
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...
Member: xeiko30
xeiko30 May 28, 2024 at 20:54:29 (UTC)
Goto Top
Die config von meinem WireGurad Clienten auf windows:

[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 = 25

Und 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
Member: hempel
hempel May 28, 2024 updated at 22:11:04 (UTC)
Goto Top
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ß
heart2
Member: aqui
aqui May 29, 2024 updated at 07:05:49 (UTC)
Goto Top
  • 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... face-wink
Member: Pjordorf
Pjordorf May 29, 2024 at 10:51:30 (UTC)
Goto Top
Hallo,

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 ...

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
Member: aqui
aqui May 30, 2024 at 10:07:50 (UTC)
Goto Top
Kein Feedback des TO ist natürlich auch ein Feedback! 😡
Member: aqui
aqui Jun 10, 2024 at 12:04:26 (UTC)
Goto Top
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
How can I mark a post as solved?
Member: xeiko30
xeiko30 Jun 11, 2024 at 21:27:31 (UTC)
Goto Top
Wegen des Studiums bin ich zurzeit zeitlich sehr angespannt, sodass ich keine Zeit gefunden habe, eure anworten entsprechen zu beantworten und weiter nach der lösung zu suchen. Ich bin aber gewillt, an diesem Problem dran zu bleiben und würde mich melden, wahrscheinlichen in den Ferien face-smile
GermanQuestionWindows 11ProtocolsRouters, RoutingVPN