Vielen Dank an The Social Dork | Cybersicherheit für die Vorstellung eines OPNsense-Heimfirewall-Aufbaus mit ZimaBoard 2. Eine virtuelle Maschine übernimmt Routing und Firewall-Richtlinien, ein Access Point stellt WLAN bereit und Pi-hole filtert DNS-Anfragen für verbundene Clients. Sieh dir die Original-YouTube-Anleitung für die vollständige Demonstration an.
Vor dem Lesen ansehen: Dieses etwa zehnminütige Video ist hilfreich, wenn du dein Netzwerk-Gateway von deinem WLAN-Access-Point trennen möchtest. Der Creator erklärt die Topologie, startet OPNsense in Zima Virtual Machine, weist Schnittstellen und DHCP zu und überprüft anschließend einen WLAN-Laptop und dessen DNS-Filterung.
Der gezeigte Meilenstein ist, dass ein Laptop über die neue Firewall das Netzwerk erreicht und den ausgewählten DNS-Filter nutzt. Das Video zeigt den Ablauf für den ersten Client. Die einleitende Sorge um anfällige IoT-Geräte würde eine zusätzliche Netzwerktrennung und Zugriffsrichtlinien erfordern. Geräte in ein neues WLAN zu bringen, isoliert sie nicht automatisch voneinander.
Lege fest, welche Funktionen das vorhandene Gateway weiterhin übernehmen muss
Die Topologie unterscheidet drei Funktionen, die ein All-in-one-Router verbergen kann: die Providerverbindung, die geroutete Firewall-Grenze und den WLAN-Zugang. Eine Ethernet-Übergabe kann die neue Firewall versorgen, während bei DSL- oder Kabelanschlüssen weiterhin das passende Modem oder Providergerät benötigt wird. Der Austausch der Routing-Funktion hebt diese physische Verbindungsvoraussetzung nicht auf.
Im funktionierenden Aufbau des Creators ist der vorhandene Heimrouter mit der WAN-Seite der Firewall verbunden, während ein Access Point an deren LAN-Seite angeschlossen ist. Wenn das vorgeschaltete Gateway ebenfalls Netzwerkadressübersetzung durchführt, entsteht doppeltes NAT. Für einen ersten Test ist das akzeptabel, kann aber eingehende Dienste und die Fehlersuche erschweren. Ob der Bridge- oder Passthrough-Modus verfügbar ist, hängt von den Geräten und dem Dienst des Providers ab. Kläre das, bevor du die produktive Verbindung änderst.
| Aufgabe | Komponente im dargestellten Aufbau | Frage, die vor dem Umzug der Clients beantwortet werden muss |
|---|---|---|
| Übergabepunkt des Providers | Ethernet-Dienst oder das erforderliche Modem/Gateway. | Welches Gerät muss für eine funktionierende Verbindung erhalten bleiben? |
| Routing und Richtlinien | OPNsense-VM. | Läuft der Client-Datenverkehr tatsächlich über dieses Gateway? |
| WLAN-Zugang | Ein separater Access Point oder eine unterstützte AP-Konfiguration. | Bindet es die Clients in das vorgesehene LAN ein? |
| Adressvergabe | Ein DHCP-Dienst für das Client-Netzwerk. | Welcher Server stellt Gateway- und DNS-Einstellungen bereit? |
| DNS-Filterung | Pi-hole-Dienst. | Können diese Clients den ausgewählten Resolver erreichen? |
Notieren Sie vor der Umstellung die aktuellen, vom Anbieter vorgegebenen Einstellungen. Ein Video, das eine Ethernet-Übergabe zeigt, belegt nicht, welche Authentifizierung, VLAN-Konfiguration oder Modemvoraussetzungen Ihr Internetanbieter verlangt. Halten Sie die Konfiguration des alten Gateways während der Tests des neuen Pfads mit einem Client bereit. So können Sie ein Problem mit dem vorgelagerten Dienst von einem Fehler im neuen LAN unterscheiden.
Double NAT bezeichnet zwei geroutete Übersetzungsgrenzen. Das ist etwas anderes als ein nachgelagerter Access Point. Wenn das WLAN-Gerät weiterhin als Router arbeitet, kann es eine zusätzliche Grenze und einen weiteren DHCP-Dienst einführen. Prüfen Sie die tatsächliche Betriebsart und die Kabelverbindungen, statt seine Funktion anhand der Produktbezeichnung auf dem Gehäuse zu bestimmen.
Ordnen Sie die virtuellen Schnittstellen einer echten WAN- und LAN-Grenze zu
The Social Dork lädt ein OPNsense-Installationsimage herunter und startet es in Zima Virtual Machine auf dem ZimaBoard 2. Dies ist eine Demonstration einer virtualisierten Firewall. Auf dem Host läuft weiterhin ZimaOS. Daher gehört auch dessen Netzwerkkonfiguration zum Gesamtkonzept, ebenso wie die OPNsense-Einstellungen innerhalb des Gasts.
Ordnen Sie bei einer ähnlichen Einrichtung jede virtuelle Schnittstelle ausdrücklich dem vorgesehenen physischen Anschluss oder isolierten Hostnetzwerk zu. Ein Paar Netzwerkbuchsen stellt diese Zuordnung nicht automatisch her. Trennen Sie den WAN-seitigen Pfad von gewöhnlichen Hostdiensten und stellen Sie sicher, dass der Datenverkehr der LAN-Clients die Firewall passieren muss, um die vorgelagerte Verbindung zu erreichen. Verfügt ein Client über einen anderen Weg an der VM vorbei, kann die Firewall für diesen Datenverkehr keine Richtlinien durchsetzen.

Verwenden Sie die aktuelle Installationsanleitung für OPNsense und die Anleitung für virtuelle Maschinen für das ausgewählte Image und die Plattform. Halten Sie fest, wie Sie den Host und die VM-Konsole erreichen, bevor Sie Schnittstellen ändern. Ein Neustart des Hosts, ein Speicherproblem oder das Herunterfahren der VM kann dieses Gateway unterbrechen. Planen Sie Wartungsarbeiten daher mit Blick auf die Internetverbindung im Haushalt.
Machen Sie den Schnittstellenplan eindeutig
- Identifizieren Sie die physischen Anschlüsse des Hosts und halten Sie fest, welches Kabel zur vorgelagerten Verbindung führt.
- Ordnen Sie die WAN-seitige Schnittstelle des Gasts dem vorgesehenen vorgelagerten Netzwerk zu.
- Ordnen Sie die LAN-seitige Schnittstelle einem separaten nachgelagerten Netzwerk zu.
- Vergewissern Sie sich, dass der Verwaltungszugang und gewöhnliche Hostdienste nicht unbeabsichtigt über die WAN-Seite erreichbar sind.
- Schließen Sie einen Test-Client an das nachgelagerte Netzwerk an und prüfen Sie dessen tatsächliches Standardgateway, bevor Sie weitere Geräte hinzufügen.
Ein Schnittstellenname innerhalb des Gasts stimmt möglicherweise nicht mit der Beschriftung neben einem physischen Anschluss überein. Nutze die Netzwerkzuordnung des Hypervisors und die Gastkonsole, um den Zusammenhang zu ermitteln. Überprüfe ihn erneut, wenn du virtuelle Adapter änderst. Das Video zeigt eine funktionierende Konfiguration auf dem Rechner des Erstellers, bietet aber keine vollständige Übersicht über alle Host-Bridges oder Adaptereinstellungen, auf die du möglicherweise stößt.
Weise der Firewall genügend Ressourcen zu und lasse zugleich Kapazität für ZimaOS und die anderen Dienste auf dem Host übrig. Die aktuelle OPNsense-Virtualisierungsanleitung nennt 3 GB RAM als Mindestwert, eine virtuelle Festplatte mit mindestens 8 GB sowie Hinweise zur Netzwerkkompatibilität. Das sind Ausgangswerte, keine Garantie für einen bestimmten Durchsatz. Protokolle, VPNs, Inspektionsfunktionen und andere Workloads können den erforderlichen Spielraum verändern.
Das ist ein betrieblicher Kompromiss, wenn ein Gerät gemeinsam genutzt wird: Ein Update oder Neustart des Hosts kann auch die Gateway-VM außer Betrieb setzen. Lege fest, wie die VM nach dem Booten gestartet wird und wie du sie wiederherstellst, falls sie nicht startet. Ein zuverlässiger Konsolenzugriff ist besonders hilfreich, wenn eine fehlerhafte Netzwerkeinstellung die Weboberfläche unerreichbar macht.
Lass für jedes Client-Netzwerk einen DHCP-Dienst zuständig sein
Der Ersteller verwendet unterschiedliche IPv4-Netze für die Upstream- und Downstream-Seite: Auf der Upstream-Seite kommen 192.168.0.x-Adressen zum Einsatz, im Client-LAN 192.168.1.x-Adressen. Dies sind Beispiele aus dem Video. Wähle nicht überlappende Subnetze, die zu deinem Netzwerk passen, statt Adressen zu übernehmen, die möglicherweise bereits verwendet werden.
Der Access Point stellt die Funkverbindung her, während OPNsense die DHCP-Zuweisungen für die nachgelagerten Clients bereitstellt. In der Anleitung werden der AP-Modus und das Deaktivieren des DHCP-Dienstes des alten WLAN-Routers erläutert. Bei Geräten ohne dedizierten AP-Modus garantiert das alleinige Deaktivieren von DHCP kein transparentes Access-Point-Verhalten: Prüfe die Anforderungen des Herstellers an die LAN-zu-LAN-Verkabelung sowie an Routing und NAT. Stelle sicher, dass die Verwaltungsadresse erreichbar bleibt und nicht mit dem DHCP-Adresspool kollidiert.

Teste die resultierende DHCP-Zuweisung mit einem Laptop. Er sollte eine Adresse im vorgesehenen LAN, die LAN-Adresse der Firewall als Standardgateway und den vorgesehenen DNS-Server erhalten. Eine erfolgreiche WLAN-Verbindung beweist lediglich, dass die Funkverbindung funktioniert. Anhand der Adresse, des Gateways und des DNS-Resolvers erkennst du, ob der Client tatsächlich in das neue Netzwerk eingebunden wurde.
Feste Adressen und Lease-Pool getrennt planen
Das folgende /24-LAN-Schema dient nur zur Veranschaulichung und ist keine Wiedergabe der genauen Adressen des Erstellers. Passen Sie es an Ihre vorhandenen Netzwerke an. Reservieren Sie feste Infrastrukturadressen außerhalb des dynamisch zugewiesenen Pools und halten Sie das vorgelagerte Netzwerk vom nachgelagerten LAN getrennt.
| Element | Beispieladresse oder -bereich | Grund |
|---|---|---|
| OPNsense-LAN-Schnittstelle | 192.168.1.1/24 | Clients verwenden diese Adresse als Gateway. |
| Verwaltung des Access Points | 192.168.1.2 | Ein stabiles Verwaltungsziel außerhalb des Beispielpools. |
| Erreichbarer Pi-hole-Endpunkt | 192.168.1.10 | Der in diesem Beispiel an Clients bekanntgegebene DNS-Endpunkt. |
| DHCP-Pool für Clients | 192.168.1.100–192.168.1.199 | Ein separater Pool vermeidet Konflikte mit diesen festen Adressen. |
Wenn sich Pi-hole tatsächlich in einem anderen Subnetz oder in einem virtuellen Netzwerk auf der Host-Seite befindet, verwenden Sie den tatsächlich erreichbaren Endpunkt sowie das erforderliche Routing und die passenden Richtlinien. Durch die Beispieladresse wird der Dienst nicht automatisch im LAN verfügbar. Ein DHCP-Eintrag teilt Clients mit, wohin sie eine Anfrage senden sollen; er richtet weder die Route ein noch startet er den Server.

Prüfen Sie nach einer DHCP-Änderung die Lease auf dem Laptop, statt nur die Konfigurationsseite des Servers zu kontrollieren. Bestätigen Sie die zugewiesene Adresse, Maske, das Gateway und die DNS-Einträge. Ein Client mit einer noch gültigen alten Lease kann eine korrekte neue Einrichtung fehlerhaft erscheinen lassen. Eine unerwartete Adresse oder ein unerwartetes Gateway ist ebenfalls ein Hinweis darauf, dass möglicherweise noch ein weiterer DHCP-Server aktiv ist.
Die erste Zulassungsregel als Verbindungstest behandeln
Der Ersteller beginnt mit einer freizügigen Regel für ausgehenden Datenverkehr des einzelnen Test-Laptops und erläutert, wie unerwünschte Verbindungen vom WAN zum LAN verhindert werden. OPNsense verwendet zustandsbehaftete Filterung, sodass Antworten auf eine erlaubte Verbindung anhand des Verbindungsstatus behandelt werden. Die Dokumentation zu OPNsense-Firewall-Regeln erklärt, wie sich Schnittstelle, Richtung und Regelreihenfolge auf dieses Verhalten auswirken.

Im Video wird außerdem die Weboberfläche aus dem privaten vorgelagerten Netzwerk geöffnet. Beschränke in deiner eigenen Bereitstellung den administrativen Zugriff auf einen vertrauenswürdigen Verwaltungsweg und behalte eine Möglichkeit zur Wiederherstellung über die Konsole bei. Die Bezeichnung WAN beschreibt eine Rolle relativ zu dieser Firewall; ein vorgelagertes privates Labornetzwerk und das öffentliche Internet sind unterschiedliche Bedingungen hinsichtlich der Erreichbarkeit.
Um auf die zu Beginn angesprochene IoT-Frage einzugehen, erstellst du mit geeigneter Ausrüstung separate Netzwerke und legst anschließend fest, welcher Datenverkehr zwischen ihnen zulässig ist. Geräte, die Datenverkehr innerhalb desselben lokalen Segments austauschen, können möglicherweise kommunizieren, ohne die geroutete Firewall zu passieren. Eine weitere praktische Perspektive auf Entscheidungen zu Gateway und Datenschutz bietet der OPNsense-Firewall-Aufbau von cachito labs.
Konnektivität und Isolation getrennt betrachten
| Ziel der Richtlinie | Was zuerst gegeben sein muss | So überprüfst du die Konfiguration |
|---|---|---|
| Ein Test-Laptop kann im Internet surfen. | Es verwendet das vorgesehene Gateway und den vorgesehenen Resolver. | Öffne ein zulässiges Ziel und prüfe den zugehörigen Datenverkehr. |
| Ein IoT-Netzwerk kann nicht auf ein vertrauenswürdiges LAN zugreifen. | Die Geräte befinden sich in separaten gerouteten Netzwerken. | Versuche die ausgewählte Verbindung zwischen Netzwerken und prüfe die Richtlinie. |
| Die Clients verwenden den vorgesehenen DNS-Dienst. | Der Resolver ist erreichbar und wird korrekt bekannt gegeben. | Gleiche die Anfragen der Clients mit dem Pi-hole-Abfrageprotokoll ab. |
| Die Administration erfolgt über einen vertrauenswürdigen Zugriffsweg. | Der Verwaltungszugriff ist auf die vorgesehenen Quellen beschränkt. | Prüfe einen autorisierten Zugriffsweg und behalte die Möglichkeit zur Wiederherstellung über die Konsole bei. |
Lege Quelle, Ziel, Protokoll und Zweck fest, bevor du eine Regel hinzufügst. Eine Regel, die belegt, dass ein Laptop auf das Internet zugreifen kann, ist keine Richtlinie für alle Geräte im Haushalt. Für die Segmentierung verwendest du separate Netzwerke und eine Firewall-Verbindung zwischen ihnen. Datenverkehr, der lokal im selben Segment ausgetauscht wird, erreicht möglicherweise gar nicht das Gateway.
Wenn eine Regeländerung scheinbar keine Wirkung zeigt, teste eine neue Verbindung und berücksichtige den Verbindungsstatus. Die Anleitung zu OPNsense-Regeln erklärt die zustandsbehaftete Verarbeitung. Bestehende Verbindungszustände können einen erneuten Test beeinflussen, während das Zurücksetzen aller Zustände andere aktive Verbindungen unterbrechen würde. Ermittle den konkreten Test-Datenverkehr, bevor du eine umfassende Diagnoseänderung vornimmst.
Pi-hole über DHCP einbinden, ohne eine DNS-Schleife zu erzeugen
Gegen Ende stellt The Social Dork den über DHCP bereitgestellten DNS-Server auf die Adresse von Pi-hole ein. Dadurch wird das zuvor erwähnte Pi-hole- und Tailscale-Projekt zur Werbeblockierung in das neue WLAN eingebunden. OPNsense steuert den gerouteten Datenverkehr; Pi-hole wertet die über seinen Dienst angefragten DNS-Namen aus. Die beiden Komponenten haben unterschiedliche Aufgaben.

Pi-holes OPNsense-Integrationsleitfaden beschreibt die direkte Verteilung per DHCP und die Weiterleitung über die Firewall als alternative Konfigurationen. Wählen Sie einen einheitlichen Pfad und stellen Sie sicher, dass die Resolver Anfragen nicht in einer Schleife aneinander zurückleiten. Prüfen Sie außerdem, ob die Clients die Pi-hole-Adresse erreichen dürfen, wenn sie sich in einem anderen Netzwerk befindet.

Wählen Sie einen Resolver-Pfad und zeichnen Sie ihn vollständig auf
| Konfiguration | Abfragepfad | Was die Protokolle zeigen können |
|---|---|---|
| Clients fragen Pi-hole direkt ab. | Client → erreichbarer Pi-hole-Endpunkt → ausgewählter Upstream-Resolver. | Pi-hole kann Anfragen den Quelladressen zuordnen, von denen sie tatsächlich empfangen werden. |
| Clients fragen einen weiterleitenden Firewall-Resolver ab. | Client → Firewall-Resolver → Pi-hole → unabhängiger Upstream-Pfad. | Pi-hole sieht möglicherweise hauptsächlich die weiterleitende Firewall als Quelle. |
Im Video wird für die Clients die von DHCP bereitgestellte Pi-hole-Adresse verwendet. Die Weiterleitungskonfiguration im verlinkten offiziellen Leitfaden ist eine Alternative. Wenn Sie diese wählen, stellen Sie sicher, dass Pi-holes Upstream den Request nicht direkt in dieselbe Weiterleitungskette zurücksendet. Ein klarer Pfad erleichtert die Diagnose, wenn keine Antwort eingeht.
DNS hängt auch von Transport und Routing ab. Wenn sich Client und Resolver in verschiedenen Netzwerken befinden, prüfen Sie den Pfad und die entsprechenden TCP-/UDP-Richtlinien für Port 53. Kontrollieren Sie IPv6-DNS-Ankündigungen und unabhängige DNS-Einstellungen des Clients, wenn das beobachtete Ergebnis von der DHCP-Konfiguration abweicht. Der Zugriff auf die Pi-hole-Weboberfläche allein ist kein ausreichender Nachweis.
Für Filterung außerhalb des Heimnetzwerks lesen Sie erneut die begleitende Pi-hole- und Tailscale-Anleitung. Remote-DNS-Zugriff, lokale Gateway-Richtlinien und der gesamte Internetverkehr über ein VPN sind getrennte Entscheidungen. Testen Sie jede davon über die Verbindung, auf der sie tatsächlich verwendet wird.
Überprüfen Sie den gesamten Pfad, bevor Sie alle Geräte umstellen
In der abschließenden Demonstration wird das WLAN des Laptops gewechselt und dieselbe Website mit und ohne Filterkonfiguration verglichen. Sie veranschaulicht den ausgewählten Client-Pfad, beweist aber nicht, dass alle Websites werbefrei sind oder alle Geräte voneinander isoliert sind. Prüfen Sie zuerst den Internetzugang und DNS und sehen Sie sich anschließend die relevanten Firewall- und Pi-hole-Protokolle an, um jedes Ergebnis dem vorgesehenen Client zuzuordnen.
Testen Sie vor der Umstellung des Haushalts die Lease-Erneuerung eines Clients, eine erlaubte Verbindung und, falls die Segmentierung Teil Ihres Designs ist, eine bewusst gesperrte Verbindung zwischen getrennten Netzwerken. Exportieren Sie eine funktionierende Firewall-Konfiguration und prüfen Sie den Wiederherstellungsweg. Das Ziel ist ein Gateway, dessen Routing, DHCP, Filterung und Verwaltung Sie erklären und warten können. Im vollständigen OPNsense-Leitfaden für die Heim-Firewall von The Social Dork sehen Sie die ursprüngliche Topologie und die Einrichtungsabfolge.
Führen Sie einen schrittweisen Abnahmetest durch
- Verbinden Sie sich mit dem vorgesehenen WLAN und prüfen Sie die neue Client-Lease.
- Prüfen Sie das Standard-Gateway und testen Sie dann gegebenenfalls eine erlaubte Verbindung über eine IP-Adresse.
- Lösen Sie einen erlaubten Hostnamen über den ausgewählten Resolver auf und suchen Sie die zugehörige Abfrage.
- Testen Sie eine Domain in der aktiven Pi-hole-Richtlinie und prüfen Sie, ob die erwartete Antwort erfolgt.
- Wenn Sie eine Netzwerksegmentierung eingerichtet haben, testen Sie über die geroutete Grenze hinweg sowohl eine erlaubte als auch eine gesperrte Verbindung.
- Verbinden Sie den Client erneut oder erneuern Sie seine Lease und prüfen Sie, ob die vorgesehenen Einstellungen wiederhergestellt werden.
- Prüfen Sie während eines geplanten Wartungsfensters den Startpfad von Host und Gateway-VM, bevor Sie sich dauerhaft darauf verlassen.
Fehlersuche in Netzwerkreihenfolge
| Symptom | Wahrscheinliche zu prüfende Ebene | Nützliche Nachweise |
|---|---|---|
| Keine erwartete Client-Adresse. | AP-Bridge, Verkabelung, DHCP-Schnittstelle oder konkurrierender DHCP-Server. | Die Lease und das Netzwerk, in dem sie bezogen wurde. |
| Der Client hat eine Adresse, aber keinen Internetzugang. | Gateway, Zuordnung virtueller Schnittstellen, Upstream-Zugriff, Routing oder NAT. | Status der Gast-Schnittstelle und der Testdatenfluss. |
| IP-Verbindungen funktionieren, Namensauflösung schlägt fehl. | DNS-Endpunkt, Richtlinie, Listener oder Upstream-Resolver. | Ein expliziter DNS-Test und ein passender Resolver-Protokolleintrag. |
| Eine gesperrte Verbindung funktioniert weiterhin. | Falscher Netzwerkpfad, Regelumfang/-reihenfolge oder ein bestehender Status. | Quell-/Zieladressen und der jeweilige Verbindungsstatus. |
| Das Netzwerk fällt nach einem Host-Update aus. | Start der Gateway-VM oder Netzwerkzuordnung des Hosts. | Konsolenzugriff und die zuletzt als funktionierend bekannten Host-/Gast-Einstellungen. |
Beantworten Sie mithilfe der Protokolle immer nur eine Frage auf einmal. Die Dokumentation zur Firewall-Protokollierung von OPNsense erklärt, dass für einen zustandsbehafteten Datenfluss nicht unbedingt für jedes Paket eine neue Zeile im Live-Protokoll erscheint. Der Leitfaden zur Firewall-Diagnose bietet eine Zustandsübersicht. Ein ruhiges Protokoll allein beweist nicht, dass kein Datenverkehr die Firewall passiert hat.
Speichere eine funktionierende Konfiguration, bevor du größere Änderungen vornimmst, und halte einen klaren Rollback-Plan bereit. Halte während der Tests die alte Verbindung separat verfügbar. Vermeide es, die Netzwerke vor und hinter der Firewall versehentlich miteinander zu verbinden. Bei einem sinnvollen Rollback werden ein bekanntes Gateway und eine bekannte Client-Konfiguration wiederhergestellt, anstatt zwei konkurrierende Router in dasselbe Client-Segment einzuführen.
FAQ
Kann die ZimaBoard 2 allein das WLAN bereitstellen?
In diesem Video stellt ein separater Access Point das WLAN bereit. Das Board hostet das virtualisierte Gateway und zugehörige Dienste. Routing und WLAN-Zugang sind unterschiedliche Aufgaben.
Kann ich das ISP-Modem entfernen?
Nur, wenn deine Dienste nicht mehr darauf angewiesen sind. DSL-, Kabel- und anbieterabhängige Konfigurationen benötigen möglicherweise weiterhin ihre ursprünglichen Übergabegeräte. Prüfe die Anforderungen an Hardware und Dienste, bevor du ein Gateway ersetzt.
Isoliert eine Regel für ausgehenden Datenverkehr IoT-Geräte?
Dadurch wird keine Netzwerksegmentierung geschaffen. Geräte in einem lokalen Segment können möglicherweise miteinander kommunizieren, ohne die geroutete Firewall zu passieren. Für eine Isolierung sind getrennte Netzwerke und eine getestete Richtlinie zwischen ihnen erforderlich.
Sollte Pi-hole innerhalb von OPNsense laufen?
Das vorgestellte Projekt verwendet neben der virtualisierten Firewall einen Pi-hole-Dienst und gibt dessen Adresse über DHCP bekannt. Entscheidend ist ein erreichbarer, konsistenter DNS-Pfad. Gehe nicht davon aus, dass dieser Dienst mit der Installation von OPNsense ebenfalls installiert wird.
Warum benötigt die Firewall-VM zwei Netzwerkpfade?
Das geroutete Design benötigt einen Pfad zum vorgelagerten Netzwerk und einen separaten Pfad zum nachgelagerten Netzwerk. Durch die korrekte Zuordnung der Schnittstellen zwischen Gast und Host wird diese Grenze eingerichtet. Zwei sichtbare Adapternamen allein belegen nicht, dass die Netzwerke isoliert sind.
Was passiert beim Neustart des ZimaOS-Hosts?
Die Gast-Firewall und andere gehostete Dienste können ausfallen. Plane den Start und die Wiederherstellung der virtuellen Maschinen und überprüfe beides während eines Wartungsfensters. Bei gemeinsam genutzter Hardware gehört die Host-Wartung zur Verfügbarkeit des Gateways.
Fazit
Der Aufbau von The Social Dork ist hilfreich, weil er aus einem All-in-One-Gateway eine Reihe verständlicher Aufgaben macht: Internetanbindung, virtualisiertes Routing, WLAN-Zugang, Adresszuweisung und DNS-Filterung. Der erste erfolgreiche Laptop-Test liefert einen Ausgangspunkt. Bei einem dauerhaft betriebenen Heim-Gateway müssen außerdem die Netzwerkgrenzen überprüft, geeignete Richtlinien für die einzelnen Client-Gruppen festgelegt und ein Wiederherstellungsweg eingerichtet werden.
Führe die Prüfungen mit einem einzelnen Client vollständig durch, bevor du den Haushalt umstellst. Überprüfe zusätzliche Segmentierungen oder VPN-Verhalten anschließend unabhängig davon. Halte die OPNsense-Videoanleitung zusammen mit deinem eigenen Schnittstellenplan und der aktuellen offiziellen Dokumentation bereit. Ziel ist ein Netzwerk, dessen Verhalten du erklären, testen und wiederherstellen kannst.
Zima-Kampagnenzentrale
Mehr zum Lesen

ZimaSpace Black-Friday-Kaufratgeber 2026: Angebote, Cluster und Geschenke
Vergleiche die Black-Friday-Angebote für ZimaBoard 2, SE und ZimaCube 2, Cluster mit drei Boards und Produktgeschenke. Erfahre, wie du zeitlich begrenzte Warenkorbgeschenke einlösen und...

Wie The Social Dork mit dem ZimaBoard 2 einen Pi-hole-Werbeblocker baut
Folge dem Pi-hole- und Tailscale-Aufbau von The Social Dork auf dem ZimaBoard 2 – mit lokalen DNS-Tests, Blocklistenprüfungen und privater Filterung von unterwegs.

Ich habe KI gekauft, um Zeit zu sparen. Dann begann ich, ihre Grenzen zu umgehen.
Ich begann, meine Abende nach KI-Credits und Codex-Resets zu planen. Als ich einige alltägliche Aufgaben auf lokale KI verlagerte, konnte ich meinen Arbeitstag anders...



