OPNsense: Netzwerkisolation mit OPNsense auf Proxmox

1. Netzwerkkonfiguration in Proxmox: zweite Bridge für isoLAN erstellen

Für das isolierte Netz wird eine eigene, rein interne Linux-Bridge ohne Anbindung an eine physische Netzwerkkarte benötigt.

1. In der Proxmox-Weboberfläche in der linken Baumstruktur den betreffenden Node auswählen (nicht “Datacenter”).
2. Menüpunkt System → Network öffnen.
3. Oben auf Erstellen → Linux Bridge klicken.
4. Im Dialog:
   • Name: isoLAN (bzw. den nächsten freien vmbrX-Namen, falls die Proxmox-Version keine frei wählbaren Bridge-Namen erlaubt).
   • IPv4/CIDR, Gateway: leer lassen – die Bridge selbst benötigt keine IP-Adresse, da nur OPNsense und die VMs darauf kommunizieren.
   • Bridge ports: leer lassen. Das ist der entscheidende Punkt: Ohne eingetragenen physischen Port ist die Bridge komplett vom restlichen Netzwerk isoliert und existiert nur virtuell innerhalb des Proxmox-Hosts.
   • Häkchen bei VLAN aware ist nicht erforderlich, kann deaktiviert bleiben.
   • Erstellen klicken, danach oben den Button Konfiguration anwenden anklicken, damit die Bridge tatsächlich aktiv geschaltet wird.
   • Kontrolle: Die neue Bridge erscheint in der Liste unter System → Network mit dem Status “Active”, aber ohne zugeordnete physische Schnittstelle.

Tipp: Da diese Bridge keinen Bridge-Port besitzt, kann später ausschließlich über das OPNsense-LAN-Interface auf dieses Netz zugegriffen werden – das ist gewünscht und Grundlage der Isolation.

2. Proxmox-VM für OPNsense einrichten

1. Oben rechts Erstelle VM klicken.
2. Allgemein: Name und VM ID vergeben, z. B. OPN-GW-isoLAN.
3. OS: OPNsense-ISO als Installationsmedium auswählen (vorher per Upload oder Download from URL unter local (Node) → ISO Images bereitgestellt), Typ: Linux / 7.x – 2.6 Kernel.
4. System: Standardwerte übernehmen, BIOS kann bei OVMF/UEFI oder SeaBIOS bleiben (SeaBIOS reicht für OPNsense).
5. Disks: mindestens 6 GB (Systempartition sollte mindestens 4 GB groß sein, da sonst für spätere Updates zu wenig Speicherplatz zur Verfügung steht), Standard-Controller (VirtIO SCSI) beibehalten.
6. CPU: mindestens 2 Kerne, Typ: Host
7. Speicher: mindestens 4096 MB, Ballooning Gerät: Haken entfernen (deaktivieren)
8. Netzwerk: erste Netzwerkkarte konfigurieren:
   • Bridge: vmbr0 (CoreLAN)
   • Model: VirtIO (paravirtualized)
   • Firewall: Haken entfernen (deaktivieren)
9. VM mit Bestätigen anlegen, aber noch nicht starten.
10. Nach dem Anlegen: VM auswählen → Hardware → Hinzufügen → Netzwerkkarte, zweite NIC hinzufügen:
    • Bridge: isoLAN
    • Model: VirtIO (paravirtualized)
    • Firewall: Haken entfernen (deaktivieren)

Wichtig: CoreLAN-NIC vor dem ersten Start vom Netz trennen

OPNsense installiert das LAN-Interface standardmäßig mit der IP 192.168.1.1/24 und aktivem DHCP-Server. Bliebe die CoreLAN-NIC während der Installation und Erstkonfiguration mit vmbr0 verbunden, könnte der OPNSense eigene DHCP-Server kurzzeitig parallel zum Router DHCP Server im CoreLAN aktiv werden und dort IP-Konflikte verursachen.

Vorgehen:

1. VM auswählen → Hardware.
2. Die Netzwerkkarte, die an vmbr0 hängt, per Doppelklick öffnen.
3. Haken bei “Erweitert” (neben dem OK Button) um erweiterte Optionen anzuzeigen.
4. Option “Trennen” aktivieren (trennt die virtuelle NIC logisch vom Netzwerk, ohne sie zu entfernen) und mit OK bestätigen.
5. Die NIC an isoLAN kann verbunden bleiben, da diese Bridge ohnehin isoliert ist und keine Konfliktgefahr besteht.
6. Diese Trennung bleibt bestehen, bis die Basiskonfiguration über die Konsole (Abschnitt 4) abgeschlossen ist.

3. Installation von OPNsense

1. VM starten, Console öffnen (noVNC oder xterm.js).
2. Der Installer bootet automatisch ins Live-System.
3. Login an der Konsole: installer / opnsense
4. Installations-Assistenten durchklicken:
   • Tastaturlayout bestätigen bzw. auswählen.
   • Other Modes >> Extended Installation auswählen
   • Auto (ZFS) auswählen (Voraussetzung für den Growfs-Mechanismus weiter unten sowie für automatische Boot-Environments bei künftigen Updates).
   • Optionen ggf. anpassen und mit >>> Install fortfahren
   • Select Virtual Device type: stripe
   • Virtuelle Disk auswählen: (da0 – QEMU QEMU Harddisk)
   • Folgenden Dialog mit YES bestätigen und Installation starten
   • Nach Abschluss: Root-Passwort ändern
   • Complete Install – Confirm and exit auswählen.
   • Vor dem erneuten Hochfahren die ISO-Datei aus der VM aushängen (Hardware → CD/DVD Drive → Do not use any media), sonst startet der Installer erneut.

Exkurs: Festplatte nachträglich vergrößern (Growfs)

Falls die virtuelle Festplatte zu knapp bemessen wurde (z. B. für ein späteres Firmware-Update zu wenig freier Speicher), lässt sich das bei einer OPNsense-Installation mit ZFS über den eingebauten automatischen “Growfs”-Mechanismus nachträglich beheben, ohne Neuinstallation:

1. VM in Proxmox herunterfahren.
2. VM auswählen → Hardware → die virtuelle Festplatte auswählen → Disk Aktion → Größe anpassen → Wert um die Disk vergrößert werden soll eintragen, nicht Zielgröße.
3. VM wieder starten, per Konsole oder SSH verbinden.
4. In der OPNsense-Shell folgenden Befehl ausführen, um eine “magische” Datei anzulegen, die den Mechanismus beim nächsten Boot auslöst:
   
   touch /.probe.for.growfs

   1	touch /.probe.for.growfs

   
   VM neu starten. Beim Boot erkennt OPNsense die Datei, vergrößert automatisch die ZFS-Partition und den Pool und löscht die Datei anschließend selbstständig.
5. Kontrolle nach dem Neustart:
   
   df -h

   1

   df -h

   
   Der verfügbare Speicherplatz für / sollte jetzt der neuen, größeren Festplattengröße entsprechen.

4. Basiskonfiguration über die Proxmox-Konsole (Shell)

Nach dem Neustart bzw. Login (root/opnsense bzw. vergebenes Passwort) landet man automatisch im textbasierten OPNsense-Hauptmenü. Da LAN und WAN für das oben beschriebene Szenario zu diesem Zeitpunkt noch nicht sinnvoll konfiguriert sind, erfolgt die gesamte Grundkonfiguration zunächst ausschließlich über die Konsole.

4.1 Interfaces zuweisen

Menüpunkt 1) Assign interfaces wählen:

• “Do you want to configure LAGGs now?”: n (Link Aggregation wird in den meisten Fällen nicht benötigt)
• “Do you want to configure VLANs now?”: n (Virtuelle LANs werden nicht benötigt)
• “Enter the WAN interface name or ‘a’ for auto-detection”: vtnet0 (CoreLAN-NIC)
• “Enter the LAN interface name…”: vtnet1 (isoLAN-Nic)
• “Enter the Optional interface 1 name…”: leer lassen (Enter)
• “Do you want to proceed? [y/N]”: y

Hinweis: Welche NIC als vtnet0 bzw. vtnet1 erscheint, hängt von der Reihenfolge beim Anlegen in Proxmox ab. Im Zweifel beide MAC-Adressen unter Hardware in Proxmox mit der Anzeige an der Konsole abgleichen.

4.2 LAN-Interface (isoLAN) konfigurieren

Menüpunkt 2) Set interface IP address → Interface 1 (LAN) wählen.

Diese Konfiguration kann auch mittels OPNSense WebUI erstellt werden

• Enter the number of the interface to configure: 1 (LAN)
• Configure IPv4 address LAN interface via DHCP? [y/N]: n
  Bei Auswahl von DHCP würde OPNsense versuchen, selbst eine IP von einem DHCP-Server innerhalb des isoLAN-Netzes zu beziehen; da OPNsense hier aber selbst als DHCP-Server fungieren soll, erscheint bei versehentlicher DHCP-Auswahl anschließend auch keine DHCP-Server-Konfigurationsabfrage.
• IPv4-Adresse: 192.168.10.1
• Subnetz-Bitcount: 24
• Upstream-Gateway: leer lassen (Enter) – LAN-Interfaces besitzen kein Gateway.
• Configure IPv6 address LAN interface via WAN tracking: n
• Configure IPv6 address LAN interface via DHCP6?: n
• IPv6-Adresse: leer lassen (Enter)
• Do you want to enable the DHCP server on LAN? [y/N]: y (nur nach o.g. Eingabe von fester IPv4-Adresse)
  • Start-Adresse: 192.168.10.10
  • End-Adresse: 192.168.10.200
• Do you want to change the web GUI protocol from HTTPS to HTTP? [y/N]: n
• Do you want to generate a new self-signed web Gui certificate? [y/N]: y
• Restore web GUI access defaults [y/N]: y

4.3 WAN-Interface (CoreLAN) konfigurieren

Menüpunkt 2) Set interface IP address → Interface 2 (WAN) wählen.

Für dieses Szenario wird eine feste WAN-Adresse verwendet. Dadurch bleibt die OPNsense-WebUI, die spätere Route und die gesamte Dokumentation unter derselben Adresse erreichbar.

• Enter the number of the interface to configure: 2 (WAN)
• Configure IPv4 address WAN interface via DHCP? [y/N]: n
• IPv4-Adresse: 192.168.1.91
• Subnetz-Bitcount: 24
• Upstream-Gateway: 192.168.1.1
• “Do you want to use the gateway as the IPv4 name server, too?”: y
• IPv6 via DHCP6: n
• Für WAN erscheint keine DHCP-Server-Abfrage – OPNsense bietet auf WAN-Interfaces grundsätzlich keinen DHCP-Server an. Die Anforderung “DHCP von OPNsense für CoreLAN darf nicht aktiv sein” ist damit strukturell automatisch erfüllt.
• “Change web GUI protocol HTTPS→HTTP?”: n
• “Generate new self-signed web GUI certificate?”: y
• “Restore web GUI access defaults?”: y

Alternative: Statt einer festen Adresse kann das WAN-Interface auch per DHCP eine Adresse vom Router beziehen. Für die weiteren Schritte muss dann überall die tatsächlich vom Router vergebene WAN-Adresse verwendet werden. Eine feste Adresse wie 192.168.1.91 ist für dieses Tutorial jedoch übersichtlicher.

4.4 CoreLAN-NIC wieder verbinden

Erst jetzt, nach abgeschlossener Basiskonfiguration, die zuvor getrennte NIC wieder aktivieren:

1. In Proxmox: VM → Hardware → die CoreLAN-NIC öffnen.
2. Option “Trennen” wieder deaktivieren, mit OK bestätigen.

Die Konsole zeigt danach die finale Übersicht:

• LAN (vtnet1) -> v4: 192.168.10.1/24
• WAN (vtnet0) -> v4: 192.168.1.91/24 (oder falls DHCP gewählt, IP aus CoreLAN Adressbereich)

5. Management-VM (Linux-Live-Image) für die weitere WebUI-Konfiguration

Die OPNsense-WebUI ist nach der Grundkonfiguration ausschließlich über das LAN-Interface (IsoLAN) erreichbar, da nur dort eine Default-Allow-Regel existiert, die auch Zugriff auf die Firewall selbst einschließt. Auf dem WAN-Interface (CoreLAN) existiert dafür zunächst keine Regel.

 Temporäre Management-VM starten

• In Proxmox eine neue, schlanke VM anlegen (z. B. mit einem Linux-Live-Image mit Desktopumgebung und Browser, etwa einer gängigen Live-Distribution).
• Netzwerkkarte dieser VM an die Bridge isoLAN anbinden.
• VM starten, Live-System bootet direkt in eine grafische Desktopumgebung, ohne Installation.
• Netzwerkverbindung prüfen: Die VM sollte automatisch über DHCP eine Adresse aus dem Bereich 192.168.10.10–192.168.10.200 erhalten (bezogen vom OPNsense-DHCP-Server).
• Browser öffnen und http://192.168.10.1 (oder https, wenn konfiguriert)  aufrufen.
• Zertifikatswarnung bestätigen, wenn https konfiguriert (selbstsigniertes Zertifikat).
• Login mit root und dem zuvor an der Konsole vergebenen Passwort.

---

6.0 WebUI-Zugriff aus dem WAN (CoreLAN) einrichten

Um den Traffic aus dem CoreLAN (WAN-Interface von OPNsense) bis zur Firewall weiterzuleiten, muss unter Schnittstellen → WAN (CoreLAN) die Option „Private Netzwerke blockieren“ deaktiviert werden. Da es sich bei 192.168.1.0/24 um ein privates RFC1918-Netz handelt, würde OPNsense diesen Traffic andernfalls bereits durch eine automatisch generierte Regel vor der Verarbeitung der eigenen Firewall-Regeln verwerfen. „Bogon-Netzwerke blockieren“ kann hingegen aktiviert bleiben.

Damit die WebUI künftig auch direkt aus dem CoreLAN über das WAN-Interface erreichbar ist und die temporäre Management-VM nicht mehr benötigt wird, wird anschließend eine entsprechende Firewall-Regel für das CoreLAN-Interface angelegt.

Die Firewall-Regeln werden zentral unter Firewall → Regeln verwaltet. Eine neue Regel wird über das rote “+”-Symbol unten rechts in der Liste angelegt, Der Bearbeiten-Dialog lässt sich über den Schalter “Erweiterter Modus” oben links um zusätzliche Felder erweitern.

Menü: Firewall → Regeln, über “+” neue Regel:

• • Aktiviert: Häkchen gesetzt
  • Beschreibung: “Allow WAN / CoreLAN -> OPN Webui”
  • Schnittstelle: WAN (CoreLAN)
  • Schnell: Haken setzen
  • Aktion: Erlauben
  • Richtung: Eingehend
  • Version: IPv4
  • Protokoll: beliebig – damit ist der vollständige Zugriff vom CoreLAN auf die Firewall erlaubt.
  • Quelle: WAN network
  • Quellport: beliebig – damit ist der vollständige Zugriff vom CoreLAN auf die Firewall erlaubt.
  • Ziel: Diese Firewall
  • Zielport: beliebig

Zielport

Eingabe Speichern und sicherstellen, dass Regel an erster Stelle in der Regelliste steht, dann mit Anwenden Änderungen laden. Ab diesem Zeitpunkt ist die WebUI unter https://192.168.1.91 auch direkt aus dem CoreLAN erreichbar, die Management-VM wird nicht mehr benötigt.

Hinweis: Der vollständige Zugriff ist für dieses Tutorial ausdrücklich gewünscht. Wenn stattdessen nur einzelne Dienste freigegeben werden sollen, kann die Regel gezielt auf das benötigte Protokoll und den jeweiligen Zielport eingeschränkt werden, z. B. TCP auf den konfigurierten WebUI-Port.

---

7. IPv6 im LAN (isoLAN) deaktivieren

Aus Gründen der Übersichtlichkeit und Sicherheit wird IPv6 im isoLAN nicht verwendet. Dadurch beschränkt sich die Netzwerkkonfiguration auf IPv4 und es müssen keine zusätzlichen IPv6-Routen oder Firewall-Regeln berücksichtigt werden. Hierzu wird unter Schnittstellen → LAN(isoLAN) bei IPv6-Konfigurationstype die Einstellung Keine ausgewählt und anschließend die Änderung übernommen. Zusätzlich ist sicherzustellen, dass für das isoLAN keine DHCPv6-Dienste oder Router Advertisements aktiviert sind.

Die Deaktivierung von IPv6 reduziert damit den Konfigurationsaufwand und verhindert, dass IPv6-Verbindungen die für das isoLAN definierten IPv4-Firewallregeln umgehen.

---

8. Abschließende Konfiguration

Für die Kommunikation zwischen CoreLAN und isoLAN sind Routing und Firewall-Regeln gleichermaßen erforderlich. Eine Freigabe durch die Firewall allein stellt noch keine funktionierende Verbindung her. Da 192.168.10.0/24 ein für CoreLAN-Clients fremdes Subnetz ist, senden die Clients Pakete für dieses Zielnetz standardmäßig an ihr Default-Gateway. In diesem Beispiel ist dies die FRITZ!Box mit der IP-Adresse 192.168.1.1. Kennt die FRITZ!Box keine Route zum Netzwerk 192.168.10.0/24, kann sie die Pakete nicht gezielt an die OPNsense-Firewall weiterleiten. Das Paket erreicht OPNsense in diesem Fall nicht und kann dort folglich auch durch keine Firewall-Regel verarbeitet werden. Für den Zugriff von CoreLAN-Clients auf Systeme im isoLAN müssen daher zwei Voraussetzungen erfüllt sein:

1. Routing: Der CoreLAN-Client bzw. der zuständige Router muss wissen, dass das Netzwerk 192.168.10.0/24 über OPNsense erreichbar ist.
2. Firewall: OPNsense muss den anschließend eintreffenden Datenverkehr aus dem CoreLAN zum isoLAN durch eine entsprechende Firewall-Regel erlauben.

Erst wenn das Routing den Datenverkehr zur OPNsense-Firewall führt, kann diese anhand ihrer Regeln entscheiden, ob die gewünschte Verbindung zugelassen oder blockiert wird. Das Routing bestimmt somit den Weg des Pakets, während die Firewall die Zulässigkeit der Verbindung kontrolliert.

8.1 Route im CoreLAN einrichten

Da 192.168.10.0/24 ein für CoreLAN-Clients fremdes Subnetz ist, schicken Clients ihre Pakete dorthin standardmäßig an ihr Default-Gateway, in diesem Beispiel die FRITZ!Box 192.168.1.1. Kennt der Router das Netz 192.168.10.0/24 nicht, kommt das Paket bei OPNsense nie an.

Dazu muss eine der folgenden Varianten eingerichtet werden:

Option A – zentral im Router (empfohlen):

Statische Route im CoreLAN-Router (192.168.1.1) eintragen. Sie gilt anschließend für alle CoreLAN-Clients.

• Netzwerk: 192.168.10.0
• Subnetzmaske: 255.255.255.0
• Gateway: WAN-Adresse der OPNsense, 192.168.1.91

Option B – auf jedem Client:

Route auf jedem einzelnen CoreLAN-Client einrichten:

Diese Route ist bei ip route add standardmäßig nicht persistent und muss ggf. dauerhaft über die jeweilige Netzwerkverwaltung eingerichtet werden.

Ohne diese Route ist der Zugriff von CoreLAN auf isoLAN trotz korrekter OPNsense-Firewall-Regel nicht möglich.

8.2 Firewall-Regeln für WAN (CoreLAN)

Menü: Firewall → Regeln, jeweils neue Regel über “+” mit Schnittstelle: CoreLAN:

#	Aktion	NIC	Version	Protokoll	Quelle	Quellport	Ziel	Zielport	Zweck
1	Erlauben	WAN	IPv4	beliebig	WAN network (CoreLAN)	beliebig	Diese Firewall	beliebig / 443	WebUI-Zugriff aus CoreLAN erlauben (Regel aus 5.2)
2	Erlauben	WAN	IPv4	beliebig	beliebig	beliebig	LAN network (isoLAN)	beliebig	Zugriff auf isoLAN Netzwerk erlauben

Menü: Firewall → Regeln, über “+” neue Regel:

• Aktiviert: Häkchen gesetzt
• Beschreibung: “ALLOW CoreLAN => isoLAN”
• Schnittstelle: WAN (CoreLAN)
• Schnell: Haken setzen
• Aktion: Erlauben
• Richtung: Eingehend
• Version: IPv4
• Protokoll: beliebig – vollständiger Zugriff aller Protokolle von WAN (CoreLAN) nach LAN (isoLAN)
• Quelle: beliebig – vollständiger Zugriff von allen IP Adressen von WAN (CoreLAN) nach LAN (isoLAN)
• Ziel: LAN network (isoLAN)
• Quellport: beliebig – vollständiger Zugriff aller Protokolle von WAN (CoreLAN) nach LAN (isoLAN)
• Ziel: Diese Firewall
• Zielport: beliebig – vollständiger Zugriff aller Protokolle von WAN (CoreLAN) nach LAN (isoLAN)

Eingabe Speichern und sicherstellen, dass Regel an zweiter Stelle in der Regelliste steht, dann mit Anwenden Änderungen laden. Damit werden Pakete aus dem WAN  Netzwerk (CoreLAN) anhand der statischen Route (6.1) ins LAN Netzwerk (isoLAN) zugestellt.

8.3 Anti-Lockout-Regel deaktivieren

OPNsense erstellt für das als LAN zugewiesene Interface – in diesem Aufbau das isoLAN – automatisch eine Anti-Lockout-Regel, die den Zugriff auf die Firewall unabhängig von eigenen Firewall-Regeln erlaubt. Da diese Regel vor den eigenen Regeln ausgewertet wird, würde eine Sperrregel für die Firewall Dienste aus dem isoLAN nicht greifen. Da der administrative Zugriff auf die OPNsense-WebUI bereits über das CoreLAN eingerichtet ist (siehe Abschnitt 5.2), kann die Anti-Lockout-Regel für das isoLAN deaktiviert werden:

Menü: Firewall → Einstellungen → Erweitert

• Anti-Aussperrregel deaktivieren: Haken setzen

Eingabe Speichern

Hinweis: Sollte man sich danach versehentlich aus der WebUI aussperren, bleibt die Proxmox-VM-Konsole als Fallback erhalten – dort lässt sich über das Konsolenmenü (z. B. Option 1) Assign interfaces oder 13) Restore a backup) wieder eingreifen.

8.4 Firewall-Regeln für LAN (isoLAN)

Die bereits in den Punkten 6 und 8.2 erstellten Regeln (1 / 2) und Routen 8.1 steuern die Kommunikation zwischen dem WAN-Netzwerk (CoreLAN), der Firewall und dem LAN-Netzwerk (isoLAN). Standardmäßig hat das LAN-Netzwerk uneingeschränkten Zugriff auf das WAN-Netzwerk sowie die Firewall selbst. In diesem Fall ist dies jedoch nicht gewünscht, da das WAN-Netzwerk (CoreLAN) das sichere Netz darstellt, während das LAN-Netzwerk (isoLAN) als unsicher eingestuft wird. Da der Zugriff vom WAN-Netzwerk auf die Dienste der Firewall standardmäßig gesperrt ist, sind für den Betrieb des OPNsense-DHCP- und DNS-Servers drei weiter Regeln (3,4,5) erforderlich.

• Regel 3 und 4 gewähren dem WAN-Netzwerk Zugriff auf den OPNsense DHCP- und DNS-Server.
• Regel 5 sperrt den WAN Zugriff auf alle anderen Dienste, sodass nur der DNS- und DHCP-Server von OPNsense im WAN-Netzwerk erreichbar sind.
• Regel 6 und 7 sperren den WAN-Netzwerk Zugriff auf geschützte Netze.
• Regel 8 und 9 gewähren dem WAN-Netzwerk Zugriff auf das Internet (Regel werden meist automatisch erstellt).

Menü: Firewall → Regeln, jeweils neue Regel über “+” mit Schnittstelle: isoLAN. Reihenfolge von oben nach unten:

#	Aktion	NIC	Version	Protokoll	Quelle	Quellport	Ziel	Zielport	Zweck
1	Erlauben	WAN	IPv4	beliebig	WAN network (CoreLAN)	beliebig	Diese Firewall	beliebig / 443	WebUI-Zugriff aus CoreLAN erlauben (Regel aus 5.2)
2	Erlauben	WAN	IPv4	beliebig	beliebig	beliebig	LAN network (isoLAN)	beliebig	Zugriff auf isoLAN Netzwerk erlauben
3	Erlauben	LAN	IPv4	TCP/UDP	isoLAN network	beliebig	Diese Firewall	53	DNS-Auflösung über OPNsense-Resolver
4	Erlauben	LAN	IPv4	UDP	isoLAN network	beliebig	Diese Firewall	67	DHCP-Anfragen an OPNsense
5	Blockieren	LAN	IPv4	beliebig	isoLAN network	beliebig	Diese Firewall	beliebig	Rest des Zugriffs auf die Firewall selbst sperren (WebUI, SSH, Ping etc.)
6	Blockieren	LAN	IPv4	beliebig	isoLAN network	beliebig	CoreLAN network	beliebig	CoreLAN komplett sperren
7	Blockieren	LAN	IPv4	beliebig	isoLAN network	beliebig	Einzelner Host oder Netzwerk: 192.168.2.0/24	beliebig	Beispiel für ein weiteres, mit CoreLAN verbundenes Netz (z. B. VPN)
8	Erlauben	LAN	IPv4	beliebig	isoLAN network	beliebig	beliebig	beliebig	restlicher IPv4-Traffic = Internetzugriff (automatisch angelegt)
9	Erlauben	LAN	IPv6	beliebig	isoLAN network	beliebig	beliebig	beliebig	restlicher IPv6-Traffic = Internetzugriff (automatisch angelegt)

Um nicht jedes private Netzwerk (Regeln 6/7) einzeln in der Firewall konfigurieren zu müssen, können mithilfe der passenden Netzwerkmaske (CIDR) ganze private IP-Bereiche zusammengefasst und gesperrt werden. Die Einstellung erfolgt über die Ziel-IP bzw. das Zielnetzwerk der Firewall-Regel.

• 192.168.1.0/24 → 192.168.1.0–192.168.1.255 (256 Adressen)
• 192.168.0.0/16 → 192.168.0.0–192.168.255.255 (65.536 Adressen)

Wichtig zur Richtung: Bei allen Regeln muss die Richtung auf “Eingehend” stehen (Traffic, der auf dem isoLAN-Interface ankommt), nicht “Ausgehend”. Eine versehentlich auf “Ausgehend” gestellte Regel matcht praktisch nie und wird von der darunterliegenden Allow-Regel überdeckt.

Wichtig zur Reihenfolge: Die Blockierungsregeln (5-7) müssen vor den Erlauben-Regeln für den Internetzugriff (8-9) stehen, da nach dem Prinzip “erste Übereinstimmung gewinnt” ausgewertet wird. Die Reihenfolge kann in der Übersicht bei Bedarf angepasst werden.

Hinweis bei mehreren Netzen innerhalb des CoreLAN (z. B. VPN): Existieren neben 192.168.1.0/24 weitere, mit dem CoreLAN verbundene Netze (z. B. ein VPN-Netz wie 192.168.2.0/24), sind diese von der Sperrung in Abschnitt 6.3, Regel 4 (“Blockieren, isoLAN → CoreLAN network”) nicht automatisch mit erfasst – es gibt keine automatische Sperre für “alles, was mit CoreLAN verbunden ist”. Für jedes weitere Netz muss auf dem isoLAN-Interface eine eigene, zusätzliche Blockierungsregel angelegt werden; ein konkretes Beispiel dafür ist bereits als Regel 5 in der Tabelle in Abschnitt 6.2 enthalten (Blockieren, Ziel: Einzelner Host oder Netzwerk 192.168.2.0/24, Beschreibung “Deny isoLAN => VPNLAN”).

---

9. Tipps, Hinweise und mögliche Fehlerquellen

Outbound-NAT ist für den Internetzugriff nicht grundsätzlich erforderlich

Für den Internetzugriff des isoLAN ist eine Outbound-NAT-Regel nicht zwingend erforderlich, sofern das übergeordnete Netzwerk bzw. der Router eine entsprechende Route zum isoLAN kennt. In vielen typischen Heimnetzwerk-Szenarien ist diese Route jedoch nicht vorhanden.

In diesem Fall kann OPNsense den Datenverkehr des isoLAN per Outbound NAT auf seine CoreLAN-Adresse (192.168.1.91) maskieren. Der Router im CoreLAN sieht dadurch ausschließlich die Adresse der OPNsense-Firewall und benötigt keine eigene Route zum isoLAN.

Unter Firewall → NAT → Quell-NAT kann hierfür die automatische Erzeugung von Outbound-NAT-Regeln verwendet werden. OPNsense erstellt dabei automatisch eine Regel, die Verbindungen aus dem isoLAN (192.168.10.0/24) beim Verlassen über das CoreLAN/WAN-Interface auf die entsprechende OPNsense-Adresse maskiert.

Hinweis: Ob Outbound NAT tatsächlich erforderlich ist, hängt vom vorhandenen Routing ab. Bei einer korrekt eingerichteten statischen Route zum isoLAN auf dem vorgelagerten Router kann darauf verzichtet werden.

Fehlerquelle: „Antwort an“ (Reply-to)

Falls der Zugriff vom CoreLAN auf das isoLAN trotz korrekter Routing- und Firewall-Konfiguration nicht funktioniert, kann die OPNsense-Option „Antwort an“ (Reply-to) die Ursache sein.

OPNsense kann für Regeln auf dem CoreLAN-Interface standardmäßig das dort konfigurierte Gateway als festen Rückweg für Antwortpakete verwenden. In bestimmten Netzwerktopologien führt dies dazu, dass Antwortpakete nicht direkt an den anfragenden CoreLAN-Client zurückgesendet werden.

Zur Behebung kann bei der entsprechenden Firewall-Regel „Antwort an“ → „Deaktivieren“ gesetzt werden:

1. Die betreffende Firewall-Regel über das Stift-Symbol bearbeiten.
2. „Erweiterter Modus“ aktivieren.
3. Im Bereich „Quellrouting“ das Feld „Antwort an“ suchen.
4. „Deaktivieren“ auswählen und die Regel speichern.

Dadurch verwendet OPNsense für die Antwortpakete nicht mehr das durch Reply-to vorgegebene Gateway, sondern das normale Routing der Firewall.

---

by Speefak