UniFi Device Bridge IoT - Bitte um Unterstützung bei Einrichtung

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen

    N'Abend,

    ich habe mir eine UDB IoT gekauft, sie ist heute angekommen und wurde adoptiert. Mein Ziel ist es, die UDB mit dem HAN-Port meines Smart Meter Gateways (SMGW) zu verbinden, um letztendlich den Stromverbrauch lokal abzurufen (das Thema IR-Leser auf der Diode lassen wir bitte aussen vor).

    Der HAN-Port ist ein ganz "normaler" RJ45-Port. Darüber ist ein HTTP-Server unter der IP 192.168.1.200 erreichbar. Die IP kann nicht geändert werden.

    Ich dachte nun:

    • UDB IoT via UniFI Auto-Link ins Netz
    • HAN-Port an UDB IoT RJ45 Port
    • Zugriff von jedem Gerät aus auf 192.168.1.200
    • Dashboards!

    Aber - Arschlecken.

    Zunächst mal: Ich verstehe UniFI AutoLink offenbar nicht. Damit die Bridge sich ins Netz einbuchen kann, muss ich global in den Wifi-Einstellungen "UniFi Auto-Link" und "Wireless Meshing" aktivieren, sonst verbindet sich die Bridge nicht dauerhaft mit einem AP. Als Konsequenz fängt der nächstgelegene AP (ein U6 Lite) seinerseits an zu Meshen, owohl er per LAN angebunden ist. Und das wiederrum führt zu einer Warnung im Network-Controller, dass die Bridge mit einem AP "meshed", der seinerseits "meshed" und das das doof wäre (nachvollziehbar). Ist es wirklich notwendig, Wireless Meshing zu aktivieren und kann ich dennoch verhindern, dass die APs seinerseits anfangen zu meshen?

    Und dann ein grundsätzliches Verständnisproblem: Die Bridge bekommt via DHCP eine IP aus meinem Management LAN (untagged) (192.168.1.0/24), konkret die 192.168.1.130. Soweit so gut, es ist ja auch ein UniFi Device und kein Client Device. Dummerweise ist die IP des SMGW fix und liegt im Bereich des Management-LANs. Ich sehe auch (nach einiger Zeit) in der Client Devices-Ansicht das SMGW mit der IP 192.168.1.200 . Aber - Zugriff von einem Desktop PC aus in einem anderen VLAN (192.168.20.0/24) scheitert (Timeout).

    Was könnte die Ursache sein. Sowohl das Management LAN, als auch das Desktop PC LAN sind Teil der "Internal" Zone und es gibt keine (mir bekannte) Regel, die den Traffic einschränkt. Ich kann vom Desktop-PC auch IPs aus dem Management LAN anpinge?

    PS: Wirklich stabil ist die UDB IoT auch nicht. Irgendwann stellt sich den Betrieb einfach ein und braucht dann einen Factory Reset. Einfacher Neustart hilft nicht.

    Noch was: Wenn das Smart Meter an den LAN-Port der Bridge angeschlossen ist, habe ich ein weiteres, zusätzliches Client Device im Netz. Die MAC-Adresse entspricht der MAC-Adresse des UDB IoT WLAN Ports, bis auf das letzte Byte, also wird es wohl der LAN-Port sein. Aber wieso? Anfangen kann man mit dem Ding auch nichts:

    Quote

    Und das wiederrum führt zu einer Warnung im Network-Controller, dass die Bridge mit einem AP "meshed", der seinerseits "meshed" und das das doof wäre (nachvollziehbar).

    Hier, dass meine ich. Und tatsächlich wird für den ap-flug-ug im Network Controller wechselnd "Meshing" und "GbE" als Uplink dargestellt. Anzeigefehler oder ein echtes Problem?


    Also,

    Meshing muss global an sein und mindestens ein AP muss als "Mesh Parent" aktiv sein, damit die Device Bridge dauerhaft funktioniert. Und was die obige Anzeige angeht, scheint es wohl ein Anzeige-Problem zu sein, denn in den Release Notes der UniFi Network Application 10.3.55 (die noch nicht installiert ist) findet sich folgender Bugfix:

    Quote
    • Fixed an issue where UDB devices could generate false Meshing system log messages.

    Bleibt nur noch das eigentliche Problem des fehlenden Routings zum Smart Meter Gateway ..

    Quote from maxim.webster

    Bleibt nur noch das eigentliche Problem des fehlenden Routings zum Smart Meter Gateway ..

    Oder ist es eher die Rückroute? Hat das Teil denn einen Gateway eingetragen oder wenigstens die Möglichkeit für statische Routen? Klingt ja son bisschen nach dem gleichen Problem wie der Zugriff auf die Draytek GUI von anderen IP Bereichen (VLANs)

    Nuja dann wären irgendwo in der Oberfläche entsprechende Einstellungen für Gateway oder Routen. Aber ich befürchte mal, dass es sowas nicht gibt, wenn schon die IP fest und nicht änderbar vorgegeben ist.

    Allerdings kannst Du dann das Vorhaben schon streichen, denn ohne Gateway (Eine Route ist ja auch nur ein spezifisches Gateway für ein spezifisches Ziel) ist keine Kommunikation in andere IP Netze möglich. Dann könntest Du nur ein VLAN mit 192.168.1.0/24er Subnet erstellen und nur die Geräte, die sich darin befinden, können mit dem Smart Meter Gateway kommunizieren.

    Ich gehe mal davon aus, dass die Dinger keinerlei Internetzugriff benötigen/haben wollen, es also eine rein netzwerklokale "Anwendung" ist?


    Hmm... gerade noch so eine Idee ins Hirn geschossen ... vielleicht kann man da was mit Masquerade machen. Also ein VLAN mit 192.168.1.0er Netz wo nur das SMGW drin ist. Und dann eine NAT-Regel Masquerade erstellen auf das Interface des VLANs mit passenden Source/Destination Gedöhns. Das könnte sogar klappen ...

    192.168.1.0/24 existiert, es ist das untagged Management-LAN, indem sich die UniFi-Komponenten befinden. Glücklicherweise hat keins meiner Geräte in dem Netz die IP .200 vom Gateway.

    Das Smart Meter Gateway hat selbstverständlich Internet-Zugang, dafür ist ja ein LTE-Modem verbaut. Aber die Daten gehen an die Cloud-Services des Netzbetreibers und können über ein Web-Portal eingesehen werden. Aber als Visualisierung, nicht strukturiert.

    Über den HAN-Port steht ein auf dem SMGW laufendes, lokales Web-UI zur Verfügung. Designtechnisch fragwürdig und ebenfalls visualisierend, aber es gibt mindestens eine Integration für Home Assistant, welche daraus Daten extrahieren kann.

    Aber ganz verstehe ich den Einwand nicht : Die Bridge ist doch wie ein Switch-Port, ein dort angeschlossener Service kann aufgerufen werden, wenn seine IP zum VLAN des Ports passt. Und das Teil antwortet ja nur, initiiert keine Verbindung seinerseits. Also zurück an Absender über den gleichen Weg.

    Wo spielt da ein Gateway nicht mit?

    Okay wenn da eine Mobilfunkschnittstelle drin ist, dann gibt es auch ein Defaultgateway. Leider zeigt das aber zum Internet und nicht zum Unifi Gateway.

    Stellst Du eine Anfrage aus einem anderen VLAN, dann steht in den Paketen als Quelle die IP des Gerätes, welche die Paket los schickt. An diese Adresse will das SMGW dann auch die Antwortpakete verschicken. Da die Zieladresse aber nicht im eigenen IP Subnet liegt, muss dann das Paket an einen Router gesendet werden. Entweder gibt es einen Router der mittels statischer Route angesprochen wird oder eben das Default Gateway (ist eigentlich nur eine statische route zu 0.0.0.0/0). Genau das wird das Problem sein. Deine Antwortpakete landen sehr wahrscheinlich mangels anderer Route via Standardgateway des Mobilzuganges beim Provider im Internet, der die Pakete droppt. Das wäre ein klassischer Fall für den Einsatz einer statischen route.

    Ziel wären deine privaten IP Bereiche die am Unifi laufen, im Zweifelsfall halt alle RFC1918 Netze, und als Gateway würdest Du dann die IP des Unifi Gateways eintragen aus dem 192.168.1.0/24 Netz. Dann würde das SMGW Pakete die als Ziel deine Privat-IPs haben an das Unifi Gateway schicken und nicht an das Default Gateway (Mobilfunk). Genau darum funktioniert es auch von einem Gerät mit IP aus dem 192.168.1.0/24 Netz, da es für dieses Netz eine Route auf der LAN Schnittstelle gibt und somit die Pakete ohne routing direkt zum Ziel kommen.

    Betroffen ist also einfach nur der Rückweg beim Routing - gerne gemachter Fehler in komplexeren Netzen. Das initieren von Verbindungen spielt bei der Firewall eine Rolle, damit die aber überhaupt ins Spiel kommt, muss das Routing hinhauen, was es aktuell nicht macht. Also das gleiche Spiel wie mit den Darytek und Zyxel DSL Modems, wobei beim Draytek statische Routen eintragbar sind - so holt sich mein Modem auch die Uhrzeit vom PTB obwohl es eigentlich ja selbst kein Internet hat.

    Ich schaue mal eben, ob das mit dem Masquerade hinhaut.

    Quote from maxim.webster

    Wie wäre es mit einem Proxy-Service im Management-LAN, der Anfragen weiterleitet?

    Das müsste auch klappen, da Du ja mit dem Proxy kommunizierst und dieser LAN-intern mit der .200


    Hab das eben mal getestet. VLAN mit 192.168.1.0/24 angelegt (ist nicht mein Default Management Netz!) Darin einen PC fest mit der .200 ohne DNS und Standardgateway.darauf einen Miniwebserver.

    Im Controller eine neue NAT Regel erstellt, wie folgt:

    Das bewirkt, dass alles was von irgendwo in das VLAN Test geht (das ist das 192.168.1.0/24er Netz) die Quelle der Pakete mit der IP des Unifi Gateways im 192.168.1.0/24er Netz ersetzt wird. Ich würde das bei Destination vermutlich auf die 192.168.1.200 eingrenzen ... bin mir nicht sicher ob das an irgendeiner Ecke vom Unifi Management quer schießt, da in dem Netz ja die Unifi Geräte hängen bei dir.

    Zu sehen ist das ganze hier im log des Webservers. Die grüne Anfrage ist die IP des PCs der die Seite aufgerufen hat, als der PC mit der .200 noch ein Standardgateway drin hatte. Nach entfernen ist die Webseite nicht mehr erreichbar. Die gelbe Anfrage ist dann vom gleichen PC aufgerufen, nach aktivieren der NAT Regel ... du siehst angeblich hat das Gateway die Seite aufgerufen. Letzten Endes ist das so ziemlich exakt das, was die Router sonst auf den Internetschnittstellen machen.

    Langsam kommen meine Netzwerk-Basics zurück: Ohne Standard-Gateway weiß das Smart Meter Gateway nur, wo es Pakete für sein eigenes Netz hinschicken soll (192.168.1.0), aber für Anfragen aus anderen Netzen gibt es keine Route zurück.

    Ein Proxy wäre eine aktive Komponente, die ich zudem in mein UniFi LAN klemmen müsste. Sein einziger Zweck wäre das Weiterleiten von Anfragen für 192.168.1.200

    Masquerade klingt da attraktiver, da es mit der vorhandenen Hardware (incl. UDB IoT) ja umsetzbar wäre. Ich tüftel mal ...

    Quote from maxim.webster

    Doch noch eine Frage: Welchen Wert muss das Feld "Interface/VPN-Tunnel" haben, wenn die Anfragen von meinem "Home"-Netz 192.168.20.0/24 an das Smart-Meter Gateway (192.168.1.200) im Netzwerk LAN (192.168.1.0/24) gehen sollen und zurück? HOME oder LAN?

    Okay, muss "LAN" sein, "HOME" funktioniert nicht. Weiß nicht warum, ist mir jetzt aber auch egal, denn - Ergebnis zählt. Danke für die Unterstützung!

  • maxim.webster April 22, 2026 at 6:58 PM

    Set the label from offen to erledigt

    Das Interface vom LAN in dem das SMGW ist muss es sein.

    Das Zertifikat ist halt selbstsigniert. Die Firefoxmeldung sieht etwas spektakulärer aus als bei anderen Browsern. Im Prinzip reicht das Zertifikat hier völlig. Du rufst das Ding vermutlich mit IP auf und da ist es mit Man in the Middle ziemlich schwierig. Und vermutlich gibts in dem Webinterface auch nicht viel zu holen.

    Kein Problem, für Hilfe ist das Forum ja da. Und ganz nebenbei hab ich ja selbst was gelernt, nachdem mir die Idee gekommen ist ;)

    Dann kann ich meins ja Mal bei Gelegenheit verkabeln, mein Server Vlan inkl. Homeassistant ist die 192.168.1.0/24 :)


    Bezüglich Zertifikate, wie in einem anderen Thread geschrieben ist diese Schnittstelle nicht dazu gedacht ins LAN zu kommen und immer nur direkt mit einem PC auszulesen... Welcher ... sich das auch immer ausgedacht hat.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login