IPFire mit isolierten Netzwerken und Tor-Gateway-VM einrichten

Eine saubere Netzwerksegmentierung gehört zu den wichtigsten Maßnahmen, um Systeme voneinander zu isolieren und ungewollte Kommunikation zu verhindern. Besonders bei Testumgebungen, KI-Agenten, Malware-Analysen oder anderen sicherheitskritischen Anwendungen empfiehlt es sich, diese nicht direkt im Heimnetz zu betreiben, sondern in einem eigenen, abgeschotteten Netzwerk.

In diesem Tutorial wird gezeigt, wie sich mit IPFire eine Architektur aufbauen lässt, bei der das eigentliche Heimnetz vollständig vom Arbeitsnetz getrennt bleibt. Als Firewall dient IPFire, das den Datenverkehr zwischen den einzelnen Netzwerkzonen kontrolliert und ausschließlich die zuvor definierten Verbindungen zulässt.

Das Arbeitsnetz befindet sich dabei im ORANGE-Netz von IPFire und enthält eine dedizierte Tor-Gateway-VM. Diese virtuelle Maschine stellt als einzige Instanz eine Verbindung zum Router im Heimnetz her und leitet anschließend den gesamten ausgehenden Datenverkehr über das Tor-Netzwerk. Alle übrigen Systeme im ORANGE-Netz besitzen keinen direkten Zugang zum Router oder zum Internet und sind dadurch gezwungen, ausschließlich den Weg über das Tor-Gateway zu nutzen.

Dieses Konzept bietet mehrere Vorteile. Zum einen verhindert es zuverlässig, dass Anwendungen versehentlich oder absichtlich eine direkte Verbindung ins Internet aufbauen. Zum anderen bleiben Heimnetz und Arbeitsnetz vollständig voneinander getrennt. Selbst wenn eine virtuelle Maschine kompromittiert werden sollte, kann sie weder direkt auf das Heimnetz oder die Firewall selbst zugreifen noch die Anonymisierung über Tor umgehen.

Das Zielsetup besteht aus drei Netzen:

• RED — vertrauenswürdiges Netzwerk mit Internet-Router (192.168.1.1) und den primären Systemen. Von hier aus soll die Administration von IPFire erfolgen.
• ORANGE — isoliertes Netz mit einer Tor-Gateway-VM und mehreren Client-VMs. Ausschließlich die Tor-Gateway-VM soll Internetzugriff (über den Router in RED) erhalten. Alle übrigen VMs in diesem Segment dürfen weder das Internet noch das RED-Netz noch die Firewall-Administration direkt erreichen; sie sollen ausschließlich über die Tor-Gateway-VM ins Internet gelangen.
• GREEN — wird nur für die Initialkonfiguration benötigt und bleibt danach ungenutzt. IPFire benötigt dieses Interface zwingend, für das beschriebene Szenario hat es jedoch keine praktische Funktion.

---

Das IPFire-Zonenkonzept

IPFire unterteilt das Netzwerk in vier Sicherheitszonen: RED, GREEN, ORANGE und BLUE. Die Zonen RED und GREEN sind obligatorisch und müssen bei jeder Installation eingerichtet werden. Die Zonen ORANGE und BLUE sind optional und können bei Bedarf ergänzt werden. Jede Zone erfordert eine eigene physische oder virtuelle Netzwerkschnittstelle, sodass jede Sicherheitszone über ein separates Netzwerksegment verfügt.

Im Standardkonzept von IPFire sind die Rollen wie folgt festgelegt:

• RED ist das Interface, über das IPFire den eigenen Internet-Uplink bezieht (DHCP-Client, PPPoE, WAN-IP). RED gilt als nicht vertrauenswürdig und hat standardmäßig keinen Zugriff auf die Firewall-Administration oder andere Zonen.
• GREEN ist das interne, als vertrauenswürdig eingestufte Netz. Der Zugriff auf die Firewall-Weboberfläche (Port 444) und SSH ist für GREEN fest im System verankert und nicht über Firewallregeln deaktivierbar. Aus diesem Grund erfolgt die Ersteinrichtung von IPFire grundsätzlich über GREEN: Direkt nach der Installation existieren noch keine Firewallregeln, das Webinterface ist über GREEN dennoch ohne Zusatzkonfiguration erreichbar.
• ORANGE (DMZ) ist ein vom GREEN Netz getrenntes Netz für Server und Dienste, die aus dem Internet erreichbar sein sollen. ORANGE besitzt keinen direkten Zugriff auf GREEN, kann aber grundsätzlich auf das RED-Netz zugreifen. Standardmäßig entscheidet die IPFire-Firewall anhand ihrer Richtlinien und Regeln, welche Verbindungen zwischen ORANGE, GREEN und RED erlaubt sind. In einer DMZ werden üblicherweise nur die ausdrücklich benötigten Verbindungen freigegeben, um das interne Netzwerk bei einer Kompromittierung eines öffentlich erreichbaren Dienstes zu schützen.
• BLUE ist das optionale Netzwerk für drahtlose Geräte (WLAN) oder andere Geräte, denen ein eigenes Sicherheitssegment zugewiesen werden soll. Es dient dazu, nicht vollständig vertrauenswürdige Clients vom GREEN-Netz zu trennen. Geräte im BLUE-Netz können standardmäßig nicht auf GREEN zugreifen, sofern keine expliziten Firewallregeln dies erlauben. Der Zugriff von BLUE auf das Internet über RED ist hingegen über die Firewall steuerbar. Typische Einsatzszenarien sind Gast-WLANs, private WLAN-Geräte oder IoT-Geräte, die vom internen Netzwerk isoliert werden sollen. Wie ORANGE benötigt auch BLUE eine eigene physische oder virtuelle Netzwerkschnittstelle.

IPFire erwartet grundsätzlich, dass sich der Internet-Uplink im RED-Netz befindet, während GREEN ausnahmslos als vertrauenswürdiges internes Netzwerk behandelt wird. Dies hat zur Folge, dass das Webinterface der Firewall standardmäßig aus dem GREEN-Netz erreichbar ist – selbst dann, wenn der Zugriff per Firewall-Regel untersagt wurde. Das RED-Netz hingegen ist standardmäßig als nicht vertrauenswürdige Zone und für den Internet-Uplink vorgesehen. Für das hier beschriebene Setup eignet sich GREEN daher nicht als vollständig isolierte Uplink-Zone. Soll RED anstatt GREEN, wie in diesem Szenario, als vertrauenswürdige Zone genutzt werden, weicht dies vom vorgesehenen Sicherheitsmodell von IPFire ab und erfordert entsprechende Anpassungen und ein weiteres ORANGE Netz.

Deshalb wird RED als vertrauenswürdiges Netz konfiguriert, nicht weil IPFire dies vorsieht — im Gegenteil, RED gilt systemseitig weiterhin als nicht vertrauenswürdig —, sondern weil RED die einzige Zone ist, die zwingend als Internet-Gateway-Interface fungiert. Der Router im RED-Netz übernimmt in diesem Setup die tatsächliche Internetanbindung; IPFire hängt sich über RED lediglich als Client daran. Der Administrationszugriff von RED aus wird daher nicht automatisch gewährt, sondern muss über eine explizite Firewallregel eingerichtet werden (siehe Schritt 4).

Warum GREEN nicht entfernt, sondern stillgelegt wird

Da GREEN ein obligatorisches Interface ist, lässt es sich in IPFire nicht deaktivieren oder unkonfiguriert lassen. Eine vollständige Entfernung ist nicht vorgesehen. Stattdessen wird GREEN funktional entwertet, indem es an eine Bridge ohne angeschlossene VMs und ohne Uplink gebunden wird. GREEN bleibt dadurch als Interface bestehen, trägt jedoch keinen produktiven Traffic mehr und ist für kein anderes System erreichbar.

Daraus ergibt sich die folgende Reihenfolge bei der Einrichtung:

• Ersteinrichtung über GREEN und einer Management VM mit GUI und Browser im GREEN Netz (im Auslieferungszustand sind nur RED und GREEN vorhanden) — dies ist der einzige Weg, ohne vorherige Regelkonfiguration auf das Webinterface zuzugreifen.
• Einrichtung einer Regel, die den Zugriff auf das Webinterface von RED aus ermöglicht (Schritt 4).
• Erst danach kann die Management VM aus dem GREEN Netz wieder entfernt werden.
• Abschließend wird ORANGE als dritte Netzzone für das Tor-Netz eingerichtet.

Wird GREEN deaktiviert, bevor der Zugriff von RED aus eingerichtet ist, ist die Firewall-Oberfläche zwischenzeitlich von keiner Zone aus erreichbar. Eine Korrektur wäre in diesem Fall nur über die lokale Konsole der Proxmox-VM möglich.

Warum ORANGE für das isolierte Netz verwendet wird

ORANGE ist im Standardkonzept von IPFire als DMZ-Zone vorgesehen — für Systeme, die von außen erreichbar sein sollen, ohne mit dem internen Netz zu kommunizieren. Für das hier beschriebene Szenario ergeben sich daraus passende Grundeigenschaften:

• Kein automatischer Zugriff auf die Firewall-Administration (im Unterschied zu GREEN)
• Standardmäßig kein Zugriff auf GREEN
• Regelbasierter, kontrollierbarer Zugriff Richtung RED

Eine vergleichbare Isolation ließe sich auf GREEN nur mit zusätzlichem Regelaufwand annähern, wobei der Zugriff auf die Firewall-Administration von GREEN aus grundsätzlich nicht vollständig unterbindbar ist. Bei ORANGE ist diese Isolation bereits systemseitig vorgesehen.

---

Voraussetzungen

• IPFire als VM in Proxmox mit 3 dedizierten vNICs (virtual Network Interface Card)
• Management VM mit GUI und Browser für Initialkonfiguraion über GREEN NIC
• Tor-Gateway-VM mit fester MAC-Adresse im ORANGE-Netz

Schritt 1: Netzwerk-Interfaces zuweisen

Das bestehende RED-Interface wird der Bridge/Netz in der sich Router (192.168.1.1) und die zu schützenden Systeme befinden, zugewiesen, wobei die IP zuweisung per DHCP vom Router erfolgt (z. B. 192.168.1.99). Die zweite vNIC wird der Green Bridge/Netz zugewiesen in der sich ebenfalls die Management VM mit GUI und Browser für die Initialkonfiguration befindet. Die dritte vNIC/Netz wird der ORANGE Bridge/Netz zugewiesen in der sich TOR Gateway und alle weiteren isolierten VMs befinden. Für die zweite und dritte vNIC werden feste IPs via Terminal setup befehl IPFire zugewiesen und bei Bedarf ein DHCP Server eingerichtet.

RED, GREEN, ORANGE und BLUE sollten nicht an derselben Bridge hängen, da dies die logische Zonentrennung von IPFire auf L2-Ebene aufheben würde.

Quelle- und Zieltypen bei Firewallregeln

Beim Anlegen einer Regel unter Firewall → Firewallregeln → Neue Regel erstellen lassen sich Quelle und Ziel jeweils über verschiedene Typen definieren. Die Auswahl bestimmt, welche Firewall-Chain die Regel betrifft und wie präzise sie greift:

Quelltypen:

• Standardnetzwerk — bezieht sich auf eine ganze Zone (z. B. ORANGE, GRÜN, ROT) in ihrer vollen Netzausdehnung. Geeignet, wenn die Regel für alle Hosts einer Zone gelten soll.
• IP-Adresse — einzelne IP oder Subnetz, unabhängig von der Zonenzugehörigkeit. Geeignet für einzelne Hosts (Router) oder definierte Teilbereiche.
• MAC-Adresse — bindet die Regel an eine konkrete Netzwerkschnittstelle, unabhängig von deren aktueller IP. Das verhindert, dass eine andere VM im selben Segment die Regel durch eine geänderte oder gefälschte IP für sich nutzen kann.
• Firewall-Gruppe — vordefinierte Gruppe aus mehreren Quellen (IP/MAC), sinnvoll bei wiederkehrenden Kombinationen mehrerer Hosts.

Zieltypen:

• Standardnetzwerk / IP-Adresse — Ziel liegt außerhalb der Firewall selbst, z. B. ein Host in einer anderen Zone oder im Internet. Regeln mit diesem Ziel betreffen die Forward-Chain (durch IPFire hindurchgeleiteter Traffic).
• Firewall — Ziel ist IPFire selbst (eine seiner eigenen Interface-IPs, z. B. für Zugriff auf Weboberfläche, SSH oder DNS-Proxy). Regeln mit diesem Ziel betreffen die Input-Chain und erscheinen in der separaten Tabelle „Eingehender Firewallzugang“, nicht in den regulären Firewallregeln.

Diese Unterscheidung ist relevant, weil eine Regel mit Ziel „Standardnetzwerk ROT“ ausschließlich durchgeleiteten Traffic betrifft — Zugriffe auf IPFire selbst (etwa das Webinterface auf der RED-IP) werden davon nicht erfasst. Für Regeln, die den Zugriff auf die Firewall-Administration steuern sollen, muss als Ziel explizit Firewall gewählt werden.

Schritt 2: Tor-Gateway-VM für Verbindung zum Router konfigurieren

Unter Firewall → Firewallregeln → Neue Regel erstellen:

• Quelltyp: MAC-Adresse — MAC-Adresse der Tor-Gateway-VM eintragen
• Zieltyp: IP-Adresse — 192.168.1.1 (Router) eintragen, da das Ziel ein Host im RED-Netz ist, nicht die Firewall selbst
• Aktion: ACCEPT

Die Bindung an die MAC-Adresse verhindert, dass eine andere VM im ORANGE-Netz die Regel durch IP-Spoofing für sich nutzen kann. Als Zieltyp wird hier IP-Adresse statt Standardnetzwerk gewählt, da nur der einzelne Router adressiert werden soll, nicht das gesamte RED-Netz.

Schritt 3: Forward-Policy für ORANGE → RED auf „Blockiert“ setzen

Unter Firewall → Firewalloptionen → Firewallrichtlinie:

• Standardverhalten der Firewall (Forward) in Modus „Blocked“ auf Blockiert stellen und speichern. Das zugehörige Auswahlfeld befindet sich am unteren Ende der Seite „Firewalloptionen“, im Abschnitt „Standardverhalten der Firewall“, unterhalb der Protokollierungs- und Anzeigeeinstellungen.

Diese Einstellung sorgt dafür, dass sämtliche Zonen-Übergänge (ORANGE→ROT, ORANGE→GRÜN, GRÜN→ORANGE etc.) standardmäßig gesperrt sind, sofern keine explizite Ausnahmeregel greift. Die in Schritt 2 angelegte Regel wird dadurch zur wirksamen Ausnahme.

Die Outgoing-Policy (Verbindungen, die IPFire selbst initiiert — Updates, NTP, DNS-Auflösung) sollte auf „Zugelassen“ belassen werden, da sonst für jeden Wartungsdienst manuell eine Ausnahme angelegt werden müsste.

Schritt 4: Zugriff auf die Firewall-Administration konfigurieren

Es wird eine Firewallregel erstellt um Zugriff auf das Webinterface aus dem RED Netz zu erhalten, da sonst mit der “Deaktivierung” des GREEN Netzes kein Zugriff auf das Webinterface mehr möglich ist.  Unter Firewall → Firewallregeln →  Neue Regel erstellen:

• Quelltyp: IP-Adresse — 192.168.1.0/24 eintragen (oder Standardnetzwerk ROT, sofern dieses Netz mit dem RED-Subnetz identisch ist)
• Zieltyp: Firewall — nicht „Standardnetzwerk ROT“. Nur mit dem Zieltyp „Firewall“ wird die Regel der Input-Chain zugeordnet und steuert damit tatsächlich den Zugriff auf die Firewall-Administration selbst (Webinterface, SSH). Mit dem Zieltyp „Standardnetzwerk“ würde die Regel stattdessen durchgeleiteten Traffic betreffen und den Admin-Zugriff auf IPFire nicht erfassen.
• Aktion: ACCEPT

Diese Regel lässt sich optional weiter eingrenzen, etwa auf eine einzelne Administrations-IP oder -MAC innerhalb von RED anstelle des gesamten /24-Netzes, sowie auf bestimmte Ports (444, 22) statt auf sämtliche Dienste der Firewall.

Wenn das Webinterface aus dem RED Netz erreichbar ist (https://<DHCP-vergebene-IP-für-IPFire>:444) ist die Management VM nicht mehr notwendig und kann aus dem GREEN Netz wieder

Schritt 5: Kontrolle

Von einer Client-VM im ORANGE-Netz (nicht der Tor-Gateway-VM):

Von der Tor-Gateway-VM:

Ergebnis

• RED: vertrauenswürdiges Netz, einzige Zone mit Zugriff auf die Firewall-Administration und Internetgateway.
• ORANGE: isoliertes Netz — nur die MAC-gebundene Tor-Gateway-VM erreicht den Router in RED, alle anderen VMs sind auf den Zugriff über die Tor-Gateway-VM als internes Gateway beschränkt.
• GREEN: ungenutzt, bleibt bestehen, da von IPFire zwingend vorausgesetzt.

Hinweis zur Wahl der Tor-Implementierung

IPFire bietet zwar ein eigenes Tor-Paket. Dieses ist primär für den Betrieb von IPFire als Tor-Relay, -Bridge oder -Exit-Node vorgesehen und nicht in erster Linie als transparenter Client-Proxy für ein gesamtes LAN-Segment konzipiert. Gegen den Betrieb von Tor direkt auf IPFire anstelle einer separaten Gateway-VM sprechen zudem folgende Punkte:

• Firewall, Router und Tor-Client liefen in einem System, was die Angriffsfläche der Firewall selbst vergrößert.
• Der Isolationsvorteil einer separaten Gateway-VM — eine kompromittierte Client-VM hat keinen direkten Zugriff auf die Gateway-Konfiguration — entfiele.
• Tor-Updates wären an den IPFire-Update-Zyklus gebunden, statt unabhängig davon eingespielt werden zu können.
• Der Netzwerkpfad (ORANGE → RED) bliebe unverändert, unabhängig davon, auf welchem System Tor läuft.

Die dedizierte Tor-Gateway-VM im ORANGE-Netz wird daher gegenüber der IPFire-internen Tor-Integration als die robustere Lösung eingeschätzt.

---

by Speefak