Warum deine Home-Assistant-Integration das Gerät im IoT-VLAN nicht findet

Du hast dein Smart-Home-Zeug sauber ins eigene VLAN gesteckt – und plötzlich findet Home Assistant die Hälfte davon nicht mehr. Das ist kein Bug. Das ist Absicht, an zwei Stellen gleichzeitig.

TL;DR

Automatische Geräte-Erkennung (mDNS/.local, SSDP, UDP-Broadcast) endet per Design an der Subnetzgrenze. Kommt eine zonenbasierte Firewall dazu – bei mir UniFi – ist der Weg doppelt zu. Es gibt drei Lösungen: Gerät und HA ins selbe VLAN, ein mDNS-Reflector über die Grenze, oder pro Integration eine gezielte Unicast-Firewall-Regel. Und eine Grundregel, die dir viel Arbeit spart: Home Assistant gehört nicht ins strengste VLAN.

Das Symptom

Eine oder mehrere Varianten davon:

• Die Integration hängt beim Hinzufügen ewig im „Wird eingerichtet …" und läuft dann in einen Timeout.
• Die automatische Erkennung meldet „keine Geräte gefunden", obwohl das Gerät läuft und von HA aus pingbar ist.
• Ein .local-Hostname löst von der HA-Konsole aus nicht auf.
• Es lief mal – bis du das Gerät ins IoT-VLAN umgezogen hast.

Der erste Reflex ist, die Integration zu verdächtigen. In den allermeisten Fällen ist sie unschuldig.

Erst diagnostizieren: welche der zwei Schichten klemmt?

Bevor du irgendetwas an der Firewall baust, grenz das Problem ein. Alle Tests von der HA-Konsole aus (SSH-Add-on) oder von einem anderen Host im selben Netz wie HA.

Test 1 – erreichst du das Gerät überhaupt?

ping <geraete-ip>
nc -vz <geraete-ip> <port>      # port = der TCP-Port des Geräts, z.B. 80 / 6053 / 8080

Kommt der Ping durch, aber nc nicht: Firewall. Kommt beides nicht durch: Routing/Firewall grundsätzlich zu. Kommt beides durch, die Integration findet trotzdem nichts: Discovery.

Test 2 – kommt mDNS über die Grenze?

avahi-browse -at          # zeigt es Geräte aus dem anderen VLAN? meist nein
getent hosts geraet.local # löst der .local-Name auf?

Test 3 – ist es wirklich nur der eine Port? Cross-VLAN-Firewalls sind heute meist granular, nicht „VLAN A ↔ VLAN B komplett dicht". Bei mir ging SSH von einem Service-Netz zum Proxmox-Host problemlos, während derselbe Quell-Host HA auf Port 8123 nicht erreichte. Teste immer die konkrete Kombination Host:Port, nicht „das VLAN".

Warum es an zwei Stellen klemmt

Stelle 1: Discovery ist nicht routbar. Geräte werden über einen von vier Wegen gefunden:

Die ersten drei enden an der Subnetzgrenze – ganz ohne Firewall. Steht HA in 192.168.1.0/24 und das Gerät in 192.168.40.0/24, hört HA den Multicast bzw. Broadcast des Geräts nie.

Stelle 2: Die Firewall ist zonenbasiert, nicht VLAN-basiert. Bei UniFi (neuere Oberfläche, „Richtlinientabelle") liegen VLANs in Zonen – Intern, Extern, Gateway, Hotspot. Zwei VLANs können beide in der Zone Intern liegen und trotzdem standardmäßig gegeneinander dicht sein. Vor dem ersten Eingriff hatte ich genau sechs explizite Regeln: DHCP, DHCPv6, Link-Local-DHCPv6, mDNS-Reflection auf 5353, und einen Portforward. Alles andere zwischen den Segmenten war implizit verboten.

Heißt: Selbst wenn du den Multicast per Reflector über die Grenze trägst, blockt die Firewall danach noch den eigentlichen Unicast-Verkehr zum Gerät.

Die drei Wege – ausführlich

Weg A – Gerät und HA ins selbe VLAN

Am simpelsten, am unbefriedigendsten. Widerspricht dem Grund, warum du überhaupt segmentiert hast. Für einzelne, besonders zickige Geräte (billige Broadcast-Scanner ohne Unicast-Option) manchmal trotzdem die pragmatische Wahl – dann wenigstens ein eng gefasstes „Smart-Home-Kern"-VLAN, nicht das Management-Netz.

Weg B – mDNS-Reflector über die Grenze

UniFi kann mDNS zwischen Netzen spiegeln – die Option heißt je nach Controller-Version „mDNS" oder „Multicast DNS" in den Netzwerkeinstellungen (Pfad ändert sich mit den Versionen, meist unter den erweiterten Einstellungen des jeweiligen Netzes oder global).

Was du wissen musst:

• Es löst nur mDNS. SSDP und herstellereigene UDP-Broadcasts bleiben außen vor.
• Es spiegelt den gesamten mDNS-Verkehr zwischen den betroffenen Netzen, nicht nur das eine Gerät – die Trennung wird für .local also generell aufgeweicht.
• Die anschließende Unicast-Verbindung (HA → Gerät auf dessen echtem Port) braucht trotzdem eine Firewall-Freigabe. Der Reflector allein reicht fast nie.

Sinnvoll, wenn du viele mDNS-Geräte in einem IoT-Netz hast und den Kompromiss bewusst eingehst.

Weg C – manuelle IP + Unicast + gezielte Firewall-Regel

Der sauberste Weg, wenn die Integration eine feste IP oder einen Unicast-Discovery-Modus anbietet (viele tun das in den „erweiterten" Optionen des Config-Flows).

Worked Example, Gree-Klimaanlage:

1. Integration auf manuelle IP stellen statt Broadcast-Suche.

Genau eine Firewall-Regel:

Quelle:      192.168.1.169/32     (die HA-Instanz)
Ziel:        192.168.40.163/32    (das Klimagerät im IoT-VLAN)
Protokoll:   UDP
Port:        7000
Rückverkehr: automatisch erlauben

Port herausfinden. Steht in der Integrationsdoku – oder du schaust selbst nach, während das Gerät im selben Netz noch gefunden wird:

tcpdump -ni any host <geraete-ip> and udp

Bei der Gree-Integration: Unicast auf UDP 7000.

/32 auf beiden Seiten – nicht das ganze Netz freigeben. Return-Traffic aktivieren, sonst kommt die Antwort des Geräts nicht zurück.

Der Haken

Jede Integration bringt ihre eigene Discovery-Art und ihren eigenen Port mit. Was für die Gree-Anlage UDP/7000-Unicast ist, ist beim nächsten Gerät SSDP auf 1900, beim übernächsten ein TCP-Port jenseits von 8000. Du baust also nicht eine Ausnahme, sondern pflegst eine wachsende Liste – eine Regel pro Cross-VLAN-Integration. Das ist Arbeit, und sie hört nie ganz auf.

Führ diese Liste schriftlich (Quelle, Ziel, Port, wofür) – spätestens beim dritten Gerät weißt du sonst nicht mehr, welche Regel warum existiert.

Die Architektur-Entscheidung, die das eindämmt

Genau deshalb steht Home Assistant bei mir nicht im am stärksten abgeschotteten VLAN. HA ist der zentrale Controller – es muss praktisch jedes Gerät im Haus erreichen. Sperrst du es ins strengste Segment, wiederholst du den Firewall-Tanz für jedes einzelne Gerät.

Besser:

• HA in ein eigenes, moderat offenes „Automatisierungs"-Segment.
• Von dort gezielte, ausgehende Freigaben zu den IoT-Geräten (Weg C).
• Die IoT-Geräte untereinander und Richtung Internet weiter dicht – das ist die Angriffsfläche, die wirklich zählt (billige Geräte, die nach Hause telefonieren).

So bleibt zu, was zu bleiben muss, und der Controller kann trotzdem arbeiten. Ich habe einmal überlegt, HA doch ins IoT-VLAN zu ziehen – nach dem dritten „noch eine Regel für noch ein Gerät" war klar, dass das der falsche Weg ist.

Checkliste

• Integration findet nichts? Erst Test 1–3: Ping vs. Port vs. mDNS – Discovery-Problem oder Firewall-Problem?
• Discovery-Art bestimmen: mDNS, SSDP, UDP-Broadcast oder Cloud?
• Bietet die Integration manuelle IP / Unicast? → Weg C, eine /32-Regel mit Return-Traffic
• Port unbekannt? tcpdump -ni any host <ip> and udp im selben Netz mitschneiden
• Reflector nur, wenn du den generell aufgeweichten mDNS-Verkehr bewusst in Kauf nimmst – und auch dann brauchst du meist noch die Unicast-Regel
• Firewall-Ausnahmen schriftlich führen (Quelle/Ziel/Port/Zweck)
• Konkrete Kombination Host:Port testen, nie „das VLAN" pauschal beurteilen
• HA gehört ins Automatisierungs-Segment, nicht ins Management- und nicht ins strengste IoT-Netz

Verwandte Notiz: Proxmox-Restore auf einer Crucial BX500. — Die vollständige VLAN-Vorlage (welches Segment, welche Zone, welche Freigabe pro Integrationstyp, mit fertiger Regel-Liste zum Anpassen) ist Teil meines Guide „Proxmox + Home Assistant ausfallsicher". Dann hier entlang.