Nach Chat mit dem Unifi-Support nun die Lösung:
Um einem User Zugriff auf die Konsole zu geben muss dieser erst online einen Account anlegen. Dann erst kann er die Einladung annehmen und sich mit seinem online-Account einloggen.
Eine Einladung wird automatisiert versandt, sobald der User in einen Admin umgewandelt ist. Für Admins lassen sich Rechte definieren. Das oben erwähnte "Please grant at least one resource first." ist laut Support nur für Rechte in den Integrationen Zutritt und Telefon.
Ich verzweifle langsam.
Wenn ich dem User Admin Rechte gebe (Upgrade to Admin) wird unmittelbar eine Einladung an die angegebene Mailadresee verschickt, obwohl bei "dentity Invitation" nach wie vor der obige Hinweis steht und eine Einladung nicht verschickt werden kann.
Ich habe die Mail dann im Browser auf Google Workspace geöffnet (eine Gmail-Adresse) und den Link "Accepr Invitation" geklickt. Ergebnis: ich lande auf dem Site-Manager account.ui.com und werde aufgefordert Username und Passswort einzugeben. Username=Mailadresse - aber Passwort? Beim Anlegen des Users habe ich keinerlei Möglichkeit gesehen, ein Passwort zu vergeben...
Helft mir bitte. Ich zweifle an meinem Verstand.
In meiner UDM Pro SE habe ich jetzt eine HD eingebaut und Protect installiert.
Ich habe jetzt mal neben dem default Admin einen User angelegt, ihm eine eMail eingetragen und ein Onboad Date.
Das System lässt mich aber keine Identity Invitation schicken. Grund: Please grant at least one resource first.
Wahrscheinlich habe ich Tomaten auf den Augen. Ich suche mir nämlich einen Wolf und finde nicht, wo man die Rechte einstellen kann.
Ob es mit reinem SLAAC geht werde ich noch testen. Aber der jetzige Erfolg stimmt mich optimistisch.
Gerade getestet. Es geht auch mit reinem SLAAC.
2025-03-03 17:25:38.738 DEBUG MdnsScanner Added 4 IPs for operational device 645D8D7FFA6E6919-00000000B691F9C3._matter._tcp.local to cache (interface end0): type: udp ip: fd00::a:0:0:0:175 port: 5540 type: udp ip: fd00::a:b06f:7155:ffba:1dd1 port: 5540 type: udp ip: fe80::4cf4:1e27:6a7f:6f16%end0 port: 5540 type: udp ip: 192.168.100.68 port: 5540
sieht mir so aus als wenn der HA auch die IPv4 anmeldet
Ja, sehe ich auch so. Allerdings kommt der Pairing request aus dem anderen VLAN alleine mit der IPV6 Adresse.
werden dort dann alle angemeldeten devices automatisch ausgetauscht, (in beide Richtungen) oder muss jedes einzeln freigeschaltet werden?
Es gibt in meinem Setup nur zwei Matter-Devices - die Bridge im HA und der Hub in der Google Home Welt.
Mit dieser - scheinbar sinnlosen - Verbindung wird erreicht, dass ich alle in HA vorhandenen Datenpunkte / Devices (hauptsächlich KNX aber auch z.B. ein Pelletofen) in die Google Home Welt bringe, ohne über die Cloud zu gehen. Es gibt zwar eine offizielle Google Home Anbindung des HA, die erfordert aber, dass der HA von außen erreichbar ist.
Auf Basis der hier geposteten detaillierten Anleitungen 
habe ich mich nochmal intensiv selbst mit der Thematik befasst und folgendes Setup erfolgreich zum Laufen gebracht:
Ich habe in den beiden Test-VLANs folgende IPV6 Konfig vorgenommen:
- Interface Type Static.
- VLAN 10: fd00:0:0:a::/64
- VLAN 11: fd00:0:0:b::/64
- DHCPV6 (war versehentlich von vorigen Versuchen eingestellt 
)
- Allow SLAAC
Mein im anderen Thread beschriebenes Problem ist damit vermutlich gelöst. Ich muss es noch auf die produktiven VLANs transferieren und im nächsten Schritt mit Prefix Delegation testen.
Ich nehme es gleich vorweg: es läuft!
Ich habe in den beiden Test-VLANs folgende IPV6 Konfig vorgenommen:
- Interface Type Static.
- VLAN 10: fd00:0:0:a::/64
- VLAN 11: fd00:0:0:b::/64
- DHCPV6 (war versehentlich von vorigen Versuchen eingestellt 
)
- Allow SLAAC
Der HA-Server mit der Matter Bridge ist in VLAN 11. Der Hub (Google Hiome Mini) und das Android Handy in VLAN 10.
Ob es mit reinem SLAAC geht werde ich noch testen. Aber der jetzige Erfolg stimmt mich optimistisch.
Wen es interessiert: ich habe zwei Logfiles der Matter Bridge angehängt. Eines mit allen Devices im gleichen VLAN, eines mit den og. zwei VLANs. Das Device mit der Adresse fd00::b:bd0e:89f2:a944:329a ist der Google HIme Mini, der sich als Hub mit der Bridge connectet.
Hallo swag,
ich verstehe die von dir erläuterte Problematik und will auch nicht ausschließen, dass ich deshalb letztendlich bei meinem Workaround bleibe.
Inzwischen geht es mir aber darum, IPV6 besser zu verstehen und das gewünschte Setup prinzipiell zum Laufen zu bringen. Ich sehe auch keinen technischen Grund, der das verhindern sollte. Es liegt also an meiner IPV6 Konfig oder an Einschränkungen im Unifi Netzwerk oder an Einschränkunegn (Bugs?) in der eingestzten (Matter-)Software.
Und das gilt es zu identifizieren.
Erstmal danke für deine ausfühlrichen Erläuterungen.
Wenn Du möchtest, dass Geräte aus VLAN A und B miteinander über IPv6 sprechen, warum willst Du dann IPv6 für VLAN C abschalten? Was in C so los ist und ob es überhaupt ein C gibt, interessiert ein Gerät aus A nicht, wenn es mit B kommuniziert.
Ja, das ist mir klar. Der Kern des Problems ist dieser Thread.
Aktueller Stand in Kürze zusammengefasst:
Die Matter Bridge hängt in VLAN A und muss per IPV6 mit VLAN B und C kommunizieren.
Das habe ich per Workaround hinbekommen, indem ich dem Server mit der Matter Bridge zwei zusätzliche virtuelle NICs eingerichtet habe sodass die Bridge mit den VLANs B und C per Link-Local-IP kommunizieren kann.
Dieses Setup läuft stabil und ist im Produktivbetrieb.
Den möchte ich erst mal nicht stören und habe deshalb im Netz eine Testumgebung geschaffen mit VLAN X (Matter Bridge) und Y (Matter HUb). Dort versuche ich nun die VLAN übergreifende Kommunikation mit IPV6 auf die Beine zu stellen ohne am restlichen (produktiven) Netz herumzukonfigurieren.
Die Erkenntnisse daraus werden entweder mir helfen, IPV6 besser zu verstehen oder dem Entwickler der Matter Bridge (ist noch im Beta-Stadium) helfen, mögliche Bugs oder fehlende Features zu identifizieren.
Deshalb möchte ich ein Setup erreichen, das die IPV6-Kommunikation in und zwischen diesen beiden Test-VLANs vollumfänglich unterstützt. Erst bei Erfolg würde ich das dann auf die produktiven Teile übertragen.
Würde gern wissen wieso du ipv6 möchtest? Vorteil zu ipv4. ?
Weil eine Matter Bridge im Home Assistant (VLAN A) nur über IPV6 mit dem Matter Hub in Google Home kommunizieren will.
Matter baut konsequent auf IPV6. Auch wenn es Ausnahmen gibt, die ich hier aber nicht habe.
Könnte mir bitte mal jemand für einen Noob in Punkto IPV6 aufzeigen, wie ich in zwei von mehreren VLANs ein Setup für IPV6 konfiguriere.
Einziges Ziel ist, dass die beiden VLANs vollumfänglich über IPV6 miteinander kommunizieren können.
Fragen, die mir dabei in den Sinn kommen:
Reicht es, einzig in den beiden VLANs ein IPV6 Setup vorzunehmen und überall sonst (andere VLANs, WAN etc.) zu disablen?
IPV6 statisch? Welche IPV6 Präfixe (bitte Beispiel) trage ich dann ein?
SLAAC oder DHCPV6?
Falls SLAAC: müssen das alle Switche im Netz (die sind in einem anderen Infrastruktur VLAN ohne IPV6-Bedarf) unterstützen?
...
Hat ne Weile gedauert aber hier bin ich wieder
Ich würde vermuten das es mit 3 interfaces die jeweils ein fc Netz haben funktionieren sollte aber das diese Frage evt irrelevant ist.
Ist tasächlich irrelevant. Es reicht hier die Link-Local-IP fe80:...
Wenn ich alles im gleichen VLAN habe läuft es sowohl mit nur fe80:... als auch wenn ich zusätzlich static IPs mit fc00:... eintrage. Ich sehe dann tatsächlich, dass die Matter Geräte mit dieser F`fc00:... Adresse kommunizieren. Auszug aus dem Log der Matter-Bridge im Home Assistant:
2025-03-01 10:52:32.272 INFO CaseServer Received pairing request from udp://[fc00:1:b:0:9570:4606:eefe:72d]:5540Die hier angegebene IPV6 IP ist die des Google Home Mini, der als Matter Hub fungiert.
Sobald der HA mit der Matter Bridge aber in einem anderen Subnetz ist, geht es nicht mehr.
So wie ich es seht hättest Du jetz ipv6 am Start aber läuft in ein Problem mit der ZeroConfig Konfiguration der Geräte. ZeroConfig sprich die Geräte finden sich selber ohne Konfiguration von IP's ect basier meist auf multicastDNS und weiteren Mechanismen. im ipv4 Bereich gibt es dazu bei Unifi auch Einstellungen solche Anfragen weiterzuleiten. Ich habe k.A. und nie ausprobiert ob diese auch bei IPv6 vorhanden sind.
Vielleoicht löse isch die Frage, wie man in der Unifi Ungebung eine vollumfänglich funktionieren de IPV6 Kommunikation zwischen zwei VLANS konfiguriert mal aus diesem Thread und stelle sie separat.
Generell wollen IOT Geräte Ihren Controller / Gateway im HEimnetz finden. Mit Deinem Konzept zwei getrennte Heimnetze mit einem gemischen Bereich ist das nicht wirklich kompatibel.
Mag sein, Aber ich kann mir bei besten Willen nicht vorstellen, dass bei der Defintion von Matter VLAN-Umgebungen ausgeschlossen sind.
Daher schätze ich das Dein momentaner Ansatz am einfachsten ist.
Das ist er und funktioniert auch. Da er aber nicht ausdrücklich supportet ist, befürchte ich, dass es irgendwann in der Zukunft nicht mehr geht.
Jetzt bin ich wieder zum oben beschriebenen Workaround mit 3 NICs im HA-Server zurückgekehrt.
Dabei habe ich weitere Erkenntnisse gewonnen:
Wenn es im Netz eine IPV6 Konfig gibt, die zu zusätzlichen fc...-Adressen in den clients führt, geht das Matter-Gedöns nicht. Es wird offensichtlich - erfolglos - versucht, über diese Adressen zu kommunizieren.
Sobald nur die fa80...-Adressen existieren, funktioniert es. Offensichtlich über den HA-Server als "Router" mit seinen 3 NICs.
Inzwischen sieht es so aus:
Der DNS Eintrag entspricht exakt der Netzwwerk-ID. Nicht manuell eingetragen.
Auch ein Ping auf andere Maschinen, sowohl auf ein Handy im gleichen Subnetz als auch auf den HA-Server in einem anderen Subnetz (fc00:1:2::) gehen.
Was nun nicht mehr geht ist das eingangs geschilderte, Matter-Geräte in verschiedenen Subnetzen.
Zur Auffrischung:
Das Matter-Gedöns hat ja funktioniert, nachdem ich einfach den HA-Server (Native VLAN 2) zusätzlich per virtuelle NICs in die VLANs 3 u nd 4 gepackt hatte.
Nachdem ich nun (vermeintlich) in der Unifi-Umgebung IPV6 mit Routing zwischen den VLANS hinbekommen hatte, habe ic die beiden zusätzlichen NICs gelöscht. Mit dem Ergebnis, dass die Matter-Kommunikation nicht mehr geht.
Display MoreDu kannst auch ipv6 am Gateway aktive lassen.
Ich glaube nur, bin mir aber nicht sicher das Du statt zum Beispiel
2. fc00:1:2::/64
das Gateway mit
2. fc00:1:2::1/64
eintragen solltest. Evt einfach ausprobieren
Wenn ich fc00:1:2::1/64 eintrage weigert sich die UDM das anzunehmen: "Please enter a valid IPV6 address".
Jetzt habe ich aber eine neue Frage:
Wenn ich eine static V6 IP eintrage bleibt die "Link local IP" bei Subnetz eingetragen. Bei einem neuen VLAN generiert das System eine und trägt sie ein.
Wenn ich nun den Infotext an diesem Eintrag interpretiere: "Client devices will use this address as default gateway" frage ich mich: eine nicht geroutete V6 IP als Gateway?
Vermutlich ist das mal wieder ein Wissensdefizit...
Edit1:
Ein "ipconfig /all" am Windows-PC zeigt:
Edit2:
Ein Ping von meinem Windows-PC (VLAN 4) an die Maschine mit Home-Assistant (in VLAN 2, 3 und 4 mit jeweils fe80... und fc... IPV6 Adressen) bringt:
PING: Fehler bei der Übertragung. Allgemeiner Fehler.Firewallregel zwischen den beiden Netzen: Allow all IPV4 und IPV6 in beide Richtungen.
entweder werden dort [Anm.: bei den Subnetzen] staische prefix fd eingetragen oder prefix delegation aktiviert. Beim Prefix deligation wird automatisch eine /64 von der UDM zugeordnet. Ist gleichwertig wie ein fd aber zusätzlich weltweit eindeutig und öffentlich. (im Standard aber von der FW geblocked)
Mir geht es ja nur um internes V6. Ich könnte es also auf den WAN Schnittstelle disablen und in den VLANs Subnetze z.B. so konfigurieren:
und weitere Subnetze mit
2. fc00:1:2::/64
3. fc00:1:3::/64
4. fc00:1:4::/64
5. fc00:1:5::/64
6. fc00:1:6::/64
etc.
Okay. Gaaanz langsam lichtet sich der Nebel. Die Sichtweite ist allerdings immer noch gering...
Bitte bewertet mal folgende Aussagen, der einfachheit halber mit "richtig" oder "falsch":
Ich könnte das vom Provider zugewiesene Präfix verwenden und in diesem Adressraum Teilnetze in meinem LAN generieren. Das hätte den Vorteil (?), dass alle meine Geräte eine weltweit eindeutige IP hätten und evtl. sogar direkt aus dem Internet erreichbar wären.
Allerdings bedeutet das, dass beim Wechsel des Provider-Präfix sich auch alle internen Adressen ändern. Die Konfiguration einer Firewall zwischen den Netzen wäre dann eine Sisyphos-Arbeit. Edit: allerdings nicht, wenn ich mich auf globale Regeln beschränke, die für alle IPs eines Subnetzes gelten?
Also die vermeintlichen o.g. Vorteile fallen lassen und mit einem lokalen Adressraum arbeiten, der mit fc/fd beginnt, weitere Stellen willkürlich gewählt.
Die Fritzbox hat Einstellmöglichkeiten für die IPV6 Adressvergabe und sogar Routing zum angeschlossenen Netz. Da ich aber eine Unifi-Umgebung habe, die das alles selbst regeln kann, könnte / sollte ich IPV6 in der Fritte unberücksichtigt lassen und alles in der UDM einstellen.
Was in der WAN-Verbindung der UDM zu IPV6 eingetragen ist, wäre dann für meine weiteren Betrachtungen irrelevant. Die Einstellungen geschehen (wie bei IPV4) alleine in den Konfigs der einzelnen VLANs.
Dort trage ich Static-Adressen für Subnetze xxxx/64 ein, die ich aus einem übergeordneten Adressraum eines xxxx/56 Netzes gebildet habe. Die Prefix-Delegation an die Clients wird dann automatisch von der UDM im jeweiligen Subnet erledigt.
Erstmal danke für deine Mühen. UNd sorry, wenn es immer etwas dauert, bis ich regiere. Ich habe momentan viele andere Baustellen.
Zu deinem Bild von Netzwerk-Setup:
Hast du die unter "Gateway IP/Subnet" eingetragene IPV6 Adresse willkürlich gewählt oder irgendwo entnommen / abgeleitet?
Ist der im Router vom Provider übermittelte Präfix nciht ein Adressraum, der lokal verwnedet werden kann?
Falls ja - wie?
wenn ich die Verbindung von meinem Rechner 2a02:8071:****:****:****:****:7ddc:7d98 aus einem anderen Netzwerk herstelle bekomme ich eine
Antwort. (Mein Rechner hat die IP durch ein Delegate erhalten. In diesem Netzwerk sehe ich unter Gateway dann die 2a02:8071:****:****::1/64
Ist Delegate sowas wie DHCP? Also die automatische Zuweisung einer IPV6?
Was bedeutet dann in diesem Zusammenhang "Static"?
Sorry, ich stehe immer noch zu sehr auf dem Schlauch.
Welche Devices können kein ip4? Das google nest?
Die verwendeten können eigentlich alle IPV4. Die Integration von matter in HA spricht aber nur IPV6.
Mein Ursächliches Problem, ist eigentlich schon gelöst.
Das VLAN Setup (redziertt beschrieben):
- VLAN 2 Trusted Common (Zugriff von und zu VLAN 3 und 4
- VLAN 3 Haus (da Wohnt mein Sohn)
- VLAN 4 Wohnung (da wohne ich, in der Einliegerwohnung.
Trennung von VLAN 2 und 3, damit diese sich nicht gegenseitig beeinflussen. Z.B. versehentliches Streaming auf den Chromecast des anderen Haushalts. Trennung der beiden SONOS Systeme - Setup mit zwei Systemen im gleichen Netz geht nicht.
Lösung:
Die Netzwerkkarte des HomeAssistant-Rechners wird zusätzlich in die VLANs 3 und 4 gebracht. Funktioniert und läuft mit local-link Adressen.
Trotzdem habe ich den Ehrgeiz, das auf Netzwerkebene zu lösen.
Ok Das /56 bekommt die Fritz vom Provider. Sie braucht aber ein /64 für die wan Adresse der UDM da bleibt dann nur noch /57 fürs delegate zur UDM.
Verstanden.
Wenn Du eins Deiner Netzte anschaust. Siehe Dein Bild mit der fe80 lokalen Adresse sollte bei erfolgreichen delegate noch eine öffentliches prefix stehen 2003:xxx/64 nur dann wird den Clients in dem Netz eine Adresse zugeordnet. Wenn das klappt sollte auch das touting funktionieren.
Diese Infos sind für meinen aktuellen Wissenstand zu dünn. Was genau müsste ich wo konfigurieren?
Erstmal danke für deine Antwort.
Matter kann eigentlich auch ipv4
Nicht alle Devices.
fe80:xxx. sind locale adressen die sind für Transfers lokal innerhalb eines Netzes gedacht.
Das meinte ich mit "werden nicht geroutet".
evt ist /56 nicht passend zu den bereitgestellten prefixen des Providers /59 oder /62 könnte hier helfen öffentliche ipv6 zuzuweisen. Ich sehe bei gatewayIP (links neben der fe ip das IPv6 subnet prefix/64 welches für die Devices in dem NEtzwerk verwendet werden.
In der Fritzbox (die die Verbindung herstellt) steht:
IPv6-Adresse: 2003:de:ffff:49ff:b2f2:8ff:fe96:b836/64, Gültigkeit: 14332/1732s
IPv6-Präfix: 2003:de:ff49:7e00::/56, Gültigkeit: 13541/941s
Ansonsten verstehe ich von deinem Kommentar nichts. Sorry, IPV6 ist für mich noch absolut unbekanntes Terrain.
Falls keine öffentlichen IPv6 verwendet werden sollten statt Prexideligation static antippen und einen eigenen /64 prefix wählen. Denke Unifi sollte dann auch das routing hinbekommen.
Könntest du mir das bitte genauer erklären. Welchen prefix genau kann ich da verwenden? Und je VLAN ein eigener/anderer?
Welche Regel hast wurde genau eingerichten Zone Regel Intern -> IOT?
Die beiden Netze sind "Trusted Common" (Home Assistant) und "Privat" (Google Home Device). Die Regeln sind "Allow All IPV4 und IPV6" in beide Richtungen. Also komplett offenes Scheunentor.