Cover

Leseprobe

Der OPNsense-Praktiker

Markus Stubbig

Der OPNsense-Praktiker

Texte: Markus Stubbig
Verlag: BookRix GmbH & Co. KG
4., aktualisierte Auflage 2023
$Revision: 1.32 $
$Date: 2023/04/06 14:11:15 $

Das Werk, einschließlich seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung ist ohne Zustimmung des Verlages und des Autors unzulässig. Dies gilt insbesondere für die elektronische oder sonstige Vervielfältigung, Übersetzung, Verbreitung und öffentliche Zugänglichmachung.

Vorwort

OPNsense ist zu einer festen Größe in der Welt der Firewalls geworden. In den Magic Quadrant von Gartner hat es freilich noch nicht gereicht, was aber der Beliebtheit in der Open-Source-Community keinen Abriss macht. Und auch die im Webshop verfügbare Hardware wächst langsam zu einem ansehnlichen Portfolio.
Aber: Was nützt eine OPNsense-Firewall am Internetzugang, wenn fast der gesamte Datenverkehr verschlüsselt wird? Kaum eine Webseite arbeitet ohne HTTPS und die Firewall erkennt den Inhalt der Datenkommunikation nicht. Auch dafür hat OPNsense eine Lösung, die sich über Kapitel 14 erstreckt: Die Firewall entschlüsselt die IP-Pakete, scannt deren Inhalt auf Viren und bösartige Webseiten und leitet die Pakete dann verschlüsselt an den Empfänger weiter. Ohne teure Abonnements und sogar im Heimnetz nutzbar.
Für Experimentierfreudige lohnt sich ein Blick in die ständig wachsende Liste der Plug-ins. Hier tauchen Features auf, die die Entwickler nicht mit der Basissoftware ausliefern, die aber irgendwie in den Arbeitsbereich einer Firewall fallen: dynamisches Routing, WireGuard, diverse Proxys und über siebzig weitere offizielle Erweiterungen.
Bei dieser Vielfalt sind auch doppelte Funktionen dabei. Wer einen DNS-Dienst benötigt, hat die Wahl zwischen Unbound und DNSmasq. Bei VPN wird es noch bunter: OpenVPN, IPsec, WireGuard oder OpenConnect?
Für die Entscheidungsfindung und weitere Tüfteleien wünsche ich: Viel Spaß beim Ausprobieren und Staunen.

Vorwort der dritten Auflage

OPNsense wird 6 Jahre alt und langsam erwachsen. Keine Streiterei mit dem Codespender pfSense, aber dafür viele Maßnahmen für die eigene Sicherheit. Ganz nebenbei wird die Weboberfläche zum Linguisten und beherrscht mittlerweile zehn Sprachen.
Auch die Popularität wächst stetig: Ernsthafte Computer-Magazine berichten über die Firewall und auch große Systemhäuser stellen sich hinter OPNsense. In Google Trends nähert sich OPNsense immer mehr seiner Vorgängerin.
Diesem Erfolg ist die vorliegende dritte Auflage geschuldet. Alle Kapitel sind mit der Version 21.1 getestet. Wenig überraschend sind viele Einschränkungen weggefallen, denn die Entwickler von OPNsense bleiben am Ball und reagieren auf Sicherheitslücken in kürzester Zeit.

Erneut wünsche ich: Viel Spaß beim Ausprobieren, Staunen und Fluchen.

Vorwort der ersten und zweiten Auflage

OPNsense begann ihre Karriere als zickige, kleine Schwester von pfSense, die alles besser können wollte: besserer Code, bessere Sicherheit, bessere Lizenzierung, bessere Ziele – und mehr Open Source als bei den Geschwistern!
Mit dieser Angeberei spaltet sich OPNsense 2014 von pfSense ab. Unter der Haube beginnen die Entwickler mit einem Frühjahrsputz im pfSense-Quellcode. Hübsch aufgeräumt, und mit moderner Web-GUI präsentiert sich OPNsense Anfang 2015 mit ihrer ersten Version, vom Funktionsumfang hat sich nichts merklich verändert.

Wie hat es OPNsense dann tatsächlich noch über die Straße geschafft und seine ersten Fans gefunden? Gut strukturierter und dokumentierter Programmcode ist scheinbar doch ein wichtiges Merkmal für eine quelloffene Firewall! Und mehrere Security-Promis haben sich öffentlich für OPNsense ausgesprochen, allen voran der Hauptentwickler von monowall.
Vermutlich hat sich jeder pfSense-Admin schon einmal kurz OPNsense angeschaut und innerlich die Unterschiede verglichen. Das Webinterface, als Aushängeschild einer guten Konfigurationsoberfläche, überzeugt im Responsive Design, und die bekannten Features von pfSense zeigen sich hinter den aufklappbaren Menüs. Ein positiver Gesamteindruck bleibt.

Der nächste Schritt liegt gebunden oder als E-Book vor Ihnen: Denn dieses Buch will Ihnen die Arbeitsweise von OPNsense erklären und die Neuerungen vorführen, die mit dieser Open-Source-Firewall möglich sind.

Viel Spaß beim Ausprobieren, Staunen und Fluchen.

Übersicht

Teil 1, Für Einsteiger, beginnt mit dem Aufbau der Netzwerk-Umgebung mit physischen Geräten oder auf einer virtuellen Plattform. Die erstellten Maschinen erhalten ihr Betriebssystem und eine erste Konfiguration. Anschließend gesellen sich die grundlegenden Funktionen, Routing und IPv6 dazu.

In Teil 2, Für Fortgeschrittene, bekommen die Firewalls ernsthafte Aufgaben, die in jedem Netzwerk erfüllt sein müssen. Als Paketfilter und Adressumsetzer verbindet und trennt OPNsense seine angeschlossenen Subnetze.

Teil 3, Für Experten, taucht in Enterprise-Themen ein und baut standortverbindende VPN-Tunnel und Firewall-Cluster zur Verfügbarkeitssteigerung. Für tiefere Einsicht in die Masse der Datenverbindungen ist das gute, alte NetFlow im Gepäck. Und der Proxyserver kann sogar in TLS-Verbindungen hineinschnüffeln.

Auch außerhalb der Laborumgebung macht OPNsense in Teil 4, Für Praktiker, eine gute Figur als DSL-Router, Lastverteiler für mehrere Internetleitungen und als Sheriff für Einbruchsdelikte.

Teil 5, Für Trickser, zeigt viele kleine Handgriffe, die die tägliche Arbeit mit OPNsense reibungsfreier gestalten. Danach wandert die Konfigurationsdatei in die Cloud und landet revisionssicher bei Dropbox oder Google Drive. Und zuletzt kommt die Programmierschnittstelle von OPNsense auf den Prüfstand.

Ressourcen

https://opnsense.org
Die Homepage von OPNsense liefert einen guten Einstieg ins Thema und verlinkt zur Dokumentation, zum Forum und zum Download-Bereich.

https://github.com/opnsense
Die Entwickler hosten den Programmcode bei GitHub, wo jeder Einblick in den Fortschritt hat und sich an den Quellen bedienen kann. Daneben gibt es die Build-Tools und Anleitungen zum Selber-Kompilieren.

https://docs.opnsense.org/
OPNsense zum Nachlesen: Handbücher für Anwender und Entwickler, Schritt-für-Schritt-Anleitungen und How-To’s mit vielen Screenshots. Fast so umfangreich wie ein ganzes Buch.

https://forum.opnsense.org/
Das Forum ist die erste Anlaufstelle für kleine Tutorials, Diskussionen und Support aus der Community. Überraschend viele Beiträge werden in deutscher Sprache geführt.

Rechtliches

Warennamen und Bezeichnungen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Es ist davon auszugehen, dass viele der Warennamen gleichzeitig eingetragene Warenzeichen oder als solche zu betrachten sind.
Bei der Zusammenstellung von Texten, Bildern und Daten wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Der Autor lehnt daher jede juristische Verantwortung oder Haftung ab. Für Verbesserungsvorschläge und Hinweise auf Fehler ist der Verfasser dankbar.

Einleitung

OPNsense ist ein quelloffenes Netzwerk-Betriebssystem für Router und Firewalls. Es basiert auf FreeBSD-Unix und vereint Applikationen wie Squid, pf, StrongSwan und OpenVPN unter einer einheitlichen Weboberfläche. OPNsense läuft auf physischer Hardware, als virtuelle Maschine oder in der Cloud.
Zu den berühmten Namen gehört OPNsense noch nicht. Eher unbekannt punktet es in den Bereichen Funktionalität und Bedienung. OPNsense verbindet den Charme von Unix mit dem Funktionsumfang einer professionellen Firewall bei geringster Budgetanforderung.


OPNsense ist:

Unvollkommen.

Und das ist positiv gemeint. Es gibt noch genug Raum zum Wachsen. Auch die Implementierung von Features ist teilweise eigenartig: Das provider-orientierte QinQ-Tagging und VXLAN sind dabei, bei IPv6 besteht allerdings noch Nachholbedarf.

Open Source.

Der Vorteil einer quelloffenen Lösung ist nicht immer ihr Preis. Denn wirklich umsonst ist Open-Source-Software auch nicht! Lizenzgebühren fallen zwar nicht an, aber die Zeit der IT-Abteilung zum Einrichten einer wenig dokumentierten Software ohne Herstellersupport darf nicht unterschätzt werden.
Bis heute stehen die unbewiesenen Vermutungen im Raum, dass der US-Geheimdienst NSA Hintertüren in die Sicherheitssoftware von namhaften Herstellern einbauen lässt. Als Endkunde lässt sich das nicht überprüfen, aber es bleibt eine Spur von Zweifeln, wenn diese Geräte im eigenen Netz zum Einsatz kommen.
In Open-Source-Produkten können sich Sicherheitsexperten austoben und haben eine realistische Chance den Schadcode zu finden. Andersherum ist es für Hersteller auch deutlich schwieriger eine Hintertür im Quellcode zu verstecken, wenn dieser für jedermann offen zugänglich ist.

Try before Buy.

Wie bei Shareware-Programmen kann (und sollte) OPNsense vor dem Einsatz getestet werden, bevor irgendwelche Investitionen in die Infrastruktur beginnen. Und wer freut sich über einen eingeschränkten Funktionsumfang, eine Evaluierungslizenz oder einen 30-Tage-Zeitraum?
In diesem Zusammenhang steht Try für Ausprobieren mit Beispielszenarien und Buy für den Einsatz in der eigenen Umgebung.

Hardware-frei.

OPNsense ist Software. Diese Software braucht Hardware. Aber die Wahl der Hardware oder einer virtuellen Umgebung bleibt offen. Das macht eine sichere Kaufentscheidung schwierig. Welche Komponenten sind notwendig, um beispielsweise eine 34 Mbit/s-Leitung mit einem VPN-Tunnel und starker Verschlüsselung zu sättigen?
In der Vergangenheit gab es viele limitierende Gründe, warum eine softwarebasierte Lösung für Netzwerkinfrastruktur nicht an die Leistung der physischen Geräte herankam. Der Hauptgrund war das suboptimale Zusammenspiel von Software und Treiber mit der darunterliegenden Hardware. Bei der immens großen Auswahl von Netzwerkkarten, Mainboards, Prozessoren und Memory ist es für eine Software schwierig auf jede Kombination der Komponenten optimal vorbereitet zu sein.
Heutzutage sind normale Server oder eingebettete Systeme überraschend performant, sodass auch eine nicht-optimierte Software bei kleiner Paketgröße Bandbreiten jenseits der 100 Mbit/s durchbrechen kann.
Die Hardware-Frage klärt das Unternehmen Deciso [1] mit ihren Netboards A10, A20 und der DEC-Produktreihe. Anpassung, Optimierung und Marketing machen daraus mittlerweile ansehnliche Firewallappliances.

Unix.

Unter OPNsense läuft ein angepasstes FreeBSD. Der Zugriff auf das Betriebssystem ist möglich, aber passwortgeschützt. Über das Konsolenmenü oder eine SSH-Verbindung liegt der Zugang offen. Das bringt Möglichkeiten zum Anpassen, Verbessern und Nachinstallieren von Tools. Dagegen steht die Gefahr, dass die eigene Änderung ungewollte Instabilität mitbringt.

Best Of.

OPNsense erfindet das Rad nicht neu und bedient sich für seine Features bei den vertrauten Unix- und Linux-Diensten, die nach Jahren der Entwicklung eine hohe Stabilität erreicht haben. Der Web-Proxy stammt von Squid, der SSH-Server gehört zu OpenSSH und für die Umsetzung der Firewallregeln hilft der Paketfilter pf von BSD.
Diebstahl? Keineswegs! Eher ein Nachweis, dass Open Source funktioniert. Solange Lizenzbedingungen eingehalten werden, darf Fremdsoftware beigemischt werden. Gerade im Security-Umfeld ist es höchst erwünscht, dass Anwendungsentwickler keine eigenen Implementierungen stricken, sondern sich an den freien und stabilen Bibliotheken bedienen.

Geschichte

Die Historie von OPNsense ist eng verbunden mit monowall und pfSense. Anfang 2003 startet monowall als Firewall und nutzt FreeBSD als Betriebssystem. Im folgenden Jahr spaltet sich pfSense von monowall ab, mit dem klaren Ziel es besser zu machen als das Original. Das funktioniert auch soweit gut, denn im Jahr 2006 überholt pfSense seinen Vorgänger in Funktion und Popularität.
Das Konzept und die Entwicklung von pfSense sind relativ erfolgreich, denn in den darauffolgenden Jahren bringen die Entwickler eine Version nach der anderen heraus.
Der Wettstreit endet scheinbar im Januar 2014, als monowall ihre letzte stabile Version veröffentlicht. Das offizielle Ende des Projekts zieht sich noch bis Februar 2015, als der Anbieter auf seiner Webseite die Entwicklung von monowall offiziell einstellt.
Später in 2014 möchte das US-amerikanische Unternehmen Electric Sheep Fencing LLC kommerziellen Support für pfSense anbieten und übernimmt die Firewalldistribution. Die damit verbundene Lizenzänderung macht es Entwicklern schwerer, an den Quellcode zu gelangen.
Unzufrieden mit der politischen Entwicklung von pfSense und dem Untergang von monowall, beginnen niederländische und deutsche Entwickler ihre Firewalldistribution als Derivat von pfSense. Als Hauptgründe führen sie Codequalität, Sicherheit und Transparenz an, dicht gefolgt von dem Wunsch, die Meinung und Beiträge der Community einfließen zu lassen. Der Name OPNsense soll an den Ursprung in pfSense erinnern.
Die erste Version von OPNsense im Januar 2015 ist äußerlich pfSense in einem schicken Anzug. Die markanten Änderungen finden unter der Oberfläche statt und ersetzen Version für Version den pfSense-Code durch Entwicklungsarbeit von OPNsense. Heute (2023) haben die beiden Firewalls kaum noch gemeinsame Programmzeilen.
OPNsense bringt die Versionssprünge im Halbjahresrhythmus. Diese Planungssicherheit kommt in der Community gut an, wobei wichtige Sicherheitsupdates auch zwischendurch erscheinen und nicht bis zum nächsten Major-Release warten müssen.

OPNsense und pfSense konkurrieren mit ähnlichen Zielen um das Vertrauen ihrer Anwender. Wer das Rennen gewinnt, ist noch offen: OPNsense mit frischem Schwung und neuen Ansätzen oder pfSense mit langjährigem Vertrauen, Stabilität und Bekanntheit.
Bei Google Trends ist eine Annäherung schon deutlich erkennbar: pfSense von oben und OPNsense von unten. Ein Schnittpunkt ist noch nicht erreicht, aber absehbar.

Kapitel 1: Quickstart

Das erste Kapitel gibt eine kurze Einführung in die OPNsense-Firewall, führt durch das Webinterface und zeigt das Login, den Systemstatus und die Netzadapter.

Was ist OPNsense?

Die OPNsense-Firewall ist ein Sicherheitsprodukt zur Absicherung von Netzwerken. Es besteht aus Software, die auf Computern mit x86_64-Prozessor lauffähig ist. Sie basiert auf dem Unix-Derivat FreeBSD und stellt dem Administrator alle Sicherheitsfunktionen über eine Webseite zur Verfügung. Für die Ersteinrichtung und die Fehlersuche kommen zusätzlich eine Kommandozeile dazu.

Die bereitgestellte Software ist unabhängig von einem physischen Gerät. Damit ermöglicht der Anbieter den Einsatz der OPNsense-Firewall auf eigener Hardware oder als virtuelle Maschine.

IP-Adresse

Eine frisch installierte Firewall bindet stets die IPv4-Adresse 192.168.1.1 an den ersten Netzadapter. Damit ist eine Netzverbindung auch dann möglich, wenn keine Konsole für die Ersteinrichtung vorhanden ist. Eine Default-Route ist nicht gesetzt, sodass die Verbindung aus demselben IP-Netz stammen muss.
Ein Client aus dem IP-Netz der Firewall kann ihre Adresse in einem Webbrowser eintippen und erhält ein Login und anschließend den Dialog für die Ersteinrichtung aus Abbildung 1.1.

Einrichtung

Die Weboberfläche eröffnet den Zugang zur OPNsense-Firewall. Der Webdienst ist standardmäßig verschlüsselt und erreichbar unter:
https://192.168.1.1/
Eine brandneue Firewall begrüßt den Benutzer mit einem Installationsdialog, der nach Hostnamen, IP-Adressen und Admin-Passwort fragt und daraus die Konfiguration erstellt. Am Ende der Fragestunde aktiviert OPNsense die gewählten Einstellungen und verlinkt auf das Dashboard aus Abbildung 1.2.


Auf der Kommandozeile ermöglicht die Firewall ein Login per Secure Shell (SSH). Die Zugangsdaten sind dieselben wie für die Weboberfläche. Der SSH-Zugang ist anfangs inaktiv und muss einmalig eingeschaltet werden (siehe Kapitel 5).

Übersicht

Die Weboberfläche der OPNsense-Firewall empfängt den eingeloggten Administrator mit dem Dashboard. Dieses besteht aus einem Steckbrief des lokalen Systems: Hostname, Version, Speicherauslastung und eine Liste der Netzadapter.
Die Menüstruktur unterteilt sich in:

  • Berichterstattung. Hier befinden sich Echtzeit- und historische Informationen zum Datendurchsatz der lokalen Firewall.

  • System. Die administrativen Einstellungen wie Zeitzone, SSH-Zugang, Benachrichtigung, Routing, Sicherung und Update befinden sich in dieser Rubrik.

  • Schnittstellen. Hier lassen sich die Netzadapter einrichten und mit IP-Adressen versehen. Das gilt für physische Adapter sowie für Netzbrücken, Tunneladapter und Wireless-NICs.

  • Firewall. In diesem Bereich entstehen die Richtlinien für den Paketfilter, Adressumsetzung, Traffic-Shaping und das Logging.

  • VPN. Die Einstellungen für Virtuelle Private Netze (VPN) finden sich in dieser Abteilung.

  • Dienste. Die Konfiguration von netzwerknahen Diensten wie DHCP, DNS, NTP und Einbruchserkennung sammeln sich in dieser Kategorie.

  • Energie. In diesem Bereich lässt sich das System neu starten oder abschalten.

Die Menüs erweitern sich um zusätzliche Einträge, wenn Plug-ins installiert sind.

Zusammenfassung

Die OPNsense-Firewall lässt sich nicht in fünf Minuten erklären, aber für einen kurzen Einstieg reicht es. Im Kern läuft das Betriebssystem FreeBSD, das eine IP-Adresse im Netz benutzt und einen Webzugang für die Administration bietet. Ein Assistent stellt die üblichen Fragen einer Ersteinrichtung und erledigt die Konfiguration. Nach erfolgreichem Login präsentiert die Weboberfläche den Systemstatus und die Auslastung der Hardware.

Kapitel 2: Labornetzwerk

Vor dem Einstieg in den Umgang mit OPNsense steht der Aufbau des Labornetzwerks, denn eine einzelne Firewall ohne umgebendes Netzwerk ist wenig beeindruckend. Für den praxisnahen Einstieg erwacht OPNsense in einem konstruierten Labornetz zum Leben. In dieser Umgebung kann OPNsense Kapitel für Kapitel mit seinen Fähigkeiten glänzen.

Alle Themen der Kapitel haben einen praktischen Hintergrund. Theoretische Grundlagen werden nur am Anfang eines Kapitels angesprochen, um Verständnis aufzubauen oder angestaubtes Wissen aufzufrischen. Die Beispiele und Übungen sind zum Nachspielen konzipiert.
Die Kapitel basieren alle auf demselben Netzaufbau. Es stellt ein kleines Firmennetz mit zwei Standorten und redundanten WAN-Verbindungen dar. Je nach Komplexität eines Themas reicht ein Teil des Labornetzwerks aus, um die Kernaussage zu beschreiben.
Wenn ein Kapitel einen gesonderten Aufbau benötigt oder ein weiteres Gerät untersucht werden soll, gibt es am Anfang der Lektion einen entsprechenden Hinweis mit Erklärung.

Ressourcen

Der stets unveränderte Aufbau des Labornetzes hat den charmanten Vorteil, dass zwischen den Kapiteln nicht umgebaut werden muss. Kein Umverkabeln der Geräte oder Umkonfigurieren der virtuellen Umgebung. Das spart Zeit und verhindert Fehler. Und nach ein paar Kapiteln wird das Labornetz zum vertrauten Begleiter, denn die Namen der Firewalls, Clients, Netzschnittstellen und IP-Adressen bleiben unverändert.
Das vollständige Labornetz ist als Netzdiagramm in Abbildung 2.1 dargestellt. In den folgenden Kapiteln werden meist nur Teile dieses Netzwerks zur Untersuchung benutzt.


Da ein händischer Eingriff nach dem ersten Aufbau nicht mehr notwendig ist, kann das Lab auch “aus der Ferne” betrieben werden – Remotezugriff vorausgesetzt.

Die erforderliche Hardware ist stets abhängig vom geplanten Durchsatz – je mehr Arbeitsspeicher, CPU-Kerne und Festplatte, desto höhere Bandbreiten und Anwenderzahlen wird die Firewall stemmen können.
Die offiziellen Angaben für Arbeitsspeicher und Festplattengröße berücksichtigen Bandbreite und eingesetzte Features. Mit den Minimalanforderungen ist es möglich, das Lab auf dem eigenen Laptop zu starten oder preisgünstig in Hardware nachzubauen. Beispielsweise nutzt eine OPNsense-Firewall gerade mal 2 GByte Arbeitsspeicher mit einer 4 GByte großen Festplatte.

Mehr CPU, Memory und Festplatte geht immer. Tabelle 2.1 gibt die weiteren Leistungsstufen für eine Implementierung an. Die Angaben orientieren sich an der offiziellen Dokumentation [2].


Manche Kapitel arbeiten isoliert, andere benötigen Internetzugriff. Der Zugang zum Internet läuft stets über die Firewall RT-core im Kernnetz, welche hinter ihrer Netzkarte em0 das Internet erwartet. Ganz praktisch passiert das in einer virtuellen Umgebung über eine NAT-Schnittstelle. Andernfalls reicht ein Uplink zum DSL-Router. Hierbei ist alles möglich, was letztendlich ins Internet führt.

Virtualisierung

Alle Geräte im Lab können vollständig virtualisiert werden. Jede Firewall im Labornetz ist dann eine eigene virtuelle Maschine (VM) mit virtuellen Netzwerkkabeln zu den benachbarten VMs. Die Verbindungsnetze zwischen den VMs sind VMnetX (bei VMware) und vboxnetX (bei VirtualBox). Eine physische Netzwerkkarte im Hostsystem ist nötig, wenn mit echter Hardware gemischt wird. Welches Interface in welchem virtuellen Netz zu Hause ist zeigt Tabelle 2.2.


Das Netzsegment Management ermöglicht später die Verwaltung der Firewalls. Hierfür eignen sich die Verbindungstypen Netzbrücke oder Host-only. Im gebrückten Modus ist die VM über den physischen Netzadapter des Hosts im umliegenden Netzwerk erreichbar. Im Host-only-Modus ist die VM nur für den Host (und andere VMs auf demselben Host) zugänglich.
Technisch nicht erforderlich, aber hilfreich zum Auswerten: Die Netzwerkkarten der VMs verwenden vordefinierte MAC-Adressen. Damit sind alle Geräte in den Kommandoausgaben eindeutig erkennbar und mit den Beispielen im Buch vergleichbar.
Getestet und geprüft sind die Labs mit VMware Workstation 17, VMware ESXi 8 und VirtualBox 7.

Hardware

OPNsense läuft grundsätzlich auf Geräten mit einem x86_64-Prozessor. Der Typ der Netzwerkkarte ist unwichtig, da das Labornetz Verständnis bieten soll und nicht Höchstleistung. Bei Unsicherheit über passende Hardware lohnt sich ein Blick in die Kompatibilitätsmatrix von FreeBSD [3].

Netze

Die Netze zwischen den Firewalls basieren auf Ethernet. Jedes Teilnetz ist eine eigene Broadcast-Domäne. Bei der Verkabelung ist es also wichtig, dass sich die Kabel verschiedener Netzsegmente nicht vermischen.
Für die korrekte Trennung gibt es zwei gängige Methoden:

Trennung mit Switches

Jedes Netzsegment hat seinen eigenen Switch oder Hub. Die Switches sind untereinander nicht verbunden.
Da die Subnetze eher klein sind, reichen 5-Port-Geräte aus. Ein beliebiger Switch ist dafür passend.

Trennung mit VLANs

Alle Kabel führen zum selben Switch. Kabel bzw. Switchports, die zum selben Netzsegment gehören, landen in einem gemeinsamen virtuellen LAN (VLAN). So erhalten beispielsweise alle Switchports zum/vom WAN-2-Kernnetz die Zuordnung zu VLAN 6.
Da alle Firewalls mit allen Anschlüssen mit diesem Switch verkabelt sind, muss es ein Modell mit ausreichend vielen Ports sein. Der Switch muss kein Routing zwischen den VLANs beherrschen. Ein VLAN-fähiger Layer-2-Switch ist ausreichend.
Ein Mischbetrieb ist ebenfalls möglich: Beispielsweise terminieren die WAN-Segmente auf einen Switch und die Standort-Netze auf einen anderen Switch. Die Anforderung an die Geräte entspricht der Methode Trennung mit VLANs.

Firewall

Die OPNsense-Firewalls verwenden die aktuelle, stabile Version 23.1 als 64-Bit-Image. Wenn zusätzliche Versionen oder Geräte anderer Hersteller mitspielen, wird das entsprechende Gerät ersetzt oder das Lab ergänzt.
Jede Firewall hat eine weitere Netzwerkkarte für den Konsolenzugriff. Darüber erreicht der SSH-Client sein Ziel, wenn eine Konfigurationsänderung mal schiefgeht. Dieses Management-Interface kann auch weggelassen werden, wenn die Hardware nicht genug Schnittstellen bietet.
Die Labor-Firewalls sind durchnummeriert. Diese Geräte-Nummer findet sich in den IPv4-, IPv6- und MAC-Adressen wieder. Damit sind Adressen in einer Kommandoausgabe leichter dem passenden Gerät zuzuordnen.
Der Name der Netzkarte ist stets am Gerätesymbol angeschlagen. Die vollständige IPv4-Adresse ist unterhalb davon abgedruckt. Die Angaben zum IPv4-Netz und IPv6-Präfix stehen unweit davon an der Subnetz-Linie.

Adressierung

Die Subnetze der imaginären Außenstellen bauen auf private IPv4-Adressen bzw. Unique-Local IPv6-Adressen. In jedem Standort gibt es einen symbolischen Client, der nur zum Prüfen von Features oder zum Erzeugen von Datenverkehr benutzt wird. Mehr als ping, traceroute, netstat oder einen Webbrowser wird nicht gefordert. Das Betriebssystem ist relativ egal; im Demo-Lab finden aus Popularitätsgründen Debian und Windows Verwendung.
Die zwei standortverbindenden Netze stellen das zentrale Kernnetz dar. Zur besseren Unterscheidung der IP-Adressen bedienen sich die Geräte aus den Adressblöcken für Dokumentation (RFC 5737): 192.0.2.0/24 und 198.51.100.0/24. Die IPv6-Adressen stammen ebenfalls aus unterschiedlichen Bereichen, um eine Unterscheidung optisch zu vereinfachen: Das Präfix fd00::/16 gehört den Standort-LANs und der Bereich 2001:db8::/32 ist für den Kern.
Die Adressen sind genau dafür vorgesehen und kollidieren nicht mit einem öffentlichen Bereich. Weiterhin ist die Adressierung bewusst einfach gehalten: Die Adressbereiche sind einheitlich strukturiert und haben nur “normale” Netzmasken von /24 (IPv4) oder /64 (IPv6).

Zusammengefasst zeigt Tabelle 2.3 die IPv4- und IPv6-Bereiche, die sich hinter den VMnet-Netzen verstecken. Zusätzlich benötigte Adressen (z. B. für PPPoE, Tunnel, CARP) stammen aus denselben Bereichen.

Labor-Server

Alle zentralen Funktionen übernimmt der Labor-Server, der ebenfalls physisch oder virtuell integriert wird. Wenn die OPNsense-Firewall auf ein Client/Server-Protokoll getestet wird, übernimmt der Labserver stets die Rolle des Gegenstücks. Er akzeptiert von den Firewalls Anfragen zu NTP, DNS, Syslog, FTP/TFTP, NetFlow und HTTP. Der eingesetzte Labserver setzt auf Debian 11.

Verwendung

Jedes Kapitel verwendet nur einen Teil des Labornetzwerks. Weniger Geräte ermöglichen eine bessere Kontrolle, wenn es an die Beispiele und Kommandoausgaben geht. Diese Limitierung dient nur der Übersicht – gerne dürfen weitere Firewalls zugeschaltet werden, um Features intensiver zu testen.
Die IP-Adressen bleiben stets dieselben, wenn auch mit anderer Bedeutung.

Kapitel 3: Plattform

Im nächsten Schritt geht es an die Verwirklichung des Labors. Es beginnt mit der Erstellung oder Beschaffung der Geräte, gefolgt von der Installation und zuletzt der Vernetzung.
Wie in Abschnitt Virtualisierung schon angedeutet, kann das Lab auf physischer Hardware laufen oder komplett in einer virtuellen Umgebung sein Zuhause finden. Für den Aufbau macht das einen großen Unterschied – für die Beispielszenarien der folgenden Kapitel ist es irrelevant.
Die Vorgehensweise ist bei allen Methoden einheitlich: Es beginnt mit dem Anlegen der virtuellen Netze, deren Trennung entweder mit einem virtuellen Switch oder einer Portgruppe erfolgt. Danach geht es an das Erstellen der virtuellen Maschinen (VM) und zuletzt erhalten die neuen VMs ihre Netzadapter in den beheimateten VM-Netzen.
Die Wahl der Virtualisierungssoftware hängt von den persönlichen Vorlieben ab. Die folgenden Erklärungen beziehen sich auf VMware ESXi, Workstation und Player sowie auf VirtualBox.

Dieses Kapitel kann kein Fachbuch über VMware oder VirtualBox ersetzen! Die Installation der VMs setzt Grundwissen in den jeweiligen Produkten voraus. Die Beschreibungen behandeln nur den Aufbau der neuen VM und nicht, warum die einzelnen Schritte notwendig oder vorteilhaft sind.

Vorbereitung

Die Installation der Firewall startet von einem Live-Image im ISO-Format. Die Webseite von OPNsense [4] bietet stets das aktuelle Release zum Download an.
Das vorgestellte Labor verwendet Version 23.1 mit dem ISO-Image:

OPNsense-23.1-OpenSSL-dvd-amd64.iso

Bei einem Hardware-Labor muss die ISO-Datei vorab auf eine DVD gebrannt werden oder auf einen USB-Stick kopiert werden. Von diesem Medium kann ein Server oder ein Laptop booten und die Installation beginnen. Geräte mit 32-Bit-Prozessor werden nicht mehr unterstützt – die letzte Version für einen 32-Bit-Prozessor ist 20.1.

VMware

Die Produktpalette von VMware ist groß, aber für das Lab eignen sich hauptsächlich ESXi, Player und Workstation. Die Einrichtung beginnt bei den virtuellen Netzen.

Workstation Pro

VMware Workstation Pro ist eine englischsprachige Softwareanwendung für Windows und Linux, die virtuelle Maschinen trägt.
Die Konfiguration findet im Virtual Network Editor statt. Falls nicht schon vorhanden, werden dort die virtuellen Netze VMnet1 bis VMnet7 angelegt. Alle sind vom Typ Host-Only und verwenden kein DHCP. Die Subnetz-IP ist unbedeutend, da sie im Lab nicht angesprochen wird.
Danach werden die virtuellen Maschinen erstellt. Der Ablauf ist stets derselbe:

  1. VMware Workstation starten

  2. File → New Virtual Machine…

  3. Type of configuration? Custom (advanced)

  4. Hardware compatibility: die Neueste (hier Workstation 17.x)

  5. Installer disk image file (iso): ISO-Datei aus dem vorherigen Abschnitt Vorbereitung auswählen

  6. Virtual machine name: RT-1
    Location: beliebig

  7. Number of processors: 1
    Number of cores per processor: 2

  8. Memory for the virtual machine: 2 GB (oder mehr)

  9. Network connection: Use host-only networking (der Wizard ermöglicht nur eine einzelne Netzwerkkarte, die anderen folgen später)

  10. SCSI Controller: LSI Logic

  11. Virtual disk type: SCSI

  12. Disk: Create a new virtual disk

  13. Maximum disk size (GB): 6
    Store virtual disk as a single file

  14. Disk file: beliebig

  15. Finish

Anschließend wird die frisch erstellte Maschine erst mal entschlackt: Soundkarte, USB-Controller und Druckeranschluss braucht die Firewall nicht, dafür mehr Netzwerkkarten.
Über VM → Settings gibt es Einblick in die Seele der virtuellen Maschine. Hier wird gelöscht und hinzugefügt, bis die Einstellungen passen. Neue Netzwerkadapter sind stets vom Typ Custom, mit einer Zuordnung zum entsprechenden VMnet. Die feste MAC-Adresse versteckt sich bei Network Adapter hinter dem Advanced…-Button.

Die verwendete Version ist VMware Workstation 17.0.0 unter Windows.

Workstation Player

Der VMware Workstation Player ist eine funktionsreduzierte Version der VMware Workstation Pro. Für die nicht-kommerzielle Nutzung ist der Einsatz kostenfrei.
Dialoge und Vorgehensweise ähneln sich, daher gelten die Einstellungen des vorherigen Abschnitts auch hier.
Die Eigenschaften der virtuellen Netze können zwar nicht verändert werden, aber die Voreinstellung ist akzeptabel.
Die Erstellung einer VM startet mit dem Button Create a New Virtual Machine. Danach kommen die Fragen nach dem Installer-Image, Namen und Speicherort der VM und zuletzt die Größe der Festplatte.
Alle weiteren Details werden außerhalb des Wizards angepasst. Auch hier gelten dieselben Parameter wie bei VMware Workstation.

Die Linux-Version des VMware-Players ist für das Demo-Lab ungeeignet, weil das Dialogfenster die Auswahl der VMnet-Netze verschweigt. Alle Host-only-Netzwerkadapter der OPNsense-Firewall sind im selben Netz. Händisches Nachrüsten von VMnet-Netzen und Anpassungen in der .vmx-Datei einer VM bringen keine Besserung.
Die beste Alternative unter Linux ist VirtualBox (siehe Abschnitt VirtualBox).

Die verwendete Version ist VMware Workstation Player 17.0.0 unter Windows.

ESXi

VMware ESXi ist ein Typ-1-Hypervisor. Damit läuft er nicht als Anwendung auf einem Betriebssystem, sondern arbeitet direkt auf der physischen Hardware. Ein grafischer Webclient erstellt und verwaltet die virtuellen Netze und Maschinen. Intern kommunizieren die virtuellen Firewalls über virtuelle Switches miteinander, wie Abbildung 3.1 veranschaulicht [5].


Zuerst wird ein Switch innerhalb der ESXi-Welt angelegt. Dieser Switch trägt später die virtuellen Netze mit einer Segmentierung über VLANs. Das Prinzip entspricht der physischen Umgebung aus dem Abschnitt Hardware in virtueller Form.
Die virtuelle Netzwerkumgebung beginnt im Navigator des Webclients unter Netzwerk im Register Virtuelle Switches. Wenn das Lab gekapselt innerhalb des ESXi arbeiten soll, ist kein physischer Netzadapter nötig. Für alles andere erwartet die folgende Konfiguration die ungenutzte Netzwerkkarte eth1, die bei ESXi als vmnic1 geführt wird.

  • Klick auf Virtuellen Standard-Switch hinzufügen

  • vSwitch-Name: vSwitch1
    Uplink 1: vmnic1 (das ist der unbenutzte Netzadapter im Server. Das Feld kann auch leer gelassen werden, wenn das Lab nicht mit der Außenwelt kommunizieren soll)

  • Klick auf Hinzufügen

Kurz darauf ist der neue Switch vSwitch1 erstellt, hat aber noch keine VLANs oder Ports. VLANs entsprechen bei ESXi einer Portgruppe und werden beim Register Portgruppen erstellt und zugewiesen. Mit dem Button Portgruppe hinzufügen beginnt die Show. Die VLAN-Nummer ist wichtig, wenn die VMs später mit einem physischen Netz kommunizieren sollen. Für das Demo-Lab dienen die VLANs 1401 bis 1407.

  • Name: VMnet1

  • VLAN-ID: 1401

  • Virtueller Switch: vSwitch1

Dieser Schritt ist für die weiteren Netze VMnet2 bis VMnet7 identisch. Anschließend ist die virtuelle Netzlandschaft fertig und sollte der Aufstellung in Abbildung 3.2 ähneln.


Das Szenario zum Anlegen der virtuellen Maschinen beginnt im Navigator unter Virtuelle Maschinen. Der Button VM erstellen/registrieren startet den Wizard. Dieser stellt mehrere Fragen, die wie folgt beantwortet werden:

  1. Erstellungstyp auswählen: Neue virtuelle Maschine erstellen

  2. Namen und Gastbetriebssystem auswählen:

    • Name: RT-1

    • Kompatibilität: Virtuelle ESXi 8.0-Maschine

    • Gastbetriebssystemfamilie: Andere

    • Version des Gastbetriebssystems: FreeBSD 13 (64 Bit)

  3. Speicher auswählen: passenden Datastore wählen

  4. Einstellungen anpassen:

    • CPU: 1

    • Cores pro Socket: 2

    • Arbeitsspeicher: 2 GB

    • Festplatte 1: 6 GB

    • SCSI-Controller 0: LSI Logic Parallel

    • USB-Controller 1: (entfernen)

    • Netzwerkadapter 1: VM Network

    • CD/DVD-Laufwerk 1: Hostgerät

Da OPNsense insgesamt viermal installiert wird, ist es ratsam, die ISO-Datei zuerst in den Datastore des ESXi-Servers zu kopieren und davon zu mounten. Beim CD/DVD-Laufwerk der virtuellen Maschine Datenspeicher-ISO-Datei wählen und über den Dateibrowser die .iso-Datei hochladen und anschließend auswählen. Die neue VM startet dann von diesem DVD-Image. Gebootet wird das Live-System, die Installation folgt in Kapitel 4.

Der fertig gebackenen VM fehlen noch ein paar Netzwerkkarten. Über die Eigenschaften der VM werden diese hinzugefügt und im richtigen VMnet platziert. Tabelle 2.2 listet die Zugehörigkeit von Firewall-Interface zu virtuellem Netzwerk.

Die verwendete Version ist VMware ESXi 8.0.0.

VirtualBox

VirtualBox ist eine Applikation für Windows, Linux und macOS, die virtuelle Maschinen erstellt und hostet.
Bei VirtualBox ist die Produktwelt übersichtlich. VirtualBox hat zwar nicht mehrere Virtualisierungsprodukte im Angebot, aber dafür mehrere Konfigurationsmethoden. Bei der normalen Installation ist der Oracle VM VirtualBox Manager mit im Boot. Er ist leicht zu bedienen, verlangt unter Linux aber nach einer X11-Oberfläche. Alternativ (oder ergänzend) hilft phpVirtualBox [6], ein webbasierter Manager, der das Look-and-Feel des Oracle-Managers im Browser bereitstellt.
Fans der Kommandozeile bekommen ebenfalls etwas geboten, denn der Laboraufbau lässt sich unter VirtualBox komplett skripten.

vboxnet

Auch hier beginnt die Reise beim Anlegen der virtuellen Netze vboxnet1 bis vboxnet7.

Oracle VM VirtualBox Manager

Bei VirtualBox wird die Konfiguration der VMs und der Netze von demselben Programm gesteuert.

  1. Datei → Werkzeuge → Netzwerk-Manager

  2. Symbol Erzeugen für jedes vboxnet anklicken

  3. DHCP-Server für jedes vboxnet ausschalten

phpVirtualBox

Der Anspruch von phpVirtualBox ist die identische Bedienung der VirtualBox-Umgebung. Daher unterscheidet sich die Einrichtung der virtuellen Netze nicht vom Oracle-Manager des vorherigen Abschnitts.

CLI

Für den einmaligen Einsatz erwartet die Kommandozeile viel Tipparbeit. Die Vorgehensweise zwischen Linux und Windows ähnelt sich.

Linux

  1. Log-in im Linux-Hostsystem als vbox-User

  2. Jedes einzelne vboxnet erstellen mit:
    vboxmanage hostonlyif create

Windows

  1. Eingabeaufforderung starten und zum Pfad navigieren:
    cd %ProgramFiles%\Oracle\VirtualBox

  2. Jedes einzelne virtuelle Host-only-Netzwerk erstellen mit:
    vboxmanage.exe hostonlyif create

VirtualBox unter Windows verpasst den neuen Netzadaptern einen Namen vom Typ “VirtualBox Host-Only Ethernet Adapter”, gefolgt von einer laufenden Nummer.

Ob die virtuellen Netze korrekt angelegt sind, kann erst später praktisch überprüft werden.

Virtuelle Maschinen

Jetzt geht es an das Erstellen der virtuellen Maschinen. Der Ablauf ist für alle VMs ähnlich, daher zeigen die Beispiele nur die Schritte vom ersten Gerät.

Oracle VM VirtualBox Manager

Die Einrichtung in der Verwaltungssoftware von VirtualBox erfolgt über einen Wizard. Die folgende Beschreibung passt auch auf phpVirtualBox.

  1. Maschine → Neu…

    • Typ ist BSD, Version ist FreeBSD (64-Bit)

    • Hauptspeicher: 2 GB (oder mehr)

    • Processors: 2

    • Platte: 6 GB (oder mehr)

  2. Nach dem Erstellen der VM sind noch Anpassungen wichtig, damit die Netzadapter in den richtigen Netzen mitspielen (Abbildung 3.3).

    • DVD einhängen mit dem Image aus Abschnitt Vorbereitung

    • Netzwerk

      • Adapter als Host-only Adapter deklarieren

      • Verbinden mit vboxnetX (Linux) oder “VirtualBox Host-Only Ethernet Adapter X” (Windows)

      • Unter Erweitert den Typ Intel PRO/1000 MT Server wählen. Der ist einer der performantesten Netzadapter (vgl. Kap. 20), aber die anderen funktionieren auch.

    • MAC-Adresse anpassen, wenn gewünscht (nicht zwingend notwendig).

    • Vier NICs können über die GUI eingerichtet werden. Alle weiteren (RT-1 hat als einzige VM eine fünfte NIC) über die Kommandozeile, siehe Abschnitt CLI weiter unten.

CLI

Die Einrichtung per Kommandozeile erwartet Befehle, welche den Mausklicks der GUI entsprechen.

  1. Die Reise über den Befehlszeilenweg beginnt beim Anlegen einer virtuellen Maschine am Beispiel von RT-1.

    VBoxManage createvm --name "RT-1" --register
    VBoxManage modifyvm RT-1 --memory 2048
    VBoxManage modifyvm RT-1 --ostype "FreeBSD_64"

  2. DVD-Laufwerk mit eingelegtem DVD-Image aus Abschnitt Vorbereitung.

    VBoxManage storagectl RT-1 --name "IDE Controller" --add ide
    VBoxManage storageattach RT-1 --medium OPNsense-23.1-OpenSSL-dvd-amd64.iso --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive

  3. Festplatte erstellen und verbinden.

    VBoxManage storagectl RT-1 --name "SATA Controller" --add sata
    VBoxManage createhd --filename "RT-1/RT-1.vdi" --size 6144 --format VDI --variant Fixed
    VBoxManage storageattach RT-1 --storagectl "SATA Controller" --medium "RT-1/RT-1.vdi" --port 0 --type hdd

  4. Netzwerkkarte nic5 am Beispiel von RT-1. Diese NIC muss über die CLI angelegt werden, weil die GUI nur vier Karten duldet.

    VBoxManage modifyvm RT-1 --nic5 hostonly
    VBoxManage modifyvm RT-1 --hostonlyadapter5 "vboxnet6"
    VBoxManage modifyvm RT-1 --hostonlyadapter5 "VirtualBox Host-Only Ethernet Adapter #6"
    VBoxManage modifyvm RT-1 --nictype5 82540EM
    VBoxManage modifyvm RT-1 --macaddress5 001516010601

    Die Anweisung in Zeile 2 ist für VirtualBox unter Linux und Zeile 3 verwendet die Namensgebung unter Windows.

Damit ist die erste virtuelle Firewall erstellt und verkabelt. Der Ablauf für die restlichen Geräte ist identisch, mit Ausnahme der Netzadapter. Ob alles richtig verbunden ist, wird sich zeigen, sobald die Firewalls in Kapitel 5 ihre IP-Adressen erhalten.

Die verwendete Version ist VirtualBox 7.0.4.

Hardware

Für die Netze zwischen den Firewalls ist eine strikte Trennung nötig, denn viele Protokolle suchen sich selbstständig den besten Weg. Und der verläuft – vor allem bei IPv6 – bei unsauberer Vernetzung über ungeahnte Pfade.
Der Netzwerkadapter einer Firewall ist stets mit einer einfarbigen Linie im Lab-Diagramm verbunden. Jedes Netzsegment ist ein eigener Switch oder ein VLAN auf einem gemeinsamen Switch, wie in Kapitel Netze beschrieben.
Die praktische Umsetzung am Beispiel des Netzsegments mit dem IPv4-Bereich 192.0.2.0/24 umfasst die Netzwerkadapter der Geräte von:

  • RT-1:em4

  • RT-3:em2

  • RT-core:em2

Die Adapter sind per Kabel mit einem 5-Port-Switch verbunden. Der Switch hat keine weitere Verbindung oder Uplink.
Bei der Variante mit VLAN-Tagging sind die Kabel der genannten Geräte verbunden mit einem verwalteten Switch, beispielsweise auf den ersten drei Ports. Die Konfiguration für einen Cisco-Catalyst-Switch ist in Listing 3.1 abgedruckt. Die OPNsense-Firewalls bemerken diese VLAN-Zuordnung nicht.

vlan 1406
name WAN-2_192.0.2.0
!
interface range GigabitEthernet1/0/1 - 3
switchport mode access
switchport access vlan 1406

       Netztrennung mit Switchports und VLANs (Listing 3.1)

Ob die Verkabelung korrekt ist, kann erst später überprüft werden. Sobald in Kapitel 5 die Interfaces der Firewall mit IP-Adressen bestückt sind, hilft das ping-Kommando beim Aufspüren von Fehlern.

Eingebettete Systeme

OPNsense basiert zwar auf BSD, wird aber nur für die AMD64-Architektur kompiliert angeboten. Images für andere Plattformen, wie z. B. ARM oder MIPS, sind nicht in Planung.
Bei einem normalen PC oder Server mit Tastatur, Bildschirm und DVD-Laufwerk ist der Startvorgang einfach: DVD einlegen und booten. Die Installation beginnt in Kapitel 4.
Schwieriger wird es bei eingebetteter Hardware, da es keine allgemeingültige Anleitung gibt, weil die Installation stark von den Komponenten abhängt. Geräte der Embedded-Klasse sind minimalistisch und daher entfallen meist DVD-Laufwerk, Monitor-Anschluss und gespeichert wird auf einem Flash-Medium.
Als praktisches Beispiel eignet sich das APU 1D4-Board [7] des Schweizer Herstellers PC-Engines. Ausgestattet ist es mit 3x GBit-Netzwerk, SD-Karte, serieller Konsole und 2x USB-Anschluss.
Die OPNsense-Repositories stellen zwar ein fertiges Flash-Image bereit, empfehlen aber die Installation per USB-Stick. Von diesem Bootmedium startet das APU-Board und beginnt die Installation des Betriebssystems auf die SD-Karte. Das Installationsimage für Geräte mit serieller Konsole hat das Wort serial im Dateinamen.

  1. Zuerst muss die Image-Datei von einem Downloadserver von OPNsense bezogen werden.

    wget https://pkg.opnsense.org/releases/23.1/OPNsense-23.1-OpenSSL-serial-amd64.img.bz2

  2. Beim Download über das Internet empfiehlt sich die anschließende Kontrolle, um Übertragungsfehler und gewollte Manipulationen auszuschließen. Das Repository bietet dazu eine Dateisignatur, die sich mit Bordmitteln eines Linux-Systems überprüfen lässt.

    wget https://pkg.opnsense.org/releases/23.1/OPNsense-23.1.pub
    wget https://pkg.opnsense.org/releases/23.1/OPNsense-23.1-OpenSSL-serial-amd64.img.bz2.sig
    openssl base64 -d -out /tmp/image.sig -in OPNsense-23.1-OpenSSL-serial-amd64.img.bz2.sig
    openssl dgst -sha256 -verify OPNsense-23.1.pub -signature /tmp/image.sig OPNsense-23.1-OpenSSL-serial-amd64.img.bz2

  3. Anschließend wird die Datei entpackt.

    bunzip2 OPNsense-23.1-OpenSSL-serial-amd64.img.bz2

  4. Danach muss das resultierende Dateiimage
    OPNsense-23.1-OpenSSL-serial-amd64.img
    so auf einen leeren USB-Stick kopiert werden, dass er bootfähig ist. Das Tool physdiskwrite [8] vollführt diese Aufgabe auf einem beliebigen Windows-PC mit Administrator-Berechtigungen.

    physdiskwrite.exe -u -d 1 OPNsense-23.1-OpenSSL-serial-amd64.img

    physdiskwrite schreibt die Imagedatei auf das angegebene Laufwerk mit der Option -d ohne weitere Nachfrage. Eine falsche Angabe kann zu Datenverlust führen.

  5. Eine serielle Verbindung zum APU-Board muss her. Ohne serielle Schnittstelle am PC hilft ein USB-Seriell-Wandler, auch wenn die Ersteinrichtung etwas Geduld erfordert. Eine Konsolensoftware, wie beispielsweise TeraTerm oder PuTTY, benötigt die Geschwindigkeit von 115200 bps für die Kommunikation mit dem APU-Board.

  6. Zuletzt wird das APU-Board von dem frisch erstellten USB-Stick gebootet. Durch Drücken der Taste F12 zeigt der Bootloader die möglichen Startmethoden. Der USB-Stick wird als USB MSC Drive gelistet.

Damit ist OPNsense gestartet, aber noch nicht installiert. Die Installation auf die SD-Karte beginnt in Kapitel 4.

Kapitel 4: Installation

Die virtuellen

Impressum

Verlag: BookRix GmbH & Co. KG

Tag der Veröffentlichung: 05.04.2023
ISBN: 978-3-7554-3808-3

Alle Rechte vorbehalten

Nächste Seite
Seite 1 /