Posts by jaydee73

Quote from BlackSpy

Added IPv6 support for WireGuard VPN.

wohoooo!

DHCPv6, kein PPPoE

Edit:

Habe jetzt mal nen Cronjob auf dem Gateway angelegt. Mal schauen, ob es damit besser funzt.

Danke für den Tipp.

Im Community-Forum hatte ich ja vorab auch geschaut und einige Einträge gefunden (siehe auch Link im Ursprungspost). Da wird ja auch davon geschrieben, dass es wohl Probleme gibt (oder schlicht nicht geht...).

War nur verwundert, als ich dann hier gelesen habe, dass es sehr wohl funktionieren soll.

Aber vielleicht nicht bei jedem, oder nur in speziellen Konfigurationen. Oder eben in speziellen Konfigurationen gerade nicht.

Als Workaround wird auch (manchmal) empfohlen, dass man das curl-Kommando ja auch regelmäßig via cronjob ausführen könnte auf dem Gateway. Aber da ist dann wieder die Herausforderung, dass man das persistent hinbekommt. Vielleicht werfe ich da nochmal nen Blick drauf.

Sodele....nach nem guten Monat hat der ISP gestern Nacht die IPv6 mal wieder geändert.

Aber leider, leider hat das automatische dyndns wieder nicht geklappt. Ich hatte sogar zwei dyndns-Einträge bei ipv64 angelegt und zwei dazu passende dyndns-Konfigurationen in der Unifi-UI. Beide wurden nicht upgedated.

Habe mich dann gerade via ssh auf die Shell meines Gateways eingeloggt und die Update-URL manuell via curl aufgerufen. Zack, sofort auch bei ipv64.net upgedated.

Irgendwo klemmt es also weiterhin und ich bin leider ratlos...

Kleines Update: Mein ISP hat die IPv6 bisher "leider" noch nicht wieder geändert. Die letzten Tage ging das eigentlich täglich, aber da gab es auch einige Probleme mit der Leitung. Seit Donnerstag ist die v6 IP aber gleichbleibend. Ich werde also weiter abwarten müssen.

Allerdings habe ich (so wie Dennis das im Video ja auch gezeigt hat) mal auf der Shell des Gateways via curl die ipv6-Update-URL von ipv64 aufgerufen. Das hat funktioniert. Sekunden später hat ipv64 den Eintrag aktualisiert. Ich hatte spaßeshalber bei ipv64 vorher die IPv6 geändert und mit dem curl-Aufruf hat ipv64 das wieder auf die aktuelle Wan-IPv6 aktualisiert.

Der richtig manuelle Weg funktioniert also schon einmal.

Ich sagte doch, ich bin kein Profi.

Dann verstehe ich allerdings nicht, warum das bei mir bisher nicht bereits funktioniert hat. Denn alles, was du empfiehlst, hatte ich bereits so umgesetzt (meiner Meinung nach). Ich habe ne v6 IP auf dem WAN Interface, ich hatte dyndns im Gateway konfiguriert und die Firewallregel existiert auch bereits. VPN auf die IP direkt funktioniert ja auch bereits bei mir. Nur eben auf den Hostnamen nicht, bzw. zumindest nicht zuverlässig, weil die WAN IPv6 halt nicht aktualisiert wird bei ipv64.

Nun gut, ich habe Dyndns nochmal neu angelegt auf dem Gateway und jetzt warte ich mal auf den nächsten Provider-IP-Wechsel.

Ergänzung: Wenn ich dich richtig verstanden habe, wird dann die IPv6-Adresse des Gateways an ipv64 übertragen und nicht die WAN-IPv6, die das Gateway vom Provider erhalten hat. Richtig? Und die funktioniert dann auch als Wireguard-Endpunkt-IP?

I'll try...vielen Dank für deine Hilfestellungen.

Quote from DoPe

Die IPv6 Adresse ist nur vie IPv6 erreichbar, ergo muss das Gateway den Aktualisierungrequest per IPv6 an Dennis DNS senden. Dennis hat das so gemacht, das wenn der Request korrekt aufgebaut ist, die Source IP des Requests zum Aktualisieren verwendet wird und nicht eine IP die im Request übertragen wurde. Dazu muss dein Gateway bzw, der Inadyn die WAN IP nicht kennen.

=> Das könnte eventuell der entscheidende Hinweis gewesen sein. Ich hatte für die Unifi-Komponenten (die bei mir im Management-VLAN hängen) bisher IPv6 nicht aktiviert. Habe irgendwie gedacht, dass das nicht relevant/nicht notwendig wäre, zumindest nicht für die Dyndns-Geschichte. Habe das jetzt mal aktiviert und schaue die nächsten Tage, ob die IP bei ipv64 nun upgedated wird.

Den Dyndns-Eintrag im Gateway selbst hatte ich bereits, so wie auch von dir (und in den Anleitungen von Dennis) beschrieben, angelegt.

Auch auf die Gefahr hin, jetzt unhöflich zu wirken: Der Ist-Zustand von Peterfido hat nicht so richtig was mit meiner Fragestellung zu tun. Ich habe weder ne Fritte davor, noch parallel ne pfsense im Einsatz. Demzufolge ist der Beitrag auch nicht unbedingt hilfreich (sorry..). Daher würde ich auch ungerne dieses Thema hier weiter diskutieren wollen. Falls du, Tomcat, dazu Fragen hast, kannst du ihn ja bestimmt auch direkt anschreiben. Danke.

Sorry, dass ich hier vielleicht mit dem Cloud-Router Verwirrung gestiftet habe. Ja, natürlich sind das zwei verschiedene paar Schuhe. Ich wollte nur (kurz) aufzeigen, dass dieser Weg zwar funktioniert, aber eben auch was ganz anderes ist. Daher: Haken dran.

Zum DDNS: Ja, genau das ist aber doch das Problem. Das UXG Fiber kann die IPv6 nicht via besagter Update-URL an ipv64 senden. Es funktioniert schlicht nicht bei einer IPv6 Adresse. Das funktioniert nur mit IPv4. Und ja, es gibt getrennte URLs für ipv4.ipv64 und ipv6.ipv64. Was aber eben hier (meiner Meinung nach) quasi irrelevant ist, weil eben das Gateway die IP technisch nicht senden kann, weil inadyn scheisse implementiert ist. Dazu gibt es auch ein dediziertes Video von Dennis bei YT, wo er das beschreibt/erklärt/bestätigt. Zumindest so, wie ich das verstehe.

Also nicht ipv64 ist das Problem, sondern das Gateway, bzw. die inadyn-Implementierung des Gateways. Und da das Gateway die IP nicht senden kann, habe ich nach möglichen Alternativen gesucht. Also z. B. die WAN IPv6 via Script "manuell" abzufragen und dann ebenfalls manuell an die API von ipv64 zu liefern.

Aber vielleicht verstehe ich das ja auch falsch? Wie gesagt, ich bin kein Profi...Letztendlich habe ich aber dyndns auf dem Gateway eingerichtet und die Update-URL (sowohl die "normale" als auch die ipv6 URL) probiert. Ergebnis: Die IP kommt bei ipv64 nicht an. Was dann auch zu besagtem YT-Video passt.

ipv64 ist in der Tat der Anbieter, den ich auch schon verwende und auch gerne für ipv6-dyndns weiter verwenden würde. Derzeit habe ich es "provisorisch" über deren "Cloud-Router" konfiguriert, so dass mein UXG Fiber via Client-VPN dorthin connected. Das funktioniert auch, bedingt aber eine permanente Verbindung zwischen ipv64 und meinem UXG. Das finde ich gefühlt nicht so gut.

Mir erschließt sich allerdings technisch noch nicht, wie ich das umsetzen soll, was DoPe vorschlägt. Der "Client" wäre ja z. B. mein iPhone, mit welchem ich die VPN-Verbindung zum WG-Server aufmache. Auf dem iPhone habe ich den Hostnamen von ipv64 im VPN-Profil. Also geht die Anfrage erstmal dorthin. Und da wird doch dann "trotzdem" noch die WAN-IP vom UXG benötigt, um an den WG-Server zu kommen, oder denke ich da falsch?

Dafür hätte der Provider gerne ganz, ganz regelmäßig immer wieder neue Münzen in sein Säckel eingeworfen bekommen.

Wenn es letztendlich dazu kommt, dann isses so. Aber im Augenblick würde ich mich gerne noch der Vorstellung hingeben, dass es auch anders geht.

Moin zusammen,

vorweg: Ich bin kein Netzwerkprofi, und auch kein Unifi-Profi. Also habt etwas Nachsicht.

Mein "Problem": Mein ISP-Provider hat von öffentlicher IPv4 auf IPv6 mit CGNAT umgestellt. Die v6 IP ist dabei "leider" recht dynamisch, ändert sich quasi täglich.

Auf meinem UXG-Fiber (bzw. auf dem Network-Controller, der als Docker läuft) läuft ein WG-Server, so dass ich also die WAN-IP brauche (bzw. der Dyndns-Dienst, damit ich mich über einen Hostnamen connecten kann), damit die VPN-Clients sich connecten können.

Nun habe ich mittlerweile herausgefunden (siehe z. B. hier: https://community.ui.com/questions/Add-…5d-35a82684381f), dass die Unifi-DynDNS-Implementierung (welche wohl auf inadyn basiert) arge Probleme damit hat, IPv6-Adressen korrekt an Dyndns-Dienste weiterzugeben. Es funktioniert schlicht nicht. Es geht wohl (out-of-the-box) nur IPv4, was mir hier aber wegen CGNAT nicht hilft.

Ist das hier vielleicht anderen auch schon auf die Füße gefallen? Oder hat wer vielleicht schon Lösungsansätze dafür? Ich bin z. B. über ein Github-Repo gestolpert, wo jemand via Python-Script die API anzapft, um die WAN-IP zu ermitteln. Und dann könnte man das natürlich darüber auch an den gewünschten Dyndns-Anbieter weitergeben (https://github.com/gomes89/unifi-ddns6). Problem hier: So wie er das macht, scheint das nur bei der Dream Machine zu funktionieren. Ich komme über API-Abfragen zumindest aktuell bei meinem UXG Fiber noch nicht an die WAN-IP ran.

Wenn hier also jemand vielleicht ein paar Denkanstöße oder hilfreiche Tipps hätte, wäre ich dankbar.

Gruß,

Stefan

Dank euch. Ja, bei mir steht da auch die GatewayIP, und nichts vom DNS. Dann werde ich mich mal auf die Shell begeben. Danke für den Hinweis, wo ich da suchen muss.

Hallo zusammen,

ich würde gerne wissen (aus Gründen…), wo ich in meinem Network Controller (Version 10.0.60) sehen kann, welchen DNS mir mein ISP zugeteilt hat (also welche IP). Ich sehe es nicht in den WAN Einstellungen, nicht in den Networks und auch nicht in den Logs. Der Haken für „automatisch DNS“ ist gesetzt. Laut Google soll man angeblich die IP angezeigt bekommen, wenn man den Automatisch-Haken setzt. Geht aber bei mir nicht.

Bei meiner alten Fritte wurde das immer in den Logs aufgeführt.

Gibt es das bei Unifi nicht?

Ja, ich würde es ja dann irgendwann am Client sehen. Aber wie gesagt, es gibt Gründe, warum ich das gerne schon im Controller sehen würde.

Ich nutze das UXG-Fiber mit dem Controller als Docker.

Falls jemand dazu nen Tipp hat, wäre ich dankbar.

Gruß,

Stefan

Ich habe auch keinerlei Profile dafür erstellt. Wie jkasten auch: einfach im WLAN auf aus stellen.

Quote from sollner11

Dann hänge ich auch mit ran und kann berichten, dass nach jedem iOS UPdate wieder „statistisch“ vs. „aus“ drin steht

Du meinst, du hattest es auf "aus" stehen und nach einem iOS-Update wurde es wieder ohne dein Zutun auf statisch gestellt?

Das kann ich tatsächlich so nicht bestätigen. Zuletzt unterschiedlichste AppleOS (iOS, iPadOS, macOS) auf v26 upgedatet (und kürzlich auf 26.1) und bei keinem der Updates wurde die Einstellung (steht auf "aus") durch das Update verändert.

Der U6 Pro braucht ja "nur" PoE. Der LR hingegen PoE+. Ich würde mal vermuten, dass der TP-Link Switch die PoE+-Spezifikationen nicht sauber liefern kann, sondern im Wesentlichen nur PoE. Auch wenn er das eigentlich gemäß Spezifikationen können sollte.

Oder vielleicht ist es auch "nur" das Netzteil des TP-Link, was nicht genug Leistung bereitstellt.

Ist halt China-Krams...

Danke für die Erläuterung! Auflösung meinte ich in dem Sinne, als dass pihole in der Network-Übersicht eine Spalte "Hardware address" hat, wo die MAC angezeigt wird. Aber eben jetzt nur noch für das gleiche Segment. Was ja, wie ich jetzt verstanden habe, auch erwartetes Verhalten ist. Also war eher "wird angezeigt" gemeint, statt "wird aufgelöst".

Die MAC wird also nie mitgeroutet? Egal welche Regel man dafür baut? Oder anders: Siehst du überhaupt eine Möglichkeit,dem pihole beizubringen, doch an die MAC von Geräten aus anderen Segmenten zu kommen?

Hallo zusammen,

ich habe bei mir von Fritte auf UXG-Fiber umgestellt und in dem Zusammenhang auch mehrere VLANs aufgesetzt. Sowohl mit der Fritte als auch jetzt mit dem UXG läuft als DNS-Server ein pihole.

In der Network-Übersicht des Pihole ist es nun so, dass bei Geräten, die aus einem anderen VLAN kommen als der pihole selbst, dieser die MAC-Adresse des Geräts nicht auflösen kann. Dort steht dann z. B. "ip-192.168.30.197" (das wäre also ein Gerät aus dem VLAN 30 mit entsprechender IP). Bei Geräten im VLAN 20 hingegen (da ist auch der pihole drin) wird die MAC-Adresse (und damit der Netbios-Name des Gerätes) richtig aufgelöst.

Der Traffic selbst läuft korrekt über den pihole, nur eben diese MAC-Auflösung funktioniert nicht.

Ich würde vermuten, dass das kein Problem der pihole-Konfiguration ist (weil ja die DNS-Auflösung grundsätzlich auch funktioniert), sondern vielleicht eine Regelthematik oder Konfigurationsoption im UXG ist? Wobei die VLANs 20 und 30 in diesem Fall exakt gleich konfiguriert sind. Muss man für ARP-Traffic da noch irgendeine Regel bauen?