WLAN für IoT-Geräte: Eigenes Netzwerk einrichten (Anleitung)

Ein typischer Haushalt hat heute 18 bis 35 IoT-Geräte am WLAN — vom Saugroboter bis zur Zahnbürste. Genau das ist das Sicherheitsproblem: Eine kompromittierte Billig-Steckdose aus 2021 darf nicht im selben Subnetz hängen wie dein NAS mit Steuerunterlagen. Ein getrenntes IoT-WLAN ist 2026 keine Spielerei, sondern Pflicht-Hygiene.

Der zweite Grund ist Stabilität: Viele IoT-Geräte sprechen nur 2,4 GHz, einige machen Ärger im Mesh-Roaming, manche stören aktiv das 5-GHz-Band. Ein eigenes IoT-Netz löst alle drei Probleme gleichzeitig — wenn du es richtig aufsetzt.

Warum IoT-Geräte ins eigene Netzwerk gehören

IoT-Hardware ist die Schwachstelle. Update-Zyklen sind kurz (oft 18-24 Monate), danach hängt die Lampe ungepatcht im Heimnetz. Eine 2024er Mirai-Variante hat Tausende deutscher Smart-Plugs übernommen — Schadcode konnte von dort aufs Hauptnetz greifen, wenn alles im selben Subnetz lag.

Ein getrenntes IoT-WLAN bricht diese Brücke. Die Geräte erreichen das Internet, aber nicht deinen Arbeitslaptop, nicht die Backup-Platte, nicht das Bankkonto-Tablet. Standard heißt das Client-Isolation oder AP-Isolation und ist in jedem aktuellen Router-OS verfügbar.

Drei Konzepte: Gäste-SSID, VLAN, separater Router

Variante 1 ist die Gäste-SSID. Funktioniert mit jeder FRITZ!Box ab 7530, jedem Speedport Pro und jedem Asus-Router. Die Gäste-SSID ist standardmäßig isoliert vom LAN. Nachteil: Du teilst dir das Band mit Besuchern, und manche Router begrenzen die Geräteanzahl auf 32 oder 64.

Variante 2 ist VLAN-Tagging. Echter Trennungs-Standard. Der Router stellt eine zweite SSID mit eigener VLAN-Tag-ID (z. B. Tag 20 für IoT, Tag 30 für Gäste) bereit. Switch und Access-Points müssen 802.1Q sprechen. Das geht mit UniFi, OPNsense, ASUS Pro-Modellen und teils FRITZ!Box ab OS 7.50.

Variante 3 ist der separate Access-Point. Du steckst einen alten Router als reinen IoT-AP in einen LAN-Port und konfigurierst ihn als Bridge mit eigener SSID. Geht immer, kostet aber Strom und Platz.

FRITZ!Box: Gäste-WLAN für IoT umwidmen

FRITZ!OS ab Version 7.50 unterstützt zwei parallele Gäste-WLANs. Eines davon wird zum IoT-Netz. Pfad: WLAN → Gastzugang → Privater Gastzugang aktivieren. SSID setzen (z. B. "Heimnetz-IoT"), Verschlüsselung auf WPA2+WPA3, Häkchen bei "Gäste dürfen untereinander kommunizieren" entfernen. Wichtig: "Internet-Anwendungen wie E-Mail, Web und Push beschränken" deaktiviert lassen — IoT braucht oft MQTT auf Port 8883 oder Push-Dienste.

Der 2,4-GHz-Frequenzbereich muss aktiv bleiben (die meisten IoT-Geräte können kein 5 GHz). Bei FRITZ!Box ab 7590 kannst du explizit nur 2,4 GHz für die Gäste-SSID freigeben, was Bandbreite im 5-GHz-Band für deine echten Clients freihält.

UniFi und ASUS: Echte VLAN-Trennung mit 802.1Q

Bei UniFi (Dream Machine, UDM Pro, UCG-Ultra) legst du ein neues Netzwerk an: VLAN-ID 20, Subnetz 192.168.20.0/24, DHCP aktiv. Dann eine neue WiFi-SSID anlegen und im Feld "Network" das VLAN 20 auswählen. Firewall-Regel: "VLAN 20 to LAN — Block". Damit erreicht die smarte Lampe das Internet, aber niemals deinen Arbeitsrechner.

ASUS AiMesh ab Firmware 3.0.0.6 (Stand: Mai 2026) bietet "Guest Network Pro" mit echtem VLAN-Tagging. Pfad: Guest Network Pro → IoT → Enable. Hier kannst du IoT-typische QoS-Regeln setzen (geringe Priorität, max. 50 Mbit/s pro Client) damit der Saugroboter beim Update nicht das Netflix-Streaming bremst.

WLAN-Standard und 2,4-GHz-Optimierung für IoT

Praktisch alle IoT-Geräte funken 802.11n im 2,4-GHz-Band. Channel-Bonding auf 40 MHz ist hier kontraproduktiv: Es nimmt mehr Spektrum weg und stört Nachbar-WLANs. Setze die IoT-SSID auf 20 MHz Kanalbreite, fester Kanal 1, 6 oder 11.

WPA3-SAE wäre theoretisch sicherer, aber viele IoT-Geräte (ESP8266-basiert) sprechen kein WPA3. Praktischer Kompromiss: WPA2/WPA3-Transitional — neue Geräte nehmen WPA3, ältere fallen auf WPA2 zurück. PMF (Protected Management Frames) optional aktivieren, nicht zwingend.

Wenn das WLAN trotzdem instabil bleibt, lohnt eine systematische Diagnose. Der Mesh-vs-Repeater-Entscheider hilft bei der Frage, ob du für die IoT-Abdeckung im Keller einen zusätzlichen Knoten brauchst oder ob ein Powerline-Adapter mit IoT-AP reicht.

Pairing, Onboarding, Sonderfälle

Manche Geräte (Sonos, Apple HomePod, Chromecast) nutzen mDNS/Bonjour für die Erkennung. Bei strikter VLAN-Trennung sehen sie sich gegenseitig nicht mehr. Lösung: mDNS-Reflector aktivieren (UniFi heißt das "Multicast DNS", bei OPNsense "Avahi"). Dann werden mDNS-Pakete zwischen VLANs durchgereicht, ohne die Sicherheitstrennung aufzuheben.

Matter-fähige Geräte (ab Matter 1.2) onboarden über Bluetooth und brauchen das WLAN-Passwort temporär via QR-Code. Hier reicht meist die Standard-Konfiguration ohne Sonderregeln — Matter ist von Haus aus auf isolierte Netze ausgelegt.

Push-Dienste (Tuya, Mi Home, Aqara) sprechen oft mit chinesischen Cloud-Servern. Wenn du das aus Datenschutzgründen nicht willst, blockiere im IoT-VLAN die Ziel-Subnetze in der Firewall — meiste Hersteller publishen ihre Cloud-IPs in der Doku.

Bandbreiten-Reservierung und QoS für IoT

Im typischen Haushalt zieht der Saugroboter beim Firmware-Update plötzlich 80 Mbit/s, das Kamera-Backup in die Cloud läuft mit 30 Mbit/s, und parallel will das Tablet einen 4K-Stream. Wenn alles im selben WLAN ohne Priorisierung läuft, knackt es beim Stream — obwohl die Internetleitung 250 Mbit/s liefert. Die Lösung sind QoS-Regeln auf das IoT-VLAN. ASUS AiMesh bietet "Adaptive QoS" mit dem Profil "Smart Home", das IoT-Traffic automatisch auf 30 Prozent der Bandbreite begrenzt. UniFi nutzt "Smart Queues" und kann pro VLAN ein hartes Bandbreiten-Limit setzen. Die FRITZ!Box bietet im Standard nur eine grobe Priorisierung über "Echtzeit-Anwendungen" — für detaillierte IoT-QoS braucht es Drittanbieter-Hardware oder ein vorgeschaltetes pfSense/OPNsense-Gerät.

Ein praktisch wichtiger Punkt: viele IoT-Geräte laden nachts Updates herunter, typisch zwischen 2 und 5 Uhr lokaler Zeit. Diese Zeit ist meist unkritisch — Streaming läuft kaum, Cloud-Backups sind längst durch. Wenn dein Saugroboter aber tagsüber Updates zieht und dabei VoIP-Calls knirschen, lohnt eine zeitbasierte QoS-Regel: IoT-VLAN tagsüber auf 20 Mbit/s deckeln, nachts freigeben. ASUS, UniFi und OPNsense unterstützen solche Zeitfenster nativ. Bei der FRITZ!Box kann man zumindest die Update-Zeit der Geräte selbst oft konfigurieren — Tuya-Apps, Aqara und HomeKit haben dafür Einstellungen tief im Menü versteckt.

Monitoring: Wer macht eigentlich was im IoT-Netz

Sobald 25 oder mehr IoT-Geräte im eigenen VLAN hängen, verliert man den Überblick. Welche Lampe spricht mit welchem Server? Wer zieht 500 MB pro Tag? Ein praktisches Werkzeug ist PiHole oder AdGuard Home als DNS-Server fürs IoT-VLAN. Beide loggen jede DNS-Anfrage und zeigen, welches Gerät welche Domain abfragt. Auffälligkeiten — etwa eine Steckdose, die alle 2 Sekunden einen Server in Singapur anpingt — sind sofort sichtbar. Bonus: Beide blocken nebenbei Tracker und Telemetrie-Endpunkte, die manche IoT-Hersteller mitliefern.

Im UniFi-Dashboard zeigt die "Topology"-Ansicht direkt pro IoT-Gerät den Traffic-Verlauf der letzten 24 Stunden. FRITZ!Box bietet unter "Heimnetz → Mesh-Übersicht" eine vereinfachte Variante mit Tages-Traffic pro Client. Für tiefer-gehende Analyse empfiehlt sich ein Mirror-Port am Switch — Wireshark zeigt dann den kompletten Datenverkehr auf Paket-Ebene. Das ist Aufwand, aber einmal eingerichtet, weißt du genau, was die smarten Geräte im Haus wirklich tun.