Site icon bintorosoft.com

ACL Troubleshooting: Warum wird Traffic geblockt?

Red Snapper

Isometric LAN Network Diagram | Local Area Network Technology Concept

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:

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.

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:

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.

Hilfreiche Prüfungen

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

Achten Sie besonders auf:

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:

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:

Interpretation:

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.

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.

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.

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.

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.

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).

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.

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.

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:

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.

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:

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“

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

„SSH auf den Switch geht nicht mehr“

„Ein VLAN hat Internet, das andere nicht“

Best Practices, damit ACL Troubleshooting seltener nötig ist

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?

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:

Lieferumfang:

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.

 

Exit mobile version