ACL Troubleshooting: Warum wird Traffic geblockt?

Wenn Anwendungen plötzlich nicht mehr funktionieren, Verbindungen „hängen“ oder ein bestimmter Server nicht erreichbar ist, landet man in Cisco-Umgebungen sehr schnell bei der Frage: Warum wird Traffic durch eine ACL geblockt? ACL Troubleshooting gehört deshalb zu den wichtigsten Praxisfähigkeiten im Netzwerkbetrieb. Der Grund ist simpel: Access Control Lists (Standard und Extended) greifen direkt in den Datenpfad ein. Ein einziger falscher Eintrag, eine ungünstige Reihenfolge oder die Anwendung am falschen Interface genügt, um legitimen Traffic zu verwerfen – und durch das implizite „deny any“ am Ende wird das Problem häufig noch verstärkt. Gleichzeitig ist die Diagnose nicht immer offensichtlich: Manchmal blockt nicht die erwartete ACL, sondern eine andere auf einem anderen Gerät; manchmal ist es gar nicht die ACL, sondern Routing, NAT oder eine Policy-Based Routing Regel, die den Verkehr umleitet. Dieses Troubleshooting-Playbook zeigt Ihnen Schritt für Schritt, wie Sie systematisch herausfinden, welche ACL tatsächlich greift, welcher Eintrag matched und warum ein Flow abgewiesen wird. Sie lernen typische Fehlerbilder (DNS vergessen, Rückverkehr übersehen, Wildcard falsch, falsche Richtung, falsche Platzierung), die wichtigsten Cisco-Show-Befehle, sinnvolle Testmethoden sowie sichere Vorgehensweisen für Änderungen, damit Sie Probleme schnell lösen, ohne neue Ausfälle zu erzeugen.

Grundmechanik: Warum ACL Troubleshooting oft nicht „intuitiv“ ist

Viele Probleme entstehen, weil die Funktionsweise von ACLs unterschätzt wird. Cisco ACLs werden sequenziell von oben nach unten geprüft. Der erste Treffer entscheidet (First Match). Wenn kein Eintrag matcht, greift am Ende das implizite deny. Diese drei Regeln erklären einen Großteil aller Störungen:

• Die Reihenfolge ist funktional, nicht kosmetisch.
• Ein zu allgemeiner Eintrag „weiter oben“ kann spätere, spezifische Regeln wirkungslos machen.
• Wenn Sie nur „ein bisschen“ blocken wollten, aber kein abschließendes Permit existiert, blocken Sie unter Umständen alles.

Eine solide Cisco-Referenz zu ACL-Konzepten und Syntax finden Sie über den Anchor-Text Cisco ACL Grundlagen und Konfiguration. Für befehlsgenaue Syntax je IOS/IOS XE-Version ist der Anchor-Text Cisco IOS Command Reference hilfreich.

Erste Einordnung: Ist es wirklich die ACL?

Bevor Sie in die ACL selbst eintauchen, sollten Sie kurz prüfen, ob das Problem tatsächlich ein ACL-Block ist. Denn in der Praxis wirken viele Fehler wie „ACL blockt“, obwohl Routing, NAT, PBR oder ein Down-Link die Ursache ist.

• Symptom passt zu ACL: Verbindung wird sofort abgewiesen oder bleibt ohne Antwort (Timeout), aber andere Ziele funktionieren.
• Symptom passt eher zu Routing: Ziel ist aus keinem Segment erreichbar, Traceroute bricht früh ab, keine Route/Next Hop.
• Symptom passt eher zu DNS: Ping zu IP funktioniert, Namen nicht.
• Symptom passt eher zu NAT/Firewall: Outbound geht, inbound nicht, oder Sessions brechen wegen asymmetrischem Rückweg.

Praxis-Tipp: Testen Sie immer stufenweise. Erst IP-Konnektivität (Ping zu IP), dann Namensauflösung, dann Applikation (z. B. TCP-Porttest, HTTPS).

Schritt 1: Den betroffenen Flow präzise beschreiben

ACL Troubleshooting wird deutlich einfacher, wenn Sie den Flow als „5-Tuple“ formulieren. Für TCP/UDP sollten Sie mindestens diese Informationen sammeln:

• Quelle: IP (und ggf. VLAN/Subnetz)
• Ziel: IP (und ggf. VLAN/Subnetz)
• Protokoll: TCP, UDP, ICMP
• Zielport (und bei Bedarf Quellport)
• Richtung: Wer initiiert die Verbindung? (Client → Server oder umgekehrt)

Beispiel: „Client 10.20.20.50 (VLAN20) → Server 10.10.20.10 TCP/443“. Erst wenn das klar ist, können Sie zuverlässig prüfen, welche ACL-Regeln relevant sind.

Schritt 2: Herausfinden, wo gefiltert wird

Ein häufiger Irrtum ist, nur auf dem „vermuteten“ Gerät zu schauen. In realen Netzen gibt es oft mehrere Filterpunkte: SVIs auf L3-Switches, Router-Interfaces, WAN-Edges, VRF-Übergänge oder zusätzlich Zone-Based Firewall. Finden Sie daher zuerst den tatsächlichen Filterpunkt.

• Wo ist das Default Gateway des Clients? Häufig liegt dort die inbound ACL für Clientsegmente.
• Gibt es eine ACL am Server-VLAN (in/out)?
• Gibt es eine ACL am WAN-Uplink oder an einem Transit?
• Gibt es zusätzliche Policies (PBR, ZBFW, Security-Funktionen), die Traffic umleiten oder blocken?

Hilfreiche Prüfungen

• traceroute <ZIEL-IP> vom Client oder einem nahegelegenen Gerät
• show ip route <ZIEL-IP> auf dem Gateway/Router
• show ip cef <ZIEL-IP> (plattformabhängig) zur tatsächlichen Weiterleitungsentscheidung

Wenn Sie den Hop identifiziert haben, an dem es „hängt“, prüfen Sie dort die Interfaces und ACL-Bindings.

Schritt 3: Welche ACL ist am Interface gebunden?

Eine ACL wirkt nur, wenn sie gebunden ist. Der häufigste Diagnosegewinn ist daher: herausfinden, ob und wo die ACL aktiv ist, und in welcher Richtung.

Interface-Config prüfen

• show running-config interface <INTERFACE>
• show ip interface <INTERFACE> (zeigt häufig in/out ACLs)

Achten Sie besonders auf:

• ip access-group <ACL> in (Inbound)
• ip access-group <ACL> out (Outbound)
• ipv6 traffic-filter <ACL> in/out (wenn IPv6 beteiligt ist)
• access-class <ACL> in unter line vty (Managementzugriff)

Typischer Fehler: Eine ACL ist korrekt geschrieben, aber am falschen Interface oder in der falschen Richtung angewendet.

Schritt 4: Standard ACL oder Extended ACL? Das entscheidet über die Diagnose

Wenn Standard ACLs im Spiel sind, wird nur die Quell-IP betrachtet. Wenn Extended ACLs im Spiel sind, zählen Quelle, Ziel, Protokoll und Ports. Das hat direkte Konsequenzen:

• Bei Standard ACLs ist ein „Block“ häufig breiter als erwartet, weil Ziel/Port nicht berücksichtigt werden.
• Bei Extended ACLs sind DNS, Rückverkehr und zusätzliche benötigte Ports die häufigsten Lücken.

Prüfen Sie daher zunächst, um welchen ACL-Typ es sich handelt, und lesen Sie die Regeln als „Policy“: Was soll erlaubt sein, was nicht?

Schritt 5: Trefferzähler auswerten

Die schnellste Wahrheit liefert oft der Hit Counter. Wenn Traffic wirklich geblockt wird, sollte eine Deny-Regel Treffer bekommen – oder das implizite Deny greift, ohne dass Sie es direkt sehen. Nutzen Sie daher:

• show ip access-lists
• show access-lists (plattformabhängig)

Interpretation:

• Treffer steigen auf einer Deny-Regel: Sie haben den Block gefunden.
• Treffer steigen auf einer Permit-Regel, aber Applikation geht nicht: Das Problem liegt vermutlich nicht an dieser ACL (oder es gibt einen weiteren Filterpunkt / Rückwegproblem).
• Keine Treffer steigen, obwohl Traffic sicher läuft: ACL ist nicht am richtigen Punkt gebunden oder der Traffic läuft anders als gedacht (Routing/PBR).

Schritt 6: Häufigste Gründe, warum legitimer Traffic geblockt wird

Implizites deny wurde vergessen

Das klassischste Fehlerbild: Man schreibt „deny X“ und vergisst, dass am Ende „deny any“ steht. Ergebnis: Nicht nur X, sondern alles, was nicht explizit erlaubt ist, wird blockiert. Typisch bei Standard ACLs, wenn man „nur ein Netz sperren“ wollte.

• Fix: Ein bewusstes permit any (Standard ACL) oder eine vollständige Allow-List (Extended ACL) ergänzen – abhängig vom Sicherheitsziel.

Reihenfolge falsch: Allgemein vor spezifisch

Wenn eine allgemeine Regel früh matcht, werden spätere Regeln nie erreicht. Typisch ist „permit ip any any“ zu früh oder ein breites deny, das eigentlich nur eine Teilmenge betreffen sollte.

• Fix: Spezifische Regeln nach oben, allgemeine nach unten; bei benannten ACLs mit Sequenzen sauber einsortieren.

Falsche Richtung: in vs. out verwechselt

Ein Flow kann auf dem Hinweg am Client-Gateway inbound gefiltert werden oder am Ausgangsinterface outbound. Wenn Sie die ACL am falschen Interface oder in der falschen Richtung anwenden, greift sie entweder nicht oder blockt Rückverkehr unerwartet.

• Fix: Datenfluss zeichnen (Quelle → Ziel) und prüfen, an welcher Stelle der Traffic das Interface betritt/verlässt.

Wildcard-Maske falsch

Eine falsche Wildcard führt dazu, dass die Regel zu viel matcht oder gar nicht matcht. Ein /24 wird versehentlich zu /16 oder umgekehrt.

• Fix: Wildcard bewusst rechnen (inverse Subnetzmaske) und zunächst mit host testen, dann erweitern.

DNS oder notwendige Nebenservices fehlen

Bei Extended ACLs wird sehr häufig DNS vergessen (UDP/53, teilweise TCP/53). Folge: Ping zu IP geht, Webseiten nicht. Auch NTP, CRL/OCSP oder Applikations-Backends können fehlen.

• Fix: Abhängigkeiten der Anwendung kennen und gezielt erlauben.

ICMP wird zu hart blockiert

Wenn ICMP komplett geblockt wird, erschwert das Diagnose (Ping/Traceroute) und kann in einigen Fällen Nebenwirkungen haben. Häufig reicht es, ICMP selektiv zu erlauben (echo/echo-reply, time-exceeded, unreachable).

• Fix: Diagnosetypen gezielt erlauben, statt ICMP pauschal zu öffnen oder zu sperren.

Rückverkehr wird nicht berücksichtigt

ACLs sind stateless. Wenn Sie inbound sehr strikt filtern, kann der Rückverkehr an einer anderen Stelle geblockt werden. Bei TCP kann established helfen, ist aber kein vollwertiger State.

• Fix: Rückweg prüfen, ggf. passende Rückregeln ergänzen oder stateful Firewall/Zone-Based Firewall nutzen, wenn erforderlich.

Mehrere Filterpunkte: Eine zweite ACL blockt zusätzlich

Sehr häufig existiert nicht nur eine ACL, sondern mehrere (z. B. auf Client-SVI und Server-SVI). Man behebt eine Stelle, aber der Traffic wird an einer anderen weiterhin geblockt.

• Fix: End-to-End prüfen, alle relevanten Interfaces identifizieren und Hit Counter an mehreren Geräten beobachten.

Schritt 7: Logging gezielt einsetzen, ohne das Gerät zu belasten

ACL-Logging kann die Ursache sichtbar machen, aber es sollte gezielt genutzt werden. Ein generisches deny ip any any log auf stark frequentierten Links kann Logfluten und CPU-Last verursachen. Besser ist:

• Eng matchende Deny-Regeln mit log nur für den betroffenen Flow
• Logging temporär aktivieren, dann wieder entfernen
• Parallel Trefferzähler nutzen, weil sie deutlich „leichter“ sind

Wenn Sie Logging nutzen, prüfen Sie anschließend show logging und Ihre zentrale Syslog-Infrastruktur, um die Events korrekt zu korrelieren.

Schritt 8: Testmethoden, die in der Praxis wirklich helfen

Ein häufiger Fehler ist, nur „Ping geht/nicht“ zu testen. Für Applikationen brauchen Sie spezifischere Tests.

• Ping: gut für Basis-Konnektivität (ICMP), aber nicht ausreichend für TCP/UDP-Services.
• Traceroute: zeigt Pfad und hilft, den Filterpunkt einzugrenzen (ICMP/UDP je nach Tool).
• Porttests: z. B. Test auf TCP/443 (Browser, curl, oder ein Portcheck-Tool im eigenen Umfeld).
• DNS-Tests: Name vs. IP getrennt prüfen.

Praxis-Tipp: Testen Sie immer aus Sicht des Clients und – wenn möglich – auch vom Gateway/Router aus, um die Problemzone einzugrenzen.

Schritt 9: Safe Change Vorgehen, damit Troubleshooting nicht eskaliert

ACL-Fixes sind oft zeitkritisch, aber ein hektischer Change kann alles schlimmer machen. Ein bewährtes Vorgehen:

• Konfiguration sichern: copy running-config startup-config (oder vorher extern sichern, je nach Prozess)
• Eine zweite Session offen halten, besonders bei Remote-Changes
• Änderungen schrittweise: erst Permit ergänzen, testen, dann ggf. Deny/Altregeln anpassen
• Trefferzähler nach dem Change prüfen (ist die Regel wirklich aktiv?)
• Dokumentieren: remark mit Zweck/Datum/Ticket

Bei Management-ACLs (VTY access-class) ist besondere Vorsicht geboten: Ein kleiner Fehler kann den Remotezugang sperren. Deshalb sollte ein Break-Glass-Zugang (lokal/Console/OOB) immer eingeplant sein.

Typische Szenarien aus dem Alltag und die passende Diagnose

„Web geht nicht, Ping zu 8.8.8.8 geht“

• Wahrscheinliche Ursache: DNS blockiert (UDP/TCP 53) oder Proxy/HTTPS-Ports blockiert.
• Prüfen: Extended ACL für DNS und TCP/443, Hit Counter, DNS-Resolver erreichbar.

„Nur ein Server ist nicht erreichbar, alles andere schon“

• Wahrscheinliche Ursache: Zielhost wird durch eine spezifische Deny-Regel geschützt oder Server-VLAN hat eine restriktive ACL.
• Prüfen: ACLs am Server-SVI und am Client-SVI, Reihenfolge, spezifische Denies gegen den Host.

„SSH auf den Switch geht nicht mehr“

• Wahrscheinliche Ursache: VTY access-class zu restriktiv, ACL-Reihenfolge falsch, Adminnetz nicht erlaubt, AAA/SSH-Config geändert.
• Prüfen: show running-config | section line vty, Management-ACL, Hit Counter, SSH enabled.

„Ein VLAN hat Internet, das andere nicht“

• Wahrscheinliche Ursache: NAT-ACL oder PBR-ACL matcht nur ein VLAN; Extended ACL blockt DNS/HTTPS; Default Gateway/Policy unterscheidet sich.
• Prüfen: NAT-ACL Hits, PBR Route-Map Hits, ACLs am SVI, Routing/Default Route.

Best Practices, damit ACL Troubleshooting seltener nötig ist

• Benannte ACLs mit klaren Namen und remark einsetzen
• Reihenfolge nach „spezifisch vor allgemein“
• DNS und notwendige Nebenprotokolle von Anfang an berücksichtigen
• Logging sparsam und gezielt nutzen; Hit Counter regelmäßig prüfen
• Extended ACLs möglichst nahe an der Quelle platzieren, Standard ACLs nahe am Ziel
• Änderungen schrittweise ausrollen, mit Tests und Rollback-Option

Als vertiefende Cisco-Quellen eignen sich der Anchor-Text Cisco ACL Grundlagen sowie die Cisco IOS Command Reference für Syntax und Plattformdetails. Für übergreifende Sicherheits- und Betriebsprinzipien (Least Privilege, Logging, Change-Disziplin) ist der Anchor-Text CIS Controls hilfreich.

Praxis-Checkliste: Warum wird Traffic geblockt?

• Flow exakt definiert (Quelle, Ziel, Protokoll, Port, Richtung)?
• Filterpunkt identifiziert (wo hängt der Traceroute/wo endet der Pfad)?
• ACL-Binding geprüft (Interface/SVI, in/out, VTY access-class)?
• Hit Counter geprüft (welche Zeile matcht, steigt ein Deny)?
• Implizites deny berücksichtigt (fehlt ein Permit für den Rest)?
• DNS/ICMP/Rückverkehr/Abhängigkeiten geprüft?
• Weitere Filterpunkte ausgeschlossen (zweite ACL, PBR, NAT, Firewall)?
• Änderung sicher umgesetzt (zweite Session, Rollback, Dokumentation)?

copy running-config startup-config

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.