OPNsense in Produktion: Von der Ersteinrichtung zu VLANs, WireGuard, HA und automatisierter Policy-Verwaltung

OPNsense ist eine FreeBSD-basierte, modular erweiterbare Firewall-Distribution mit einem starken Fokus auf Sicherheit, Stabilität und DevOps-freundlicher Automatisierung. In diesem Tutorial bauen wir eine produktionsreife Edge-Firewall inklusive VLAN-Segmentierung, DNS-Stack (Unbound) mit DoT, konsistentem Firewall-Regelwerk, WireGuard-Remote-Access, Intrusion Prevention (Suricata), Hochverfügbarkeit via CARP/pfsync sowie API-gestützter Automatisierung. Ziel ist ein reproduzierbares Setup mit klaren Prinzipien und nachvollziehbaren Schritten – für Teams, die Infrastruktur wie Software behandeln.

Die Anleitung richtet sich an fortgeschrittene Administratoren, SREs und DevOps-Teams, die eine robuste Netzwerk-Sicherheitsarchitektur aufbauen oder modernisieren möchten. Wir setzen belastbare Best Practices ein und zeigen neben GUI-Schritten auch CLI/API-Optionen für GitOps-Workflows. Wo sinnvoll verlinken wir auf Primärquellen und Herstellerdokumentation zur Vertiefung.

Trust-Links und weiterführende Ressourcen: OPNsense Dokumentation, FreeBSD, pf.conf Referenz, WireGuard, Suricata IDS/IPS, HAProxy, Let's Encrypt.

Überblick und Zielarchitektur

Wir entwerfen eine Edge-Firewall mit folgenden Bausteinen: ein WAN-Uplink (Public), ein LAN-Mgmt-VLAN, dedizierte VLANs für Infrastruktur (INFRA), Entwickler (DEV), Produktion (PROD), Gast (GUEST) und VPN (WG). Unbound dient als lokaler rekursiver Resolver mit DNSSEC und optionalem DNS-over-TLS zu vertrauenswürdigen Upstream-Resolvern. Ausgehender Traffic wird über NAT gesteuert; Ost-West-Kommunikation ist strikt segmentiert. Remote-Zugriff realisieren wir mit WireGuard inkl. Geräteprofilen. Für Sichtbarkeit aktivieren wir NetFlow/Insight und leiten Logs an ein zentrales System. HA wird mit zwei OPNsense-Knoten per CARP-VIPs, pfsync und XML-RPC-Synchronisation umgesetzt.

High-Level-Ziele:

• Deterministische Segmentierung per VLANs und Aliases
• Explizite, minimalistische Firewall-Regeln (Default-Deny)
• Stateful Inspection mit feinkörniger NAT-Kontrolle
• Reproduzierbarkeit durch API/GitOps, testbare Änderungen
• Fehlerdomänen begrenzen (HA, Boot-Environments, Backups)
• Messbarkeit (NetFlow, zentrale Logs, Health-Checks)

Voraussetzungen

Hardware/Hypervisor:

• 2 x x86_64-Firewall-Appliance mit AES-NI und mindestens 2 NICs (für HA empfehlenswert: 4 NICs)
• Alternativ: Virtuell auf Proxmox/ESXi/KVM mit paravirtualisierten NICs (VirtIO/vmxnet3)
• Switch mit 802.1Q VLAN-Unterstützung

Kenntnisse:

• Netzwerkgrundlagen (VLANs, Routing, NAT, DNS)
• pf-Firewall-Konzepte (States, Floating Rules, Quick/pass)
• Grundlagen FreeBSD/Unix-CLI

Sonstiges:

• OPNsense ISO-Image und Zugang zur seriellen Konsole oder VNC
• Plan für VLAN-IDs, Subnetze, IP-Adressierung, Namenskonventionen

Schritt 1 – Installation und Basis-Konfiguration

Installieren Sie OPNsense auf der Hardware oder im Hypervisor. Für virtuelle Deployments deaktivieren Sie in OPNsense später Hardware-Offloading-Features, um mit netmap/IPS stabil zu bleiben (siehe Performance-Tuning).

Erstkonfiguration nach der Installation:

• Assign interfaces: WAN (z. B. igb0), LAN (z. B. igb1)
• WAN per DHCP oder statisch konfigurieren
• LAN statische IP, z. B. 10.10.0.1/24
• Admin-Passwort setzen, SSH optional nur auf Management-VLAN erlauben

WebGUI-Wizard: System > Wizard führt Sie durch WAN/LAN, Hostname, DNS und NTP. Nutzen Sie direkt sinnvolle Hostnamen (z. B. opn1, opn2 für HA) und setzen Sie die Zeitzone korrekt. Verifizieren Sie Internet-Konnektivität (Lobby > Dashboard > Interfaces) und aktualisieren Sie Firmware (System > Firmware > Updates).

Schritt 2 – VLAN-Design und Interface-Zuordnung

Beispiel-Planung:

• VLAN 10 – MGMT – 10.10.10.0/24
• VLAN 20 – INFRA – 10.20.0.0/24
• VLAN 30 – DEV – 10.30.0.0/24
• VLAN 40 – PROD – 10.40.0.0/24
• VLAN 50 – GUEST – 10.50.0.0/24
• VLAN 60 – WG (Tunnel-Subnetz) – 10.60.0.0/24

GUI-Schritte:

• Interfaces > Other Types > VLAN > Add: Parent interface (z. B. igb1-Trunk), VLAN tag (10, 20, …), Description setzen.
• Assignments: Weisen Sie jedem VLAN ein logisches Interface zu (z. B. OPT1, OPT2 …), aktivieren und vergeben Sie sprechende Namen (MGMT, INFRA, DEV, PROD, GUEST).
• Interface-Netz setzen, z. B. MGMT 10.10.10.1/24, INFRA 10.20.0.1/24 usw.

DHCP-Server pro VLAN:

• Services > DHCPv4 > [VLAN]: Aktivieren, Range definieren, Reservierungen für kritische Hosts. Optional: Option 6 (DNS) auf Firewall-IP.

CLI-Checks:

ifconfig
netstat -rn

Die VLAN-Interfaces sollten als vlanX sichtbar sein. Prüfen Sie die Routen und erreichen Sie aus einem Client per Ping die VLAN-Gateway-IP.

Schritt 3 – DNS mit Unbound und DNSSEC/DoT

Unbound als lokaler Resolver sichert interne Namensauflösung, Zwischenspeicherung und optionale Filter. Für Datenschutz lässt sich Upstream per DNS-over-TLS konfigurieren.

GUI-Schritte:

• Services > Unbound DNS > General: Enable, Listen Interfaces (alle internen VLANs), Register DHCP leases und static mappings aktivieren.
• DNSSEC aktivieren. Optional: DNS over TLS mit Forwarding-Mode und Upstream-Servern, z. B. 1.1.1.1@853, 9.9.9.9@853. Für DoT unter Services > Unbound > Advanced: server: tls-cert-bundle: /etc/ssl/cert.pem.
• Host Overrides für interne Services (z. B. git.lan, registry.lan).

Validierung:

drill example.com @10.10.10.1
unbound-control -c /var/unbound/unbound.conf status

Reload via CLI/API:

configctl unbound restart
# oder API (siehe weiter unten): /api/unbound/service/restart

Schritt 4 – Outbound NAT und Port-Weiterleitungen

Standardmäßig ist „automatic outbound NAT“ aktiv. Für feinere Kontrolle empfiehlt sich „Hybrid Outbound NAT“.

GUI-Schritte:

• Firewall > NAT > Outbound: Schalten Sie auf Hybrid um. Fügen Sie Regeln für spezielle Anforderungen ein.
• Beispiel: Static-Port für bestimmte Protokolle (z. B. WireGuard Peers hinter NAT) – Quelle DEV, Ziel any, Protokoll UDP, Port 51820, Static-port aktivieren.
• Port-Forward für einen Webdienst in INFRA: Firewall > NAT > Port Forward – Interface WAN, TCP 443, Ziel 10.20.0.10:443, Reflection falls benötigt für Hairpin (Firewall > Settings > Advanced > Reflection).

CLI-Validierung:

pfctl -sr        # Regeln
pfctl -ss        # States
sockstat -l | grep pf

Best Practice: Minimalistische NAT-Regeln, Logging bei kritischen NATs aktivieren (zurückhaltend, um nicht zu fluten), Reflection sparsam einsetzen.

Schritt 5 – Firewall-Regelstrategie mit Aliases

Statt IP-Adresslisten in Regeln direkt zu pflegen, arbeiten Sie mit Aliases (Gruppierungen). Nutzen Sie FQDN-Aliases für dynamische Ziele, Netzwerk-Aliases für VLANs und Port-Aliases für Applikationen.

Alias-Setup:

• Firewall > Aliases > Add: Name DEVOPS_NET (Networks), Inhalt: 10.30.0.0/24, 10.20.0.0/24
• Alias MGMT_ADMINS (Hosts) mit Admin-Quell-IP-Ranges
• Alias SVC_WEB (Ports): 80,443

Regelprinzipien:

• Default Deny auf allen VLANs; nur explizit erlauben.
• Floating Rule: Block RFC1918/Bogon auf WAN, Quick gesetzt.
• VLAN-seitig: Allow from MGMT_ADMINS to This Firewall (SSH/HTTPS/NTP), Logging an.
• Inter-VLAN: Erlauben Sie nur notwendige Ost-West-Flüsse (z. B. DEV -> INFRA:443 für CI/CD).
• Ausgehend: DEV darf HTTP/HTTPS ins WAN, PROD restriktiver, GUEST nur HTTP/HTTPS und DNS an Firewall.

GUI-Beispielregel: Firewall > Rules > DEV – Action Pass, Proto TCP, Source DEV net, Dest any, Ports 80,443, Description „DEV outbound web“, Log enabled.

pf-Einblick (read-only):

pfctl -vvsr | less

Hinweis: Bearbeiten Sie pf nicht manuell; OPNsense generiert pf aus der GUI/Config. Die CLI dient zur Analyse und Validierung im Betrieb.

Schritt 6 – WireGuard Remote Access

WireGuard bietet performantes, modernes VPN. Wir setzen Road-Warrior-Zugänge für Mitarbeitende auf, die selektiven Zugriff auf DEV/INFRA benötigen.

Plugin installieren:

• System > Firmware > Plugins: os-wireguard installieren.

Server konfigurieren:

• VPN > WireGuard > Local: Add – Name wg0, Listen Port 51820, Generate Keypair, Tunnel Address 10.60.0.1/24.
• VPN > WireGuard > Peers: Add – Public Key des Clients, Allowed IPs 10.60.0.2/32, Description.
• VPN > WireGuard > Instances: Instance wg0 aktivieren und Peer zuordnen.
• Interfaces > Assignments: wg0 als Interface WG assignen, enable, keine IP nötig außer Tunnel-Subnetz wenn nicht in Local konfiguriert.

Firewall-Regeln:

• Firewall > Rules > WG: Erlauben UDP 51820 auf WAN (Port-Forward falls hinter NAT) und Pass-Regeln auf WG-Interface für Allowed-Routen (z. B. WG net -> DEV net TCP 443, ICMP für Diagnose).

NAT für WG-Clients ins Internet (falls gewünscht):

• Outbound NAT: Quelle 10.60.0.0/24 -> WAN, Port beliebig, Übersetzung: Interface Address.

Client-Konfiguration (Beispiel):

[Interface]
PrivateKey = <client_private_key>
Address = 10.60.0.2/32
DNS = 10.10.10.1

[Peer]
PublicKey = <server_public_key>
AllowedIPs = 10.20.0.0/24, 10.30.0.0/24
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25

OPNsense generiert auf Wunsch QR-Codes für Mobile Clients. Test: ping 10.20.0.1 von Client, dann Zugriff auf DEV/INFRA mit traceroute und tcpdump auf WG-Interface validieren.

Schritt 7 – IDS/IPS mit Suricata

Zur Netzwerksichtbarkeit und Prävention nutzen wir Suricata als IDS/IPS im netmap-Modus. Achten Sie auf NIC-Kompatibilität und Performance-Tuning.

Plugin und Grundkonfiguration:

• System > Firmware > Plugins: os-suricata installieren.
• Services > Intrusion Detection > Settings: Enable IDS. Für IPS: Enable IPS (inline) aktivieren.
• Interfaces: WAN (und optional bestimmte VLANs), nicht auf allen Interfaces gleichzeitig starten – gezielt & schrittweise vorgehen.
• Rulesets: ETOpen aktivieren (kostenlos), Emerging Threats PRO optional. Hyperscan (falls unterstützt) unter Performance.
• Home Networks: interne Netze definieren (MGMT/DEV/INFRA/PROD), um False Positives zu reduzieren.

Tuning und Offloading:

• System > Settings > Networking: Hardware Checksum Offloading, TSO, LRO deaktivieren, wenn IPS inline genutzt wird.
• CPU Pinning: Suricata Threads begrenzen und passend den NIC-Queues zuordnen (Advanced Einstellungen in Suricata).

Validierung:

suricata -V
service suricata status
/usr/local/bin/configctl ids status

Monitoring: Services > Intrusion Detection > Alerts – Regeln iterativ von Alert -> Drop schalten, basierend auf Telemetrie und Risiko.

Schritt 8 – Hochverfügbarkeit (HA) mit CARP, pfsync und XML-RPC

Für HA betreiben wir zwei identische OPNsense-Knoten (opn1/opn2). Wir nutzen CARP für virtuelle IPs (VIPs), pfsync für State-Synchronisation und XML-RPC für Konfig-Sync.

Netzwerk-Plan:

• Dediziertes SYNC-VLAN (z. B. VLAN 99, 10.99.0.0/30) nur zwischen opn1/opn2
• Auf jedem VLAN eine CARP-VIP (z. B. 10.10.10.1/24 als VIP, 10.10.10.2 opn1, 10.10.10.3 opn2)
• WAN-VIP sofern Provider/Upstream es erlaubt

GUI-Schritte Knoten 1:

• Firewall > Virtual IPs > Add: Type CARP, Interface MGMT, IP 10.10.10.1/24, VHID 10, Advskew 0 (Master), Shared Secret setzen.
• Wiederholen für weitere VLANs (entsprechende VHIDs wählen, z. B. 20, 30,…).
• System > High Availability > pfsync: Enable, Synchronize States über SYNC-Interface.
• System > High Availability > Settings: XML-RPC Sync, Peer IP (opn2), Admin-Credentials, welche Bereiche synchronisiert werden (NAT, Rules, DHCP, Unbound…).

Knoten 2 entsprechend, aber CARP Advskew höher (z. B. 100), gleicher VHID und Secret. Prüfen Sie CARP-Status unter Interfaces > Virtual IPs > Status. Failover testen (Interface down auf opn1) und Erreichbarkeit der VIPs validieren.

Beachten Sie ARP-Cache im Upstream (WAN): ggf. GRATUITOUS ARP und niedrige ARP-Caches beim Provider/Router sicherstellen. Für WAN-Redundanz auf Ebene Carrier ist zusätzlich VRRP/BGP oder Provider-spezifische HA nötig.

Schritt 9 – Reverse Proxy mit HAProxy und Let's Encrypt

Für interne Services hinter OPNsense empfiehlt sich eine TLS-Terminierung am Edge via HAProxy-Plugin mit automatischen Zertifikaten (ACME).

Plugins:

• System > Firmware > Plugins: os-haproxy, os-acme-client installieren.

ACME konfigurieren:

• Services > ACME Client: Account-Key erstellen, DNS-Provider-API konfigurieren (DNS-01 für Wildcard) oder HTTP-01-Challenge über Frontend-Pfad.
• Certificate Issue/Renew-Tasks definieren, Auto-Renew aktivieren.

HAProxy konfigurieren:

• Services > HAProxy > Settings: Enable.
• Backends: Zielserver (z. B. registry.lan:5000, git.lan:443), Health Checks.
• Public Frontend: Bind auf WAN:443, SNI-Routing je Hostname, TLS-Settings, ACME-Zertifikat zuordnen.
• Access Control Lists (ACL) für Pfad/Host-Matches, Stickiness falls nötig.

Firewall-Ports: WAN 80/443 zum HAProxy-Frontend erlauben, ggf. Port-Forwards entfernen, um doppelte Weiterleitungen zu vermeiden. Logging zur Fehleranalyse aktivieren.

Schritt 10 – Logging, Monitoring und NetFlow/Insight

Transparenz ist entscheidend. OPNsense bietet Insight (NetFlow/IPFIX) und flexible Syslog-Ziele.

Konfiguration:

• Reporting > Netflow: Enable, Exporter ggf. zu zentralem Collector (nProbe, Elastiflow) weisen.
• System > Settings > Logging / targets: Remote Syslog (RFC5424) zu Graylog/ELK/Splunk.
• Plugins: os-telegraf für Metriken nach InfluxDB/Prometheus-Bridge, os-zabbix-agent für Zabbix.

CLI-Diagnose:

tcpdump -ni <if> port 2055   # NetFlow
clog /var/log/filter.log | tail -n 100

Best Practice: Logging gezielt aktivieren (kritische Regeln), Rotation prüfen, zentrale Dashboards etablieren.

Schritt 11 – Automatisierung via API und configctl

OPNsense stellt eine REST-API bereit, die Sie mit API-Key/Secret nutzen. Ideal für GitOps-Pipelines und Infrastructure-as-Code.

API-Key anlegen: System > Access > Users – Benutzer auswählen/erstellen, API-Key generieren. Authentifizierung via Basic Auth (key:secret).

Beispiel: Unbound neu starten

curl -sk -u 'APIKEY:APISECRET' https://opn.local/api/unbound/service/restart

Alias per API erstellen:

curl -sk -u 'APIKEY:APISECRET' \
  -H 'Content-Type: application/json' \
  -X POST \
  -d '{
    "name": "DEVOPS_NET",
    "type": "network",
    "content": ["10.30.0.0/24","10.20.0.0/24"],
    "enabled": "1",
    "description": "DEV & INFRA networks"
  }' \
  https://opn.local/api/firewall/alias/addItem

Firewall-Regel anlegen (Beispiel, Ziel-API kann je Version variieren – prüfen Sie die API-Schnittstelle in der GUI Dev Tools):

curl -sk -u 'APIKEY:APISECRET' \
  -H 'Content-Type: application/json' \
  -X POST \
  -d '{
    "rule": {
      "action": "pass",
      "interface": "lan",
      "direction": "in",
      "protocol": "tcp",
      "source_net": "DEVOPS_NET",
      "destination": "any",
      "dst_port": "80,443",
      "log": "1",
      "description": "DEV outbound web"
    }
  }' \
  https://opn.local/api/firewall/rule/addRule

Konfiguration anwenden:

curl -sk -u 'APIKEY:APISECRET' https://opn.local/api/firewall/filter/reload

Backup/Restore per API:

# Backup ziehen
curl -sk -u 'APIKEY:APISECRET' https://opn.local/api/core/backup/download > opnsense-config.xml

# Backup einspielen (prüfen Sie Endpunkt/Version)
curl -sk -u 'APIKEY:APISECRET' -F '[email protected]' https://opn.local/api/core/backup/restore

CLI-Automation: configctl ist die zentrale Kommandoschnittstelle. Beispiele: configctl filter reload, configctl unbound reload, configctl wireguard start.

Schritt 12 – Upgrades, Boot-Environments und Rollback

Produktions-Firewalls benötigen sichere Upgrades:

• System > Firmware > Settings: Release-Track wählen, Repositories sperren, Prüfsummen validieren.
• ZFS-Boot-Environment nutzen: Vor Upgrade Snapshot anlegen.

CLI-Werkzeuge:

# Paket-Liste aktualisieren und System aktualisieren
opnsense-update && opnsense-update -bkgr

# Boot Environment (wenn ZFS):
bectl list
bectl create pre-24.7-upgrade

# Paket-Rollback auf bestimmtes Paket
opnsense-revert <pkgname>

Best Practice: Blue/Green-Upgrade mit HA – Secondary zuerst aktualisieren und testen, kontrolliertes Failover, dann Primary.

Schritt 13 – Performance-Tuning und NIC-Optionen

Für hohe Durchsätze und stabile IPS:

• System > Settings > Networking: Hardware Checksum Offloading, TSO/LRO deaktivieren bei netmap/IPS.
• Driver-Tuning: RSS aktivieren, genug RX/TX-Queues; auf ESXi vmxnet3, auf KVM VirtIO mit Multi-Queue.
• Suricata: Hyperscan aktivieren, Anzahl Threads vs. CPU-Kerne abwägen, passende MTU prüfen.
• WireGuard: UDP-Port priorisieren (QoS), CPU-Frequenzskalierung nicht zu aggressiv.

Messung:

iperf3 -s   # im LAN/DMZ
iperf3 -c 10.20.0.10 -P 4
systat -ifstat 1

Schritt 14 – Sicherheitshärtung

Minimieren Sie Angriffsfläche und erzwingen Sie starke Authentifizierung:

• System > Access > Servers/Users: TOTP-2FA aktivieren und für Admin-Gruppen erzwingen.
• System > Settings > Administration: WebGUI nur auf MGMT-VLAN binden, HTTPS erzwingen, starke TLS-Profile.
• SSH: Nur auf MGMT, Key-basierte Authentifizierung, Port-Knocking optional.
• Firewall: Block bogon networks auf WAN, GeoIP-Aliases (Plugin maxmind) für regionale Blockaden.
• API-Keys: Rechte minimal halten, rotieren, in Secret-Manager verwalten.

Audit und Compliance:

• Konfig-Änderungen dokumentieren (Config History, Git-Backups).
• Regelmäßige Rule-Review-Meetings mit Stakeholdern.

Schritt 15 – Troubleshooting-Playbook

Wenn etwas klemmt, gehen Sie hypothesengetrieben vor und sammeln Sie Belege:

• Routing: netstat -rn, route get <dst>
• Firewall-Regeln: pfctl -vvsr, Rule-Counters prüfen
• States: pfctl -ss
• Packet Capture: Diagnostics > Packet Capture oder tcpdump -ni <if> host <ip> and port <port>
• NAT: pfctl -sn und Outbound NAT-Regeln checken
• DNS: drill Antworten, Unbound-Logs

Typische Stolpersteine:

• IPS inline mit aktivem LRO/TSO – führt zu Drops/Performance-Problemen
• Doppelte NAT/Portforwards (bei HAProxy plus NAT)
• Fehlende Firewall-Regel fürs WireGuard-Interface (WG->LAN/DMZ)
• ARP-Gratuitous nach CARP-Failover nicht akzeptiert – ARP-Cache im Upstream prüfen

UI-vs-CLI: Praktische Mappings

Viele Betriebsaufgaben lassen sich sowohl in der GUI als auch via CLI/API erledigen:

• Rules anpassen: GUI unter Firewall > Rules vs. API /api/firewall/rule/… vs. configctl filter reload zum Anwenden
• DNS: GUI Services > Unbound vs. API /api/unbound/… vs. configctl unbound reload
• WireGuard: GUI VPN > WireGuard vs. API /api/wireguard/… vs. configctl wireguard
• HAProxy/ACME: GUI Services > HAProxy/ACME vs. API /api/haproxy/… und /api/acmeclient/…

Nutzen Sie die Browser-Entwicklertools (Netzwerk-Tab), um API-Aufrufe der GUI zu inspizieren. So lassen sich Payloads für Skripte generieren (Achtung auf Versionen und CSRF Tokens, bei API-Schlüssel entfällt CSRF).

Beispiel: Policy-as-Code mit Git und CI

Ein pragmatischer Ansatz für GitOps mit OPNsense:

• Definieren Sie Aliases und Regeln als deklarative JSON-Dateien im Repo.
• CI-Pipeline (z. B. GitLab CI, GitHub Actions) validiert JSON-Schema, führt dry-run gegen Staging-Firewall aus.
• Bei Erfolg: Deploy an Produktion via API, anschließend configctl filter reload.
• Erzeugen Sie Audit-Artefakte: exportierte Config.xml, gehashte Regelsets, pfctl-Snapshots.

Beispiel-Pipeline-Schritt (Shell):

#!/usr/bin/env bash
set -euo pipefail
FW=https://opn.local
AUTH='APIKEY:APISECRET'

# Alias synchronisieren
curl -sk -u "$AUTH" -H 'Content-Type: application/json' \
  -X POST -d @aliases.json $FW/api/firewall/alias/setItem

# Regeln synchronisieren
curl -sk -u "$AUTH" -H 'Content-Type: application/json' \
  -X POST -d @rules.json $FW/api/firewall/rule/import

# Filter neu laden
curl -sk -u "$AUTH" $FW/api/firewall/filter/reload

Vor produktivem Einsatz sollten Sie die tatsächlichen Endpunkte im System über die API-Hilfe oder Browser-Devtools verifizieren, da Pfade je OPNsense-Version variieren können.

Zero-Trust-Praktiken und Mikrosegmentierung

Ergänzend zur VLAN-basierten Trennung lohnt es sich, Zero-Trust-Prinzipien einzuführen:

• Identitätsgebundener Netzwerkzugriff: WireGuard-Keys als Geräteidentität, Kombination mit IdP (SAML/OIDC) über Portalseiten/Proxies.
• L7-Filterung: Ergänzend zu pf/Suricata optional Zenarmor (Plugin) für Applikationskontrolle.
• Just-in-Time Access: Temporäre Firewall-Regeln via API auf Basis genehmigter Change-Requests.
• Least Privilege: Erlaubnislisten statt Blocklisten, Zeitfenster, GeoIP-Einschränkungen.

Skalierungsoptionen und Multi-Site

Für Multi-Site-Umgebungen:

• Site-to-Site WireGuard oder IPsec zwischen OPNsense-Edges
• Consistent Policy: Zentrales Repo für Aliases/Regeln, Sites als Variablen
• Observability: Zentraler NetFlow-/Log-Stack pro Region mit konsolidierten Dashboards

Sicheres Testen und Rollouts

Risk-Managed Changes:

• Shadow-Regeln mit Logging vor dem Erzwingen (Suricata: Alert vor Drop)
• Canary-Subnets: Neue Policies erst auf DEV/GUEST anwenden
• Maintenance Windows: HA-Failover bereit, Out-of-Band-Access (Seriell/iLO/iDRAC) verfügbar

Nützliche Diagnose- und Kommandosammlung

Im Alltag bewährt:

# pf Regeln und States
pfctl -sr
pfctl -ss | wc -l

# Verbindungsdebug
tcpdump -ni igb1 host 10.30.0.25 and port 443

# DNS
unbound-control -c /var/unbound/unbound.conf stats_noreset

# System
vmstat -z | head
systat -ifstat 1

# HA/CARP
ifconfig | grep carp
clog /var/log/system.log | grep carp

Security- und Architektur-Links

Vertiefung und Primärquellen:

• OPNsense How-Tos
• OPNsense Manual
• pf.conf Manpage
• CARP/pfsync in OPNsense
• WireGuard How-To
• IDS/IPS mit Suricata
• HAProxy Plugin
• ACME/Let's Encrypt Plugin

Fazit und nächste Schritte

Mit den oben skizzierten Schritten haben Sie eine tragfähige, produktionsreife OPNsense-Umgebung aufgebaut: sauber segmentierte VLANs, kontrollierte Ost-West- und Nord-Süd-Flüsse, ein verhärteter DNS-Stack, Remote-Zugriff via WireGuard, Sichtbarkeit durch NetFlow und IDS/IPS sowie echte Hochverfügbarkeit per CARP/pfsync. Durch die Nutzung von Aliases, minimalinvasiven Regeln und API-gestützter Automatisierung schaffen Sie die Grundlage für skalierbare, auditierbare Policy-Verwaltung nach GitOps-Prinzipien.

Als nächste Schritte empfehlen sich: Feinkalibrierung der Suricata-Regeln (Alert -> Drop), Zero-Trust-Vervollständigung mit Just-in-Time-Zugriff und identitätsbasierter Autorisierung, Ausbau des Observability-Stacks (zentrales SIEM, Metriken per Telegraf/Prometheus), sowie wiederkehrende GameDays, um Failover, Backup-Restore und Incident-Playbooks unter Realbedingungen zu üben. Prüfen Sie regelmäßig Upstream-Änderungen und nutzen Sie Boot-Environments für risikominimierte Upgrades. Setzen Sie auf konsistente Naming- und Tagging-Standards – und dokumentieren Sie jede Policy-Änderung im Code.

Wenn Sie tiefer einsteigen möchten, beginnen Sie mit den offiziellen Ressourcen: OPNsense Docs für Systemspezifika, die pf.conf-Referenz für Firewall-Feinheiten und den Suricata-Guide für IDS/IPS-Tuning. So bleibt Ihre Edge nicht nur sicher, sondern auch evolvierbar.