# OPNsense Logging: Zentralisierung via Remote Syslog & SIEM

TL;DR / Management Summary Lokale Logs auf der Firewall (Artikel 557) sind flüchtig und werden bei vollem Speicher überschrieben. Für Audits, Compliance (DSGVO) und tiefgreifende Security-Analysen ist das Remote Logging unverzichtbar. OPNsense kann seine Logs in Echtzeit an einen externen Syslog-Server oder ein SIEM (z.B. Graylog, Splunk, ELK) senden. Ein Senior Admin nutzt dieses Feature, um die Spuren von Angreifern auch dann noch zu haben, wenn das Gateway selbst kompromittiert oder zerstört wurde.


# 1. Einführung & Log-Formate

Vom clog zum Standard-Syslog.

OPNsense nutzt intern das clog Format (zirkuläre Binärdateien). Für den Versand nach außen wird dies in das standardisierte RFC 5424 (Syslog) Format konvertiert.


# 2. Remote Logging konfigurieren

Den Datenstrom umleiten.

System -> Settings -> Logging.

# Schritt 1: Lokale Log-Optionen

Bevor Sie senden, legen Sie fest, was überhaupt wichtig ist.

# Schritt 2: Remote Destination

Scrollen Sie zum Bereich Remote Log Targets.

  1. Transport: UDP (Standard) oder TLS (Sicherer, erfordert Zertifikate).
  2. Hostname: Die IP Ihres Log-Servers (z.B. 10.0.50.10).
  3. Port: Standard 514 (oder 1514 für Graylog).
  4. Applications: Wählen Sie, welche Logs gesendet werden sollen (Empfehlung: filter, dhcpd, unbound, charon).

# 3. Deep Dive: Graylog/ELK Integration

Die Daten nutzbar machen.

Syslog-Nachrichten der Firewall sind oft kryptisch (z.B. filterlog: 100,,,12345,igb0,match,block,in,4,0x0,,64,54321,0,DF,TCP,123,456...).


# 4. Day-2 Operations: Log-Retention & Compliance

Gesetzliche Vorgaben.

# Datenschutz (DSGVO)

Logs enthalten IP-Adressen (personenbezogene Daten).


# 5. Troubleshooting & “War Stories”

Wenn der Log-Server stumm bleibt.

# Top 3 Fehlerbilder

  1. Symptom: Remote Log Target ist konfiguriert, aber am Server kommt nichts an.

    • Ursache: Die Firewall blockiert den ausgehenden Syslog-Traffic (Port 514 UDP).
    • Lösung: Floating Rule (Artikel 556) erstellen: Pass | Direction: Out | Dest: Log_Server | Port: 514.
  2. Symptom: Massive Last auf dem WAN-Port durch Log-Traffic.

    • Ursache: “Log Any” Regel am WAN erzeugt zu viele Nachrichten.
    • Fix: Logging für die WAN-Regel deaktivieren oder Log-Ziele auf LAN-Schnittstellen beschränken.
  3. Symptom: Log-Nachrichten kommen “verwürfelt” an (TCP-Fragmente).

    • Lösung: Wechsel auf UDP für Syslog (da zustandslos) oder MTU-Anpassung prüfen.

# “War Story”: Der “Full-Disk” Kollaps

Ein Admin aktivierte das Remote Logging via TCP auf einen Server im Internet über eine instabile Leitung. Das Ergebnis: Die Internetleitung fiel kurz aus. Da der TCP-Syslog-Buffer in der OPNsense voll lief und der Dienst auf die Bestätigung wartete, blockierten wichtige Firewall-Prozesse. Das gesamte Gateway hing sich auf. Lehre: Nutzen Sie für Logging nach Möglichkeit immer UDP oder einen lokalen Log-Proxy (wie Fluentd/NXLog) auf einem separaten Interface, um Rückwirkungen auf den Firewall-Kern zu vermeiden.


# 6. Monitoring & Alerting

Die Log-Qualität prüfen.

# Health Dashboard

Überwachen Sie am SIEM-Server:


# 7. Fazit & Empfehlung

Remote Logging ist die Voraussetzung für professionelles Incident-Management.


# Anhang: Cheatsheet

Dienst Log-Name Zweck
pf filter Firewall-Regeln
dhcpd dhcp IP-Vergabe
charon vpn IPsec-Status
unbound dns Namensauflösung
sshd ssh Admin-Zugriff

# Referenzen