Homelab-Umbau Teil 3: Die Firewall dazwischenschieben

Das Problem mit dem Umbau Link zu Überschrift

Die Hardware aus Teil 2 stand auf dem Tisch. Das Netz lief weiter. Und genau das ist die unangenehme Stelle: Der Anschluss ist nicht mein Bastelprojekt, sondern der Weg ins Internet. Wenn ich den kaputt mache, ist er kaputt.

Die Aufgabe war also nicht “OPNsense einrichten”, sondern “OPNsense einrichten, ohne dass zwischendurch stundenlang nichts geht”.

Vorbereiten, bevor es zählt Link zu Überschrift

Der erste Schritt hatte mit dem Netz gar nichts zu tun: Die Firewall wurde im Zimmer zusammengebaut, an die Workstation gehängt und vollständig vorkonfiguriert. LAN auf 10.0.1.1, DHCP eingerichtet, Grundregeln gesetzt, alles durchgeklickt.

Das klingt banal, ist aber der eigentliche Trick. Als die Kiste tatsächlich an die Leitung kam, war der Rest eine Sache von Minuten — statt einer Stunde Erstkonfiguration mit einem toten Anschluss im Rücken.

Nebenbei: Ich bin gleich auf 10.0.1.0/24 gegangen statt beim alten 192.168.1.0/24 zu bleiben. Nicht weil das eine besser wäre, sondern weil ich später mehrere Netze wollte und 10.0.<VLAN>.0/24 sich sauber durchnummerieren lässt. VLAN 30 wird 10.0.30.0/24, VLAN 41 wird 10.0.41.0/24. Wenn ich eine IP sehe, weiss ich sofort, wo sie hingehört.

Die MAC-Falle Link zu Überschrift

Ein Detail, das ich vorher wusste und das leicht ein verlorener Abend geworden wäre: Mein Anbieter merkt sich die MAC-Adresse am Anschluss. Steckt da plötzlich ein Gerät mit einer anderen, kann es im schlimmsten Fall Stunden dauern, bis wieder eine Adresse rausgegeben wird.

Also habe ich auf dem WAN-Interface der OPNsense die MAC des R4 eingetragen. Für die Gegenseite hat sich damit schlicht nichts geändert.

Das ist die Sorte von Problem, die man nicht debuggen kann, während sie passiert — man kann dann nur warten. Deshalb vorher nachschauen, wie der eigene Anbieter das handhabt.

Der Umstieg: Doppel-NAT als Brücke Link zu Überschrift

Jetzt der eigentliche Wechsel. Naheliegend wäre gewesen, den R4 komplett umzubauen und dann alles zusammenzustecken. Das hätte bedeutet: Beide Geräte gleichzeitig in einem unfertigen Zustand.

Stattdessen bin ich einen Zwischenschritt gegangen:

• Glasfaser raus aus dem R4, rein in die OPNsense (das SFP-Modul ist einfach umgezogen)
• OPNsense per DAC-Kabel an den R4
• Der R4 blieb unverändert Router — er bekam auf seinem WAN-Port einfach eine Adresse aus dem neuen Netz, 10.0.1.2
• Dahinter lief alles weiter wie bisher in 192.168.1.x

Das ist Doppel-NAT, und normalerweise will man das nicht: zwei Übersetzungen hintereinander, eingehende Verbindungen werden kompliziert, Fehlersuche wird unübersichtlich.

Als Übergangszustand ist es aber genau richtig. Nach zwanzig Minuten war ich wieder online, alle Geräte im Haus liefen unverändert weiter, und ich hatte ab da eine funktionierende Firewall, an der ich in Ruhe arbeiten konnte. Der WAN-Anschluss lief übrigens auf Anhieb per DHCP, nachdem das SFP-Modul umgezogen war.

Von da an ging es nicht mehr um einen grossen Umbau, sondern um viele kleine Schritte: Routing vom R4 weg, DHCP vom R4 weg, DNS vom R4 weg — Stück für Stück an die OPNsense delegiert. Nach jedem Schritt konnte ich prüfen, ob noch alles läuft. Und wenn nicht, wusste ich genau, welcher Schritt es war.

Was schiefging: die VLAN-MAC Link zu Überschrift

Und dann kam das VLAN.

Ich hatte auf der OPNsense eine statische DHCP-Reservierung für den R4 angelegt: MAC des R4 bekommt 10.0.1.2. Sauber, wie man das macht.

Dann habe ich angefangen, VLANs einzurichten. Und war anschliessend nicht mehr auf dem R4. Nicht per SSH, nicht per LuCI, gar nicht. Meine Annahme: Ich hab die Konfiguration zerschossen.

Hatte ich nicht. Ein VLAN-Interface bekommt eine eigene MAC-Adresse. Der R4 hat sich also nicht mehr mit der MAC gemeldet, auf die meine Reservierung lief, sondern mit einer neuen — und damit eine ganz andere Adresse aus dem DHCP-Pool bekommen. Das Gerät war die ganze Zeit erreichbar. Nur eben nicht dort, wo ich gesucht habe.

Das hat mich an dem Tag zwei Neuinstallationen der SD-Karte gekostet, bevor ich verstanden habe, was passiert.

Die Lehre daraus ist unspektakulär, aber sie hat mir seitdem viel gespart: Wenn ein Gerät nach einer Netzwerkänderung verschwindet, ist der erste Blick nicht die Konfiguration des Geräts, sondern die DHCP-Leases der Firewall. Steht es dort mit einer neuen Adresse, ist nichts kaputt — es ist nur umgezogen.

Und statische Reservierungen hängen an MAC-Adressen. Alles, was eine neue MAC erzeugt — VLANs, Bridges, virtuelle Interfaces — bricht sie.

Das Sicherheitsnetz Link zu Überschrift

Nach dem zweiten Neuflashen habe ich mir angewöhnt, vor jeder Netzwerkänderung am R4 einen Rückweg zu legen. Ein Timer sichert die laufende Konfiguration, wartet 90 Sekunden und spielt sie zurück, falls ich ihn nicht vorher abbreche:

cp /etc/config/network /etc/config/network.failsafe
setsid sh -c 'sleep 90; cp /etc/config/network.failsafe /etc/config/network; /etc/init.d/network restart' >/dev/null 2>&1 </dev/null &

Dann die Änderung machen und testen. Läuft es, brich den Timer ab:

pkill -f "sleep 90"

Läuft es nicht, machst du nichts — nach anderthalb Minuten ist der alte Zustand zurück.

Zwei Details, die mich Zeit gekostet haben: disown gibt es in der BusyBox-Shell von OpenWrt nicht, das braucht man auch nicht — setsid reicht. Und wer das Ganze auf einer OPNsense nachbaut, muss aufpassen: Dort ist die Root-Shell csh, nicht bash. Konstrukte wie 2>/dev/null vor einer Pipe funktionieren dort anders und quittieren mit “Ambiguous output redirect”. Entweder csh-Syntax verwenden oder ein bash -c '...' davorsetzen.

Zusätzlich hat der R4 seitdem ein eigenes Recovery-Interface auf einem sonst ungenutzten Port, mit fester Adresse und unabhängig von der Bridge. Das wird nie angefasst, auch nicht “nur kurz”. Genau dafür ist es da.

Danach: das IPTV-Thema Link zu Überschrift

Kaum lief das Netz, fiel auf, dass der Fernseher nicht mehr wollte. Mein Anbieter liefert sein TV-Angebot über Multicast, und Multicast läuft nicht einfach so über eine Firewall.

Die Lösung besteht aus zwei Teilen. Auf der OPNsense übernimmt ein IGMP-Proxy die Anmeldung an den Multicast-Gruppen und reicht den TV-Stream ins interne Netz weiter. Auf dem R4 läuft udpxy und macht daraus HTTP-Unicast — was ich brauche, weil auch WLAN-Geräte den TV-Stream empfangen sollen und Multicast über WLAN eine unangenehme Angelegenheit ist.

Der Bug, der mich dabei am längsten aufgehalten hat, steckte an einer unscheinbaren Stelle: In der IGMP-Proxy-Konfiguration gibt es beim Upstream ein Feld “Allowed Subnets”, das standardmässig auf 0.0.0.0/32 steht. Damit kommt nichts durch. Dort gehört das Netz rein, aus dem der Anbieter seine Streams schickt.

Wo ich jetzt stehe Link zu Überschrift

Die OPNsense routet, der R4 ist Switch und Access Point, das Doppel-NAT ist Geschichte. Fernsehen läuft, Telefonie läuft, und es gibt zum ersten Mal eine Stelle im Netz, an der ich Regeln durchsetzen kann.

Was noch fehlt, ist alles Interessante: die VLANs, die automatische Zuweisung, die eigene CA. Dafür brauche ich aber erst einen Ort, an dem Dienste laufen können — und darum geht es im nächsten Teil.

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