Firewall Troubleshooting: “Erlaubt” aber trotzdem blockiert?

Firewall Troubleshooting ist im Alltag oft weniger ein Technikproblem als ein Übersetzungsproblem: Die Policy sagt „allow“, der Change wurde deployed, die Logs zeigen keine eindeutigen Denies – und trotzdem klappt die Verbindung nicht oder verhält sich instabil. Genau dieses Fehlerbild („Erlaubt“ aber trotzdem blockiert?) ist typisch für stateful Firewalls, weil zwischen Regelwerk und realem Datenpfad viele zusätzliche Mechanismen wirken: Session-State, NAT, Security-Profile (IPS/AV/URL), Application Identification, Decryption, Routing/PBR, asymmetrische Pfade, Zonenlogik, virtuelle Router/VRFs, HA-Cluster und nicht zuletzt Performance-Limits wie Ressourcen, Session-Tables oder Policer. Wer hier ohne System debuggt, verliert Zeit und dreht oft an der falschen Stelle: Man erweitert eine Rule, obwohl das Problem ein fehlender Rückweg ist. Oder man jagt einem „Deny“ hinterher, obwohl ein Security-Profil die Session später mit einem Reset beendet. Dieser Artikel zeigt eine methodische Vorgehensweise für Firewall Troubleshooting: Sie lernen, warum „allow“ nicht gleich „durchgelassen“ ist, wie Sie mit Beweisen statt Annahmen arbeiten, welche typischen Side Effects Sie prüfen müssen und wie Sie in wenigen Minuten zur wahrscheinlichsten Ursache kommen – inklusive Checklisten, Evidence-Pack und nachhaltigen Baselines für den Betrieb.

Warum „Allow“ nicht genügt: Die versteckten Entscheidungsebenen einer Firewall

Moderne Firewalls entscheiden nicht nur anhand einer ACL-Zeile. Selbst wenn eine Policy den Traffic erlaubt, können andere Ebenen blockieren oder verändern:

• Stateful Session-Tracking: Die Firewall lässt nicht „Pakete“, sondern „Sessions“ zu. Wenn der Session-State fehlt oder inkonsistent ist, wird verworfen – auch bei erlaubter Regel.
• NAT (SNAT/DNAT/PAT): Eine Regel kann matchen, aber die NAT-Übersetzung ist falsch oder kollidiert (Port-Exhaustion, falsche Rückübersetzung).
• Security-Profile: IPS/AV/URL-Filter/DNS-Security können eine Session nach dem Allow beenden (Drop oder TCP RST).
• App-ID / L7 Enforcement: Die Regel erlaubt Port 443, aber die Applikation wird als „unerwünscht“ klassifiziert und blockiert.
• Decryption (TLS Inspection): Zertifikat/Policy/Handshake-Fehler, unsupported ciphers oder pinning führen zu „blockiert“, obwohl die Grundregel erlaubt.
• Routing/Policy-Based Routing: Der Traffic wird über ein anderes Interface geschickt als erwartet; Rückweg läuft anders (Asymmetrie) oder Next-Hop ist unerreichbar.
• Plattformlimits: Session-Table voll, CPU hoch, CoPP/DoS-Profile greifen, oder Hardware-Offload passiert anders als gedacht.

Die wichtigste Konsequenz: Firewall Troubleshooting ist eine Beweiskette. Sie müssen nachweisen, wo der Flow tatsächlich entlangläuft und an welcher Stelle er endet oder verändert wird.

Das beste mentale Modell: 5-Tuple, Zone, NAT, Session

Arbeiten Sie konsequent flow-basiert. Definieren Sie für den betroffenen Verkehr ein konkretes 5-Tuple: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll – plus Kontext: Source Zone, Destination Zone, VRF/Virtual Router, Interface, erwartete NAT-Übersetzung. Damit vermeiden Sie das klassische „es geht nicht“ ohne Greifbarkeit.

• Flow-Identität: 5-Tuple + Zeitfenster
• Policy-Pfad: von welcher Zone nach welcher Zone, welche Regel soll matchen?
• NAT-Pfad: welche Pre-NAT und Post-NAT Adressen/Ports sind real?
• Session-Pfad: existiert eine Session? In welchem State? Wer beendet sie?

Die häufigsten Root Causes, wenn „Allow“ gesetzt ist

Im Betrieb wiederholen sich bestimmte Ursachen so häufig, dass Sie sie als Standard-Checkliste behandeln sollten.

Asymmetrisches Routing und fehlender Rückweg

Stateful Firewalls erwarten in vielen Designs, dass Hin- und Rückweg derselben Session über dieselbe Instanz laufen. Wenn der Rückweg über eine andere Firewall, einen anderen HA-Node ohne State-Sync oder einen anderen Internet-Exit geht, fehlt der Session-State. Ergebnis: Drops oder „out of state“. Dieses Muster ist besonders häufig bei ECMP, mehreren Upstreams, SD-WAN Steering oder unsauberen PBR-Regeln.

• Indiz: SYN geht raus, aber SYN-ACK kommt nicht zurück oder wird gedroppt; Logs zeigen „no session“ oder „out of state“.
• Nachweis: Traceroute/MTR in beide Richtungen, Session-Table auf beiden HA-Nodes, Flow-Logs am Return-Path.
• Fix-Richtung: Symmetrie herstellen (Routing/Policy), State-Sync korrekt betreiben oder Traffic gezielt an eine Instanz binden.

NAT-Missverständnisse: „Rule matcht“, aber Übersetzung passt nicht

NAT ist eine der häufigsten Ursachen für „allow but blocked“. Typische Fälle: DNAT ist korrekt, aber SNAT fehlt (Rückweg geht ins Nirvana), Port-Overload führt zu sporadischem Failure, oder ein NAT-Pool ist erschöpft.

• Indiz: Inbound funktioniert teilweise, Outbound sporadisch; viele kurze Verbindungen schlagen fehl; bestimmte Ports gehen nie.
• Nachweis: NAT-Session/Translation Counters, Port-Auslastung (PAT), Kollisionen/Overlaps, Log-Hinweise auf Port Exhaustion.
• Fix-Richtung: SNAT/DNAT konsistent, ausreichend Pool/Port-Budget, Hairpin/Same-Zone NAT bewusst konfigurieren.

Security-Profile droppen nach dem Allow

Eine Policy kann „permit“ sein, aber ein IPS-Signature oder ein URL-Filter blockiert später. Das wirkt wie „es geht kurz, dann nicht“ oder „nur bestimmte Inhalte gehen“. Häufig wird das über TCP RST beendet, was in Client-Tools wie ein Serverproblem aussieht.

• Indiz: Handshake klappt, danach Reset; bestimmte URLs oder Payloads brechen reproduzierbar.
• Nachweis: Threat/IPS-Logs, URL-Logs, Content-Inspection Events, korrelierter Session-Endgrund.
• Fix-Richtung: Profile gezielt anpassen (Ausnahme minimal), Signaturen tunen, false positives sauber dokumentieren.

App-ID/Layer-7: Port offen, Anwendung trotzdem blockiert

In Next-Gen-Firewalls ist „allow tcp/443“ nicht gleich „erlaubt für jede App“. Wenn die Regel auf „application-default“ oder spezifische Apps eingeschränkt ist, kann eine neue App-Version, QUIC (UDP/443) oder ein Protokollwechsel dazu führen, dass die Session nicht mehr matcht oder später umklassifiziert wird.

• Indiz: Alte Version geht, neue nicht; Browser wechselt auf QUIC; nur UDP/443 scheitert.
• Nachweis: App-Identification in Session-Details, Logs zu App-Shift, Protokoll/Port in Captures.
• Fix-Richtung: App-Policy bewusst erweitern, QUIC/HTTP3 explizit behandeln, Logging für App-ID aktivieren.

TLS/Decryption: „Erlaubt“, aber Zertifikat/Handshake blockt

Wenn TLS-Inspection aktiv ist, können Zertifikatsketten, SNI-Policies, unsupported ciphers, certificate pinning oder Fehlkonfigurationen (fehlende Intermediate CAs) Verbindungen brechen. Von außen wirkt das oft wie „Server down“ oder „DNS kaputt“.

• Indiz: TLS Handshake Errors im Client, nur HTTPS betroffen, bestimmte Domains funktionieren, andere nicht.
• Nachweis: Decryption-Logs, TLS-Handshake-Details, Zertifikatspfad, SNI-Auswertung.
• Fix-Richtung: Decryption-Policy sauber trennen (No-Decrypt für Pinning), CA-Deployment prüfen, TLS-Profile aktualisieren.

Methodik: Firewall Troubleshooting in der richtigen Reihenfolge

Mit dieser Reihenfolge vermeiden Sie, dass Sie an Policies drehen, obwohl das Problem im Routing oder NAT liegt.

• 1) Reproduzierbarkeit schaffen: Konkreter Flow, Zeitpunkt, Quelle/Ziel, Protokoll, Port.
• 2) Routing & Pfad prüfen: Kommt der Flow wirklich über die erwartete Firewall? Ist der Rückweg symmetrisch?
• 3) Policy Match prüfen: Welche Regel matcht tatsächlich? (Nicht welche matchen „soll“.)
• 4) NAT prüfen: Welche Übersetzung wird angewendet? Gibt es Kollisionen/Exhaustion?
• 5) Session-State prüfen: Session vorhanden? Zustand? Timeout? Wer beendet?
• 6) Security-Profile/L7 prüfen: IPS/URL/Decryption/App-ID Events korrelieren.
• 7) Drops lokalisieren: Werden Pakete gedroppt (Drop) oder aktiv beendet (RST/ICMP)?

Evidence Pack: Was Sie im Ticket immer brauchen

Firewall-Probleme eskalieren, wenn Informationen fehlen. Ein kleines Evidence Pack macht die Analyse deutlich schneller.

• Flow-Daten: 5-Tuple, Zeitpunkt, Frequenz, ob TCP/UDP, ob QUIC/HTTP3 relevant.
• Pfad-Daten: Source Zone/Dest Zone, VRF/Virtual Router, erwarteter Next-Hop, Return-Path.
• Firewall-Logs: Policy-Log (match), NAT-Details, Session-Endreason, Threat/URL/Decryption Log (falls aktiv).
• Session-Details: State (SYN-SENT/ESTABLISHED), Bytes/Packets, Timeout-Klasse, offload status (falls sichtbar).
• Packet Capture (kurz): idealerweise ingress und egress oder vor/nach NAT.

Für Capture-Workflows eignen sich die Wireshark Dokumentation und die tcpdump Manpage als solide Referenzen.

„Erlaubt“, aber kein Traffic: typische Missinterpretationen und wie Sie sie auflösen

Viele Teams interpretieren Logs falsch. Zwei Beispiele sind besonders häufig:

• Log zeigt „allow“, aber nur für den SYN: Der erste Paket-Satz wird geloggt, danach blockt ein Profil oder der Rückweg fehlt. Lösung: Session-Endreason und return traffic prüfen, nicht nur den ersten Logeintrag.
• Log zeigt „allow“, aber im falschen Kontext: Die Regel matcht in einer anderen VRF/Zone oder auf einer anderen Firewall als gedacht. Lösung: Interface/Zone/VRF im Log verifizieren.

Timeouts und „silent drops“: Wenn nichts eindeutig im Log steht

Ein besonders frustrierendes Fehlerbild ist ein Timeout ohne klare Deny-Logs. Das kann mehrere Ursachen haben:

• Return-Path fehlt: SYN geht raus, Reply kommt nie zurück (Routing/ACL upstream).
• Intermediate Device droppt: ISP, DDoS-Protection, Load Balancer, Server-Security-Group.
• State Table Pressure: Firewall ist unter Last, Sessions werden früher geaged oder nicht korrekt erstellt.
• PMTUD/MTU Blackhole: kleine Pakete gehen, größere hängen; wirkt wie Firewall-Block, ist aber MTU/ICMP-Thema.

Bei MTU/PMTUD sind RFC 1191 (IPv4) und RFC 8201 (IPv6) hilfreiche Hintergrundquellen.

HA-Cluster und „Split Brain“: Wenn der falsche Node den Traffic sieht

In HA-Setups (Active/Passive oder Active/Active) entstehen typische Side Effects: State-Sync ist verzögert oder unvollständig, Session-Ownership ist nicht konsistent, oder ARP/Gratuitous ARP Events führen zu kurzfristig falschem Pfad. Das Ergebnis ist wieder „allow, but blocked“ – meist als out-of-state.

• Indiz: Problem tritt nach Failover oder Link-Events auf; Logs zeigen Sessions auf einem Node, Traffic kommt aber beim anderen an.
• Nachweis: Session-Table Vergleich beider Nodes, HA-Sync-Status, Interface MAC/ARP Events.
• Fix-Richtung: HA-Sync stabilisieren, Pfade symmetrisieren, Healthchecks/Failover-Trigger prüfen.

Wenn „Allow“ stimmt, aber Performance schlecht ist

Firewall Troubleshooting betrifft nicht nur Blockaden, sondern auch Performance: hohe Latenz, Throughput-Probleme, Retransmissions. Häufige Ursachen sind:

• Decryption/IPS CPU-lastig: Traffic wird erlaubt, aber Processing überlastet die Box → Drops/Delay.
• QoS/Policer auf der Firewall: Voice/Video wird falsch klassifiziert oder policed, wodurch Loss entsteht.
• TCP MSS/MTU: falsches MSS-Clamping führt zu Fragmentation oder Blackholes.
• Path Asymmetry: Unterschiedliche Pfade verursachen Jitter/Loss und wirken wie „Firewall langsam“.

TCP-Verhalten bei Loss/Delay ist in RFC 9293 beschrieben, was bei Retransmissions-Analysen hilfreich ist.

Runbook-Baustein: „Erlaubt“ aber blockiert in 15 Minuten

• Minute 0–3: Flow definieren (5-Tuple), Reproduktion starten, Zeitpunkt notieren. Pfad grob prüfen: geht der Traffic durch die erwartete Firewall?
• Minute 3–6: Policy Match verifizieren: Welche Regel matcht tatsächlich? Logging auf diese Regel/Flow sicherstellen.
• Minute 6–9: NAT und Session prüfen: Welche Übersetzung wird angewendet? Session-State vorhanden? Endreason/Timeout?
• Minute 9–12: Side Effects prüfen: Return-Path/Asymmetrie, HA-Node-Ownership, ECMP/PBR, MTU/PMTUD Muster.
• Minute 12–15: Security-Profile/L7 prüfen: IPS/URL/Decryption/App-ID Events korrelieren, dann minimalen Fix anwenden und mit demselben Flow verifizieren.

Nachhaltige Baselines: Damit „Allow“ auch wirklich „durch“ bedeutet

• Trustworthy Logging: Policy-Logs + Session-Endreason standardisieren, nicht nur Denies loggen.
• NAT-Transparenz: Dokumentierte NAT-Policy-Reihenfolge, klare Pre-/Post-NAT Sichtbarkeit in Tools und Tickets.
• Symmetrie-Governance: Routing/PBR/ECMP so gestalten, dass stateful Kanten nicht asymmetrisch werden, oder HA/State-Sync bewusst auslegen.
• Profile-Hygiene: IPS/URL/Decryption Ausnahmen minimal und nachvollziehbar, false positives mit Evidence dokumentieren.
• Kapazitäts- und Limit-Monitoring: Session-Table, CPU, Decryption-Load, Drops/Queues als Standard-Dashboards.
• Change-Disziplin: Bei Firewall-Changes immer Return-Path, NAT und Profile mitprüfen; Canary-Tests pro Zone/Service.

Weiterführende Quellen für Standards und Praxis

• RFC 9293 für TCP-Grundverhalten (Retransmissions, Timeouts, Zusammenhang zu „scheinbar geblockt“)
• RFC 8201 und RFC 1191 für PMTUD (häufige Ursache für „geht kurz, dann hängt“)
• Wireshark Dokumentation für Flow-Forensik, RST/ICMP-Interpretation und NAT/Handshake-Analyse
• tcpdump Manpage für effiziente Mitschnitte und Filterung nach 5-Tuple
• OWASP als Sicherheitskontext für L7-Blockaden, TLS/Proxy-Themen und typische False-Positive-Klassen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.