Wireguard IPv6-Tunnel

[rowein]

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.

[Maurice]

Die WireGuard-Tunnel-Adresse ist doch die Adresse des internen Tunnel-Interfaces. Auf die hast Du weitergeleitet? Also eine direkte Weiterleitung aus dem Internet IN den Tunnel? ...

Das riecht eher danach, dass nicht wie Weiterleitung das Problem gelöst hat, sondern die damit verknüpfte Firewall-Regel. Ich würde die Portweiterleitung löschen und die ursprüngliche WAN-Firewall-Regel nochmal ganz genau anschauen. Und ins Firewall-Log schauen, ob da etwas geblockt wird.

[rowein]

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

[Maurice]

Auf dem WAN-Interface ist der Port auf die WAN-Adresse freigegeben. Worauf auch eigentlich die Dyndns-Adresse zeigt

"Eigentlich" oder ganz sicher?

und ich sehe auch ein Paket von außen ankommen, wenn ich das so laufen habe.

Und die Destination-Adresse dieses Pakets ist ganz sicher die OPNsense-WAN-Adresse? Nachgeprüft?

Nur kommt das nicht am Tunnel an

Du meinst wahrscheinlich "es kommt nichts aus dem Tunnel-Interface heraus"? Die verschlüsselten Pakete, die von außen am WAN ankommen, sind ja nicht die, die aus dem wg-Interface herauskommen. Da sieht man erst Pakete, nachdem die Verbindung erfolgreich aufgebaut wurde.

Das riecht sehr danach, dass der Android-Client nicht die OPNsense-WAN-Adresse als Endpoint verwendet, sondern irgend eine Adresse aus dem /56.

[rowein]

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.

[Maurice]

Hm, sehr mysteriös. Da fällt mir jetzt nicht mehr viel ein. Soweit ich weiß läuft bei Telekom-DSL nur die Prefix Delegation über DHCPv6, die WAN-Adresse hingegen wird autokonfiguriert (SLAAC). Vielleicht gibt es ja in dieser Konstellation irgend einen Bug. Kann ich leider nicht so einfach nachstellen, da hier die WAN-Adresse tatsächlich via DHCPv6 kommt.

Zumindest würde ich als Workaround aber keine Portweiterleitung machen. Besser: Den DynDNS-Eintrag auf die LAN-Adresse setzen und die Firewall-Regel entsprechend anpassen.

[rowein]

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.

[rowein]

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.

[Maurice]

Interessant. Das wäre plausibel, da ich zur Zeit den Development-Zweig nutze. Hatte ich nicht bedacht, sorry. Vielleicht war es ja ein Bug, für den es schon länger einen Patch gibt, der aber erst jetzt in den Production-Zweig eingeflossen ist.

Oder es war einfach nur der Reboot. :-)

[rowein]

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.

[Maurice]

Falls sich das unterschiedliche Verhalten bei Stop / Start vs. Restart reproduzieren lässt kannst Du ja mal ein Issue aufmachen. Wobei ich den Dienst nach Änderungen bisher nie neu starten musste, ein "Save" auf der WireGuard-Hauptseite war immer ausreichend.

Falls man im Tunnel GUAs verwenden möchte ist ein sich häufig änderndes Präfix natürlich problematisch. Wobei das ja allgemein für OPNsense gilt. Für häufige Präfix-Änderungen ist das ganze System im jetzigen Zustand ungeeignet. Da ist aus meiner Sicht mal eine Grundsatzentscheidung fällig, ob man das ernsthaft angehen möchte oder ganz klar sagt, dass die meisten Features nur mit einem festen Präfix funktionieren.

[rowein]

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.

[crazyducky]

Vielen Dank rowein,
Dieses Verhalten ist auch in 21.7 noch so präsent.

WG mit ipv6 only funktioniert, bei mir nur mit Portforwarding auf die ipv6 WG-Interface Adresse.

Vielleicht sollte man die Doku (https://docs.opnsense.org/manual/how-tos/wireguard-client.html) dies bzgl. noch anpassen.

Gruß

[PlanetDyna]

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

Lege ich die ipv6 WG-Interface Adresse selber fest?
Auf dem Dashboard wird mir nur eine ipv4 angezeigt.

[robgnu]

Hallo,

schalte mal unter "Firewall" -> "Advanced" das Häkchen bei "Disable reply-to on WAN rules" ein.
Es muss ohne eine IPv6 Portweiterleitung gehen.

Gruß
Robert