# Stateful Inspection: Wie OPNsense sich an Pakete erinnert

TL;DR / Management Summary OPNsense ist eine Stateful Firewall. Das bedeutet, sie prüft nicht jedes einzelne Paket isoliert, sondern erkennt, ob ein Paket zu einer bereits erlaubten Verbindung gehört. Wenn ein User eine Webseite anfragt, erstellt OPNsense einen State (Zustand). Alle Antwort-Pakete vom Server werden dann automatisch durchgelassen, ohne dass eine explizite Inbound-Regel am WAN nötig ist. Ein Senior Admin beherrscht die State Table, um hängende Verbindungen zu kappen und DDoS-Angriffe auf den RAM zu verhindern.

# 1. Einführung & Konzepte

Stateless vs. Stateful.

# Stateless (Alt)

Jedes Paket wird gegen alle Regeln geprüft. Wenn der User raussendet (SYN), muss eine Regel für die Antwort (SYN-ACK) existieren. Sehr komplex und unsicher.

# Stateful (Modern)

Nur das erste Paket (z.B. TCP SYN) wird gegen das Regelwerk geprüft.

# 2. Die State-Tabelle in der Praxis

In das Gedächtnis schauen.

# Status-Abfrage via GUI

Firewall -> Diagnostics -> States. Hier sehen Sie:

# States löschen (Der ‘Reset’ Knopf)

Wenn Sie eine Regel ändern (z.B. SSH blockieren), können bestehende Sessions noch Stunden weiterlaufen.

# 3. Deep Dive: State-Limits & Timeouts

Ressourcen schützen.

Jeder State belegt ca. 1 KB RAM. Bei einem DDoS-Angriff mit Millionen von SYN-Paketen kann der RAM des Gateways vollaufen.

# Globale Limits anpassen

Firewall -> Settings -> Advanced.

# 4. Day-2 Operations: State-Logging

Wer hat die Session gestartet?

Aktivieren Sie das Logging nur für die Pakete, die den State erstellen (First Match). Dies reduziert die Log-Größe massiv, da nicht jedes Folgepaket protokolliert wird.

# 5. Troubleshooting & “War Stories”

Wenn die Firewall vergisst.

# Top 3 Fehlerbilder

  1. Symptom: Verbindungen brechen nach exakt 24 Stunden ab.

    • Ursache: Zu strikte TCP-Timeouts oder ISP-Zwangstrennung ohne State-Purge.
    • Lösung: Keep-alive in der Applikation aktivieren oder Timeout-Werte in OPNsense moderat erhöhen.

  2. Symptom: “State Table Full” Fehlermeldung in den System-Logs.

    • Lösung: Sofortiges Erhöhen des Limits (siehe Punkt 3) und Prüfung auf Port-Scanning Attacken aus dem LAN.

  3. Symptom: Asymmetrisches Routing.

    • Folge: Pakete gehen über FW-A raus, aber über FW-B zurück. Da FW-B den State nicht kennt, werden die Pakete gedroppt.
    • Lösung: Regel auf Stateless stellen (Haken bei “Sloppy State”) – Vorsicht: Sicherheitsrisiko!

# “War Story”: Der “Zombie” SQL-Connect

Ein Unternehmen meldete, dass ihr ERP-System am Montagmorgen nicht funktionierte. Die Entdeckung: Die Applikation hielt hunderte TCP-Verbindungen über das Wochenende offen. Die Firewall hatte diese inaktiven States nach 24 Stunden gelöscht (Timeout). Die App dachte aber, die Leitung stünde noch und schickte Daten ins Leere. Lösung: Wir erstellten eine spezifische Firewall-Regel für den SQL-Port mit einem Custom State Timeout von 72 Stunden. Lehre: Nicht jede Applikation kann mit einem “Stateful” Reset umgehen. Wissen Sie, welche Timeouts Ihre Apps brauchen.

# 6. Monitoring & Alerting

Die Tabellengröße im Blick.

# Dashboard Widget

Fügen Sie das Widget “State Table” zu Ihrem Dashboard hinzu.

# 7. Fazit & Empfehlung

Stateful Inspection ist die Basis für Effizienz und Sicherheit.

# Anhang: Cheatsheet

Begriff Bedeutung
ESTABLISHED Verbindung ist aktiv und bidirektional.
SYN_SENT Client wartet auf Antwort vom Server.
TIME_WAIT Verbindung wurde geschlossen, wird noch kurz gehalten.
Sloppy State Ignoriert TCP-Sequenznummern (für asymmetrisches Routing).

# Referenzen