OPNsense Forum
International Forums => German - Deutsch => Topic started by: rowein on February 28, 2020, 10:08:06 am
-
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.
-
Moin,
Verwendest Du vielleicht für beide Instanzen den selben Listen-Port?
Grüße
Maurice
-
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
-
Moin Robin,
Okay, bei mir läuft das einwandfrei über IPv6. Unterschiede zu deiner Konfiguration, die ich spontan erkennen kann:
- Nur eine WireGuard-Instanz,
- keine Endpoint-Adresse / -Port definiert (der mobile Client hat keine statische Adresse),
- im Tunnel GUAs statt link-local und kein IPv4.
Grüße
Maurice
-
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
-
Moin,
Dann tippe ich entweder auf ein DynDNS-Problem oder irgendwelche WAN-seitigen Filter.
Zur Fehlereingrenzung würde ich
- unter OPNsense die Endpoint-Adresse löschen und
- unter Android als Endpoint-Adresse direkt die IPv6-WAN-Adresse der OPNsense eintragen.
Damit wären DynDNS-Probleme als Ursache ausgeschlossen.
Grüße
Maurice
-
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,
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
-
Port-Weiterleitung an die IPv6 des Wireguard-Servers
Port-Weiterleitung bei IPv6? Da läuft irgend etwas grundsätzlich schief. Was meinst Du mit "IPv6 des Wireguard-Servers"? WG sollte doch an alle Interfaces binden? Von wo nach wo leitest Du denn da weiter?
-
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.
-
Und welche Adresse ist die unkenntlich gemachte? Die WAN-Adresse? Oder eine LAN-Adresse?
-
Es handelt sich hierbei um ein /64-Netz innerhalb meines zugewiesenen /56 Prefix. Also eine öffentliche IPv6.
-
Aber welchem Interface ist diese Adresse zugewiesen? WAN oder LAN?
-
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?
-
?
Diese /128-Adresse in der Port-Weiterleitung muss doch irgendwo konfiguriert sein. Wenn das weder die WAN- noch die LAN-Adresse ist, was dann?
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. :-)
-
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.
-
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.
-
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.
-
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ß
-
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.
-
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
-
Bitte zu eurem eigenen Nutzen mal kurz auf den Tacho schauen, ihr antwortet auf ein über 2 Jahre alten Post. Wireguard und auch die UI haben sich weiterentwickelt. WG hat keine Interfaces auf die es hört, WG hört automatisch auf alle Adressen die die Sense hat auf dem entsprechenden Port, bindet sich also an alles was da ist. Da werden keine Forwards gebraucht im Normalfall. Und die reply-tos abzuschalten kann manchmal mehr Probleme als Lösungen bringen, das würde ich auch nicht einfach so empfehlen ohne zu wissen, was jemand am Start hat. Das hat schon seinen Grund, dass die reply-tos da sind.
Cheers