Homelab-Umbau Teil 10: Aus Netzen werden Grenzen

Worum es geht Link zu Überschrift

Seit Teil 9 landet jedes Gerät automatisch im richtigen VLAN. Damit ist die Trennung auf Layer 2 fertig — und noch keine Sicherheitsgrenze. Ein eigenes Netz heisst erstmal nur, dass der Verkehr über die Firewall läuft. Ob sie ihn durchlässt, ist eine andere Frage.

In Teil 5 habe ich das für ein einzelnes VLAN schon einmal gemacht, für die Telefonie. Inzwischen sind es zwölf Netze, und die Versuchung ist gross, ein Muster zu bauen und es überall hinzukopieren.

Das funktioniert für die Mehrheit der Geräte und für einige eben nicht. Dieser Teil ist das Muster, die Fälle, in denen es nicht passt, und ein Fernseher, an dem ich gelernt habe, warum man vor dem Bauen einer Lösung ins Log schaut.

Wo eine Regel hingehört Link zu Überschrift

Zwei Grundsätze vorweg, weil sich fast jeder Anfängerfehler auf einen davon zurückführen lässt.

Die Regel gehört auf das Interface, wo das Paket eintrifft. Also beim Quell-VLAN, nicht beim Ziel. Wer den Zugriff auf den Drucker erlauben will, legt die Regel nicht auf das Drucker-Interface, sondern auf das der Workstation.

Die Firewall ist stateful. Eine Regel für die Rückrichtung gibt es nicht und braucht es nicht. Ist eine Verbindung erlaubt, sind die Antwortpakete automatisch mit erlaubt.

Zwei Datenströme, zwei Richtungen — und beide Regeln liegen auf der Seite, von der aus verbunden wird.

Das klingt trivial und ist es auch, bis man müde ist. Der zweitverbreitetste Fehler ist verwandt: Der Port gehört in die Ziel-Portangabe, nicht in die Quell-Portangabe. Ein Client wählt seinen Quellport zufällig aus dem oberen Bereich; wer dort 631 einträgt, baut eine Regel, die praktisch nie greift.

Das Muster für Geräte, deren Aufgabe das Internet ist Link zu Überschrift

Für Receiver, Konsole und Gäste sehen die Regeln gleich aus. Vier Stück, und die Reihenfolge ist der ganze Trick.

Vier Regeln. Die dritte ist die, um die es eigentlich geht.

OPNsense wertet von oben nach unten aus, die erste passende Regel gewinnt. Daraus folgt alles:

Regel 3 ist der eigentliche Gewinn. Sie fängt alles Interne ab. Das Gerät kommt nicht ans NAS, nicht an die Workstation, nicht an den Proxmox-Host und auch nicht an die anderen Geräte-VLANs.

Regel 4 muss darunter stehen. Sie lässt pauschal durch, was übrig ist. Stünde sie oben, wäre Regel 3 nie erreichbar.

Regel 1 und 2 stehen ganz oben, weil die Firewall selbst eine private Adresse hat. Ohne sie würde Regel 3 auch DNS und Zeitsynchronisation mitsperren — und ein Gerät ohne DNS sieht aus wie ein Gerät ohne Internet.

Die Aliases dahinter sind schnell erklärt: RFC1918 sind die drei privaten Bereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Das Ausrufezeichen davor ist die Invertierung, also „alles ausser".

Wer eine zusätzliche Regel braucht, muss sie oberhalb von Regel 4 einsortieren.

Der Fall, für den ich kein gemeinsames VLAN gebaut habe Link zu Überschrift

In Teil 1 war der Plan, Mediaplayer und Lichtcontroller ins selbe VLAN zu legen, weil sich die Ambientebeleuchtung aus dem Bild speist. In Teil 9 steht, warum daraus zwei Netze wurden. Hier ist die Regel, die den Unterschied ausmacht:

Eine Zeile, oberhalb der Internet-Regel, genau ein Port zu genau einer Adresse.

Der Protokollwechsel gehört zur Geschichte: Bei 177 LEDs sind das 531 Kanäle. E1.31 bräuchte dafür zwei Universen samt Adressrechnerei, DDP schafft es in einem Paket — und der Gerätetyp „WLED" in Hyperion spricht ohnehin DDP.

Der Mediaplayer braucht ein paar Ausnahmen mehr als ein reines Konsumgerät:

Die beiden ersten Regeln zeigen auf private Adressen und müssen deshalb oberhalb der Internet-Regel stehen — die schliesst mit dem invertierten RFC1918 alles Private aus und würde sie sonst nie zum Zug kommen lassen.

Wo das Muster nicht passt Link zu Überschrift

Konsolen und Gäste: kein Portfilter Link zu Überschrift

Bei Regel 4 wäre die Versuchung gross, auf 80 und 443 einzuschränken. Man tut es besser nicht.

Spielekonsolen und Handys brauchen QUIC, Push-Verbindungen und wechselnde UDP-Ports. Und Android prüft nach dem Verbinden per HTTP gegen connectivitycheck.gstatic.com, ob das Netz wirklich ins Internet kommt. Scheitert das, meldet das Gerät „kein Internet" — und wechselt in vielen Fällen selbstständig zurück ins Mobilfunknetz oder in ein anderes WLAN.

Das ist der unangenehmste Fall überhaupt: Die Regel ist zu eng, das Gerät funktioniert scheinbar trotzdem, und der Fehler äussert sich als „das WLAN ist hier schlecht".

Bei diesen Netzen bleibt Regel 4 offen. Die Sicherheit steckt nicht im Portfilter, sondern in Regel 3.

Das Telefon: die letzte Regel dreht sich um Link zu Überschrift

Und dann der Fall, der zeigt, dass das Muster kein Gesetz ist.

Das DECT-Telefon in VLAN 31 hat genau eine Aufgabe: sich bei der Telefonanlage registrieren und Gespräche führen. Die Trunks hängen an der Anlage, nicht am Telefon. Es braucht also kein Internet — und aus der Pass-Regel am Ende wird ein Block.

Dasselbe Gerüst, andere letzte Regel. Die Frage ist nie „welches Muster", sondern „wohin muss das Gerät".

Schön daran ist die Abgrenzung zum Nachbarnetz. VLAN 30 mit der Telefonanlage braucht Internet, dort hängen die beiden SIP-Trunks. VLAN 31 mit dem Telefon braucht es nicht. Zwei benachbarte Netze, gegensätzliche letzte Regel, und der Grund liegt nicht im Gerätetyp, sondern in der Aufgabe.

Ein Detail, über das ich dabei gestolpert bin: Im Log tauchte das Telefon sekündlich mit Anfragen auf Port 123 auf. In seiner Konfiguration standen pool.ntp.org und time.windows.com — beides nach draussen, beides geblockt. Und ein Gerät, das im Sekundentakt wiederholt, ist ein Gerät, das keine Antwort bekommt.

Statt eine Ausnahme nach aussen zu bauen, ging es andersherum: DHCP-Option 42 auf die Firewall zeigen lassen, im Telefon auf „Zeit per DHCP" umstellen, dazu eine Regel für UDP 123 zur Firewall-Adresse. Damit hat das Telefon eine Zeitquelle und weiterhin kein Internet.

Die Lehre: Die Wiederholrate im Log ist ein Diagnosewerkzeug. Ein einzelner Block ist ein Versuch, ein Block pro Sekunde ist ein Gerät, das etwas braucht.

Der Drucker: die Richtung dreht sich um Link zu Überschrift

Der Drucker ist das Gegenstück zu allem bisherigen. Er baut keine Verbindungen auf, er nimmt welche entgegen. Sein Regelwerk gehört deshalb überwiegend gar nicht auf sein eigenes Interface:

• VLAN 20 → Drucker: nur IPP auf 631/tcp, optional 9100/tcp fürs rohe Drucken und 161/udp für SNMP-Statusabfragen
• Drucker → NAS: nur bei Bedarf 445/tcp für Scan-to-Share
• Drucker → Internet: blockiert

Kein mDNS-Reflector. Der Drucker wird manuell per IP eingebunden, und das ist kein Kompromiss, sondern die einfachere Lösung: mDNS wird nicht geroutet, und wer es über VLAN-Grenzen tragen will, baut sich einen Dienst dazu, der auch funktionieren muss.

Das ist der Stand der Planung, nicht der Umsetzung. Aktuell steht auf dem Drucker-Interface eine mDNS-Regel und sonst nichts — also ausgerechnet das, was über VLAN-Grenzen ohnehin nicht funktioniert. Das nachzuziehen ist Fleissarbeit für einen ruhigen Abend, und ich schreibe es hier hin, damit ich es nicht vergesse.

Ports, die man nicht kennt Link zu Überschrift

Für die Einmess-Software meines Receivers gibt es keine Portliste. Es gibt sie für viele Geräte nicht.

Das Vorgehen dafür ist immer dasselbe:

1. Eine breite Regel anlegen — Quell-VLAN auf die Zieladresse, alle Ports — und Logging einschalten
2. Die Anwendung einmal komplett durchlaufen lassen, alle Funktionen anfassen
3. Aus dem Log die tatsächlich genutzten Ports ablesen
4. Die Regel darauf eindampfen und die breite entfernen

Wichtig ist Schritt 2: nicht nur starten, sondern zu Ende spielen. Was man nicht angefasst hat, steht nicht im Log, und die Regel fällt genau dort zu eng aus.

Ein Detail, das mich fast in die Irre geführt hätte: Solche Apps suchen ihr Gerät per SSDP, also per Broadcast. Broadcasts werden nicht geroutet. Über eine VLAN-Grenze findet die App nichts, egal wie offen die Regeln sind. Die Lösung ist nicht ein SSDP-Relay, sondern das Feld „Adresse manuell eingeben", das fast jede dieser Apps hat.

Und noch etwas, das der Aufteilung geschuldet ist: Ich brauche dafür zwei Regeln. Die eine App läuft auf dem Handy und damit im Handy-VLAN, die andere auf der Workstation in VLAN 20. Zwei Quellen, zwei Interfaces, zwei Regeln. In einem Sammel-VLAN wäre das eine gewesen — der Preis der feineren Aufteilung, und er ist niedrig.

Der Fehler, den ich zuerst woanders gesucht habe Link zu Überschrift

Mein Fernseher hat die VLAN-Aufnahme klaglos mitgemacht. Seitdem funktionierten die Firmware-Updates nicht mehr.

Meine Vermutung stand sofort fest, weil das Muster verbreitet ist: Das Gerät bringt seinen eigenen DNS-Server mit. Viele Consumer-Geräte haben 8.8.8.8 fest einkompiliert und ignorieren, was sie per DHCP bekommen. Ich hatte die Lösung schon im Kopf — eine NAT-Umleitung, die alles auf Port 53 auf die eigene Firewall zurückbiegt.

Dann habe ich ins Log geschaut, gefiltert auf Port 53. Nichts. Kein einziger DNS-Versuch, weder an 8.8.8.8 noch sonst wohin.

Was stattdessen dastand, waren Dutzende geblockter Verbindungen pro Minute, alle auf TCP 443: ein paar Google-Adressen und rund ein Dutzend AWS-Hosts in Irland, mit ständig wechselnden Quellports. Der Fernseher rannte im Sekundentakt dagegen an.

Die Ursache lag in meiner eigenen Regel. Die stand nicht auf Ports, sondern auf einem Alias mit bekannten Update-Hosts. So etwas baut man einmal aus einer Liste im Netz zusammen, und es funktioniert genau so lange, bis der Hersteller umzieht. Cloud-Endpunkte an eine IP-Liste zu binden, trägt nicht — bei AWS rotieren die Adressen, und ein Fernseher fragt eben nicht nur beim Hersteller an.

Die Korrektur war eine Zeile: Destination von der Alias-Liste auf !RFC1918 umstellen, Ports auf 80 und 443 lassen, Protokoll auf TCP. Dazu die fehlende NTP-Regel, denn ohne halbwegs richtige Uhr scheitern TLS-Handshakes — und das sieht dann wieder aus wie ein Netzwerkproblem. Danach lief das Update auf Anhieb.

Port 80 habe ich bewusst drin gelassen. Zertifikatsprüfungen über OCSP und CRL laufen dort, und zwar aus gutem Grund unverschlüsselt, sonst wäre die Prüfung zirkulär. Wer 80 sperrt, hängt je nach Implementierung in einem Timeout statt in einem sauberen Fehler. Der Sicherheitsgewinn ist dabei praktisch null — wer auf 443 rausdarf, kann dort dasselbe tun.

Die Lehre, und sie ist die wichtigste in diesem Teil: Ich hatte eine plausible Diagnose, eine passende Lösung und alle Werte für die Umsetzung beisammen. Gestimmt hat davon nichts. Zwei Minuten Log hätten mir eine halbe Stunde Konfigurationsarbeit an der falschen Stelle erspart. Das ist dieselbe Lehre wie am Ende von Teil 8, nur andersherum: Dort ging es darum zu prüfen, was tatsächlich ankommt. Hier darum zu prüfen, was tatsächlich rausgeht — bevor man baut.

Was im Log stehen darf Link zu Überschrift

Nach dem Einschalten der Regeln ist die Blockliste voll, und das meiste davon ist kein Fehler.

mDNS auf 5353 an 224.0.0.251 und NetBIOS auf 138 an die Broadcast-Adresse. Multicast und Broadcast werden nicht geroutet, das ist die Firewall, die ordnungsgemäss nichts tut. Ich brauche beides nicht, weil überall feste Adressen stehen.

„Default deny / state violation" direkt nach einem Apply. Das sind die verlorenen Zustände laufender Verbindungen. Beim Übernehmen der Regeln fällt die Zustandstabelle in Teilen weg, und Pakete mitten aus einer bestehenden Verbindung passen dann zu keinem Eintrag mehr. Client neu verbinden lassen, fertig. Bei mir trat das beim Internetradio auf dem Mediaplayer auf, und ich habe eine Viertelstunde die falsche Regel gesucht.

Der ganze Block „Automatically generated rules". Default deny, IPv6-ICMP nach RFC 4890, Anti-Lockout für SSH und die Oberfläche, die DHCP-Freigaben. Die legt OPNsense auf jedem Interface an. Sie sehen beim ersten Aufklappen nach viel zu viel aus und gehören dahin.

Wo ich jetzt stehe Link zu Überschrift

Das Muster steht bei Receiver, Konsole und Gästen. Der Mediaplayer hat seinen eigenen Satz mit vier Ausnahmen. Der Fernseher hat seit heute vier Regeln statt zwei und bekommt seine Updates wieder. Das Telefon hat DNS, Zeit, den Weg zur Telefonanlage und sonst nichts.

Was offen bleibt, und zwar benannt statt weggelassen:

Der Drucker. Siehe oben — die Planung steht, die Regeln nicht.

Die Regel vom Telefon zur Telefonanlage ist noch auf Protokoll * und das ganze VLAN 30 gestellt. Richtig wäre UDP auf die Adresse der Anlage, mit SIP und der RTP-Portrange aus deren Konfiguration. Es funktioniert, es ist nur weiter als nötig — und das ist genau die Sorte offener Punkt, die man nie findet, weil nichts kaputt ist. Die Gegenrichtung von 30 nach 31 habe ich ebenfalls nie geprüft.

Der Portfilter bei Receiver und Konsole. Beim Fernseher ist die Einschränkung auf 80 und 443 vertretbar, weil das Gerät einen klaren Auftrag hat. Bei einer Spielekonsole ist sie es nicht, siehe weiter oben. Das gehört überdacht, bevor mich das Ergebnis in einem halben Jahr als „das WLAN ist schlecht" einholt.

Nächster Schritt Link zu Überschrift

Mit den Regeln steht die Segmentierung. Der nächste Baustein ist der, der von aussen hereinkommt: WireGuard auf der Firewall, damit ich fremdem WLAN nicht trauen muss.

Und der ist bewusst erst jetzt dran. Ein VPN-Client ist auch nur ein Gerät in einem Netz — und erst jetzt gibt es überhaupt eine Antwort auf die Frage, in welchem.

Teil einer Serie über den Umbau meines Heimnetzes. Stand: September 2026. Fragen, Korrekturen und eigene Erfahrungen gerne in die Kommentare.