OPNsense VLAN-Routing: 6 Best Practices für Mittelstands-Netze

Ein flaches /24-Netz war vor zehn Jahren noch akzeptabel — heute ist es ein Befund im IT-Audit. Cyber-Versicherer, NIS-2 und die eigene Risikoabwägung fordern sauber segmentierte Netze, in denen ein kompromittierter Drucker nicht zum Sprungbrett für den Domain Controller wird. OPNsense 25.7 bringt als FreeBSD-basierte Firewall alle Werkzeuge mit, um VLANs, DHCP, DNS und Firewall-Regeln zentral und nachvollziehbar zu verwalten — vorausgesetzt, das Design stimmt von Anfang an.

In diesem Artikel zeigen wir sechs Best Practices, die wir in OPNsense-Projekten für Mittelständler in Bayern und ganz Süddeutschland regelmäßig umsetzen. Es geht nicht um Theorie, sondern um konkrete Konfigurationen, die Audits bestehen und im Tagesgeschäft funktionieren.

1. Management-VLAN strikt isolieren

Der häufigste Fehler in gewachsenen Netzen: Switches, Access Points, USVs und ILO-Karten hängen im selben VLAN wie die Office-Clients. Ein einziger infizierter Mitarbeiter-Laptop sieht damit die gesamte Infrastruktur. Richten Sie ein dediziertes VLAN — typischerweise VLAN 10 — ausschließlich für Management-Interfaces ein.

Konkret bedeutet das:

• Eigener IP-Bereich, z. B. 10.10.10.0/24
• Zugriff nur über Jump-Host oder explizite Admin-Workstation
• Kein DHCP, sondern statische Reservierungen
• Logging aller Verbindungen via OPNsense Suricata

In OPNsense legen Sie das VLAN unter Schnittstellen > Andere Arten > VLAN an, weisen es einem physischen Port zu und versehen die Firewall-Schnittstelle mit einem aussagekräftigen Alias wie MGMT. Die Floating-Regel block log quick from any to MGMT_net als erste Regel verhindert, dass aus Versehen aus anderen VLANs zugegriffen wird — Ausnahmen werden explizit oberhalb erlaubt.

2. DHCP pro VLAN — mit Option 43 für VoIP

Jedes VLAN bekommt seinen eigenen DHCP-Scope. OPNsense nutzt seit Version 24.7 Kea als modernen DHCP-Server, der pro Schnittstelle granular konfigurierbar ist. Für VoIP-VLANs (typischerweise VLAN 20) ist DHCP-Option 43 entscheidend, damit Telefone von Snom, Yealink oder Gigaset Pro automatisch ihre Provisioning-URL finden.

VLAN	Zweck	Subnetz	DHCP-Range	Besonderheit
10	Management	10.10.10.0/24	keine	Statisch
20	VoIP	10.10.20.0/24	.50-.200	Option 43, eigene DNS
30	Clients	10.10.30.0/24	.50-.250	Standard
40	Server	10.10.40.0/24	keine	Statisch
50	IoT	10.10.50.0/24	.50-.250	Internet-only
60	Gäste	10.10.60.0/24	.50-.250	Captive Portal

Die Option 43 lässt sich in Kea per Custom-Option setzen, z. B. für Snom-Telefone mit der Provisioning-URL der Auerswald- oder 3CX-Anlage:

option-data:
  - name: vendor-encapsulated-options
    code: 43
    data: "https://pbx.firma.local/provisioning/{mac}.xml"

3. Inter-VLAN-Firewall: Default Deny, explizite Erlaubnis

Der größte Sicherheitsgewinn entsteht durch konsequente Default-Deny-Regeln zwischen allen VLANs. OPNsense erlaubt standardmäßig allen ausgehenden Traffic auf einer Schnittstelle — das müssen Sie als erstes ändern.

Empfohlenes Vorgehen pro VLAN-Interface:

1. Regel 1: Erlauben DNS zur OPNsense (Port 53 TCP/UDP)
2. Regel 2: Erlauben DHCP zur OPNsense (Port 67/68)
3. Regel 3: Erlauben explizite Zielnetze, z. B. VoIP -> PBX-Server
4. Letzte Regel: block log from VLAN_net to any

Mit Aliases bleiben die Regelsätze übersichtlich. Definieren Sie etwa RFC1918, PBX_HOSTS, BACKUP_TARGETS und referenzieren Sie diese statt einzelner IPs. Bei größeren Umgebungen lohnt sich der Einsatz von Zonen-basierten Regelvorlagen via Floating Rules, damit nicht jede Schnittstelle dupliziert gepflegt werden muss.

4. MAC-Tracking gegen Schatten-Geräte

In gewachsenen Netzen tauchen ständig neue Geräte auf — private Notebooks, Smart-TVs in Besprechungsräumen, ungeplante Drucker. Mit dem OPNsense-Plugin os-net-mgmt und Kea-DHCP-Logs identifizieren Sie unbekannte MAC-Adressen automatisch.

Praktisch umgesetzt:

• Kea-DHCP loggt jeden Lease nach /var/log/dhcpd/
• Ein cron-Job vergleicht die MACs gegen eine Whitelist (CSV oder LDAP-Export)
• Unbekannte Geräte landen automatisch in einem Quarantäne-VLAN (z. B. VLAN 99)
• Benachrichtigung an die IT per E-Mail oder Webhook

Für Umgebungen mit höheren Compliance-Anforderungen empfehlen wir zusätzlich 802.1X mit FreeRADIUS auf den Switches. Damit wird Port-basierte Authentifizierung möglich — ein unbekanntes Gerät erhält gar nicht erst einen Link.

5. DNS pro VLAN mit Unbound Views

Unbound, der in OPNsense integrierte DNS-Resolver, unterstützt seit Langem Views — also unterschiedliche Antworten je nach Quell-Netz. Das ist Gold wert: Server-VLAN-Clients erhalten interne IPs für die Domain Controller, Gäste-VLAN-Clients hingegen nur öffentliche Antworten.

Beispielkonfiguration in der /usr/local/etc/unbound.opnsense.d/views.conf:

access-control-view: 10.10.40.0/24 internal
access-control-view: 10.10.60.0/24 guest

view:
  name: "internal"
  local-zone: "firma.local" transparent
  local-data: "dc01.firma.local. IN A 10.10.40.10"

view:
  name: "guest"
  local-zone: "firma.local" refuse

Damit ist sichergestellt, dass aus dem Gäste-WLAN niemals interne Hostnamen aufgelöst werden — ein klassisches Reconnaissance-Hindernis. Kombiniert mit DNS-over-TLS Forwarding zu Quad9 oder Cloudflare schließen Sie zusätzlich DNS-Leaks.

6. IoT-VLAN: nur Internet, sonst nichts

Smarte Heizungen, Drucker mit Cloud-Anbindung, Konferenzraum-Beamer, Zutrittssysteme — die IoT-Welt ist ein Sicherheits-Albtraum, weil Firmware oft Jahre nicht gepatcht wird. Das Schutzkonzept ist einfach: IoT-Geräte dürfen ausschließlich ins Internet, niemals ins LAN.

Die Regelsätze für VLAN 50 (IoT):

pass in on IOT proto udp from IOT_net to OPNsense port 53
pass in on IOT proto udp from IOT_net to OPNsense port 67
pass in on IOT proto { tcp udp } from IOT_net to !RFC1918 any
block in log on IOT from IOT_net to any

Die Magie steckt in !RFC1918 — damit ist jeglicher Traffic in private Netze blockiert. IoT-Geräte erreichen ihre Cloud, aber weder Server noch Clients. Für Multicast-Discovery (z. B. AirPlay, Chromecast) zwischen Office- und IoT-VLAN nutzen Sie das Plugin os-mdns-repeater statt offener Firewall-Regeln.

Praxiserfahrung: kleine Schritte, große Wirkung

In den meisten Mittelstandsprojekten setzen wir diese sechs Practices schrittweise um — nicht alles auf einmal. Typischer Fahrplan:

1. Management-VLAN trennen (Quick Win, Woche 1)
2. Server-VLAN aus dem Client-Netz herausnehmen (Woche 2)
3. VoIP-VLAN inkl. QoS einrichten (Woche 3)
4. IoT- und Gäste-VLAN aktivieren (Woche 4)
5. Unbound-Views und DHCP-Optimierung (Woche 5-6)

Wichtig: Vor jedem Schritt ein Backup der OPNsense-Konfiguration ziehen und in der Wartungszeit ausrollen. OPNsense bietet mit System > Konfiguration > Sicherungen eine versionierte Historie, auf die sich jederzeit zurückrollen lässt.

DATAZONE unterstützt Sie

Wir planen und betreiben OPNsense-Cluster für Mittelständler in Bayern und Süddeutschland — vom Single-Site-Setup bis zur Multi-Standort-Lösung mit WireGuard-Mesh. Wir analysieren Ihr aktuelles Netz, entwerfen ein passendes VLAN-Schema und übernehmen die Migration im laufenden Betrieb. Mehr Informationen finden Sie auf unseren Seiten zu OPNsense-Beratung und Linux-Infrastruktur. Sprechen Sie uns an unter datazone.de/kontakt — wir freuen uns auf Ihr Projekt.