Netzwerk Fortgeschritten

Netzwerk segmentieren: VLANs für IoT & Gäste

Trenne IoT, Gäste und vertrauenswürdige Geräte sauber per VLAN — und sperre IoT mit einer Firewall-Regel aus deinem LAN aus.

Auf eigene Gefahr: Falsch gesetzte Firewall-Regeln können dich vom Gateway oder Controller aussperren oder die Geräte-Steuerung lahmlegen — alles auf eigene Gefahr. Exportiere vor Änderungen ein Backup deiner UniFi-Konfiguration, halte einen kabelgebundenen Admin-Zugang im trusted LAN offen und teste mit aktiviertem Regel-Logging, bevor du die Segmentierung scharf schaltest.

Warum überhaupt segmentieren?

Ein flaches Heimnetz behandelt deinen Saugroboter, die billige WLAN-Steckdose und deinen Laptop mit den Steuerunterlagen gleich — alle im selben Broadcast-Segment, alle erreichbar untereinander. IoT-Geräte bekommen selten Updates und „telefonieren" gerne nach Hause. Das Prinzip heißt Least Privilege: Jedes Gerät darf nur das, was es wirklich braucht. Mit VLANs zerlegst du das eine Netz in logisch getrennte Bereiche auf derselben Hardware. Ziel-Layout für ein Heimnetz:

Netz	VLAN-ID	Subnetz	Wer darf rein
LAN (trusted)	1 (default)	192.168.1.0/24	Darf zu IoT, Gäste, Internet
IoT	20	192.168.20.0/24	Nur Internet, kein LAN
Gäste	30	192.168.30.0/24	Nur Internet, Client-Isolation

Tagged vs. untagged — die zwei Minuten Theorie

Ein untagged Port (Access-Port) gehört genau zu einem VLAN. Das angeschlossene Gerät weiß nichts von VLANs und bekommt seine IP einfach aus dem zugewiesenen Netz — so steckst du z. B. einen smarten Fernseher ins IoT-VLAN. Ein tagged Port (Trunk) transportiert mehrere VLANs gleichzeitig per 802.1Q-Tag und verbindet die „Infrastruktur": Gateway zu Switch, Switch zu Switch, Switch zu Access Point. Der Access Point braucht die Tags, weil er pro SSID ein anderes VLAN funkt.

Faustregel: Endgeräte hängen an untagged Access-Ports, Netzwerkgeräte (Switch/AP/Gateway) verbinden sich über tagged Trunk-Ports. Das „Native VLAN" eines Trunks ist der untagged Rest — lass es bei deinem Management-/LAN-Netz, sonst verlierst du den Switch.

Netzwerke in UniFi anlegen

In der UniFi Network App (Self-Hosted Controller oder Cloud Gateway): Settings → Networks → New Virtual Network. Lege zwei neue an, z. B. „IoT" mit VLAN ID 20 und „Gäste" mit VLAN ID 30. Vergib jeweils ein eigenes Subnetz und aktiviere DHCP. Bei „Gäste" setzt du zusätzlich oben den Network-Typ auf Guest (aktiviert die L2-Client-Isolation, sodass Gäste sich nicht gegenseitig sehen).

SSID auf VLAN mappen

Unter Settings → WiFi legst du pro Zone eine SSID an. In den WiFi-Einstellungen wählst du unter „Network" das jeweilige virtuelle Netz:

SSID "Zuhause"   → Network: Default (VLAN 1)
SSID "Zuhause-IoT" → Network: IoT (VLAN 20)
SSID "Gäste"     → Network: Gäste (VLAN 30)

Der AP funkt jede SSID ins zugehörige VLAN und taggt den Traffic auf dem Trunk Richtung Switch. Du musst am AP nichts manuell taggen — das erledigt UniFi automatisch über das SSID-Mapping.

Switch-Ports zuweisen

Pro Port unter Ports → Port Manage ein Port-Profil setzen. Für ein Endgerät, das fest ins IoT-Netz soll (z. B. ein NAS-loser Smart-TV per Kabel), wählst du als Port-Profil das IoT-Netz (untagged = Access). Für den Uplink zum Gateway und zum AP nutzt du das Profil All bzw. einen Trunk, der LAN untagged und IoT/Gäste tagged führt.

Die entscheidende Firewall-Regel: IoT darf nicht ins LAN

Hier liegt der eigentliche Sicherheitsgewinn. Standardmäßig routet das Gateway zwischen allen VLANs frei. Du willst: LAN → IoT erlaubt (damit dein Handy den Drucker/Fernseher steuert), aber IoT → LAN blockiert. Eine Stateful-Firewall lässt Antwortpakete der vom LAN initiierten Verbindung automatisch durch — du musst also nur die von IoT neu aufgebauten Verbindungen ins LAN sperren.

Bei aktuellen UniFi-Versionen unter Settings → Security → Traffic & Firewall Rules eine neue Policy:

Aktion:   Block (Drop)
Richtung: Source = IoT (192.168.20.0/24)
          Destination = "RFC1918" / Local-Networks außer IoT
          oder konkret LAN 192.168.1.0/24 + Gäste 192.168.30.0/24
Connection-States: New
Logging: an (zum Testen)

Wichtig ist die Reihenfolge: Lege die Block-Regel nach einer eventuellen Allow-Regel für DNS/Multicast an. Pakete von etablierten Verbindungen (Established/Related) lässt du in Ruhe — sonst bricht die LAN→IoT-Steuerung. Gäste behandelst du genauso: Block Gäste → alle lokalen Netze, nur Internet bleibt offen.

mDNS/Bonjour-Falle beim Casting

Chromecast, AirPlay, Sonos & Co. finden sich über mDNS (Multicast, 224.0.0.251), das standardmäßig nicht über VLAN-Grenzen läuft. Wenn dein Handy im LAN den Chromecast im IoT-VLAN finden soll, aktiviere den mDNS-Reflector: Settings → Networks → Global Network Settings → Multicast DNS einschalten und die betroffenen Netze auswählen. Das durchbricht die Trennung kontrolliert nur für Discovery — die strikte Firewall-Block-Regel bleibt bestehen, der Reflector ersetzt sie nicht.

Teste vor dem Scharfschalten: Aktiviere Logging an der Block-Regel und prüfe unter „Insights → Flows", ob legitime Geräte unerwartet geblockt werden. Erst wenn Casting, Drucker und Steuerung laufen, deaktivierst du das Logging wieder.

Sicher ausrollen, ohne dich auszusperren

Die größte Gefahr: Du blockierst aus Versehen den Zugriff auf das Gateway/den Controller selbst. Halte deshalb immer einen kabelgebundenen Admin-Pfad im trusted LAN offen und arbeite die VLANs schrittweise ab — erst Netze und SSIDs anlegen und testen, dann die Firewall-Regeln aktivieren. Setze die Block-Regeln spezifisch auf IoT/Gäste als Quelle, nie pauschal „alles blocken". So bleibt dein Management-Zugang erreichbar, falls eine Regel danebengeht.