# OPNsense Troubleshooting: Methodische Fehlersuche für Admins

TL;DR / Management Summary Netzwerkfehler sind oft komplex und verstecken sich hinter Symptomen wie “Internet ist langsam” oder “Server X nicht erreichbar”. Wir nutzen einen Layer-für-Layer Ansatz (OSI-Modell). Senior Admins nutzen die in OPNsense integrierten Werkzeuge wie Packet Capture, MTR (My Traceroute) und die Live-Log Ansicht, um Probleme präzise zwischen Client, Firewall und ISP zu isolieren. Wer die Diagnostics-Tools beherrscht, reduziert die MTTR (Mean Time To Repair) massiv.

# 1. Der methodische Ansatz

Vom Kabel zur Applikation.

  1. Physical (Layer 1): Interfaces Up/Down? (Interfaces -> Overview).
  2. Data Link (Layer 2): ARP-Eintrag vorhanden? (Diagnostics -> Network -> ARP Table).
  3. Network (Layer 3): Ping zum Gateway und zum Ziel? (Diagnostics -> Network -> Ping).
  4. Transport (Layer 4): Port offen? (Diagnostics -> Network -> Port Probe).
  5. Application (Layer 7): Logs prüfen! (System -> Log-Files).

# 2. Die wichtigsten Diagnostics-Tools

Bordmittel effektiv nutzen.

# 1. Packet Capture (Der ‘Röntgenblick’)

Diagnostics -> Packet Capture. Wenn Sie wissen wollen, ob ein Paket die Firewall überhaupt verlässt:

# 2. MTR (My Traceroute)

Diagnostics -> Network -> Traceroute. Kombiniert Ping und Traceroute.

# 3. Port Probe (Nmap Lite)

Prüfen Sie, ob ein interner Server einen Port wirklich offen hat, ohne ein Tool auf dem Client zu installieren.

# 3. Deep Dive: ARP & NDP (Layer 2 Troubleshooting)

Wer ist wer im LAN?

Wenn der Ping fehlschlägt, prüfen Sie die ARP-Tabelle.

# 4. Day-2 Operations: Log-Korrelation

Fehlerursachen im Text finden.

Nutzen Sie die Suchfunktion in den System-Logs:

# 5. Troubleshooting & “War Stories”

Wenn die Tools ‘Alles OK’ sagen.

# Top 3 Fehlerbilder

  1. Symptom: Ping geht, aber Webseiten/SSH nicht.

    • Ursache: MTU/MSS Problem. Pakete sind zu groß für den Pfad (besonders bei PPPoE oder VPN).
    • Lösung: MSS Clamping am Interface auf 1350 setzen.

  2. Symptom: Sporadische Verbindungsabbrüche im gesamten LAN.

    • Ursache: IP-Konflikt (z.B. ein zweiter Router mit der gleichen IP wie die OPNsense).
    • Tool: arp -a am Client beobachten. Wenn die MAC für das Gateway springt -> Konflikt!

  3. Symptom: Firewall reagiert extrem träge.

    • Ursache: Disk-I/O Wait oder RAM-Mangel durch Suricata/ntopng.
    • Lösung: top -SH in der Shell prüfen.

# “War Story”: Der “unsichtbare” Switch-Loop

Ein Kunde klagte über einen Totalausfall des Netzwerks. Die OPNsense-CPU war bei 10% (niedrig!), aber kein Traffic kam durch. Die Entdeckung via Shell: netstat -i zeigte Millionen von “Input Errors” an einem LAN-Port. Ein unmanaged Switch im Büro hatte einen Loop. Die OPNsense-CPU war zwar nicht ausgelastet, aber der interne Switch-Chip der Firewall-Hardware war durch die Broadcast-Flut blockiert. Lehre: Schauen Sie bei Netzwerkproblemen immer zuerst auf die Interface-Fehler-Zähler, nicht nur auf die CPU-Last.

# 6. Monitoring & Reporting

Selbstdiagnose automatisieren.

# Health Dashboard

Fügen Sie das Widget “System Information” hinzu und achten Sie auf den Load Average.

# 7. Fazit & Empfehlung

Troubleshooting ist eine Kunst, die man lernen kann.

# Anhang: Cheatsheet (Die 10-Sekunden Diagnose)

Befehl (Shell) Zweck
top -SH Was frisst CPU/RAM?
pftop Welche Verbindung läuft gerade?
netstat -rn Wie sieht die Routing-Tabelle aus?
ifconfig IP und Link-Status aller NICs
clog /var/log/filter/latest.log Letzte Firewall-Blocks sehen

# Referenzen