Server über WireGuard Tunnel hängt bei IPV6 Aufruf

S

siam

New Member
Hallo,

ich habe in Problem, welches ich mir nicht erklären kann.
Ich habe folgenden Aufbau

Externen VPS Server, wo WireGuard als Server läuft, ----------- Fritz!Box ----------- Server wo WireGuard als Client läuft (hier hängen auch dann meine anderen Rechner ohne WireGuard)

Über IPV4 kann ich sämtliche Dienste auf dem WireGuard Clienten erreichen, deshalb vernachlässige ich das mal hier.

Wenn ich nun aus meinem Lokalen Netz über die externe IPV6 Adresse auf den WireGuard Clienten zugreifen möchte, dauert es ca. 10 Sekunden bis ich die Antwort vom Server erhalte. (hier ist es egal auf welchen Dienst ich zugreife http, https, pop, smtp etc. ich hab immer die Pause von 10 Sek.)

Wenn ich dasselbe Spiel über einen externen Server mache, habe ich diese 10 Sek. Pause nicht.
Zuerst hatte ich die DNS Auflösung im Verdacht, da meine IP-Adresse wohl nicht auflösbar ist. Ich hab zum Testen mir die IP in die Hosts Datei gepackt, damit diese dann auflösbar ist. Dies brachte aber keinen Erfolg.

Wenn ich über mein Lokales-Netzwerk versuche, eine Seite mit IPV6 auf meinem WireGuard clienten zu öffnen, sehe ich über tcpdump, dass Der Request auch sofort dort ankommt.
Danach ist für ca. 3 Sekunden Pause. Dann kommt wieder ein Request, nachdem dann wieder eine 3 Sekunden Pause erfolgt, erst jetzt werden dann die Daten ausgeliefert.

Hier mal die Ausgabe des TCP Dump eines http Aufrufes
13:30:26.308446 IP6 **************online.de.50526 > admin*****.de.http: Flags , seq 892810030, win 64440, options [mss 1432,nop,wscale 8,nop,nop,sackOK], length 0
Click to expand...

6 Sekunden Pause
13:30:33.399112 IP6 **************online.de.50526 > admin*****.de.http: Flags [.], ack 3484647144, win 1029, options [nop,nop,sack 1 {0:1}], length 0
Click to expand...
3 Sekunden Pause
13:30:35.931640 IP6 **************online.de.50526 > admin*****.de.http: Flags [P.], seq 4294967223:0, ack 1, win 1029, length 73: HTTP: GET / HTTP/1.1

13:30:35.949877 IP6 **************online.de.50526 > admin*****.de.http: Flags [.], ack 410, win 1027, length 0
13:30:35.958061 IP6 **************online.de.50526 > admin*****.de.http: Flags [F.], seq 0, ack 410, win 1027, length 0
13:30:35.984905 IP6 **************online.de.50526 > admin*****.de.http: Flags [.], ack 411, win 1027, length 0
Click to expand...

Hier dasselbe nur über den externen Server abgerufen.
13:35:33.251775 IP6*****online.de.51550 > *****.de.http: Flags , seq 166576655, win 28800, options [mss 1440,sackOK,TS val 4074549547 ecr 0,nop,wscale 7], length 0
13:35:33.251822 IP6************** .de.http > *****online.de.51550: Flags [S.], seq 3698081365, ack 166576656, win 64320, options [mss 1352,sackOK,TS val 3887327731 ecr 4074549547,nop,wscale 7], length 0
13:35:33.268159 IP6 ******online.de.51550 > *****.de.http: Flags [.], ack 1, win 225, options [nop,nop,TS val 4074549564 ecr 3887327731], length 0
13:35:33.268193 IP6 ******online.de.51550 > *****.de.http: Flags [P.], seq 1:74, ack 1, win 225, options [nop,nop,TS val 4074549564 ecr 3887327731], length 73: HTTP: GET / HTTP/1.1
13:35:33.268230 IP6 ***************.de.http > *****online.de.51550: Flags [.], ack 74, win 502, options [nop,nop,TS val 3887327747 ecr 4074549564], length 0
13:35:33.268423 IP6 ***************.de.http > *****online.de.51550: Flags [P.], seq 1:410, ack 74, win 502, options [nop,nop,TS val 3887327748 ecr 4074549564], length 409: HTTP: HTTP/1.1 301 Moved Permanently
13:35:33.284612 IP6 ******online.de.51550 > *****.de.http: Flags [.], ack 410, win 234, options [nop,nop,TS val 4074549580 ecr 3887327748], length 0
13:35:33.284920 IP6 *****online.de.51550 > ******.de.http: Flags [F.], seq 74, ack 410, win 234, options [nop,nop,TS val 4074549581 ecr 3887327748], length 0
13:35:33.285012 IP6 ****************.de.http > ******.de.51550: Flags [F.], seq 410, ack 75, win 502, options [nop,nop,TS val 3887327764 ecr 4074549581], length 0
13:35:33.301303 IP6 *******online.de.51550 > ******.de.http: Flags [.], ack 411, win 234, options [nop,nop,TS val 4074549597 ecr 3887327764], length 0
Click to expand...


Was natürlich auffällt ist, dass beide Datensätze ziemlich unterschiedlich sind, hierfür fehlt mir aber jegliche Erklärung. Vielleicht kann mich mal jemand in die richtige Richtung stupsen? Sollten weitere Logs benötigt werden, lasst es mich bitte wissen.

Die IPV6 Adresse des Clienten ist aus dem Internet erreichbar, Ping und Tracert sind so weit auch ok.



Ich bin mir sicher, dass der Fehler hier 40 cm vor dem Monitor sitzt, mir fehlt momentan jedoch jegliche Idee, wo ich hier eingreifen könnte.

lg
Andy
 
Last edited:
Ich sehe eine MSS von 1440 Bytes und vermute ein MTU-Problem.
Ein IPv6-Header ist 40 Bytes lang, ein TCP-Header misst 20 Bytes. Bei einem Payload von 1440 Bytes muss das Paket also insgesamt 1500 Bytes groß werden können.
Nachdem 1500 Bytes Gesamtgröße, resp. 1440 Bytes Payload bereits das Maximum dessen ist, was du in normalen Ethernet-Umgebungen hast (Jumbo-Frames mal ausgeklammert), kann das einfach nicht durch den Tunnel passen - denn der Tunnel benötigt ja mindestens einen weiteren IPv4- oder IPv6-Header und einen UDP-Header, bevor der getunnelte Payload kommt. Es müssen also mindestens nochmal 40 Bytes IPv6-Header und 8 Bytes UDP-Header für den Tunnel-Overhead berücksichtigt werden.

Konfiguriere einmal deine Tunnel-Interfaces mit 1400 Bytes MTU, das sollte über jeden Internetzugang sicher funktionieren.

Dein aktuelles Problem wird sein, dass die kleinen SYN- und ACK-Pakete problemlos durch den Tunnel passen - die Pakete mit größerem Payload (z.B. eine Antwort auf deine HTTP-Anfrage) nicht hindurch passen und daher einfach verworfen werden.
 
Hallo,
vielen lieben Dank für deinen Hinweis, die MTU Einstellung hatte ich tatsächlich nicht auf dem Schirm. Ich habe jetzt mit verschiedenen werten. "Herumgespielt" dies jedoch leider ohne Erfolg.
 
Hallo,

ich bin ein kleines Stück weiter gekommen. Das Problem ist, wenn ich aus meinem lokalen Netz die IPV6 Seite öffne, wird logischerweise meine IPV6 Adresse an den WireGuard Client mitgeschickt, dieser erkennt diese IPV6 Adr. Und schickt, teile der Antwort über eth0 raus (weil ist a dasselbe Netz) der andere teil der Antwort geht über WireGuard.
Ich kann das Problem kurzzeitig fixen, in dem ich die Route ins lokale Netzwerk lösche,

root@admin:~# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:8d8:1800:114:****::/72 dev wg1 proto kernel metric 256 pref medium
2a05:5800:27a:****::/64 dev enp5s0 proto ra metric 100 expires 1216sec pref medium <- ist das Problem
2a05:5800:27a:****::/64 dev wg1 metric 1024 pref medium
2a05:5800:27a:****::/56 via fe80::464e:6dff:fe1e:31f5 dev enp5s0 proto ra metric 100 expires 1728sec pref medium
fe80::/64 dev enp5s0 proto kernel metric 256 pref medium
default via fe80::464e:6dff:fe1e:31f5 dev enp5s0 proto ra metric 100 expires 1728sec mtu 1492 pref medium
Click to expand...

Das dumme ist, dass diese Route alle paar Minuten wieder eingetragen wird. Da ich mit IPV6 noch nicht wirklich viel gemacht habe, stellt sich mir jetzt die Frage kann man diese Aktualisierung unterbinden, solange WireGuard läuft oder gibt es eine andere Lösung für dieses Problem.
 
Dein Router wird Router-Announcements für die Default-Route ins Netz schicken, woraufhin die Route wieder neu gesetzt wird, wenn sie nicht mehr da ist. Du musst auf deinem Wireguard-Client die Verarbeitung der Router-Announcements deaktivieren (systemd. oder sysctl, abhängig von deiner Konfiguration) und die Routen manuell setzen.
 
You must log in or register to reply here.
Back
Top