OPNsense - VLAN und Netzwerksegmentierung

Aus maxTechCorner
(Weitergeleitet von OPNsense VLAN)

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (Interfaces → Devices → VLAN, Interfaces → Assignments)
BereichIT-Security
Dauerca. 30 Minuten (drei VLANs über einen Trunk inkl. Firewall-Regeln)
RechteAdministrator (OPNsense-WebUI), Zugriff auf die Switch-Konfiguration
StandOktober 2026 (OPNsense 26.7.5)

VLANs in OPNsense teilen ein physisches Netzwerk in mehrere logisch getrennte Netze – etwa für Arbeitsplätze, Server, Telefonie, Gäste und IoT-Geräte. Die OPNsense ist dabei der Router zwischen den VLANs: Jedes VLAN erhält eine eigene Schnittstelle mit eigenem Netz, eigenem DHCP und eigenen Firewall-Regeln. So entsteht eine wirksame Netzwerksegmentierung, die die Ausbreitung von Angriffen begrenzt und Gäste oder unsichere Geräte vom Firmennetz fernhält.

Dieser Artikel zeigt Planung und Einrichtung mit OPNsense 26.7: VLAN-Grundlagen, die Verbindung zum Switch über einen Trunk-Port (optional mit LAGG/LACP), VLAN-Schnittstellen, Zuweisung und Adressen, DHCP, Firewall-Regeln für Inter-VLAN-Routing, Sonderfälle wie Provider-VLANs und QinQ sowie die Fehlersuche.

VLAN-Grundlagen

Begriff Bedeutung
VLAN-Tag (802.1Q) 4-Byte-Kennung im Ethernet-Rahmen mit der VLAN-ID (1–4094) und der Priorität (PCP, 0–7)
Tagged Rahmen werden mit Tag übertragen – mehrere VLANs über eine Leitung (Trunk)
Untagged Rahmen ohne Tag; der Switch-Port ordnet sie einem Standard-VLAN zu (Access-Port für Endgeräte)
Trunk Verbindung, über die mehrere VLANs tagged laufen – z. B. zwischen Switch und OPNsense
Inter-VLAN-Routing Verkehr zwischen VLANs läuft über die OPNsense und wird dort per Firewall-Regeln kontrolliert
QinQ (802.1ad) zwei gestapelte VLAN-Tags, z. B. bei Provider-Netzen
VLANs auf der OPNsense: Ein Trunk (optional als LAGG mit LACP) trägt die VLANs 5 (LAN), 20 (DMZ) und 33 (Gäste) tagged zum Switch; die OPNsense routet zwischen den VLANs und entscheidet per Firewall-Regeln, welcher Verkehr erlaubt ist.

Planung

Beispiel nach dem Muster der OPNsense-Dokumentation:

VLAN Zweck Netz Firewall-Adresse
5 LAN (Arbeitsplätze) 192.168.5.0/24 192.168.5.1
20 DMZ (Webserver) 192.168.20.0/24 192.168.20.1
33 Gäste-WLAN 192.168.33.0/24 192.168.33.1
40 VoIP-Telefone 192.168.40.0/24 192.168.40.1
50 IoT / Gebäudetechnik 192.168.50.0/24 192.168.50.1

Tipps aus der Praxis:

  • VLAN-ID im Netz abbilden (VLAN 20 → 192.168.20.0/24) – erleichtert die Fehlersuche.
  • Jedes VLAN braucht ein eigenes, eindeutiges Netz; bei mehreren Standorten (VPN) dürfen die VLAN-IDs gleich sein, die Netze aber nicht.
  • Ein eigenes Management-VLAN für Switches, Access Points und die Verwaltung der Firewall.

Switch vorbereiten

Der Port bzw. die Portgruppe zur OPNsense wird als Trunk konfiguriert, über den alle VLANs tagged laufen:

Verbindung Tagged Untagged Port-Modus
Switch ↔ OPNsense 5, 20, 33, 40, 50 keines Trunk
Switch ↔ PC – 5 Access
Switch ↔ Webserver – 20 Access
Switch ↔ Access Point 33 (Gast-SSID) Management-VLAN Trunk (gemischt)
Switch ↔ Telefon 40 5 (PC hinter dem Telefon) je nach Hersteller (Voice-VLAN)
HinweisLaut OPNsense-Dokumentation sollten auf dem Trunk zur OPNsense keine tagged und untagged VLANs gemischt werden: Je nach Switch können sonst Router Advertisements, DHCP, CARP und andere Broadcasts zwischen den Netzen „durchsickern“. Lässt der Switch kein Trunk ohne Native VLAN zu, ein ungenutztes „Opfer-VLAN“ (z. B. 3999) als Native VLAN setzen und nirgends sonst verwenden. Mehrere Ports zum selben Switch nie per Bridge, sondern per LAGG verbinden – sonst entsteht eine Schleife.

Schritt 1 (optional): LAGG mit LACP

Ein LACP-Verbund aus zwei oder mehr Ports erhöht Bandbreite und Ausfallsicherheit und schafft eine Abstraktionsebene: Die VLANs hängen am LAGG, nicht an einem bestimmten Port.

  • Mitglieder dürfen nicht zugewiesen sein (Interfaces → Assignments prüfen).
  • Interfaces → Devices → LAGG → +: Parent = z. B. igc0 und igc1, Proto lacp, Fast timeout aus, Hash Layers wie am Switch.
  • Am Switch denselben LACP-Verbund anlegen und den Status prüfen.

Ein LAGG kann auch mit nur einem Port angelegt werden, um später einfach Ports zu ergänzen. Protokolle, Hash Layers, Timeouts und Redundanz über Switch-Stack oder MLAG beschreibt der Artikel LAGG und LACP auf der OPNsense.

Schritt 2: VLAN-Geräte anlegen

Interfaces → Devices → VLAN → + je VLAN:

Feld Beispiel Hinweis
Device vlan0.20 leer lassen = Name wird erzeugt; eigene Namen müssen mit vlan bzw. qinq beginnen
Parent lagg0 oder igc0 nur VLAN-fähige Schnittstellen werden angeboten
VLAN tag 20 1–4094
VLAN priority Best Effort (0) PCP 0–7, z. B. Voice (5) für ein Telefonie-VLAN – wirkt nur, wenn Switches die Priorität auswerten
Protokoll Automatic 802.1Q, bei VLAN auf VLAN automatisch 802.1ad (QinQ)
Description lagg0_vlan20_DMZ sprechendes Schema aus Schnittstelle, VLAN und Zweck

Seit OPNsense 26.7.3 können VLAN-Geräte auch Mitglied einer Bridge sein.

Schritt 3: Zuweisen und Adressen vergeben

  1. Interfaces → Assignments: die VLAN-Geräte als neue Schnittstellen zuweisen und sprechend benennen. Die Parent-Schnittstelle bleibt in der Regel unzugewiesen (nur in Sonderfällen ohne IP-Konfiguration zuweisen, etwa um Linkgeschwindigkeiten festzulegen).
  2. Jede neue Schnittstelle öffnen, Enable setzen, IPv4 Configuration Type = Static IPv4 und die Firewall-Adresse eintragen (z. B. 192.168.20.1/24); für IPv6 z. B. Identity Association mit eigener Prefix ID.
  3. Speichern und anwenden.

Schritt 4: DHCP und DNS je VLAN

  • DHCP: für jedes VLAN einen Bereich anlegen – mit Dnsmasq (eigene Domain je VLAN, z. B. dmz.internal) oder Kea.
  • DNS: Unbound beantwortet Anfragen aus allen zugewiesenen Schnittstellen; Blocklisten lassen sich per Policy pro VLAN unterschiedlich gestalten (z. B. strenger im Gäste- und IoT-VLAN).

Schritt 5: Firewall-Regeln und Inter-VLAN-Routing

Neue Schnittstellen haben keine Pass-Regeln – zunächst wird alles blockiert. Die Regeln unter Firewall → Rules (Schnittstelle wählen; Grundlagen siehe Firewall-Regeln in OPNsense) legen fest, was jedes VLAN darf. Ein bewährtes Muster:

VLAN Erlaubt Gesperrt
LAN Internet, DMZ (z. B. HTTPS), Drucker, Server-Dienste Management-Zugriff nur für Admin-Geräte
DMZ Internet (Updates), gezielte Ziele (z. B. Datenbank) alle internen Netze
Gäste Internet, DNS der Firewall alle internen Netze, Weboberfläche der Firewall
VoIP Telefonanlage bzw. SIP-Anbieter, NTP, DNS übrige interne Netze
IoT nur benötigte Cloud-Dienste bzw. lokale Steuerzentrale interne Netze, ggf. Internet

Praktisch ist ein Alias RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16): Regel 1 Block → RFC1918, Regel 2 Pass → any – so erhalten Gäste und DMZ Internet, aber keinen Zugriff auf interne Netze. Für mehrere VLANs mit identischen Regeln bieten sich Interface-Gruppen (Firewall → Groups) an.

Gäste-VLANs lassen sich zusätzlich mit dem Captive Portal absichern und per Traffic Shaper in der Bandbreite begrenzen.

Sonderfälle

Provider-VLAN am WAN

Viele Glasfaser- und DSL-Anschlüsse erwarten den Internetverkehr in einem bestimmten VLAN – bei der Deutschen Telekom z. B. VLAN 7 mit PPPoE. Dazu ein VLAN-Gerät mit dem WAN-Port als Parent und dem Tag des Providers anlegen und darauf die PPPoE-Verbindung (Interfaces → Devices → Point-to-Point) bzw. die WAN-Schnittstelle konfigurieren. Fordert der Provider eine bestimmte Priorität, wird sie unter VLAN priority gesetzt (für DHCPv6 gibt es im WAN-Interface die Option Use VLAN priority).

QinQ (802.1ad)

Für Provider- oder Rechenzentrumsnetze mit doppelten Tags wird ein VLAN auf ein anderes VLAN gesetzt; OPNsense wählt dann automatisch 802.1ad und Gerätenamen mit qinq. Siehe auch QinQ.

VLANs in virtuellen Umgebungen

In Proxmox, VMware oder Hyper-V entweder die VLANs im Hypervisor an getrennte virtuelle Netzwerkkarten übergeben (dann kein VLAN in der OPNsense nötig) oder einen Trunk an die VM durchreichen und die VLANs in der OPNsense anlegen. Bei VMware muss die Portgruppe dafür VLAN-ID 4095 (alle VLANs) verwenden, bei Proxmox die Bridge „VLAN aware“ sein.

Hochverfügbarkeit

Im CARP-Cluster müssen VLAN-Geräte und Zuweisungen auf beiden Firewalls identisch sein (gleicher Parent, gleiches Tag, gleiche interne Bezeichnung wie opt3). Pro VLAN wird eine eigene CARP-Adresse mit eigener VHID angelegt; DHCP verteilt diese als Gateway.

Typische Probleme und Lösungen

Symptom Ursache und Lösung
Clients im VLAN erhalten keine Adresse VLAN am Switch-Trunk nicht erlaubt, Access-Port im falschen VLAN, DHCP-Bereich fehlt oder Schnittstelle nicht aktiviert.
Kein Zugriff zwischen VLANs Firewall-Regel auf der Quell-Schnittstelle fehlt (Regeln wirken eingehend) oder Ziel-Host hat eine eigene Firewall bzw. ein falsches Gateway.
Verkehr „leckt“ zwischen Netzen, seltsame DHCP-/RA-Effekte Tagged und untagged auf dem Trunk gemischt – Native VLAN entfernen bzw. Opfer-VLAN nutzen.
Sporadische Verbindungsabbrüche auf VLANs Treiberprobleme mit Hardware-Offloading – unter Interfaces → Settings VLAN Hardware Filtering deaktiviert lassen (Standard).
Große Pakete gehen verloren MTU: Parent und Switch müssen 1500 Byte plus Tag verarbeiten; bei QinQ ggf. höhere MTU am Parent.
Schleife / Broadcast-Sturm Mehrere Ports per Bridge zum selben Switch – stattdessen LAGG mit LACP.
LAGG kommt nicht hoch Protokoll oder Hash am Switch abweichend, Mitglieder noch zugewiesen – siehe LAGG-Fehlersuche.

Zur Diagnose helfen Interfaces → Overview (Status, Zähler) und Interfaces → Diagnostics → Packet Capture auf dem Parent, um zu prüfen, ob Rahmen mit dem erwarteten Tag ankommen.

Fazit

VLANs sind auf der OPNsense schnell eingerichtet und die Grundlage jeder sauberen Netzwerksegmentierung: ein Trunk zum Switch (optional als LACP-Verbund), je VLAN ein Gerät, eine Schnittstelle mit eigenem Netz und eigenen Regeln. Die eigentliche Sicherheit entsteht in den Firewall-Regeln für das Inter-VLAN-Routing – Gäste, DMZ und IoT erhalten nur das, was sie wirklich brauchen.

Unterstützung von m.a.x. it

Sie möchten Ihr Netzwerk mit VLANs segmentieren, Gäste-, IoT- und Telefonie-Netze sauber trennen oder Switches und Firewall gemeinsam neu strukturieren? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen