Der Abend der Umstellung — das Heimnetz läuft über die eigene Firewall

Am 20. Oktober habe ich das Heimnetz nach dem Muster des Rechenzentrums geplant. Seit dem 2. November 2026 läuft es: Die FRITZ!Box routet nichts mehr, eine OPNsense trennt die Netze, und zwischen Wohnung und Rechenzentrum steht ein WireGuard-Tunnel. Nur die Firewall, die dafür bestellt war, ist noch nicht geliefert. Hier steht, wie es trotzdem ging und wo es gehakt hat.

Eine Übergangsbox statt zu warten

Die Switches und der Access Point waren da, die Protectli VP6670 nicht. Statt zu warten, habe ich eine ältere, kleinere OPNsense-Box mit vier Gigabit-Ports neu aufgesetzt. Ihre alte Konfiguration brauchte ich nicht mehr, also kein Import, sondern ein leerer Anfang mit dem Assistenten und danach alles von Hand, Schritt für Schritt mitgeschrieben.

Die Ports sind so verteilt, dass später nur ein Kabel umgesteckt werden muss:

Wenn die neue Firewall kommt, wird die Konfiguration exportiert und nur der Name der Trunk-Schnittstelle getauscht. Alle VLANs hängen an genau dieser einen Zeile.

Modem statt Router — und ein VLAN, das niemand zeigt

Am Anschluss hängt jetzt ein DrayTek Vigor 167 im Modem-Modus. Er setzt nur DSL in Ethernet um, die Einwahl per PPPoE macht die Firewall. Der erste Test war ein Mac mit eingebautem PPPoE direkt am Modem. Es kam keine Verbindung zustande, und das Protokoll gab nur einen Abbruch beim Aushandeln her.

In der FRITZ!Box war kein VLAN eingetragen. Der Anbieter verlangt aber eins: VLAN 7, wie bei fast allen VDSL-Anschlüssen in Deutschland. Die FRITZ!Box setzt es bei der Auswahl des Anbieters stillschweigend selbst. Gezeigt hat das erst ein Mitschnitt, den die FRITZ!Box über ihre versteckte Diagnoseseite selbst schreiben kann. Darin hatten die Einwahlpakete den VLAN-Tag 7. Mit VLAN 7 im Modem und leerem Dienstnamen stand die Verbindung sofort.

Die Verwaltung umziehen, ohne sich auszusperren

Alle Switches sollten in ein eigenes Verwaltungs-VLAN, VLAN 1 bleibt leer. Der Omada-Controller lehnte das zunächst ab, solange die Switches im alten Netz eine feste Adresse hatten: zwei feste Adressen im selben Netz, fehlerhaft. Die Reihenfolge, die funktioniert hat:

1. Die alte Schnittstelle auf DHCP stellen.
2. Die neue im Verwaltungs-VLAN mit fester Adresse anlegen.
3. Den Haken setzen, der die alte Verwaltungsschnittstelle abschaltet.

Der Controller schickt Änderungen einzeln und wartet, ob der Switch danach noch antwortet. Der Kern-Switch kommt zuletzt dran, sonst verliert der Controller die übrigen auf halbem Weg. Am Ende gibt es keine Port-Profile mit „alle VLANs“ mehr, jeder Port trägt nur, was dort hingehört.

Die FRITZ!Box als reine Telefonanlage

Die FRITZ!Box hängt jetzt als gewöhnlicher Client im Sprach-VLAN, mit festem Lease und abgeschaltetem WLAN. Telefonie und DECT laufen wie vorher. Eine Sache hat überrascht: Der Zugriff auf ihre Oberfläche aus dem Verwaltungs-VLAN ging nicht mehr. Die FRITZ!Box behandelt jede Anfrage aus einem fremden Netz wie einen Zugriff aus dem Internet und verlangt dafür eine Freigabe, die es im Client-Modus nicht gibt.

Die Lösung steht auf der Firewall, nicht auf der Box: Anfragen aus dem Verwaltungsnetz an die FRITZ!Box werden auf die Adresse der Firewall im Sprach-VLAN umgeschrieben. Die Box sieht dann einen Nachbarn im eigenen Netz und lässt ihn herein. Für die Oberfläche des Modems gilt dasselbe Muster.

DHCP und DNS getrennt

Dnsmasq vergibt nur noch Adressen und trägt die Namen in eine eigene Unterdomain ein. Unbound beantwortet alle Anfragen, prüft DNSSEC und reicht nur zwei Dinge weiter: die DHCP-Unterdomain an Dnsmasq und die internen Zonen des Rechenzentrums an dessen Nameserver, durch den Tunnel. So hat jede Aufgabe genau einen Dienst, und ein Fehler im einen legt den anderen nicht mit lahm.

Die Kopplung ins Rechenzentrum

Zwischen der Firewall zu Hause und der im Rechenzentrum steht ein WireGuard-Tunnel mit einem eigenen Transfernetz. Erlaubt sind auf beiden Seiten nur die Netze der Gegenseite, und auch die nur dorthin, wo die Regeln es zulassen.

Wichtig war mir eine Richtung: Nur die Firewall zu Hause wählt sich ein. Die Seite im Rechenzentrum kennt keinen Endpunkt für die Gegenstelle, sie lernt ihn aus dem ersten gültigen Paket. Fällt die Leitung aus und das 5G-Modem übernimmt, ändert sich die Adresse zu Hause. Der Tunnel steht trotzdem nach dem nächsten Keepalive wieder, ohne dass irgendwo eine Adresse nachgetragen werden muss. Eine feste Adresse für den Anschluss zu Hause wird damit überflüssig.

Zwei Stolpersteine auf dem Weg:

• Der Cache war schneller als der Tunnel. Nach dem Aufbau lieferten interne Namen weiter die öffentlichen Adressen. Die Zugriffsliste auf dem Nameserver war richtig, Unbound hatte die Antworten von vorher noch im Cache. Ein Neustart von Unbound, und die internen Adressen kamen.
• Ein Test, der zu früh grün war. Schon vor dem Tunnel kam eine Verbindung zu einer internen Adresse des Rechenzentrums zustande — über das Netz des Anbieters, das dieselben privaten Bereiche nutzt. Seitdem sperrt eine Regel auf der WAN-Seite alle privaten Ziele. Was nicht durch den Tunnel geht, geht gar nicht.

Was ich daraus mitnehme

Ein Gerät, das „automatisch“ etwas einstellt, versteckt es auch. Das VLAN hätte ich ohne den Mitschnitt nicht gefunden. Wer ein Gerät ersetzt, sollte vorher nachsehen, was es auf der Leitung tatsächlich tut, nicht nur, was es in der Oberfläche zeigt.

Mitschreiben beim Klicken lohnt sich. Jeder Schritt der Einrichtung steht in einer Anleitung, jedes Kabel mit Etikett in einer Liste. Als der Zugriff auf die FRITZ!Box scheiterte, war in zwei Minuten klar, welche Regel fehlte, statt eine Stunde zu suchen.

Die Übergangslösung ist keine verlorene Arbeit. Regeln, Aliase, VLANs und die Tunnel-Kopplung ziehen mit der Konfiguration auf die neue Firewall um. Die Zwischenstufe hat nur die Zeit überbrückt, in der sonst ein halb fertiges Netz herumgestanden hätte.

Was noch kommt

• Der Tausch auf die VP6670 mit 10G zum Kern-Switch, sobald sie geliefert ist.
• Der Wechsel auf das 5G-Modem, wenn die Leitung ausfällt, mit automatischer Umschaltung auf der Firewall.
• Anmeldung an der Firewall nur noch mit Schlüssel und zweitem Faktor.
• Das Konfigurationsbackup beider Firewalls ins Git, wie bei den übrigen Maschinen.
• Die Firewall zu Hause unter dieselbe Überwachung wie die im Rechenzentrum.