OpenWrt mit VLANs segmentieren: LAN, Gastnetz und IoT sauber trennen und korrekt freischalten

Netzarchitektur mit OpenWrt: Switch-/Portmodell, Bridge-Konzept und VLAN-Tagging (Trunk vs. Access)

Die Segmentierung eines Netzes mit OpenWrt beginnt nicht in der Firewall, sondern auf der Layer-2-Ebene: Switch-Chip, Portzuordnung, Bridge-Design und VLAN-Tagging entscheiden darüber, ob Netze sauber getrennt bleiben oder unbemerkt ineinanderlaufen. Das gilt besonders dann, wenn mehrere SSIDs über einen Access Point in unterschiedliche VLANs abgebildet werden oder wenn ein externer Managed Switch per Trunk angebunden ist. In OpenWrt hängen diese Entscheidungen eng mit dem verwendeten Treiber- und Switchmodell zusammen, weil sich die Konfiguration je nach DSA- oder (älterem) swconfig-Design unterscheidet.

Switch-/Portmodell erkennen: DSA vs. separater Switch-Chip

OpenWrt bildet Ports und VLANs entweder als „normale“ Linux-Netzinterfaces (DSA) oder über eine Switch-Abstraktion ab. Moderne Geräte nutzen in der Regel DSA: Jeder physische Port erscheint als eigenes Interface (je nach Plattform z. B. lan1/lan2, eth0/eth1 oder auch swp0/swp1), VLANs werden als Subinterfaces (zum Beispiel br-lan.10 oder eth0.10) angelegt, und Bridges verhalten sich wie klassische Linux-Bridges. Bei älteren Plattformen kann swconfig im Einsatz sein; dort werden VLANs direkt am Switch definiert und Ports in VLANs „getaggt“ oder „untagged“ zugewiesen. Für die Architekturentscheidung zählt vor allem, welche Portnamen in ip link auftauchen und ob im Systemlog Hinweise auf DSA oder swconfig erscheinen; ubus call system board liefert dafür Board-/Release-Informationen, ist aber allein kein eindeutiger DSA-Nachweis.

• Port-/Interface-Inventar: ip -br link
ip -d link show
• Board- und Treiberhinweise: ubus call system board
logread -e dsa -e switch -e swconfig
• Bridge-/VLAN-Überblick: bridge link
bridge vlan show

Bridge-Konzept: eine Bridge, mehrere VLANs (VLAN-aware) statt Bridge-Sprawl

Für segmentierte Heim- und Small-Office-Netze hat sich ein VLAN-aware-Bridge-Ansatz etabliert: Eine zentrale Layer-2-Bridge (häufig br-lan) führt mehrere VLANs, die jeweils eigenen Layer-3-Interfaces zugeordnet werden. Der entscheidende Punkt ist die Trennung der Broadcast-Domänen: VLANs definieren, welche Frames gemeinsam „sehen“. Die Bridge bleibt dabei nur Transport; IP-Adressierung, DHCP und Firewall werden pro VLAN auf eigene Interfaces gelegt. Das verhindert, dass WLAN-SSIDs oder Kabelports „zufällig“ im gleichen Netz enden, nur weil sie an derselben Bridge hängen.

Wichtig ist die saubere Planung der PVID (Port VLAN ID) je Access-Port: Ungetaggter Traffic eines Endgeräts soll genau in einem VLAN landen. Trunk-Ports tragen hingegen mehrere VLANs getaggt, typischerweise zum Access Point oder zu einem Managed Switch. Untagged auf Trunks wird nach Möglichkeit vermieden; falls ein Native-VLAN erforderlich ist, muss es bewusst dokumentiert und auf beiden Seiten identisch umgesetzt werden, da sonst VLAN-Leaks oder Fehlzuordnungen entstehen.

VLAN-Tagging richtig denken: Trunk/Access, Tagged/Untagged, PVID und Native VLAN

Die Begriffe „Trunk“ und „Access“ beschreiben nicht die Hardware, sondern die Portfunktion. Ein Access-Port überträgt Frames untagged; der Switch ordnet sie intern über die PVID einem VLAN zu. Ein Trunk-Port überträgt Frames mit 802.1Q-Tag und kann mehrere VLANs parallel führen. In OpenWrt muss diese Logik exakt abgebildet werden: Auf Uplink-/Trunk-Ports sind VLANs in der Regel getaggt, damit sie getrennt bis in die Layer-3-Interfaces durchreichen. Endgeräte-Ports erhalten untagged genau das Segment, das sie nutzen sollen (Gast, IoT, LAN, Admin).

Typische Fehler entstehen an den Kanten: Ein AP-Port wird als Access konfiguriert, obwohl der AP mehrere SSIDs in VLANs taggt; oder ein Managed-Switch-Trunk lässt ein VLAN ungewollt untagged passieren. Beides führt zu Symptomen wie „falsches Subnetz per DHCP“, „IP-Adresse passt, aber kein Gateway“ oder zu sporadischen Multicast-Leaks. Stabilität entsteht, wenn jedes VLAN eine klare VLAN-ID hat, jeder Trunk eine definierte Allowed-VLAN-Liste erhält und untagged Traffic nur dort vorkommt, wo er zwingend benötigt wird.

• Trunk zu Access Point: VLANs als Tagged führen, z. B. br-lan Port lan4 mit VLAN 10, 20, 30, 99; SSIDs im AP jeweils auf die passende VLAN-ID mappen.
• Access-Port für IoT-Kabelgerät: Port PVID auf IoT-VLAN (z. B. 30) setzen, untagged; keine weiteren VLANs auf diesem Port zulassen, damit kein „seitlicher“ VLAN-Wechsel möglich ist.
• Native-VLAN vermeiden: Wenn ein Trunk untagged benötigt, muss die Zuordnung explizit und symmetrisch erfolgen; sonst landet ungetaggter Traffic auf OpenWrt im falschen VLAN (PVID-Mismatch).

Portplan als Architekturvertrag: Zuordnung, Namenskonventionen und Änderungsdisziplin

Eine konsistente Port- und VLAN-Namensgebung erleichtert später die Firewall- und DHCP-Konfiguration, weil Zonen und Interfaces eindeutig erkennbar bleiben. In OpenWrt bietet sich eine Trennung aus sprechendem Interface-Namen und VLAN-ID an (beispielsweise „lan“, „guest“, „iot“, „admin“, technisch als br-lan.10, br-lan.20 usw.). Der physische Portplan sollte parallel existieren: welcher RJ45-Port ist Trunk, welcher ist Access, welche VLANs sind erlaubt, welcher Port führt das Managementnetz. Ohne diese Festlegung werden spätere Sonderfälle (z. B. AirPrint-/Chromecast-Ausnahmen) unnötig komplex, weil bereits die Layer-2-Basis wackelt.

Für den Betrieb zählt außerdem die Nachvollziehbarkeit von Änderungen. VLAN-Umstellungen sind riskant, weil ein Fehler die Erreichbarkeit von Router, AP oder Switch gleichzeitig betreffen kann. Daher gehören Portänderungen in eine feste Reihenfolge: zuerst VLANs im Switch/DSA korrekt anlegen, dann Trunk-Links stabilisieren, anschließend Access-Ports umstellen. Parallel sollte ein Rettungsweg bestehen, etwa über einen bekannten Admin-Port oder eine serielle Konsole, bevor ein Management-VLAN verschoben wird.

Konfiguration Schritt für Schritt: VLANs, Interfaces/Bridges, DHCP/DNS je Segment und SSID-zu-VLAN-Zuordnung

Die Konfiguration folgt einer festen Reihenfolge, weil OpenWrt Netzdefinition, DHCP/DNS und Firewall über voneinander abhängige Objekte verknüpft. Sinnvoll ist eine eindeutige Segment-Nomenklatur, etwa lan, guest, iot, admin, die sich konsistent in VLAN-IDs, Interface-Namen, DHCP-Scopes und Firewall-Zonen wiederfindet. Als Basis dient ein Trunk zwischen Router und (Managed-)Switch bzw. einem AP, der mehrere SSIDs in VLANs terminiert. Auf dem Router werden die VLANs auf dem Uplink getaggt, interne Access-Ports erhalten jeweils genau ein ungetaggtes VLAN.

1) Switch- und Portmodell prüfen (DSA vs. swconfig) und Portrollen festlegen

Vor dem Anlegen von VLANs muss klar sein, ob das Gerät DSA (aktuelle Standard-Architektur) oder das ältere swconfig-Modell nutzt. Das entscheidet, ob VLANs als Bridge-VLAN-Filtering (DSA, bridge vlan / „Bridge VLAN filtering“) oder als Switch-Konfiguration (swconfig) umgesetzt werden. Zusätzlich sind die physischen Ports zu inventarisieren: WAN (Uplink zum Modem/ONT), Trunk zum Switch/AP, Access-Ports für Endgeräte und gegebenenfalls ein dedizierter Admin-Port, der nur im Admin-Segment untagged ist.

• DSA-Erkennung: ls -l /sys/class/net
ubus call system board
• Port-/Link-Status: ip -br link
ethtool eth0
• Bridge-VLAN-Überblick (DSA): bridge vlan show
bridge link show
• Switch-Überblick (swconfig, falls vorhanden): swconfig list
swconfig dev switch0 show

2) VLANs anlegen und Trunk/Access korrekt abbilden

Unter DSA wird typischerweise eine zentrale Bridge (z. B. br-lan) verwendet. Darauf wird VLAN-Filtering aktiviert und anschließend pro VLAN festgelegt, welche Ports getaggt (Trunk) oder ungetaggt (Access) teilnehmen. Der Trunk-Port zum Switch/AP führt mehrere VLANs getaggt; Access-Ports führen exakt ein VLAN ungetaggt und sind in allen anderen VLANs nicht Mitglied. Wichtig ist, dass „PVID“ und „untagged“ zusammenpassen: Das ungetaggte VLAN eines Ports ist dessen PVID.

Bei Geräten mit separatem WAN-Port ist darauf zu achten, dass WAN nicht versehentlich in die LAN-Bridge gelangt. Falls der physische Uplink zum externen Switch derselbe Switch-/SoC-Portbereich wie interne Ports ist (plattformabhängig), muss die Trunk-Definition exakt auf den richtigen Port gelegt werden; Abweichungen führen oft zu „kein Internet“ oder „DHCP kommt nicht an“, weil Tags verloren gehen oder Frames in falschen VLANs landen.

3) Interfaces und Bridges definieren: pro Segment ein L3-Interface

Für jedes Segment wird ein eigenes L3-Interface mit statischer Adresse erstellt. Unter DSA wird das meist als VLAN-Subinterface auf der Bridge geführt, z. B. br-lan.10, br-lan.20 usw. Alternativ kann pro VLAN eine eigene Bridge entstehen, wenn mehrere physische Ports ohne VLAN-Filtering gebündelt werden müssen; im Heim-/Small-Office-Umfeld ist ein zentrales Bridge-VLAN-Filtering jedoch übersichtlicher. Das Interface erhält den Gateway des jeweiligen Subnetzes und wird später einer Firewall-Zone zugeordnet.

• Netz-Interfaces prüfen: ubus call network.interface dump
ip -br addr
• Routing plausibilisieren: ip route
ip rule show
• ARP/ND bei Erreichbarkeitsproblemen: ip neigh show

4) DHCP je Segment: klare Scopes, Optionen, Leases und RA (IPv6)

DHCP wird segmentweise getrennt betrieben. Pro Interface entstehen eigene Pools mit nicht überlappenden Bereichen, konsistenter Lease-Zeit (für Gast oft kürzer), sowie optionalen DHCP-Optionen wie NTP oder statischen DNS-Servern. Für IPv6 ist eine bewusste Entscheidung nötig: entweder delegiertes Präfix (PD) pro Segment mit RA/DHCPv6 oder IPv6 im Gast/IoT bewusst deaktivieren, wenn die Policy und Filterung noch nicht sauber abbildbar sind. Wichtig ist, dass DNS-Server für Clients pro Segment eindeutig sind, um „kein DNS“ nicht mit „kein Internet“ zu verwechseln.

5) DNS-Resolver-Strategie: lokales dnsmasq, Upstream und Split-Horizon

OpenWrt nutzt typischerweise dnsmasq als DNS-Forwarder und DHCP-Server. Für segmentierte Netze ist entscheidend, welche Namen wo auflösbar sein sollen. Eine robuste Standardlinie: interne Hostnamen (DHCP-Leases) nur in vertrauenswürdigen Segmenten (LAN/Admin) bereitstellen, Gast strikt auf externes DNS beschränken, IoT abhängig vom Gerätebedarf. Split-Horizon lässt sich über getrennte DHCP/DNS-Instanzen oder restriktive dnsmasq-Konfiguration je Interface umsetzen; in jedem Fall sollte verhindert werden, dass Gast-Clients interne Namen auflösen, wenn das Segment ohnehin keinen Zugriff erhält.

• DNS-Serverstatus und Queries: logread -e dnsmasq
nslookup openwrt.lan 192.168.10.1
• DHCP-Serverlog je Segment: logread -e dhcp
• Upstream-DNS nachvollziehen: cat /tmp/resolv.conf.d/resolv.conf.auto
ubus call network.interface.wan status

6) SSID-zu-VLAN-Zuordnung: AP/Radio, Netzwerke und Trunk konsistent halten

Die SSID-Zuordnung erfolgt entweder auf dem OpenWrt-Gerät selbst (wenn es zugleich AP ist) oder auf einem externen AP, der VLANs zum Router trunked. Jede SSID wird einem OpenWrt-Netzwerkinterface zugeordnet; bei mehreren SSIDs auf demselben Funkmodul entstehen entsprechend mehrere virtuelle Interfaces, die jeweils auf br-lan.10, br-lan.20 usw. gemappt werden. Kritisch sind dabei zwei Punkte: Der Ethernet-Uplink des AP muss als Trunk alle benötigten VLANs taggen, und die „native“/untagged VLAN-Einstellung darf nicht ungewollt Frames in das falsche Segment schieben. Für eine Admin-SSID ist zusätzlich sinnvoll, Management-Zugriff auf den AP selbst nur aus dem Admin-Segment zu erlauben.

Bei WPA3/WPA2-Mixed-Setups oder 802.11r ist sicherzustellen, dass die Einstellungen pro SSID konsistent bleiben; Roaming-Features beeinflussen nicht die VLAN-Trennung, erhöhen aber die Komplexität bei Fehlersuche. Wenn ein Endgerät in der falschen IP-Range landet, liegt die Ursache fast immer in einem VLAN-Mismatch (AP taggt anders als der Router erwartet) oder in einem Access-Port, der versehentlich als untagged in mehreren VLANs geführt wird.

7) Schnelle Prüfkette bei „kein Internet / kein DNS / Gerät sieht Gerät nicht“

Die Fehlersuche beginnt am Segment-Interface und arbeitet entlang der Kette L2 (VLAN/Bridge) → L3 (IP/Routing) → L4/7 (DNS/Firewall). „Kein Internet“ ist häufig ein Forwarding-/NAT-Thema, „kein DNS“ ein reines Resolver-Problem, und „Gerät sieht Gerät nicht“ betrifft in segmentierten Netzen oft mDNS/SSDP, das ohne gezielte Regeln nicht über Subnetze hinweg funktioniert. Für reproduzierbare Diagnosen sollten Tests aus jedem Segment erfolgen, idealerweise mit einem Notebook pro VLAN oder per temporärem Access-Port am Switch.

• Layer-2 (VLAN) validieren: bridge vlan show
tcpdump -eni br-lan vlan and port 67
• DHCP-/IP-Zustand am Client spiegeln: ipconfig /all
nmcli dev show
• Routing und NAT prüfen: ip route get 1.1.1.1
nft list ruleset
• DNS isolieren: nslookup example.com 192.168.20.1
nslookup example.com 1.1.1.1
• Firewall-Entscheidungen sichtbar machen: logread -e firewall
nft monitor trace

Firewall, Ausnahmen und Fehlersuche: Zonen/Forwarding, mDNS/Multicast, Drucker/Cast/AirPlay-Szenarien und Diagnose bei DNS-/Routing-Problemen

Zonen, Forwarding und Default-Policy: sauber trennen, gezielt erlauben

Bei mehreren Netzsegmenten entscheidet die Firewall-Topologie über Sicherheit und Fehlertoleranz. In OpenWrt bildet jedes L3-Segment typischerweise eine eigene Firewall-Zone (z. B. lan, guest, iot, admin, wan). Für interne Zonen empfiehlt sich als Grundhaltung: Eingehend in den Router nur das Nötigste (input restriktiv), Weiterleitung zwischen Zonen grundsätzlich sperren und ausschließlich über explizite Regeln freigeben. Internetzugang entsteht dann über Forwarding der jeweiligen Zone nach wan; Ost-West-Verkehr (zwischen LAN/Gast/IoT/Admin) bleibt standardmäßig blockiert.

Ein häufiger Stolperstein liegt in der Unterscheidung zwischen „Zugriff auf den Router“ (Traffic zur Router-IP im jeweiligen Subnetz) und „Zugriff durch den Router“ (Forwarding durch den Router). Gäste sollen oft DNS/DHCP erhalten, aber weder Weboberfläche (uhttpd) noch SSH erreichen. IoT-Geräte benötigen meist nur ausgehende Verbindungen und DNS/NTP, aber keine Erreichbarkeit anderer Segmente. Für Administration gilt oft das Gegenteil: Zugriff auf Router-Services, auf andere Zonen und auf Management-Interfaces von Switch/AP.

Für die Umsetzung sind zwei Mechanismen zu trennen: Forwardings (Zonen-zu-Zonen) schaffen grundsätzlich erlaubte Pfade; Regeln („Traffic Rules“) verfeinern das. Für die meisten Ausnahmen ist es stabiler, kein globales Forwarding zu öffnen, sondern pro Dienst eine präzise Regel zu erstellen (Quelle, Ziel, Protokoll, Ports, Ziel-IP). Das verhindert, dass spätere Geräte oder Dienste ungewollt durch ein einmal geöffnetes Forwarding profitieren.

• Grundlegendes Zonenset (Beispielnamen): wan, lan, guest, iot, admin
• Internet für Segment erlauben: Forwarding in der Firewall von guest nach wan bzw. iot nach wan, ohne Forwarding nach lan/admin
• DNS/DHCP in restriktiven Zonen: Regeln für udp/67 (DHCPv4-Server), udp/68 (DHCPv4-Client), udp/53, tcp/53 (DNS) zum Router-Interface der Zone; bei IPv6 zusätzlich udp/547 (DHCPv6-Server) sowie ICMPv6-Notwendigkeiten (RA/ND) berücksichtigen
• Router-Management abschotten: explizite Sperrregeln für tcp/22 (SSH) und tcp/80, tcp/443 (LuCI/uhttpd) aus guest/iot zum Router; Verwaltung ausschließlich aus admin

mDNS/Multicast über Segmentgrenzen: Discovery ermöglichen, Broadcast-Domänen nicht vermischen

Viele „Gerät findet Gerät“-Funktionen nutzen Multicast-Discovery statt klassischem DNS: mDNS (UDP 5353, 224.0.0.251/ff02::fb), SSDP/UPnP (UDP 1900, 239.255.255.250), teils proprietäre Multicast-Gruppen. Router forwarden Multicast standardmäßig nicht zwischen VLANs, was korrekt ist: L2-Broadcast-Domänen sollen getrennt bleiben. Discovery lässt sich dennoch gezielt bereitstellen, ohne ein Segment Layer-2-seitig zu öffnen.

Für mDNS ist in OpenWrt üblicherweise ein Reflector sinnvoll, der mDNS-Anfragen zwischen ausgewählten Interfaces spiegelt. Dafür wird häufig avahi-daemon mit aktiviertem mDNS-Reflector eingesetzt; alternativ existieren spezialisierte Pakete wie mdns-repeater. Wichtig bleibt die Firewall: Zwischen den betroffenen Zonen muss UDP 5353 sowie das benötigte Multicast/IGMP-Verhalten erlaubt sein, jedoch nur zwischen den konkreten Segmenten, in denen Discovery gewünscht ist (z. B. lan ↔ iot, nicht guest ↔ irgendwas).

SSDP/UPnP und Cast-Discovery sind schwieriger zu kapseln: Chromecast nutzt neben mDNS auch SSDP; AirPlay/AirPrint nutzen mDNS. Ein reflektierter Discovery-Kanal reicht nicht immer aus, wenn anschließend Verbindungen auf dynamischen Ports oder zu mehreren IPs aufgebaut werden. Deshalb sollte zuerst geklärt werden, ob tatsächlich Discovery über Grenzen nötig ist, oder ob die steuernde App in dasselbe Segment wie das Zielgerät gehört (häufig die robusteste Lösung: Steuergeräte ins iot-WLAN, nicht umgekehrt).

• mDNS gezielt zulassen: Firewall-Regel für udp/5353 zwischen lan und iot; guest bleibt ausgeschlossen
• SSDP bewusst handhaben: falls nötig, Regeln für udp/1900 und Multicast-Ziele (239.255.255.250) nur für definierte Quellnetze; UPnP-IGD selbst nicht in untrusted Zonen aktivieren
• IGMP/MLD-Snooping beachten: bei managed Switches/APs Multicast-Steuerung sauber konfigurieren; sonst drohen Flooding-Effekte oder „Discovery geht nur sporadisch“

Ausnahmen für Drucker, Cast und AirPlay: minimaler Zugriff statt Segmentöffnung

Typische Ausnahmen betreffen einen Drucker im IoT-Segment oder ein Cast-/AirPlay-Ziel, das von Clients im LAN steuerbar sein soll. Die saubere Herangehensweise trennt Discovery von Nutzdaten: Erst Discovery (häufig mDNS) ermöglichen, dann die eigentlichen Dienst-Ports zum Zielgerät freigeben. Dabei hilft eine feste IP oder DHCP-Reservierung für das Zielgerät, weil Regeln dann auf eine einzelne Ziel-IP beschränkt bleiben. Regeln „zu einem ganzen Segment“ sind meist zu grob.

Für Druckdienste sind die relevanten Protokolle heterogen: IPP (TCP 631), RAW/JetDirect (TCP 9100), LPD (TCP 515), SMB-Druck (TCP 445). Bei AirPrint steckt die Entdeckung in mDNS, der Druck selbst läuft in der Regel über IPP. Für Cast/AirPlay wechseln die Ports je nach Implementierung; häufig werden nach der Entdeckung zusätzliche TCP-Verbindungen auf dynamischen Ports aufgebaut. In solchen Fällen ist eine eng gefasste Portliste manchmal nicht ausreichend; dann bleibt als sichere Alternative, Steuergerät und Zielgerät in dasselbe Segment zu bringen oder über einen Application-Proxy (z. B. Druckserver) zu arbeiten, statt Router-zu-Router-Bereiche breit zu öffnen.

Fehlersuche: „kein Internet“, „kein DNS“, „Gerät sieht Gerät nicht“ – systematisch mit Status, Logs und Traces

Diagnose sollte immer entlang der Kette erfolgen: Link/VLAN → IP-Adressierung → Default-Route/NAT → DNS → Firewall. Bei „kein Internet“ in einem Segment liegt die Ursache häufig nicht im WAN selbst, sondern in falscher VLAN-Zuordnung (SSID auf falsches Interface gebunden, Trunk/Access vertauscht), fehlendem Forwarding nach wan, oder einer Zone, die dem Interface nicht korrekt zugeordnet ist. Bei „kein DNS“ fällt dagegen oft auf, dass DHCP zwar Adressen verteilt, aber kein DNS-Server oder ein falscher DNS-Server propagiert wird, oder dass Firewall-Regeln DNS zum Router blockieren.

Wenn Geräte sich nicht sehen, ist zunächst zu klären, ob L3-Erreichbarkeit gewollt ist. Segmentierung bedeutet: Ping zwischen Zonen scheitert standardmäßig, und das ist ein Erfolg, kein Fehler. In den Fällen, in denen ein Dienst über Grenzen funktionieren soll, muss zwischen „Discovery fehlt“ (mDNS/SSDP) und „Datenpfad fehlt“ (TCP/UDP zum Ziel) unterschieden werden. Ein reflektiertes mDNS kann dazu führen, dass Geräte in Listen erscheinen, aber der Verbindungsaufbau anschließend an der Firewall blockiert; ohne zusätzliche Regeln wirkt das wie ein Widerspruch, ist aber technisch konsistent.

• Interface-/VLAN-Zuordnung prüfen: ip -br link
ip -br addr
bridge vlan show
• Routing und Default-Gateway prüfen: ip route show
ip -6 route show
• Firewall-Zonenbindung verifizieren: ubus call network.interface dump (Interface-Namen und Status)
  nft list ruleset (tatsächlich aktive Regeln)
• DNS-Auflösung getrennt testen: nslookup openwrt.org 192.168.X.1 (Router-DNS im jeweiligen Segment)
  nslookup openwrt.org (Client-Default)
• DHCP-Lease und Optionen prüfen: logread -e dnsmasq
cat /tmp/dhcp.leases
• Paketmitschnitt je Segment: tcpdump -ni br-guest port 53
tcpdump -ni br-iot udp port 5353
tcpdump -ni wan 'host 8.8.8.8 or port 53'

Für „kein Internet“ ist ein schneller Realitätscheck hilfreich: Eine IP wie 1.1.1.1 anpingen trennt DNS-Probleme von Routing/NAT. Scheitert Ping auf IP, folgt die Prüfung der Forwardings, der NAT-Regeln (Masquerading auf wan) und der tatsächlichen Egress-Route. Funktioniert Ping auf IP, aber keine Namen, liegt der Fokus auf DNS-Servern, DNS-Weiterleitung und möglichen Blockaden von tcp/53 und udp/53.

Für „Gerät sieht Gerät nicht“ liefert ein Mitschnitt schnelle Evidenz: Fehlen mDNS-Pakete im Zielsegment, ist Reflecting/Repeating oder eine Firewall-Regel im Weg. Sind mDNS-Pakete vorhanden und das Gerät taucht dennoch nicht auf, sind oft Client-Filter (WLAN-Client-Isolation), AP-spezifische Multicast-Einstellungen oder IGMP/MLD-Effekte beteiligt. Taucht das Gerät auf, aber der Zugriff scheitert, blockiert meist die Firewall den nachgelagerten Datenpfad; dann sollten Regeln auf Ziel-IP und konkrete Ports reduziert, geloggt und iterativ verifiziert werden, statt breitflächig Zone-Forwardings zu öffnen.