OpenWrt mit VLANs segmentieren: Gastnetz und IoT-Isolation mit nachvollziehbaren Firewall-Regeln einrichten

Architektur und Grundlagen: Bridge vs. Routing, VLAN-Tagging, Trunk/Access-Ports und ein konsistentes Segmentmodell

Segmentierung mit OpenWrt steht und fällt mit einer klaren Grundarchitektur: Welche Netze werden nur auf Layer 2 getrennt (Switching/Bridging), welche Übergänge werden auf Layer 3 geroutet, und an welchen Stellen erzwingen Firewall-Regeln die gewünschten Kommunikationsgrenzen. VLANs liefern dabei die saubere Trennung auf der Kabel- und Funkstrecke, während das Routing auf dem OpenWrt-Gerät die kontrollierte Kopplung zwischen Segmenten herstellt.

Für konsistente Ergebnisse wird das Segmentmodell zuerst als logische Blaupause definiert (LAN, Gast, IoT, Admin), anschließend auf Ports und SSIDs abgebildet und erst danach in Firewall-Zonen übersetzt. Werden diese Ebenen vermischt, entstehen typische Fehlerbilder: „falsches“ DHCP im Segment, unbeabsichtigtes Bridging zwischen Netzen oder Regelwerke, die zwar Internet erlauben, aber DNS oder notwendige Dienste unbemerkt blockieren.

Bridge vs. Routing: Trennung auf Layer 2 und kontrollierte Kopplung auf Layer 3

OpenWrt kann mehrere Ports zu einer Bridge zusammenfassen und innerhalb dieser Bridge VLANs terminieren. Innerhalb eines VLANs arbeitet das System wie ein Switch: Broadcasts (z. B. ARP, DHCP Discover) bleiben im Segment. Zwischen VLANs findet hingegen Routing statt; erst dadurch werden Firewall-Zonen wirksam, und erst dadurch lassen sich Kommunikationspfade explizit erlauben oder verweigern.

Eine häufige Fehlannahme besteht darin, mehrere Netze „in eine Bridge“ zu legen und danach per Firewall zu trennen. Das ist nur dann belastbar, wenn die Trennung tatsächlich über VLANs (mit VLAN-Filtering auf der Bridge bzw. sauberem Switch-VLAN-Layout) erfolgt und die Netze nicht im gleichen L2-Segment landen. Best Practice ist daher: ein VLAN pro Segment, pro VLAN ein eigenes L3-Interface mit IP-Adresse und DHCP (oder statisch), und nur dort Forwarding/Traffic erlauben, wo es wirklich benötigt wird. Bridging bleibt auf das jeweilige Segment beschränkt (z. B. LAN-VLAN mit mehreren Access-Ports).

VLAN-Tagging: 802.1Q, Port-PVID und das Ende von „Switch-VLANs“ als Sonderwelt

VLANs basieren im Ethernet auf 802.1Q-Tags. Trunks transportieren mehrere VLANs getaggt über eine Leitung; Access-Ports ordnen ungetaggte Frames einem VLAN zu (PVID) und senden Frames typischerweise ungetaggt an Endgeräte. Auf OpenWrt werden VLANs in aktuellen Versionen primär über DSA (Distributed Switch Architecture) modelliert: Ports gehören nicht mehr zu einer separaten „Switch-Konfigurationsseite“, sondern werden als Linux-Netzwerkports und Bridges mit VLAN-Filterung verwaltet. Dadurch wird die Darstellung konsistenter, aber das Port- und Tagging-Modell muss sauber verstanden werden.

Entscheidend ist die Richtungskonsistenz: Wird ein Port als Trunk betrieben, müssen alle beteiligten Geräte (OpenWrt, Managed Switch, ggf. AP) dieselben VLAN-IDs, Tagging-States und native/untagged Regeln verwenden. Ein einziger abweichender „native VLAN“-/PVID-Wert führt schnell zu DHCP in der falschen Broadcast-Domain. Ebenso wichtig: Management-Zugänge (z. B. Switch- oder AP-Admin) gehören in ein klar benanntes Admin-VLAN und nicht „nebenbei“ ins LAN.

• VLAN-ID (802.1Q): Numerische Kennung des Segments auf dem Link, z. B. 10 (LAN), 20 (Gast), 30 (IoT), 99 (Admin).
• Tagged vs. Untagged: Auf Trunks laufen VLANs typischerweise tagged, auf Access-Ports wird ein VLAN als untagged geführt; ungetaggte Frames werden über die PVID in ein VLAN einsortiert.
• Native VLAN / PVID-Falle: Ein Trunk mit „native“ untagged VLAN führt dazu, dass ungetaggte Frames in einem bestimmten VLAN landen. Für reproduzierbare Setups wird auf Trunks bevorzugt ausschließlich tagged gearbeitet und untagged nur dort verwendet, wo es zwingend erforderlich ist (Endgeräte-Ports oder Geräte, die kein Tagging unterstützen).
• Bridge VLAN Filtering: VLANs werden innerhalb einer Bridge pro Port zugelassen oder gesperrt; damit wird festgelegt, welche VLANs ein Port transportiert und ob ein VLAN dort tagged oder untagged erscheint.

Trunk- und Access-Ports: Abbildung auf Switch, OpenWrt und Access Points

Der typische Aufbau im Heim- oder Small-Office-Umfeld nutzt einen Trunk vom OpenWrt-Gerät zum zentralen Switch und einen weiteren Trunk vom Switch zu einem oder mehreren Access Points. Endgeräteports am Switch bleiben Access-Ports und werden je nach Bedarf einem einzigen Segment zugeordnet. Damit bleibt die Fehlerfläche klein: Ein Clientport kann kein VLAN „aus Versehen“ in ein anderes Segment tragen.

Bei WLAN wird die Segmentierung über mehrere SSIDs oder über ein SSID-Profil mit VLAN-Zuordnung umgesetzt. Entscheidend ist, dass der Uplink zum AP als Trunk betrieben wird und die SSID jeweils auf ein VLAN gemappt ist. Wenn ein AP nur untagged einspeist, ist echte Mehrsegmentfähigkeit nicht gegeben; in dem Fall müssen SSIDs am AP per interner VLAN-Funktion oder per separater Verkabelung segmentiert werden.

Konsistentes Segmentmodell: Namenskonventionen, Netze und Zuständigkeiten

Ein segmentiertes Netz bleibt wartbar, wenn Bezeichner, VLAN-IDs, IP-Adressräume und Firewall-Zonen zueinander passen. Üblich ist eine „eine Zahl pro Segment“-Regel: VLAN 10 korrespondiert mit 192.168.10.0/24, VLAN 20 mit 192.168.20.0/24 usw. Dadurch werden Fehlzuordnungen schneller sichtbar, etwa wenn ein Client im Gastnetz eine Adresse aus dem LAN-Netz erhält.

Rollen sollten technisch ausgedrückt werden: „Admin“ bedeutet nicht „mehr Bandbreite“, sondern Zugriff auf Management-Interfaces (OpenWrt, Switch, AP, NAS-Admin), während „IoT“ typischerweise ausgehend ins Internet darf, aber keine Initiierung von Verbindungen ins LAN. „Gast“ ist in vielen Setups strikt internet-only, optional mit Zugriff auf einen Drucker oder ein Präsentationsgerät über eng begrenzte Ausnahmen. „LAN“ enthält Arbeitsgeräte und Serverdienste; interne Dienste (DNS, NTP, ggf. SMB) werden dort verortet und nur bei Bedarf für andere Segmente freigegeben.

• Segment-LAN: Vertrauenszone für Arbeitsplatzgeräte; VLAN z. B. 10, Netz z. B. 192.168.10.0/24.
• Segment-Gast: Unvertrauenszone, in der Regel nur forward nach WAN; VLAN z. B. 20, Netz z. B. 192.168.20.0/24.
• Segment-IoT: Reduzierte Rechte, oft mit gezielten Ausnahmen (z. B. zum Drucker); VLAN z. B. 30, Netz z. B. 192.168.30.0/24.
• Segment-Admin: Management und Infrastruktur; Zugriff auf Web-UIs/SSH, Switch/AP-Management, ggf. Monitoring; VLAN z. B. 99, Netz z. B. 192.168.99.0/24.

Dieses Modell legt fest, wo Bridging endet und Routing beginnt: Innerhalb eines Segments wird gebridged (mehrere Ports/SSIDs im gleichen VLAN), zwischen Segmenten wird geroutet und durch Zonenregeln beschränkt. Damit entsteht eine klare Kante, an der später DHCP/DNS-Design, SSID-Zuordnung und Firewall-Policies ohne Widersprüche angesetzt werden können.

Konfiguration in OpenWrt: Switch/Portmodell verifizieren, VLANs und Interfaces anlegen, DHCP/DNS je Segment, SSIDs zuordnen, Firewall-Zonen und Forwarding definieren

1) Switch- und Portmodell verifizieren (DSA vs. swconfig, CPU-Port, Trunk/Access)

Vor jeder VLAN-Konfiguration muss klar sein, wie das Gerät intern schaltet: aktuelle OpenWrt-Versionen setzen auf DSA (Distributed Switch Architecture), ältere Plattformen nutzen swconfig. Beide Modelle unterscheiden sich in Begriffen, UI-Pfaden und Fehlerbildern. Zusätzlich entscheidet die Verkabelung (CPU-/Uplink-Port, LAN-Ports, ggf. externer Managed Switch), ob VLANs als Trunk (tagged) oder Access (untagged) geführt werden. Ein falsch verstandener CPU-/Uplink-Port ist eine der häufigsten Ursachen für „kein Internet“ nach VLAN-Umstellung.

Die Prüfung erfolgt über Gerätestatus und Kernel-Log: Bei DSA erscheinen Switch-Ports typischerweise als eigenständige Netzgeräte (z. B. lan1, lan2), und Bridges werden explizit aufgebaut. Bei swconfig wird die VLAN-Mitgliedschaft über den Switch-Treiber verwaltet, Ports tragen oft eine Portnummer und das Tagging wird mit t markiert. Auf DSA-Systemen ist ein „VLAN-Filtering“ auf der Linux-Bridge zentral; auf swconfig-Systemen muss das VLAN-Layout im Switch korrekt sein, bevor Interfaces sauber greifen.

• Switch-Architektur erkennen: ubus call system board (liefert Modell/Target)
  ip link show (zeigt Ports/Bridges)
  logread -e dsa bzw. dmesg | grep -i dsa
• Switch/Ports bei swconfig prüfen (falls vorhanden): swconfig list
swconfig dev switch0 show
• Verkabelung dokumentieren (Trunk/Access): Uplink zum Managed Switch als Trunk (tagged VLANs), Endgeräteports als Access (untagged, PVID). Für OpenWrt-Ports werden Tagging-Entscheidungen konsistent notiert (z. B. lan4 = Trunk, lan1 = Access VLAN 10).

2) VLANs anlegen und Interfaces/Bridges sauber definieren

Auf DSA-Geräten wird zuerst die Bridge (typisch br-lan) mit VLAN-Filtering so aufgebaut, dass Ports entweder untagged (Access) oder tagged (Trunk) Mitglied eines VLANs werden. Danach werden pro Segment VLAN-Subinterfaces bzw. Bridge-VLAN-Devices angelegt, die als „Interface“ in OpenWrt erscheinen (z. B. br-lan.20 für VLAN 20). Bei swconfig wird die VLAN-Mitgliedschaft im Switch festgelegt und anschließend ein Interface auf dem entsprechenden VLAN-Device gebunden.

Wichtig ist die konsequente Trennung von Layer-2- und Layer-3-Aufgaben: Die Bridge/Portzuordnung bildet das Layer-2-Layout, während OpenWrt-Interfaces IP-Adressierung, DHCP, Firewall-Zonen und Dienste steuern. Vermischungen (z. B. mehrere Subnetze auf demselben L2-Segment) erschweren Fehlersuche und führen zu ungewolltem Broadcast-Leakage.

• VLANs auf DSA-Bridge aktivieren: In LuCI unter Network → Devices → br-lan → Bridge VLAN filtering VLAN-IDs hinzufügen und pro Port „tagged/untagged“ setzen; Trunk-Port tagged für alle benötigten VLANs, Access-Port untagged nur für genau ein VLAN.
• Layer-3-Interfaces pro Segment definieren: Für jedes VLAN ein Interface (z. B. admin, lan, iot, guest) mit statischer IPv4-Adresse (z. B. 192.168.30.1/24) auf dem jeweiligen Device (z. B. br-lan.30).
• MTU/Offloading konsistent halten: VLAN-Tagging erhöht die Ethernet-Frame-Größe um 4 Byte; in der Praxis ist das auf Ethernet meist unkritisch. Bei PPPoE/DS-Lite oder wenn Path-MTU-Discovery scheitert, kann eine reduzierte MTU am WAN-Interface erforderlich sein; segmentweise MTU-Änderungen sind nur sinnvoll, wenn ein Segment über einen abweichenden L2-Pfad/Uplink läuft.

3) DHCP je Segment und DNS-Resolver-Strategie festlegen

Pro Segment wird ein eigener DHCP-Server-Bereich konfiguriert, inklusive Gateway, DNS und Lease-Policy. In OpenWrt übernimmt das in der Regel dnsmasq (DHCPv4/DNS) und je nach Setup zusätzlich odhcpd (IPv6-RA/DHCPv6). Eine robuste Praxis ist: DNS für alle Segmente zentral über den Router, aber mit klaren Ausnahmen. Gäste erhalten typischerweise nur den Router als DNS und keine lokalen Suchdomänen; IoT erhält ebenfalls den Router, jedoch ohne Zugriff auf interne Hostnamen, sofern interne Namensauflösung nicht benötigt wird.

Für die DNS-Resolver-Strategie sind drei Punkte entscheidend: erstens die Bindung von DNS/DHCP an die korrekten Interfaces (damit kein Dienst „in fremde Segmente“ lauscht), zweitens eine konsistente lokale Domain (z. B. home.arpa statt historischer local-Namen), drittens die Entscheidung, ob interne Namen überhaupt segmentübergreifend auflösbar sein sollen. Wo Isolation gefordert ist, wird interne DNS-Auflösung in Gast/IoT bewusst eingeschränkt und stattdessen nur rekursive Auflösung ins Internet bereitgestellt.

• DHCP-Scopes sauber trennen: Je Interface eigener Pool, z. B. IoT 192.168.30.100-192.168.30.199, Gäste 192.168.20.100-192.168.20.250; statische Leases werden segmentbezogen gepflegt, um MAC-Reuse über Segmente sichtbar zu halten.
• DNS an Interfaces binden: In /etc/config/dhcp bzw. LuCI sicherstellen, dass dnsmasq nur auf den vorgesehenen Interfaces lauscht (Option interface) und dass für Gäste/IoT keine unnötigen lokalen Records verteilt werden (Optionen wie domain, localservice und ggf. separate DHCP-Optionen pro Interface). Je nach OpenWrt-Version/Setup kann zusätzlich list notinterface bzw. die LuCI-Option „Listen interfaces“ relevant sein; entscheidend ist, dass DNS/DHCP nicht unbeabsichtigt auf WAN oder fremden VLANs angeboten wird.
• Validierung aus dem jeweiligen Segment: nslookup openwrt.org 192.168.30.1 (DNS erreichbar)
  ip route (Default-Gateway korrekt)
  logread -e dnsmasq (Leases/Queries pro Interface nachvollziehen)

4) SSIDs zu VLANs zuordnen (Multi-SSID, WPA2/WPA3, AP-Bridge)

WLAN-SSIDs werden in OpenWrt als eigene Netzwerkschnittstellen behandelt, die an ein Layer-2-Netz gebunden werden. Auf Geräten mit integriertem AP bedeutet das: Jede SSID wird als „Access Point“ (nicht „Client“) angelegt und anschließend einem Netzwerk (Interface) zugeordnet, das wiederum auf dem passenden VLAN-Device liegt. Dadurch bleibt die Segmentierung konsistent: SSID guest landet in VLAN 20, SSID iot in VLAN 30. Bei externen Access Points erfolgt die Trennung stattdessen am Switch/Trunk; OpenWrt sieht dann nur die VLANs am Uplink.

Bei WPA3/WPA2-Mixed-Mode und älteren IoT-Geräten treten regelmäßig Assoziationsprobleme auf. Technisch ist das kein VLAN-Thema, wirkt aber wie „IoT kommt nicht ins Netz“. In solchen Fällen wird die IoT-SSID bewusst konservativ konfiguriert (häufig WPA2-PSK, 2,4 GHz, keine 802.11r-Roaming-Features), während Admin/LAN moderner abgesichert bleibt. Die VLAN-Zuordnung bleibt dabei unverändert.

• SSID-Binding in LuCI: Unter Network → Wireless pro SSID „Interface konfigurieren“ und bei „Netzwerk“ exakt das Zielinterface wählen (z. B. guest); keine Mehrfachzuordnung, sofern nicht absichtlich Bridging geplant ist.
• Tagging bei externen APs: AP-Uplink als Trunk (tagged VLANs), Management-SSID optional in Admin-VLAN; auf dem Switch PVID/untagged nur dort einsetzen, wo der AP es verlangt, und ansonsten konsequent tagged führen.

5) Firewall-Zonen, Forwardings und Ausnahmen ohne Segmentvermischung

Die Firewall wird zonenbasiert aufgebaut: eine Zone pro Segment (Admin, LAN, IoT, Gast) plus WAN. Grundregel: jedes Segment darf ins WAN, aber nicht lateral in andere internen Segmente. Admin darf administrativ auf Router und Infrastruktur, LAN darf auf ausgewählte Dienste (z. B. Drucker), IoT und Gast werden restriktiv gehalten. In OpenWrt wird dies über Zonen, Forwardings und gezielte Traffic Rules umgesetzt; NAT bleibt typischerweise nur auf der WAN-Zone aktiv.

Für Sonderfälle wie AirPrint, Chromecast oder AirPlay ist nicht „Firewall öffnen“ die Lösung, sondern präzise Steuerung von Discovery-Protokollen. mDNS (UDP/5353) und SSDP/UPnP-Discovery (UDP/1900 Multicast) funktionieren segmentübergreifend nicht ohne Hilfsmechanismus, weil Multicast/Broadcast an L3-Grenzen endet. OpenWrt kann mDNS über einen Reflector (z. B. avahi-daemon im Reflector-Modus) zwischen ausgewählten Segmenten spiegeln, ohne komplettes Routing zu erlauben. Für Chromecast-ähnliche Szenarien kommen zusätzlich gezielte Unicast-Freigaben und IGMP/Multicast-Themen hinzu; jede Ausnahme wird so eng wie möglich auf Quell-/Ziel-IP, Port und Richtung begrenzt.

• Zonen-Grundgerüst: admin, lan, iot, guest mit Policy input REJECT, forward REJECT, output ACCEPT; WAN mit masq 1 und mtu_fix je nach Anschluss. (Hinweis: Für admin/lan ist input REJECT nur dann sinnvoll, wenn Zugriffe auf den Router explizit per Traffic Rules erlaubt werden; viele Setups nutzen dort input ACCEPT und härten stattdessen über erlaubte Dienste/Listen-Interfaces.)
• Forwardings minimal halten: Nur admin → wan, lan → wan, iot → wan, guest → wan; kein guest → lan, kein iot → lan. Administrative Zugriffe auf OpenWrt (LuCI/SSH) ausschließlich aus admin.
• Gezielte Ausnahmen (Beispiele): Drucker im IoT-Segment: Allow von lan nach Drucker-IP auf tcp/9100, tcp/631, ggf. zusätzlich Discovery über mDNS-Reflector; keine pauschale Freigabe lan → iot. Chromecast: mDNS-Reflector nur zwischen lan und iot, zusätzliche Regel für Controller→Device-Ports erst nach Protokollanalyse (Conntrack- und Firewall-Logs nutzen).
• Fehlersuche bei „kein Internet/kein DNS“: Interface-Status: ifstatus guest
  Firewall-Hits: logread -e firewall und nft list ruleset (Zonen, Chains, Counter)
  Pfad prüfen: ping -c 3 1.1.1.1 (Routing) und nslookup openwrt.org (DNS) aus dem Segment heraus.

Sonderfälle und Fehlersuche: mDNS/Multicast, Drucker/Chromecast/AirPlay-ähnliche Ausnahmen ohne Segmentmix, Debug mit Status/Logs und reproduzierbare Dokumentation

mDNS, Multicast und Geräteerkennung über Segmentgrenzen

Segmentierung trennt Broadcast-Domänen; Discovery-Mechanismen brechen dadurch erwartbar. Viele Consumer-Protokolle basieren auf Multicast im Link-Local-Bereich, typischerweise mDNS auf 224.0.0.251:5353 (IPv4) beziehungsweise ff02::fb (IPv6). Diese Pakete werden nicht geroutet; ohne gezielte Proxy- oder Reflector-Funktion bleiben AirPlay-, Chromecast-, Sonos-, HomeKit- oder Drucker-Advertisings im jeweiligen VLAN.

In OpenWrt wird Discovery am saubersten mit einem mDNS-Reflector gelöst, der ausschließlich Ankündigungen spiegelt, nicht aber die Netze miteinander bridged. Dafür eignet sich umdns (bei Bedarf im Reflector-Modus), alternativ avahi-daemon mit Reflector-Funktion. Wichtig bleibt die Begrenzung auf exakt die Interfaces/Zonen, die Discovery benötigen (zum Beispiel IoT ↔ LAN), während Gastnetze typischerweise ausgeschlossen werden. Parallel müssen Firewall-Regeln mDNS erlauben, sonst arbeitet der Reflector zwar lokal, scheitert aber am Zonengrenzübergang.

Ausnahmen für Drucker, Chromecast, AirPlay: minimal erlauben, Segmentmix vermeiden

Ausnahmen sollten als explizite „Service-Korridore“ umgesetzt werden: ein Client aus Netz A darf zu einem konkreten Server/Gerät in Netz B, nicht zu „dem VLAN“. Dafür bieten sich IP-Reservierungen und Alias-Listen (Firewall-IP-Sets) an, um Regeln stabil und lesbar zu halten. Praktisch bewährt sich, Geräte mit Sonderrollen (Drucker, Mediaserver, Bridges) in ein eigenes Service-Segment zu legen oder zumindest mit festen IPs in IoT zu arbeiten; dynamische Adressen erzeugen sonst schwer nachvollziehbare Sonderregeln.

Bei Chromecast-ähnlichen Szenarien muss zwischen Discovery und Steuerung unterschieden werden. Discovery läuft häufig über mDNS; die eigentliche Session erfolgt dann per TCP/UDP zu gerätespezifischen Ports und ist je nach Hersteller unterschiedlich. Statt Port-Raten ist ein kontrolliertes Vorgehen zuverlässiger: zunächst nur Discovery spiegeln, dann Verbindungsversuche im Firewall-Log beobachten und daraus minimalistische Erlaubnisregeln ableiten. Ein Gastnetz sollte dabei weiterhin von allen internen Zielen getrennt bleiben; selbst „nur Drucker“ wird im Gast oft missbraucht und wird besser über separate, temporäre Mechanismen (z. B. zeitlich begrenzte Freigaben oder druckerseitige Gast-/PIN-Funktionen) abgedeckt, sofern verfügbar.

• mDNS für Discovery gezielt erlauben: Firewall-Regel auf den betroffenen Zonen/Interfaces für udp Port 5353 (IPv4 Multicast 224.0.0.251, optional IPv6 ff02::fb), kombiniert mit einem Reflector (umdns oder avahi-daemon) nur auf den benötigten Interfaces. (Hinweis: Je nach Implementierung/Setup ist die Regel als „eingehend zum Router“ auf den beteiligten Zonen zu formulieren, weil der Reflector auf dem Router empfängt und erneut sendet.)
• Druckpfad minimal öffnen: Nur von definierten Client-Netzen zu fixer Drucker-IP, typischerweise tcp/9100 (RAW), tcp/631 (IPP) oder herstellerspezifisch; kein allgemeines Forwarding guest → lan und keine „any-to-any“-Regeln.
• Chromecast/AirPlay-Steuerung aus Logs ableiten: Nach aktivierter Protokollierung der Drop-Regeln (z. B. in der Zone iot) die Ziel-Ports aus logread -e firewall oder nft list ruleset ableiten und als eng gefasste Allow-Regeln (Quelle = Controller-Netz, Ziel = Geräte-IP/Set) umsetzen.
• Client-Isolation korrekt einsetzen: WLAN-Client-Isolation (AP-seitig) nur im Gastnetz aktivieren; in IoT kann sie Discovery/Steuerung innerhalb des VLANs unerwartet verhindern, wenn Geräte untereinander sprechen müssen (z. B. Lautsprechergruppen).

Fehlersuche in drei Klassen: „kein Internet“, „kein DNS“, „Gerät sieht Gerät nicht“

Fehlerbilder lassen sich meist auf eine von drei Ursachenketten reduzieren: fehlendes Routing/Forwarding, kaputte Namensauflösung oder blockierte Ost-West-Kommunikation. Entscheidend ist eine reproduzierbare Reihenfolge: zuerst Link/VLAN, dann IP/DHCP, dann DNS, dann Firewall und erst zuletzt Anwendungsebene. Bei OpenWrt liefert die Kombination aus Statusanzeigen und CLI die schnellste Eingrenzung.

• „Kein Internet“ (L3/NAT): Interface-Status prüfen ubus call network.interface.wan status und ip route; NAT/Forwarding im Ruleset verifizieren nft list ruleset; Paketpfad am WAN beobachten tcpdump -ni wan 'icmp or (tcp and port 443)'.
• „Kein DNS“ (Resolver/DHCP-Optionen): Lease-Parameter auf dem Client prüfen (Gateway/DNS-Server); auf OpenWrt logread -e dnsmasq und ubus call service list; Auflösung testen nslookup openwrt.org 192.168.x.1 und falls DoH/Stubby genutzt wird zusätzlich Upstream-Erreichbarkeit prüfen (z. B. per tcpdump -ni wan port 53 für klassisches DNS oder per Mitschnitt auf dem tatsächlich genutzten DoH/DoT-Port).
• „Gerät sieht Gerät nicht“ (Discovery/Firewall): mDNS sichtbar machen tcpdump -ni br-XYZ udp port 5353; bei SSDP/UPnP tcpdump -ni br-XYZ udp port 1900; Drop-Logs aktiv auswerten logread -e 'DROP\|REJECT' und parallel Zonen-Matrix prüfen uci show firewall.
• VLAN/Port-Tagging als Grundursache: Wenn nur einzelne Ports/SSIDs betroffen sind, VLAN-Mitgliedschaften und PVID/Tagged-Status am Switchmodell verifizieren (DSA: ip -d link show, Bridge/VLAN-Zustand z. B. via bridge vlan show); asymmetrische Tagging-Fehler zeigen sich oft als „DHCP geht, aber nur in eine Richtung“.

Logs, Statusseiten und paketbasierte Diagnose ohne Rätselraten

Für eine belastbare Diagnose braucht es Beobachtungspunkte pro Segment: Interface-Status (Carrier, Adressen, Routen), DHCP/DNS-Logs, Firewall-Hits und ein kurzer Mitschnitt am richtigen Interface. Dabei sollte der Mitschnitt immer an der Stelle erfolgen, an der das Paket voraussichtlich verworfen wird: bei VLAN-Problemen auf dem Bridge-/VLAN-Device, bei Firewall-Problemen auf dem eingehenden Zonen-Interface, bei WAN-Problemen direkt auf wan.

Mit nftables lässt sich die Wirksamkeit von Regeln nicht nur lesen, sondern auch über Zähler prüfen. Steigen Counter in Drop-Chains, ist die Ursache häufig bereits gefunden; steigen sie nicht, landet der Verkehr an anderer Stelle (falsches Interface, falsche Zone, falscher Adressbereich). Ergänzend hilft ein konsequentes Benennen von Zonen, Interfaces und IP-Sets; kryptische Default-Namen erschweren die Korrelation von Logs, Regeln und Topologie.

Reproduzierbare Dokumentation: Änderungen nachvollziehbar halten

Segmentierung wird schnell unübersichtlich, sobald Ausnahmen hinzukommen. Reproduzierbarkeit entsteht nicht durch Screenshots, sondern durch eine klare Änderungslogik: Was wurde geändert, warum, und welche Abhängigkeiten bestehen (VLAN-ID, SSID-Zuordnung, DHCP-Optionen, Firewall-Regeln, Reflexionsdienste). Für OpenWrt ist uci die natürliche Quelle; relevante Konfigurationsstände sollten als Text exportiert und versioniert werden. Zusätzlich ist eine „Betriebsdoku“ sinnvoll, die für jedes Segment Zweck, Adressraum, DNS/DHCP-Verhalten und erlaubte Kommunikationspfade festhält.

• Konfigurationssnapshots als Text: Vor und nach Änderungen exportieren, z. B. uci export network
uci export dhcp
uci export firewall.
• Zonen- und VLAN-Matrix pflegen: Pro VLAN die Attribute dokumentieren (VLAN-ID, Subnetz, Gateway-IP, SSID/Ports, DHCP-Range, DNS-Policy) und pro Zone die Forwardings/Allow-Regeln; idealerweise ergänzt um Referenzen auf IP-Sets/Aliase.
• Änderungen messbar machen: Zu jeder Ausnahme einen Testfall notieren (Quelle, Ziel, Protokoll/Port, erwartetes Ergebnis) und die Beobachtungspunkte festhalten, z. B. tcpdump-Interface und relevante logread-Filter.