Messages

Leider hat sich herausgestellt, dass es nicht am fehlerhaften Neustart des Wireguard lag, sondern dass der Handshake länger aktiv war, als ich angenommen habe,
daher sah es so aus, als würde eine Konfig funktionieren und die nächste dann auch.
Doch nach einiger Zeit hat dieselbe Konfig wieder nicht funktioniert.
Das einzige, was aktuell zuverlässig zu funktionieren scheint ist eine Portweiterleitung von WAN zur Tunneladresse, damit der Handshake zustande kommt. Sobald der Handshake funktioniert, funktioniert der Rest.
Es liegt also immer am Handshake, der nicht zustande kommt, wenn keine Portweiterleitung aktiv ist.
Da scheint die Bindung der Tunneladresse auf die Wan-Schnittstelle noch nicht richtig zu funktionieren (bei IPv6).
Bei IPv4 funktioniert alles weiterhin problemlos.

Nach weiteren Tests bin ich wieder über dasselbe Problem gestolpert.
Problem ist, dass wenn einmal der Prefix (z. B. nach Reboot) sich ändert, muss ich die Tunneladresse anpassen.
Danach habe ich bisher immer einen Neustart des Dienstes gemacht.
Dabei bin ich jetzt wieder über dasselbe gestolpert, also dass kein Handshake zustande kommt.
Wenn ich jetzt aber statt einem Neustart des Wireguard ein Stop und Start mache, funktioniert der Handshake.
Scheint also noch ein Bug zu sein. Immerhin weiß ich jetzt, woran es liegt und kann das beheben.

Läuft jetzt über die Dyndns, die auf WAN zeigt (IPv6).
Das dynamische Prefix der Telekom lässt sich so leider nicht umgehen und ich muss immer mal wieder die Tunneladresse anpassen, aber erstmal geht das so.
Vllt kann ich das auch mit einem Skript lösen, der die Config auf das Prefix anpasst.
Muss ich mir mal überlegen.

Habe heute das Update auf Version 20.1.2 eingespielt und gleich mal die Portweiterleitung deaktiviert und die normale Portfreigabe auf WAN aktiviert. Nach kurzem Test scheint das jetzt zu funktionieren. Weitere Tests stehen aber noch aus.

Ja, irgendetwas scheint da nicht richtig zu funktionieren.
Habe jetzt mal die Dyndns auf das LAN-Interface und die Portfreigabe darauf umgestellt.
Es kommt auch ein Paket an und es wird eines gesendet.
Das ankommende Paket kommt an das LAN-Interface, allerdings ist das ausgehende dann von der WAN-Adresse,
sodass hier auch wieder kein Handshake aufgrund unterschiedlicher IP´s zustande kommt.
Lässt sich das auch noch lösen?

Edit:
Bei der Pourtweiterleitung von WAN auf Tunneladresse kommt es nicht zu dem Problem, da hierbei ja bereits beim ankommenden Paket eigentlich die WAN-Adresse angesprochen wird und die Umleitung intern erfolgt.

Hallo,
ja, die DynDNS zeigt auf die WAN-Adresse und es kommt ein Paket zu dieser von der mobilen IPv6 des Handys an.
Habe es gerade nochmal überprüft.

Und ja klar, ein eingehendes Paket kommt ja an, es kommt nur nichts zurück. War eine falsche Denkweise von mir.
Ich sehe unter "List configuration" dann auch die IPv6 des Handys und auch dass Daten ankommen und gesendet werden. Am Handy kommt da dann allerdings nichts mehr an und über WAN wird auch nichts weiter außer das einkommende Paket geloggt. Dadurch kommt kein Handshake zustande und dementsprechend auch kein Datenfluss.

Auf dem WAN-Interface ist der Port auf die WAN-Adresse freigegeben. Worauf auch eigentlich die Dyndns-Adresse zeigt und ich sehe auch ein Paket von außen ankommen, wenn ich das so laufen habe.
Nur kommt das nicht am Tunnel an und es gibt kein Handshake.
Der einzige Unterschied bei den WAN-Regeln ist, dass meine erstellte den Port auf die WAN-Adresse freigibt und die durch die Portweiterleitung erstellte auf die Adresse im Wireguard-Tunnel zeigt.

Edit:
Habs mal angehängt.
Die erste ist die normale Portfreigabe und die zweite ist von der Portweiterleitung.
WAN-Adresse und Tunneladresse haben unterschiedliche IP´s

Das Netz der IPv6 ist nur in Wireguard unter Local als Tunneladresse angegeben bzw. dann noch im Endpoint mit einer IP aus dem Netz.
So wie es eigentlich auch in den Anleitungen steht.

Keinem.
LAN hat eine andere IPv6/64-Adresse.
Und WAN erhält ja über DHCPv6 (Telekom) eine separate IPv6.
Mein Dyndns zeigt auf WAN und vermutlich brauche ich deshalb àuch diese Weiterleitung, da die Netze unterschiedlich sind?

Es handelt sich hierbei um ein /64-Netz innerhalb meines zugewiesenen /56 Prefix. Also eine öffentliche IPv6.

Hallo,

habe die Regel mal angehängt.
Interface ist keines zugewiesen und ich dachte auch, dass es so funktionieren sollte.
Nach etwas rumprobieren und testen war das dann aber schlussendlich die Lösung.
Wie gesagt, bei Verbindung über IPv4 musste ich dies auch nicht machen und es funktioniert da dann auch wie bei OpenVPN, dass einfach am WAN der Port freigegeben werden musste.
Bei Wireguard über IPv6 war dies aber (zumindest bei mir) nicht ausreichend.

Hallo,

noch eine kurze Rückmeldung meinerseits.
Scheinbar ist dies bei IPv4 von Extern nicht notwendig,
aber ich musste bei mir bei Wireguard über IPv6 eine Port-Weiterleitung an die IPv6 des Wireguard-Servers machen.
Jetzt funktioniert der Handshake und die Verbindung über IPv6.

Grüße
Robin

Hallo,

Dyndns scheint es keine Probleme zu geben.
Bei direkter Eingabe der Ipv6 das gleiche Fehlerbild. Ein Paket kommt am WAN an und das war es. Kein Handshake.
Da es im WLAN mit dem VPN funktioniert vermute ich auch irgendetwas auf der WAN-Seite. Nur habe ich keine Ahnung, was es sein könnte.

Gruß Robin

Hallo,

habe das mal soweit getestet.
Endpoint habe ich dyndns im Einsatz, daher sollte das keine Probleme machen (auch bei IPv6).
Die richtige Adresse bekomme ich per Ping zurück und ich sehe am WAN ja auch ein Paket ankommen.
Habe testweise das IPv4-VPN deaktiviert, aber keine Änderung.
Auch das Zuweisen von GUA statt local brachte keine Änderung.
Was jedoch funktioniert, dass wenn ich mit meinem WLAN verbunden bin, die Wireguard-Verbindung funktioniert?
Ich bekomme sowohl die richtige IPv4, als auch IPv6, die ich in Wireguard dem Endpoint zugewiesen habe.
Lediglich aus dem WAN scheint es Probleme zu geben.
Hilft euch das vllt bei meinem Problem? Prinzipiell scheint die Instanz ja dann schonmal zu funktionieren.

Gruß
Robin

Hallo Maurice,

nein, ich verwende für wg0 (IPv4) den Port 11946 und für wg1 (Ipv6) den Port 51280.
Außerdem noch für Openvpn UDP 11948 und TCP 443.

Grüße
Robin

Hallo Zusammen,

ich habe bei mir Wireguard über Dyndns mit einer IPv4 eingerichtet.
Das funktioniert soweit prima.
Nun wollte ich testweise mal eine VPN-Verbindung über IPv6 only einrichten. Leider habe ich hierbei Probleme.
Eine Dyndns-Adresse für die IPv6 ist eingerichtet und erreichbar.
Ich habe daher unter lokal einen weiteren Wireguard-Server angelegt (Bild:Server).
Anschließend habe ich einen weiteren Endpoint angelegt, der nur über die IPv6-Adresse zugreifen darf (Bild: Endpoint).
Zusätzlich habe ich auf der Wan-Seite den Port 51280 für IPv6 UDP freigegeben (Bild:WAN).

Zum Test nutze ich ein Android-Client (sowohl über Mobilfunkt als auch fremdes WLAN - bei beiden eine öffentliche IPv6-Adresse). Dort habe ich wie bei IPv4 auch einen neuen Eintrag angelegt und die Public-Keys ausgetauscht.
Beim Starten der Verbindung sehe ich in der Firewall auf der WAN-Seite ein einkommendes UDP-Paket über IPv6 und Port 51280.
Allerdings kommt nie ein Handshake zustande.
Unter Wireguard - List configuration wird die IPv6 des Android-Clients mitsamt Port und allowed IPs dann auch angezeigt und es werden sowohl bei Client als auch beim Server Pakete gesendet, es kommen jedoch keine an und damit kommt es auch zu keinem Handshake.
Habe ich bei IPv6 etwas übersehen, was bei IPv4 anders oder nicht gemacht werden musste?
Der einzige Unterschied,den ich jetzt habe ist noch das aktive NAT bei Wireguard Net IPv4.
Da habe ich bei IPv6 nichts eingestellt.
Bei Wireguard Server und Endpoint hatte ich auch schon eine IPv6 /64 innerhalb meines /56 Prefix eingestellt, machte jedoch keinen Unterschied

Vielen Dank schonmal für die Unterstützung.

Edit:
ein tcpdump auf das Interface (wg1) sagt, dass hier nichts ankommt.
Wenn ich das auf wg0 laufen lasse (IPv4) sieht man direkt, dass über das Interface kommuniziert wird.