Eine Nachricht von Zima
Vielen Dank, Active_Learner05, dass du ZimaBoard 2 als Plattform zum Lernen und nicht als Gerät mit nur einer festen Aufgabe nutzt. Ein ZimaBoard 2 1664 in eine OPNsense-Firewall zu verwandeln und dich anschließend mit Speicher, Bootreihenfolge, Schnittstellenzuweisung, der Umwandlung in einen Access Point und Sicherheits-Plugins auseinanderzusetzen, zeigt genau die praktische Experimentierfreude, die ein Homelab wirklich nützlich macht.
Wir schätzen besonders, dass du den Prozess geteilt hast, während er noch in Arbeit war. Der interessante Teil ist nicht nur, dass die Firewall online ging, sondern dass andere Nutzer die dahinterstehenden Entscheidungen nachvollziehen können: warum OPNsense zum Hauptbetriebssystem wurde, wie das Netzwerk verbunden wurde, welche Sicherheitsdienste aktiviert wurden, was während der Einrichtung schiefging und was du gelernt hast, indem du diese Probleme selbst gelöst hast.
— Zima
Active_Learner05 im Porträt
Active_Learner05 beschreibt sich selbst als Allrounder mit Erfahrungen in Kunst, Spieleentwicklung, Weltraummissionen, Amateurfunk und Programmierung. Obwohl er sich aus gesundheitlichen Gründen aus der klassischen Arbeitswelt zurückgezogen hat, ist er weiterhin kreativ tätig: Er schreibt, veröffentlicht Bücher, verkauft digitale Produkte und erkundet neue technische Projekte.
Diese Neugier führte dazu, dass zwei ZimaBoard 2 1664-Systeme Teil seines Setups wurden. Eines davon wurde zu einer dedizierten Sicherheits-Appliance für das Heimnetzwerk auf Basis von OPNsense. Das zweite schlug mit einer eGPU und einer älteren RTX 4060 Ti für Ollama, Plex, IT Tools und andere Experimente eine völlig andere Richtung ein. In dieser Geschichte geht es um das erste Board: darum, wie er es in die Firewall und den Router im Zentrum seines Heimnetzwerks verwandelte.
Du kannst Active_Learner05 auf Reddit folgen, um die Weiterentwicklung des Projekts über diese Seite hinaus zu verfolgen.
Warum ZimaBoard 2 zur Firewall-Plattform wurde
Die Entscheidung begann mit den technischen Daten des ZimaBoard 2 1664 und nicht mit einer einzigen, von Anfang an festgelegten Anwendung. Active_Learner05 wollte Hardware, mit der er sein vorhandenes Wissen anwenden und gleichzeitig in den Bereichen Netzwerk, Sicherheit zu Hause, Programmierung, Produktivität und anderen selbst gehosteten Anwendungen weiterlernen konnte.
Für das Firewall-Projekt bedeutete das, das Board als dedizierten OPNsense-Host zu verwenden, anstatt ZimaOS als primäres Betriebssystem beizubehalten. Seine veröffentlichte Konfiguration umfasst einen Intel-N150-Prozessor, 16 GB Arbeitsspeicher, eine 500-GB-Crucial-SSD und einen OPNsense-Stack mit Suricata, Unbound, Zenarmor und CrowdSec.
OPNsense auf einer SATA-SSD installieren
Der erste Start selbst verlief unkompliziert. Active_Learner05 beschrieb das Board als einfach in Betrieb zu nehmen und nahezu Plug-and-Play, doch die Installation von OPNsense brachte den ersten echten Lernschritt mit sich.
Er wollte OPNsense von einer SATA-SSD ausführen, statt weiterhin einfach das werkseitige System auf dem internen eMMC zu verwenden. Dafür musste die Boot-Konfiguration geändert werden, damit die externe SSD zum bevorzugten Datenträger für das Betriebssystem wurde. In seinem Reddit-Baubericht dokumentierte er die Installation der werkseitigen Wiederherstellungsumgebung von ZimaBoard für den Notfallzugriff, die Erstellung eines OPNsense-Installationsmediums und anschließend die Installation von OPNsense per USB auf der SSD.
Nach der Installation lautete seine bevorzugte Bootreihenfolge:
1. SSD
2. CasaOS-Wiederherstellungsumgebung
Das entspricht auch der Wiederherstellungsdokumentation von ZimaSpace, die darauf hinweist, dass bei Systemen, die auf einem externen Datenträger installiert wurden, möglicherweise die BIOS-Bootreihenfolge oder das Bootgerät geändert werden muss. Der Leitfaden zur werkseitigen Wiederherstellung von ZimaBoard beschreibt den offiziellen Wiederherstellungsweg, während der OPNsense-Installationsleitfaden die Firewall-Installation selbst erläutert.
WAN, LAN und die zusätzlichen Schnittstellen zuweisen
Nach der Installation von OPNsense bestand der nächste Schritt darin, die Ethernet-Ports in eine echte Routing-Struktur zu überführen, anstatt einfach Kabel anzuschließen und darauf zu hoffen, dass die Standardeinstellungen zur gewünschten Topologie passten.
Active_Learner05 dokumentierte zunächst die Zuweisung von WAN und LAN, fügte anschließend die übrigen Schnittstellen hinzu und konfigurierte zusätzliche Ports als OPT1 und OPT2. Dadurch konnte die Firewall verschiedene Aufgabenbereiche voneinander trennen, statt jeden Port als Teil eines einzigen flachen Netzwerks zu behandeln.
Die Komponenten auf der Upstream- und Downstream-Seite waren bewusst einfach gehalten. Ein ASUS-Gaming-Router wurde ohne Zurücksetzen auf die Werkseinstellungen in einen Access Point umgewandelt, während ein Plug-and-Play-2,5-GbE-Switch vom Typ D-Link DMS-105 die kabelgebundene Verteilung übernahm. ZimaBoard 2 befand sich zwischen diesen Komponenten und war für Routing, Firewall-Regeln, DNS und Netzwerksicherheitsdienste zuständig.
Den Sicherheits-Stack rund um OPNsense aufbauen
Der Datenverkehr von WAN zu LAN war erst der Anfang. Der interessantere Teil des Aufbaus war der Sicherheits-Stack, den Active_Learner05 auf OPNsense aufsetzte.
Unbound übernahm die DNS-Auflösung. Suricata ergänzte Funktionen zur Angriffserkennung und Datenverkehrsanalyse. Zenarmor lieferte anwendungsbezogene Einblicke und Berichte zum Netzwerkverkehr. CrowdSec fügte eine weitere Ebene zur Erkennung und Abwehr schädlichen Verhaltens hinzu.
Diese Kombination machte ZimaBoard 2 zu mehr als einem Ersatz für einen ISP-Router. Es wurde zu einem System, das er aktiv untersuchen konnte: Dienste ließen sich überprüfen, die Ressourcennutzung beobachten und das Netzwerkverhalten erkunden, statt es hinter einer vereinfachten Benutzeroberfläche eines Consumer-Routers zu verbergen.
Was er bei der ersten Einrichtung gelernt hat
Das Projekt verlief nicht völlig reibungslos, und genau das macht die Geschichte nützlich. Eine Herausforderung bestand darin, den standardmäßigen eMMC-Bootpfad zu verlassen, damit OPNsense auf der SATA-SSD betrieben werden konnte. Eine weitere trat bei einem separaten PCIe-Experiment auf: Ein Verlängerungskabel, das mit einer OCuLink-Karte verwendet wurde, funktionierte nicht wie erwartet. Daraus schloss er, dass die Kabellänge oder die Kompatibilität eine zuverlässige Datenübertragung verhinderte.
Bei der Firewall selbst berichtete er später, dass sich die Speichernutzung je nach Aktivität von ungefähr niedrigen 40 Prozent auf niedrige 80 Prozent erhöhte; die CPU-Auslastung erreichte seinen damaligen Beobachtungen zufolge Spitzenwerte von etwa 50 Prozent. Außerdem bemerkte er, dass das Board unter der Sicherheitslast wärmer wurde, und ergänzte einen älteren temperaturgesteuerten 80-mm-Lüfter von AC Infinity, der die Temperaturen nach seiner Aussage verbesserte.
Diese Details sind wichtig, weil sie die Seite von einer sauberen Installationszusammenfassung in eine echte Homelab-Geschichte verwandeln: Das System funktionierte, doch der Prozess erforderte weiterhin, das Zusammenspiel von Bootgeräten, Schnittstellenzuweisungen, Plugins, Temperaturen und Erweiterungshardware zu verstehen.
Vom Consumer-Router zu einem überprüfbaren Netzwerk
Die praktische Veränderung im Alltag bestand nicht einfach darin, einen Router durch einen anderen zu ersetzen. OPNsense gab Active_Learner05 ein Netzwerk, das er untersuchen konnte.
Der Access Point konnte sich auf WLAN konzentrieren. Der 2,5-GbE-Switch konnte die Verteilung übernehmen. ZimaBoard 2 konnte sich auf Routing und Sicherheit konzentrieren. Innerhalb von OPNsense ließen sich DNS, Firewall-Dienste, Verkehrsüberwachung, Angriffserkennung und CrowdSec unabhängig voneinander überwachen, statt in einer undurchsichtigen Appliance gebündelt zu sein.
Diese Trennung entsprach auch seinem ursprünglichen Grund für den Kauf der Hardware: die technischen Daten als Möglichkeit zu nutzen, vorhandenes Wissen anzuwenden und weiterzulernen. Die Firewall war nicht das Ende des Experiments, sondern eines der deutlichsten Beispiele dafür, wie ein universelles x86-Board zu einer spezialisierten Netzwerk-Appliance werden kann.
Zwei ZimaBoard-2-Systeme, zwei unterschiedliche Richtungen
Das OPNsense-System ist nur eine Seite des Setups von Active_Learner05. Sein zweites ZimaBoard 2 1664 schlug den entgegengesetzten Weg ein und wurde mit einer externen GPU und einer RTX 4060 Ti für Ollama, GPU-beschleunigtes Plex, IT Tools und weitere Experimente kombiniert.
Dieser Kontrast erklärt seinen Ansatz zu ZimaBoard 2. Er kaufte nicht zwei identische Geräte, um zwei identische Aufgaben auszuführen. Eines wurde zur Netzwerkinfrastruktur, das andere zu einer Plattform für GPU-, Medien- und KI-Experimente. Das verbindende Element ist die Bereitschaft zum Ausprobieren.
Die Geschichte wird weitergeschrieben
Die Geschichte von Active_Learner05 und Zima wird weitergeschrieben. Er beschrieb sich als noch unerfahren im Umgang mit Einplatinencomputern und weiterhin neugierig darauf, was die Hardware leisten kann. Damit ist diese OPNsense-Firewall weniger ein fertiger Endpunkt als vielmehr sein erstes ernsthaftes Netzwerkprojekt auf Basis des Boards.
Sein Rat an zukünftige Nutzer war in einem Satz zusammengefasst: „Ausprobieren und erkunden.“ Die vollständige Diskussion zur Firewall, die sich noch in der Entwicklung befindet, findest du im ursprünglichen ZimaBoard-2-OPNsense-Aufbau auf Reddit. Du kannst außerdem Active_Learner05 auf Reddit folgen, während das Projekt weiter wächst.
