OpenWrt mit VLANs und mehreren Netzsegmenten einrichten: Gastnetz, IoT-Isolation und saubere Firewall-Regeln

Netzarchitektur mit OpenWrt: Bridge, VLAN-Tagging sowie Trunk- und Access-Ports realistisch planen

Eine Segmentierung mit OpenWrt steht und fällt mit einer konsistenten Layer-2-Architektur. VLANs lösen nicht „automatisch“ Sicherheitsprobleme, sondern schaffen definierte Broadcast-Domänen, auf denen anschließend klare Layer-3-Regeln greifen. Entscheidend ist deshalb, dass Switch-Ports, Bridge-Design und VLAN-IDs zueinander passen. Ein späteres „Nachrüsten“ führt häufig zu schwer erklärbaren Effekten wie zufälliger Geräteerreichbarkeit, Doppel-DHCP oder stillen Drops durch falsch gesetzte PVIDs.

In OpenWrt wird die VLAN-Logik heute typischerweise über DSA (Distributed Switch Architecture) abgebildet; auf älterer Hardware existiert teils noch swconfig. Das Konzept bleibt unabhängig davon gleich: Ein Port arbeitet entweder als Access-Port (ein ungetaggtes VLAN; je nach Switch/DSA-Implementierung optional zusätzlich getaggte VLANs) oder als Trunk (mehrere getaggte VLANs, optional ein natives/untagged VLAN). Die Bridge verbindet Switch-Ports logisch; VLAN-Filtering stellt sicher, dass Frames nur in den vorgesehenen VLAN-Kontext gelangen.

Bridge-Design: ein oder mehrere Bridges, und warum das relevant ist

Für Heimumgebungen ist ein einzelnes Bridge-Device mit VLAN-Filtering in vielen Fällen die robusteste Grundlage: Alle LAN-seitigen Ethernet-Ports (und ggf. ein CPU-Port zum Switch) landen in einer Bridge, die VLAN-aware arbeitet. Die IP-Interfaces liegen dann nicht „auf der Bridge“, sondern auf VLAN-Subinterfaces, etwa als br-lan.10 (Admin), br-lan.20 (LAN), br-lan.30 (IoT) und br-lan.40 (Gast). Damit bleibt Layer 2 sauber getrennt, während Layer 3 (Routing/Firewall) pro Netzsegment eindeutig zuordenbar ist.

Mehrere Bridges können sinnvoll sein, wenn physische Trennung zwingend ist (z. B. dedizierter „Admin“-Port ohne VLAN-Tagging-Fähigkeit am Endgerät) oder wenn bestimmte Treiber/Offload-Pfade mit VLAN-Filtering unerwartete Einschränkungen haben. Der Preis ist höhere Komplexität: Je mehr Bridges existieren, desto mehr Stellen müssen konsistent mit DHCP, Firewall-Zonen, DNS-Policies und WLAN-SSIDs gepflegt werden. In der Praxis entsteht der größte Stabilitätsgewinn meist durch wenige, klar definierte L2-Bausteine.

VLAN-Tagging korrekt denken: PVID, Untagged, Tagged und „Native VLAN“

Auf einem Access-Port wird eingehender ungetaggter Traffic einem VLAN zugeordnet. Diese Zuordnung ist die PVID (Port VLAN ID). Ausgehend werden Frames dieses VLANs ungetaggt gesendet, damit klassische Clients ohne VLAN-Unterstützung funktionieren. Ein Trunk hingegen transportiert mehrere VLANs als getaggte Frames; optional kann ein VLAN ungetaggt („native“) laufen, was allerdings häufig Fehlerquellen erzeugt, weil auf beiden Seiten identische Erwartungen an PVID und untagged VLAN bestehen müssen.

Für eine nachvollziehbare Planung bietet sich an, das Management/Admin-Netz entweder konsequent getaggt über Trunks zu führen oder strikt physisch zu separieren. Ein Mischbetrieb „Admin untagged auf dem Trunk“ ist technisch möglich, erschwert aber Fehlersuche und erhöht das Risiko, dass ein falsch konfigurierter Switch-Port plötzlich Zugriff auf das Admin-Segment erhält.

Portrollen im Heim-/SOHO-Layout: Router, Switch, Access Points

Realistische Heim-Setups bestehen häufig aus einem OpenWrt-Router, einem optionalen managed Switch und einem oder mehreren Access Points. Ein AP-Port sollte in der Regel als Trunk laufen, damit mehrere SSIDs getrennt bleiben: „Gast“ und „IoT“ dürfen nicht über dieselbe untagged Bridge wie das interne LAN „mitfahren“. Bei Ethernet-Backhaul für Mesh-Systeme gilt dasselbe; viele Systeme unterstützen VLAN-Trunks, einige nur eingeschränkt. Unklare Herstellerbegriffe wie „Guest Network Isolation“ ersetzen keine VLAN-Segmentierung, weil sie oft nur WLAN-Client-Isolation innerhalb einer SSID abbilden.

Für kabelgebundene Endgeräte empfiehlt sich ein konsequentes Access-Port-Modell: Jeder Port gehört genau einem VLAN. Geräte mit Sonderrolle (z. B. NAS oder Drucker) werden nicht „aus Bequemlichkeit“ ins LAN gelegt, sondern in das Segment, dessen Kommunikationsbedarf tatsächlich besteht (häufig LAN oder ein eigenes „Services“-VLAN; bei IoT-Geräten eher IoT). Die Erreichbarkeit ergibt sich anschließend aus Firewall-Regeln und nicht aus einer gemeinsamen Broadcast-Domäne.

• Router-Uplink (WAN): Keine Bridge mit LAN-Ports; physisch/logisch getrennt, z. B. als eigenes Device wan bzw. pppoe-wan.
• AP-Uplink als Trunk: Getaggte VLANs für VLAN10 (Admin), VLAN20 (LAN), VLAN30 (IoT), VLAN40 (Gast); untagged nur dann, wenn der AP ein natives VLAN zwingend erwartet.
• Client-Port als Access: PVID genau ein VLAN, z. B. VLAN30 für Smarthome-Bridge; keine zusätzlichen getaggten VLANs auf Endgeräte-Ports.
• Switch-Uplink/Stack: Trunk mit identischer VLAN-Liste auf beiden Seiten; für konsistente Verwaltung VLAN-IDs und Namen dokumentieren (z. B. 10=admin, 20=lan, 30=iot, 40=guest).

SSID-Zuordnung zu VLANs: Trennung entsteht am AP, nicht erst in der Firewall

WLAN-Segmentierung funktioniert stabil, wenn jede SSID eindeutig auf ein VLAN gemappt wird. In OpenWrt geschieht das über separate WLAN-Interfaces, die jeweils an ein passendes VLAN-Interface gebunden werden. Das vermeidet ungewollte L2-Kopplungen, bei denen ein „Gast“-WLAN zwar per Firewall eingeschränkt wird, aber weiterhin Broadcast/Multicast aus dem internen Netz sieht oder umgekehrt.

Bei mehreren APs muss die VLAN-Zuordnung identisch sein. Besonders kritisch ist das bei Roaming: Wenn SSID und VLAN auf AP A zusammenpassen, auf AP B jedoch vertauscht sind, erscheinen Symptome wie „IP-Adresse stimmt, aber keine Erreichbarkeit“, weil Clients je nach AP im falschen Segment landen. Deshalb gehört zur Planungsphase eine feste Matrix aus SSID, VLAN-ID, IP-Netz, DHCP-Optionen und Firewall-Zone, die sich eins zu eins in allen Geräten wiederfindet.

Planungs-Checkliste: minimale Komplexität, maximale Eindeutigkeit

Vor der eigentlichen Konfiguration sollte die Architektur so festgelegt sein, dass jedes Kabel und jeder Port eine eindeutige Rolle erhält. Das reduziert die typischen Fehlerklassen (VLAN-Leaks, doppelte DHCP-Server, falsche PVID) bereits auf dem Papier. Ebenso wichtig: VLAN-IDs nicht „nach Gefühl“ wählen, sondern als dauerhaftes Schema, das auch spätere Erweiterungen (weiterer AP, zusätzlicher Switch, separates VoIP) ohne Umnummerierung erlaubt.

• VLAN-Schema: Feste IDs und Namen, z. B. 10=admin, 20=lan, 30=iot, 40=guest; keine Überschneidung mit Provider-/ONT-VLANs auf der WAN-Seite.
• Portplan: Pro physischem Port festlegen: Access vs. Trunk, PVID, getaggte VLAN-Liste; Uplinks klar markieren, z. B. lan1=trunk-ap1, lan2=access-iot.
• Bridge-Entscheidung: Bevorzugt eine VLAN-aware Bridge (DSA) und darauf VLAN-Subinterfaces wie br-lan.20; mehrere Bridges nur bei zwingenden Hardware-/Designgründen.
• AP-Fähigkeiten prüfen: Unterstützung für VLAN-Trunking und SSID→VLAN-Mapping verifizieren; bei Unsicherheit Management-VLAN zunächst getaggt, aber mit Fallback-Zugang über dedizierten Access-Port vorsehen.

Konfiguration in OpenWrt: Switch- und Portmodell prüfen, VLANs/Interfaces anlegen, DHCP/DNS definieren und SSIDs den Segmenten zuordnen

Switch- und Portmodell verifizieren (DSA vs. swconfig)

Vor jeder VLAN-Konfiguration muss klar sein, ob das Gerät das moderne DSA-Stack (Distributed Switch Architecture) nutzt oder noch das ältere swconfig-Modell. OpenWrt setzt bei aktuellen Targets typischerweise auf DSA; die Oberfläche unterscheidet sich spürbar, und auch die Gerätebezeichnungen ändern sich. Diese Prüfung verhindert klassisches „falsches Interface konfiguriert“-Troubleshooting, bei dem VLANs zwar angelegt werden, aber auf dem falschen Switch-Chip oder Port landen.

• Netzwerkgeräte und Switch erkennen: ip link show
ubus call system board
• DSA-Indizien prüfen: VLAN-fähige Ports erscheinen als eigene Linux-Interfaces (z. B. lan1, lan2) und VLANs als Subinterfaces (z. B. br-lan.20), während bei swconfig ein Interface wie eth0 viele Switch-Ports „versteckt“.
• Konfigurationsquelle lokalisieren: DSA-Konfiguration steht konsistent in /etc/config/network; bei älteren Geräten existieren oft zusätzlich Switch-Sektionen. Änderungen sollten ausschließlich über eine Methode erfolgen, nicht gemischt.

VLANs am Trunk/Access-Design ausrichten

Als robuste Praxis hat sich ein klares Portmodell bewährt: Ein Port als Trunk zum Managed Switch oder Access Point (getaggt: alle relevanten VLANs), übrige Ports als Access (untagged genau ein VLAN, mit passender PVID). Unter DSA wird VLAN-Tagging häufig auf der Bridge umgesetzt: VLAN-Filter an br-lan, dann pro VLAN ein Bridge-Subinterface. Das reduziert Sonderlogik und lässt sich sauber dokumentieren.

Die konkrete Portzuordnung hängt vom Gerät ab, das Ziel bleibt jedoch identisch: VLAN 99 nie „aus Versehen“ untagged auf Benutzerports ausgeben, und Trunks konsequent als tagged führen. Bei Switches mit CPU-Port ist zu beachten, dass der Uplink zur CPU alle VLANs tragen muss, die am Router terminiert werden. Bei DSA wird dieser Zusammenhang implizit über die Bridge-Ports abgebildet, trotzdem bleibt die Logik dieselbe: Ohne korrekte Tagging-Matrix bleiben DHCP oder Internetzugriff segmentweise aus.

Interfaces/Bridges in OpenWrt definieren (pro Segment ein L3-Interface)

Für jedes Segment wird ein eigenes Layer-3-Interface angelegt, das auf dem jeweiligen VLAN-Subinterface der Bridge aufsetzt (z. B. br-lan.20). Dadurch lassen sich DHCP, DNS-Optionen und Firewall-Zonen sauber getrennt verwalten. Wichtig ist, dass die Bridge selbst nicht „wild“ geroutet wird, sondern als gemeinsame Layer-2-Basis dient, auf der VLAN-Filterung greift.

• Netzwerkgeräte prüfen: ip -d link show br-lan
bridge vlan show
• VLAN-Subinterfaces verifizieren: ip link show br-lan.10
ip link show br-lan.20
ip link show br-lan.30
ip link show br-lan.99
• IP-Plan prüfen: Jedes Interface erhält eine eindeutige Router-IP im eigenen Subnetz (z. B. 192.168.20.1/24) und niemals überlappende Netze; Routing-Probleme wirken sonst wie Firewall-Fehler.

DHCP pro Segment: Adressbereiche, Optionen, Leases

OpenWrt nutzt in der Standardarchitektur dnsmasq für DHCP und optional DNS. Pro Segment wird ein eigener DHCP-Pool definiert, inklusive sinnvoller Lease-Zeiten (Gast eher kurz, IoT oft länger wegen träger Clients). Zusätzlich sollte pro Segment klar entschieden werden, ob lokale Hostnames verteilt werden und ob statische Leases im selben Segment gepflegt werden. Segmentübergreifende Namensauflösung gehört nicht in DHCP-Tricks, sondern in eine geplante DNS-Strategie.

• DHCP-Status prüfen: logread -e dnsmasq-dhcp
/etc/init.d/dnsmasq status
• Lease-Daten kontrollieren: cat /tmp/dhcp.leases
• Typische Fehlerquelle: DHCP läuft, aber Clients erhalten keine Adresse, wenn VLAN-Tagging am AP/Switch nicht passt (Client sitzt faktisch im falschen L2-Segment) oder wenn das DHCP-Interface in OpenWrt dem falschen Device zugeordnet wurde.

DNS-Resolver-Strategie festlegen (dnsmasq, Unbound, DoH/DoT, Segmentregeln)

DNS entscheidet häufig darüber, ob ein Segment „funktioniert“. Ein praxistaugliches Design trennt zwei Ebenen: (1) Der Router beantwortet DNS für alle internen Segmente konsistent, (2) Upstream-Auflösung erfolgt über definierte Resolver (ISP, Unbound, DoH/DoT je nach Policy). Entscheidend ist, dass Gast/IoT nicht beliebig interne Namen auflösen oder interne Suchdomänen erhalten, sofern das nicht explizit gewollt ist. Gleichzeitig sollten Captive-Portal- oder Geräte-Clouds im Gast/IoT nicht durch zu restriktive DNS-Filter „kaputt“ wirken.

• DNS-Auflösung vom Router testen: nslookup openwrt.org 127.0.0.1
nslookup example.com 192.168.20.1
• DNS-Fehler einkreisen: logread -e dnsmasq
netstat -lntup | grep ':53' (oder je nach Image ss -lntup | grep ':53')
• Segmentpolitiken umsetzen: DNS-Server per DHCP pro Segment setzen (Router-IP oder externer Resolver), Suchdomäne sparsam halten, und DNS-Intercept (Redirect von Port 53 auf den Router) nur dann nutzen, wenn er mit Firewall-Regeln und Protokollen (TCP/UDP 53) vollständig abgedeckt wird.

SSIDs den VLANs zuordnen (Access Points, Bridge, Tagging)

Mehrere SSIDs werden sauber segmentiert, indem jede SSID einem eigenen Netzwerk (Interface) zugewiesen wird, das wiederum auf dem passenden VLAN liegt. Bei einem OpenWrt-AP (oder einem OpenWrt-Router mit WLAN) erfolgt die Zuordnung in der Regel über die WLAN-Konfiguration: SSID „Gast“ hängt am Interface guest (VLAN 20), SSID „IoT“ am Interface iot (VLAN 30). Bei externen APs ist der Uplink-Port zum Switch/Router als Trunk zu konfigurieren, und jede SSID wird auf die korrekte VLAN-ID gemappt.

WPA2/WPA3-Profile sollten je Segment getrennt verwaltet werden, um die Rotation von Passwörtern oder das Abschalten eines Segments ohne Nebeneffekte zu ermöglichen. Für IoT ist Kompatibilität oft höher zu gewichten (z. B. kein WPA3-only), während das Admin-Segment strengere Einstellungen toleriert. Falls der AP Management im VLAN 99 betreibt, sollte dieses VLAN nicht gleichzeitig für Client-SSIDs genutzt werden; sonst entstehen unnötige Querabhängigkeiten zwischen Managementzugriff und Clientbetrieb.

• WLAN-Zuordnung prüfen (OpenWrt): uci show wireless
wifi status
• VLAN-Transport am Uplink verifizieren: bridge vlan show
ip link show
• Symptom „WLAN verbindet, aber kein Internet“: häufig falsches VLAN am SSID-Mapping oder Trunk-Port untagged statt tagged; kontrollierbar über logread -e hostapd und DHCP-Logs (logread -e dnsmasq-dhcp).

Konfigurationsreihenfolge und reproduzierbare Dokumentation

Eine stabile Umsetzung folgt einer festen Reihenfolge: erst das Portmodell (Trunk/Access) und VLAN-Matrix, dann VLANs auf der Bridge, anschließend L3-Interfaces, dann DHCP/DNS, zuletzt WLAN-Zuordnung. So bleibt bei Ausfällen klar, auf welcher Ebene die Störung entsteht. Für reproduzierbare Änderungen sollten die relevanten UCI-Exports versioniert abgelegt und jede VLAN-/Port-Entscheidung mit einer eindeutigen Bezeichnung versehen werden (VLAN-ID, Zweck, zugehörige Firewall-Zone).

• Aktuellen Stand sichern: uci export network
uci export dhcp
uci export wireless
uci export firewall
• Live-Status kontrollieren: ifstatus lan
ifstatus guest
ifstatus iot
ifstatus admin
• End-to-End-Checks pro Segment: ping -c 3 192.168.20.1
ping -c 3 1.1.1.1
nslookup openwrt.org 192.168.20.1

Firewall, Ausnahmen und Fehlersuche: Zonen/Forwarding-Regeln, mDNS- und Druck/Streaming-Szenarien, Logs und reproduzierbare Dokumentation

Zonenmodell: klare Richtung statt „any-any“

Bei mehreren Netzsegmenten entscheidet die Firewall über den tatsächlichen Sicherheitsgewinn. Bewährt hat sich ein Zonenmodell, das entlang von Trust-Leveln arbeitet und nur wenige, eindeutig begründete Forwardings erlaubt. Typisch ist eine Zone pro L3-Segment (z. B. lan, guest, iot, admin) sowie eine gemeinsame WAN-Zone (wan). Zwischen internen Zonen gilt: kein Forwarding als Default, keine pauschalen „Allow“-Regeln, keine Portfreigaben als Ersatz für Routing-Design. Stattdessen werden gezielte Ausnahmen als eigene Regeln dokumentiert, inklusive Quelle, Ziel, Protokoll und Begründung.

OpenWrt (fw4 mit nftables) trennt Zonen technisch über die Interface-Zuordnung; das ist die zentrale Quelle der Wahrheit. Forwarding definiert ausschließlich den Durchsatz zwischen Zonen, Firewall-Regeln erlauben einzelne Flows. In der Praxis entsteht die größte Fehlerquote durch unklare Grenzziehung zwischen „Zonen-Policy“ (Input/Output/Forward) und „Ausnahme-Regeln“ (Traffic erlauben, NAT erzwingen, ICMP selektiv). Eine stabile Konfiguration setzt daher auf minimale Forwardings und wenige, gut lesbare Regeln.

• Basispolicy pro Zone: guest und iot mit input REJECT, forward REJECT, output ACCEPT; lan/admin typischerweise input ACCEPT, aber Forwarding nur bei Bedarf.
• WAN-Exit: je internes Segment genau ein Forwarding nach wan; NAT (Masquerading) nur in wan aktiv, keine Doppel-NAT-Konstrukte (außer wenn der Upstream selbst bereits NAT macht).
• Router-Dienste je Segment: DHCP/DNS auf dem Router erfordert pro Zone passende Eingangsregeln, z. B. udp/67 (DHCP) und tcp+udp/53 (DNS) nur aus den lokalen Subnetzen der Zone.
• Management separieren: LuCI/SSH nur aus admin erlauben (und nicht aus guest/iot), z. B. tcp/22, tcp/80, tcp/443 mit Source-Restriktion.

Gezielte Ausnahmen ohne Segmentvermischung

Praxisanforderungen kollidieren häufig mit strikter Isolation: ein IoT-Client soll auf einen Drucker zugreifen, Gäste sollen auf einen HDMI-Streamer casten, oder eine Admin-Workstation soll Geräte im IoT-Netz verwalten. Das Ziel bleibt, den Flow auf genau die erforderlichen Protokolle und Ziele zu begrenzen. Pauschale Forwardings wie guest → lan sind in der Regel nicht erforderlich, selbst wenn „ein Gerät gesehen werden muss“.

Für klassische Druckpfade reicht oft ein unidirektionaler Zugriff auf definierte Ports eines einzelnen Hosts (z. B. IPP/JetDirect). Für Streaming/Discovery sind dagegen Broadcast- und Multicast-Verfahren im Spiel, die nicht „geroutet“ werden. Hier hilft ein Proxy-Ansatz (mDNS-Repeater/Reflector) oder eine Applikations-Gateway-Logik, statt L2-Bridging oder großzügiger L3-Freigaben.

mDNS/Multicast: Erkennung ermöglichen, ohne Netze zu koppeln

mDNS basiert auf Link-Local-Multicast (224.0.0.251, udp/5353) und bleibt ohne Hilfsmittel in einem Broadcast-Domain-Segment. Für getrennte VLANs sind zwei Ansätze verbreitet: ein mDNS-Proxy, der Anfragen selektiv zwischen Interfaces weiterreicht, oder ein „Reflector“, der Multicast in mehrere Netze spiegelt. Beide Varianten sollten bewusst restriktiv betrieben werden, weil sie Discovery über Segmentgrenzen hinweg ermöglichen und damit die Sichtbarkeit erhöht.

In OpenWrt wird hierfür häufig avahi-daemon mit aktivierter Reflexion eingesetzt, oder ein dedizierter mDNS-Proxy je nach Paketlage. Entscheidend ist die Kombination mit Firewall-Regeln: mDNS-Weiterleitung ersetzt nicht die eigentliche Zugriffserlaubnis auf den Dienst. Discovery ohne passende TCP/UDP-Freigaben führt zu „Gerät sichtbar, aber Verbindung scheitert“; umgekehrt führen Freigaben ohne Discovery zu „Dienst funktioniert nur bei manueller IP“. Bei Streaming-Systemen sollten die Ausnahmeregeln auf einzelne Zielgeräte oder eine kleine IP-Gruppe begrenzen, weil viele Implementierungen dynamische Ports nutzen.

• mDNS zwischen zwei Zonen: Firewall-Regel für udp/5353 nicht als generelles Forwarding missbrauchen; stattdessen Proxy/Reflector nutzen und die Datenpfade separat als Regeln definieren.
• IGMP/Multicast-Verhalten prüfen: Switches mit IGMP-Snooping können Multicast selektiv verteilen; bei Fehlkonfiguration verschwinden Discovery-Pakete. Relevante Indikatoren finden sich in logread und im Interface-Zähler bei ip -s link.
• Alternativen bevorzugen: Wo möglich, Controller-Apps (Smartphone/Tablet) ins gleiche Segment wie das Zielgerät bringen, z. B. per dedizierter SSID im IoT-Netz, statt Multicast über Zonen zu spiegeln.

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

Segmentierte Netze scheitern in der Praxis selten an Routing-Grundlagen, sondern an Detailfehlern: falsche Zonen-Zuordnung eines Interfaces, fehlendes Forwarding nach WAN, DNS-Resolver nicht erreichbar, oder DHCP verteilt einen falschen Gateway. Eine effiziente Diagnose trennt konsequent L2, L3, DNS und Firewall und nutzt Statusanzeigen, die OpenWrt unmittelbar bereitstellt.

• Link/VLAN/Bridge: ip link
bridge vlan show
bridge link
• IP/DHCP-Lease prüfen: ip addr
logread -e dnsmasq-dhcp
cat /tmp/dhcp.leases
• Routing und Default-Route: ip route
ip route get 1.1.1.1
• DNS getrennt von „Internet“ testen: nslookup openwrt.org 192.168.x.1
nslookup openwrt.org 1.1.1.1
• Firewall-Entscheidung sichtbar machen: nft list ruleset
logread -e firewall
• Paketfluss am Interface beobachten: tcpdump -ni br-lan
tcpdump -ni br-lan vlan (oder gezielt z. B. tcpdump -ni br-lan vlan 20)

Bei „kein Internet“ trotz korrekter IP zeigen sich typische Muster: DNS-Zeitüberschreitungen bei erreichbarem IP-Ziel deuten auf fehlende DNS-Regel oder falschen Resolver hin; fehlende Antworten auf ping zu externen IPs sprechen für fehlendes Forwarding, fehlendes NAT oder Upstream-Probleme; eine falsche Interface-Zuordnung zur Zone führt zu scheinbar „zufälligen“ Drops, weil Regeln am erwarteten Zonenübergang nicht greifen. Für „Gerät sieht Gerät nicht“ ist zuerst zu klären, ob Sichtbarkeit per Discovery (mDNS/SSDP) oder echte Konnektivität (TCP/UDP) gemeint ist. Beide Probleme erfordern unterschiedliche Maßnahmen.

Reproduzierbare Dokumentation: Regeln, Begründungen, Änderungsnachweise

Firewall-Ausnahmen altern schlecht, weil sich Geräteflotten, Apps und Anforderungen ändern. Eine belastbare Dokumentation hält pro Zone die zugeordneten Interfaces (inklusive VLAN-IDs), Subnetze, DHCP-Optionen sowie jede einzelne Ausnahme mit Zweck und Scope fest. Damit bleibt nachvollziehbar, warum eine Regel existiert, welches Gerät betroffen ist und welche Abhängigkeiten (mDNS-Proxy, statische DHCP-Leases, feste Ziel-IP) vorliegen.

Für Änderungen eignen sich zwei parallele Spuren: eine technische Exportbasis und ein menschenlesbarer Änderungslog. Technisch bietet sich ein Versionsstand der relevanten UCI-Konfigurationen an (z. B. /etc/config/network, /etc/config/firewall, /etc/config/dhcp, optional /etc/config/wireless). Ergänzend beschreibt ein kurzes Regelregister pro Ausnahme die Richtung (Zone A → Zone B), Ziel-IP/Port, Protokoll, Quelle und das Deaktivierungskriterium (wann die Ausnahme wieder entfernt werden kann). Das verhindert „Regelruinen“ und erleichtert die Fehlersuche, weil jeder Drop gegen eine begründete Soll-Liste geprüft werden kann.