Heimnetz in VLANs trennen: Aufbau, DHCP-Relay und Stand des Umbaus

Rund 150 Geräte in einem einzigen flachen /24-Netz sind bequem, solange man nicht darüber nachdenkt, dass jede smarte Steckdose, jede Kamera und jedes Gast-Smartphone direkt mit den Windows-Domänencontrollern, dem Proxmox-Cluster und dem Dateiserver sprechen kann. Ich trenne mein Heimnetz deshalb schrittweise in acht VLANs auf. Auf der Firewall stehen die neuen Netze, die zweite Netzwerkkarte für Home Assistant und die Protokollierung bereits, während die Geräte derzeit Gruppe für Gruppe umziehen und die eigentlichen Sperrregeln erst nach einer mehrwöchigen Verkehrsanalyse scharfgeschaltet werden.

Ausgangslage: 150 Geräte und zwei Hardware-Bremsen

Historisch ist das Netz rund um die Active-Directory-Domäne example.lan in einem einzigen Subnetz (hier als Beispiel 192.0.2.0/24) gewachsen. Darin liefen sämtliche Systeme nebeneinander: drei Proxmox-Knoten (Knoten 1 bis 3), zwei Windows-Domänencontroller (192.0.2.12 und 192.0.2.13) im DHCP-Failover-Verbund, zwei AdGuard-Home-Instanzen (192.0.2.22 und 192.0.2.23), der Dateiserver sowie Home Assistant, Frigate und Plex. Im selben Adressbereich hingen Arbeitsplatzrechner, Smartphones, Drucker, eine Spielkonsole, ein Heizungs-Gateway von Buderus, Kameras samt Reolink Home Hub und Türklingel sowie Dutzende WLAN-Komponenten von Tuya, Shelly und Xiaomi neben Amazon Echo und Fire TV.

Als Gateway dient eine OPNsense 26.7.5 in einer virtuellen Maschine auf Knoten 2. Ihre LAN-Schnittstelle vtnet0 hing bisher ungetaggt an der Proxmox-Bridge vmbr1 (192.0.2.1/24), während der Glasfaseranschluss über VLAN 700 mit öffentlicher IPv4-Adresse ohne IPv6 angebunden ist. Ein älteres Verwaltungsnetz für Access Points und ein vorbereitetes Testnetz lagen lediglich als virtuelle Zusatzadressen (VIPs) auf derselben Schnittstelle vtnet0 – logisch auf dem Papier getrennt, auf Layer 2 aber im selben Broadcast-Segment.

Einer sauberen 802.1Q-Trennung standen bei der Bestandsaufnahme am 19. Oktober 2026 vor allem zwei Hardware-Grenzen im Weg:

• Am zentralen 24-Port-Gigabit-Switch (Netgear GS724Tv3, Firmware 5.4.2.30, ohne PoE) waren nur sieben Ports belegt, doch an Port g16 hing ein unverwalteter 2,5-Gbit-Switch mit acht Ports. Genau an diesem unverwalteten Switch steckten alle drei Proxmox-Knoten, die OPNsense, die Domänencontroller und der Dateiserver mit zusammen 25 Adressen. Ein solcher Switch kann keine VLAN-Trunks sauber nach Ports aufschlüsseln.
• Für das WLAN sorgten drei HUAWEI WiFi AX3 (WS7200-20) und eine FRITZ!Box 7590 AX (FRITZ!OS 8.25) im IP-Client-Modus, an der allein 34 WLAN-Geräte und die DECT-Thermostate hingen. Die Huawei-Geräte erlauben wegen ihres signierten HiSilicon-Bootloaders kein OpenWrt und können in der Hersteller-Firmware keine SSIDs auf VLANs abbilden; auch die FRITZ!Box unterstützt als IP-Client keine VLAN-Zuordnung.

Neue Switch- und WLAN-Ebene ohne zweite Switch-Etage

Um beide Engpässe aufzulösen, habe ich am 19. Oktober 2026 einen verwalteten 2,5-Gbit-Switch vom Typ Grandstream GWN7721 (acht 2,5-Gbit-Kupferports plus zwei SFP+-Slots für 1, 2,5 oder 10 Gbit, Layer 2 Lite managed mit 802.1Q für bis zu 32 VLANs, RSTP und lokaler Weboberfläche ohne Cloud-Zwang) sowie vier Zyxel T-56 (baugleich zum EX5601-T1, MediaTek MT7986a, 4×4 Wi-Fi 6, 1 GB RAM, 512 MB NAND) mit vorinstalliertem OpenWrt 25 beschafft. Weder der GWN7721 noch die Zyxel-Geräte nutzen PoE; jedes Gerät läuft über sein eigenes 12-V-Steckernetzteil.

Bei der Planung der neuen Verkabelung zeigte sich ein angenehmer Nebeneffekt der Zyxel T-56: Jedes Gerät besitzt fünf Ethernet-Ports – WAN und lan1 mit 2,5 Gbit/s sowie lan2 bis lan4 mit 1 Gbit/s. Geht der Uplink zum Switch über lan1, bleiben an jedem Access Point vier Ports frei. Unter OpenWrt lässt sich jedem dieser Ports einzeln ein ungetaggtes VLAN zuweisen. Damit übernehmen die vier Access Points an ihren Standorten im Haus gleichzeitig die Aufgabe kleiner Zugangs-Switche für ortsfeste Kabelgeräte: An einem Standort hängen Spielkonsole und Fire TV Cube direkt am Access Point, am zweiten das Heizungs-Gateway (100 Mbit/s), am dritten der Drucker sowie die FRITZ!Box 7590 AX, deren eigenes WLAN abgeschaltet wird und die nur noch als DECT-Basis für die Heizkörperthermostate dient.

Am Grandstream GWN7721 geht die Portrechnung dadurch auf, ohne dass der alte 24-Port-Switch weiterlaufen muss:

• SFP+ 1 (10 Gbit/s): Knoten 3 (Mainboard Gigabyte B760M DS3H). Da der PCIe-x16-Steckplatz durch eine an eine VM durchgereichte Radeon-Grafikkarte belegt ist und die x1-Steckplätze zu schmal sind, wandert eine SFP+-Karte (Intel X520/X710 oder Mellanox ConnectX-3/4 Lx per DAC-Kabel) über einen Adapter in den freien M.2-Steckplatz M2A_CPU (PCIe 4.0 x4). Eine Karte mit Realtek RTL8127 schied aus, weil deren Treiber erst ab Linux 7.4 im Kernel steckt, Knoten 3 aber mit Kernel 7.0 läuft. Der bisherige USB-Netzwerkadapter auf Knoten 3 bleibt als Reserve im Bond.
• RJ45 1 und RJ45 2 (2,5 Gbit/s): Knoten 1 und Knoten 2 (jeweils Dell Wyse 5070 mit USB-2,5-Gbit-Adapter).
• RJ45 3 (2,5 Gbit/s): Schneller Arbeitsplatz-PC.
• RJ45 4 bis RJ45 7 (2,5 Gbit/s): Uplink für die vier Zyxel T-56 über deren Port lan1.
• RJ45 8 (2,5 Gbit/s) und SFP+ 2: Reserve für einen weiteren PC im Haus.

Durch diese Aufteilung entfällt der alte Netgear GS724Tv3 komplett. Das spart rund 13,5 Watt Dauerverbrauch, entfernt ein End-of-Life-Gerät aus dem Betrieb und erspart den 1-Gbit-Flaschenhals zwischen zwei Switch-Etagen. Abgebaut wird er trotzdem erst ganz am Schluss, und danach bleibt er stromlos als schneller Rückfallweg im Schrank liegen. Einen Preis hat die schlanke Verkabelung über die Access Points allerdings: Startet ein Zyxel T-56 wegen eines OpenWrt-Updates neu, verlieren die an seinen LAN-Ports angeschlossenen Geräte – inklusive der DECT-Basis an der FRITZ!Box – für ein bis zwei Minuten die Verbindung. Updates der Access Points laufen deshalb grundsätzlich einzeln und angekündigt.

Der Netzzuschnitt auf Proxmox und OPNsense

Bei der Aufteilung der Netze habe ich mich dagegen entschieden, die zentralen Server umzuziehen. Das bestehende ungetaggte Netz bleibt das Servernetz: Die drei Proxmox-Hosts, beide Domänencontroller, AdGuard Home, der Dateiserver und Home Assistant behalten ihre festen IP-Adressen. Um 802.1Q-Tags bis zur Firewall durchzureichen, musste auf den drei Proxmox-Knoten lediglich der Haken VLAN-aware auf der Bridge vmbr1 gesetzt werden – ein Eingriff, der im laufenden Betrieb ohne Ausfall für das ungetaggte Bestandsnetz durchlief.

Auf der Schnittstelle vtnet0 der OPNsense sind neben dem ungetaggten Servernetz und dem WAN-VLAN 700 acht VLAN-Schnittstellen eingerichtet:

VLAN-ID	Bezeichnung	Geräte und Zweck	WLAN-Zuordnung
ungetaggt	Servernetz	Proxmox-Knoten 1–3, 2× Domänencontroller, 2× AdGuard Home, Dateiserver, Home Assistant	kein WLAN
VLAN 10	Verwaltung	Weboberflächen von GWN7721 und den vier OpenWrt-Access-Points (löst die alte VIP ab)	kein WLAN
VLAN 20	Clients	Arbeitsplatzrechner, Notebooks, eigene Smartphones und Tablets	Haupt-SSID (WPA2/WPA3)
VLAN 21	Ohne Filter	Sondernetz mit reinem Internetzugang ohne AdGuard-Sperrlisten (DNS direkt über Unbound)	eigene SSID (WPA2/WPA3)
VLAN 30	IoT	Sensoren und Aktoren (Tuya, Shelly, Xiaomi) sowie das Buderus-Heizungs-Gateway	IoT-SSID (2,4 GHz, WPA2, PPSK 1)
VLAN 31	Kameras	Reolink Home Hub, Türklingel und Kameras (mit Internetzugang)	IoT-SSID (2,4 GHz, WPA2, PPSK 2)
VLAN 35	Medien	Amazon Echo, Fire TV und Spielkonsole, getrennt von den einfachen Sensoren	IoT-SSID (2,4 GHz, WPA2, PPSK 3)
VLAN 40	Gäste	Besucher-Geräte mit aktiver Client-Isolation und reinem Internetzugang	Gäste-SSID (WPA2/WPA3)
VLAN 50	Testnetz	Erstes echtes VLAN (statt der früheren VIP) zum Vorabtest von DHCP, DNS und Regeln	nur bei Bedarf

Damit im 2,4-GHz-Band nicht drei zusätzliche SSIDs für Sensoren, Kameras und Mediengeräte die Airtime auffressen, nutzen die VLANs 30, 31 und 35 auf den Zyxel T-56 eine gemeinsame IoT-SSID mit reinem WPA2. Die Zuordnung zum richtigen VLAN erfolgt über PPSK (Private Pre-Shared Key): Je nachdem, mit welchem der drei hinterlegten WLAN-Kennwörter sich ein Gerät anmeldet, setzt OpenWrt das Tag für VLAN 30, 31 oder 35.

Zweite Netzwerkkarten statt Dauerlast auf der Firewall-VM

Wenn du eine Firewall als virtuelle Maschine auf einem kompakten Proxmox-Knoten betreibst, hat striktes Routing zwischen allen VLANs einen Haken: Jeder Kamera-Dauerstrom zu Frigate und jeder große Videostream von Plex müsste einmal quer durch vtnet0 in die OPNsense-VM und wieder zurück auf die Bridge. Hinzu kommt, dass viele Smart-Home- und Mediengeräte auf Broadcasts oder Multicast im lokalen Subnetz angewiesen sind.

Ich habe deshalb im Bestandsregister geprüft, welche Dienste ein direktes zweites Bein im jeweiligen Ziel-VLAN bekommen sollten – und wo man das besser bleiben lässt:

• Home Assistant bleibt mit seiner Hauptadresse im Servernetz, besitzt aber zusätzliche virtuelle Netzwerkkarten in VLAN 30 (IoT) und VLAN 35 (Medien). Zusätzlich läuft auf der OPNsense der mDNS-Repeater zwischen Client-VLAN 20, Medien-VLAN 35 und dem Servernetz, damit die Steuerung per Smartphone-App und Matter über die Netzgrenze hinweg funktionieren.
• Für Frigate ist eine zweite Netzwerkkarte in VLAN 31 (Kameras) sinnvoll, geprüft, aber noch nicht angelegt: Die Videoströme aller Kameras würden dann direkt auf Layer 2 in den Dienst fließen, ohne die OPNsense-VM zu belasten.
• Für Plex gilt dasselbe in VLAN 35 (Medien), ebenfalls noch offen: Eine zweite Karte würde die lokale Erkennung per Broadcast und große Streams zum Fernseher abkürzen.

Für jedes System mit zweiter Karte gelten zwei feste Regeln: Erstens ist die IP-Weiterleitung im Gast-Kernel abgeschaltet (net.ipv4.ip_forward = 0), damit niemand ein solches System als heimlichen Router an der Firewall vorbei missbrauchen kann. Zweitens lauschen auf der Zusatzkarte nur die dort benötigten Ports. Bewusst kein zweites Bein erhalten die beiden Windows-Domänencontroller, AdGuard Home und das Monitoring. Gerade auf Active-Directory-Domänencontrollern führen mehrere Netzwerkkarten regelmäßig zu falschen DNS-Selbstregistrierungen und schwer auffindbaren Routing-Fehlern.

DHCP-Relay über zwei Domänencontroller und die Namensschutz-Falle

Für die Adressvergabe in den neuen VLANs bot sich auf den ersten Blick der DHCP-Dienst auf der OPNsense an. Da im Servernetz aber ohnehin zwei Windows-Domänencontroller im DHCP-Failover-Verbund laufen und die lokale Namensauflösung für example.lan verwalten, bleibt DHCP und DNS für alle internen Segmente (VLAN 10, 20, 30, 31, 35 und 50) zentral auf den beiden Domänencontrollern. Die OPNsense leitet DHCP-Anfragen aus diesen sechs VLANs per DHCP-Relay an beide Server weiter. Dort lege ich die Bereiche (Scopes) je VLAN einzeln an und gleiche sie im Failover ab.

Alle Geräte in den internen VLANs bekommen per DHCP die beiden Domänencontroller als DNS-Server zugewiesen; die Domänencontroller leiten externe Anfragen an die beiden AdGuard-Home-Instanzen weiter. Damit auch Linux-Systeme, Kameras und IoT-Komponenten ohne Domänenmitgliedschaft im internen DNS unter ihrem Namen auflösbar sind, ist auf den Windows-DHCP-Servern die dynamische DNS-Registrierung für sämtliche Clients aktiviert – der DHCP-Server trägt den vom Gerät gemeldeten Hostnamen stellvertretend in die Zone ein.

Wie gefährlich diese Standardeinstellung ohne zusätzliche Absicherung ist, zeigte sich am 23. Oktober 2026 direkt beim Vorabtest: Ein Testgerät meldete sich im neuen Netz mit dem Hostnamen knoten4 beim DHCP-Server – und der DHCP-Dienst überschrieb daraufhin auf beiden Domänencontrollern ungefragt den bestehenden statischen A-Eintrag dieses Namens in der DNS-Zone. Ein beliebiges Gerät im IoT- oder Kamera-VLAN hätte so durch bloßes Setzen seines eigenen Hostnamens bestehende DNS-Einträge im Heimnetz kapern können.

Bevor das erste produktive Gerät umziehen durfte, habe ich deshalb auf beiden Domänencontrollern für alle sechs internen VLAN-Bereiche den DHCP-Namensschutz (NameProtection auf Basis von DHCID-Einträgen nach RFC 4701) per PowerShell eingeschaltet und zwischen beiden Servern verglichen:

# Auf beiden Domänencontrollern für die VLAN-Bereiche 10, 20, 30, 31, 35 und 50 ausführen:
$Scopes = @("192.0.2.0") # stellvertretend je VLAN-Subnetz-ID
foreach ($Scope in $Scopes) {
    Set-DhcpServerv4DnsSetting -ScopeId $Scope -NameProtection $true
    Get-DhcpServerv4DnsSetting -ScopeId $Scope | Select-Object ScopeId, DynamicUpdates, NameProtection
}

Mit aktivem NameProtection verweigert der DHCP-Server das Überschreiben eines bereits existierenden DNS-Namens, sobald dieser einem anderen Gerät oder einem festen Eintrag gehört. Komplett außen vor bleiben bei diesem Weg ohnehin das Gästenetz (VLAN 40) und das ungefilterte Netz (VLAN 21): Dort macht die OPNsense selbst DHCP und beantwortet DNS-Anfragen lokal über Unbound (für Gäste mit Weiterleitung an AdGuard Home, für VLAN 21 ungefiltert direkt ins Internet). Fremde Smartphones im Gäste-WLAN hinterlassen so keinerlei Spuren im Active-Directory-DNS.

Erst protokollieren, dann sperren: Stand des Umbaus

Der häufigste Fehler beim nachträglichen Segmentieren eines gewachsenen Heimnetzes besteht darin, neue VLANs anzulegen, sofort harte Sperrregeln zu setzen und anschließend im Dunkeln zu suchen, warum der Saugroboter, die Türklingel oder das Streaming am Fernseher streikt. Ich gehe deshalb den umgekehrten Weg und werte vor jeder Sperre erst den realen Verkehr aus.

Auf der OPNsense starten die neuen internen VLANs (10, 20, 30, 31 und 35) mit offenen Firewall-Regeln, die den Verkehr zwischen den Netzen vorerst erlauben, aber jede Verbindung mitprotokollieren. Parallel ist auf der OPNsense NetFlow (Insight) aktiviert. Sofort hart auf reinen Internetzugang beschränkt sind von Tag eins an nur das Gästenetz (VLAN 40) und das ungefilterte Netz (VLAN 21). Beim WireGuard-VPN räume ich als Nächstes auf: Eine zweite, nie genutzte Instanz fällt weg, die aktive Instanz bekommt die Regeln des Client-Netzes, und jedes Endgerät bekommt zwei Profile – einen Split-Tunnel nur für die Heimnetze und einen Voll-Tunnel. Für das Smartphone soll im Voll-Profil in der WireGuard-App unter „Ausgeschlossene Anwendungen“ Android Auto eingetragen werden, weil der Voll-Tunnel sonst den lokalen Datenverkehr zum Fahrzeug abfängt und die Verbindung im Auto abbricht.

Weil alle Eingriffe im laufenden Betrieb und ausschließlich außerhalb meines nächtlichen Backup-Fensters (02:00 bis 04:00 Uhr) stattfinden, ist der Umbau in einzelne Sitzungen mit jeweils eigenem Rückfallweg aufgeteilt. Anfang November 2026 sieht der Stand so aus:

• Abgeschlossen sind die Aktivierung von VLAN-aware auf vmbr1 über alle drei Proxmox-Knoten, die Einrichtung des Testnetzes (VLAN 50) sowie der produktiven VLANs 10, 20, 21, 30, 31, 35 und 40 auf der OPNsense. Ebenso laufen die protokollierenden Startregeln, NetFlow/Insight, Unbound für die VLANs 21 und 40, der mDNS-Repeater, die zweite Netzwerkkarte an Home Assistant sowie der DHCP-Namensschutz auf beiden Domänencontrollern.
• Aktuell in Arbeit sind der Feinschliff am DHCP-Relay über die beiden Domänencontroller und der gruppenweise Umzug der IoT-Sensoren, Mediengeräte und Kameras über die PPSK-SSID in die VLANs 30, 31 und 35. Jede Gerätegruppe wird nach dem Wechsel einzeln gegen Home Assistant und Frigate getestet; hakt ein Gerät, reicht das Zurückstellen des WLAN-Kennworts oder des Switch-Ports als sofortiger Rückfallweg.
• Noch offen sind das Umlegen der Verwaltungsadressen von Switch und Access Points in VLAN 10 samt Löschen der alten VIP auf der OPNsense, das Freischalten des Gäste-WLANs im Alltagsbetrieb und im letzten Schritt der Umzug der regulären Arbeitsplatzrechner und Smartphones in VLAN 20.

Sobald alle Geräte, auch die Clients in VLAN 20, in ihrem Ziel-VLAN laufen, sammle ich über zwei bis vier Wochen die NetFlow-Daten auf der OPNsense; erst danach klemme ich den alten 24-Port-Switch ab. Erst aus dieser Auswertung – welche Quelle in VLAN 30, 31 oder 35 mit welchem Ziel auf welchem Port spricht – entstehen die endgültigen Firewall-Regeln, die IoT, Kameras und Mediengeräte auf die Verbindungen festnageln, die sie im Alltag wirklich brauchen.