Security Group „korrekt“, aber Traffic droppt: So verifizierst du es

Wenn eine Security Group „korrekt“ aussieht, aber der Traffic droppt, beginnt oft die frustrierendste Art von Netzwerkdebugging: Die Regeln wirken sauber, Ports sind freigegeben, Quellen stimmen – und trotzdem kommt keine Verbindung zustande oder sie bricht sporadisch ab. In Cloud-Umgebungen ist das ein typisches Muster, weil Security Groups (oder äquivalente Konstrukte wie Azure NSG und GCP Firewall Rules) nur eine Schicht im gesamten Pfad sind. Außerdem sind Security Groups zustandsbehaftet, aber nicht allwissend: Routing, NACLs/Network ACLs, Load Balancer, Private Endpoints, DNS-Auflösung, Asymmetrien oder MTU-Probleme können Verkehr ebenso zuverlässig „verschwinden lassen“, obwohl die Security Group auf den ersten Blick richtig ist. In diesem Artikel lernen Sie eine verlässliche Vorgehensweise, um solche Fälle zu verifizieren: Sie sammeln Evidence, prüfen den tatsächlichen Datenpfad (nicht nur die Konfiguration), unterscheiden harte Blocks von stillen Drops und bauen eine Beweiskette auf, die eindeutig zeigt, wo der Traffic verloren geht. Das Ziel: weniger Raten, mehr reproduzierbare Diagnosen – und eine Methode, die Sie bei Incidents wiederholt anwenden können.

Warum „Security Group korrekt“ selten die ganze Wahrheit ist

Security Groups sind in vielen Clouds der primäre Mechanismus für Instanz- oder Interface-basierte Netzwerkfreigaben. Sie wirken deshalb wie der „Gatekeeper“. In der Praxis entstehen Drops aber häufig außerhalb dieser Ebene. Typische Gründe:

• Der Traffic erreicht das Interface nie: Routing oder DNS führt in eine andere Richtung (z. B. falsche Ziel-IP, falscher Load Balancer, falscher Endpoint).
• Eine andere Schicht blockiert zustandslos: Network ACLs, Firewall-Appliances oder policy-basiertes Routing droppen Rückverkehr.
• Asymmetrisches Routing: Hinweg und Rückweg laufen über unterschiedliche Pfade; stateful Komponenten verwerfen Antworten.
• Port- und Protokolldetails: Ephemeral Ports, ICMP, PMTUD, UDP-Timeouts oder sehr kurze Connection-Timeouts erzeugen „Drops“ ohne klare Fehlermeldung.

Als konzeptioneller Einstieg in die Funktionsweise zustandsbehafteter Regeln vs. stateless Filter sind die Grundlagen zu TCP/Ports hilfreich, z. B. RFC 793 (TCP). Für Cloud-spezifische Details finden Sie offizielle Dokumentation bei AWS Security Groups, Azure Network Security Groups und Google Cloud Firewall Rules.

Die wichtigste Debugging-Regel: Erst verifizieren, dass es denselben Flow ist

Bevor Sie Regeln vergleichen, müssen Sie sicherstellen, dass Sie den gleichen Traffic betrachten: gleiche Quelle, gleiche Ziel-IP, gleicher Port, gleiches Protokoll, gleiche AZ/Zone, gleiche Netzwerkpfade. Gerade bei DNS, Load Balancern und Private Endpoints ist das ein häufiger Stolperstein.

• Quelle: Welche Instanz/Pod/Node erzeugt den Traffic tatsächlich?
• Ziel: Welche IP wird aufgelöst? A/AAAA getrennt prüfen (IPv4 vs. IPv6).
• Port/Protokoll: TCP 443 ist nicht „HTTP“; zusätzlich können Health Checks oder Sidecars andere Ports nutzen.
• Zeitfenster: Passiert es nur unter Last oder nach Deployments (neue Verbindungen, Retries, Warmups)?

Schritt 1: DNS und Ziel-IP beweisen, nicht annehmen

Wenn Traffic „droppt“, ist DNS oft der heimliche Schuldige: Split-Horizon, Private Zones oder unterschiedliche Resolverpfade liefern andere Ziel-IPs. Dann debuggen Sie die Security Group am falschen Objekt.

• Verifizieren Sie die aufgelöste IP: Ist sie privat/öffentlich? Passt sie zur erwarteten VPC/VNet?
• Prüfen Sie AAAA vs. A: Wenn IPv6 bevorzugt wird, kann IPv4-Freigabe korrekt sein und trotzdem droppen die Verbindungen über IPv6.
• Vergleichen Sie Resolver-Pfade: Pod/VM kann andere DNS-Server verwenden als Ihr Laptop.

Ein nützlicher Überblick zu DNS-Mechanik (inkl. Resolver und Caching) ist Cloudflare: Was ist DNS?.

Schritt 2: Den Datenpfad grob bestätigen (Reachability statt Rule-Reading)

Bevor Sie in Details gehen, lohnt sich ein schneller „Reachability“-Check: Kommt überhaupt ein Paket am Zielinterface an? Viele Clouds bieten dafür Analyse-Tools (z. B. Reachability Analyzer), die den theoretischen Pfad über Routing und Security prüfen. Das ersetzt keine echte Messung, kann aber schnell zeigen, ob Sie eine offensichtliche Blockade übersehen.

• Route Table prüfen: Greift die erwartete Route (Longest Prefix Match)?
• Subnet-Zuordnung: Hängt die Instanz wirklich an dem Subnet, dessen Regeln Sie prüfen?
• Zwischenkomponenten: NAT, Firewall, Transit/Peering, PrivateLink/Endpoints – alle können den Pfad verändern.

Wichtig: Analyse-Tools prüfen oft nur Konfiguration, nicht Live-Zustand (z. B. Kapazitätsengpässe, Interface-Errors, Health-Status). Deshalb bleibt Evidence aus Logs/Flows entscheidend.

Schritt 3: Flow Logs nutzen, um „Drop“ von „Timeout“ zu trennen

Wenn Security Groups „richtig“ wirken, brauchen Sie eine objektive Sicht: Wird der Traffic akzeptiert, abgelehnt oder verschwindet er, bevor er überhaupt in den Logs auftaucht? VPC/VNet Flow Logs (oder vergleichbare Telemetrie) sind dafür meist der schnellste Hebel.

• ACCEPT outbound, kein inbound: Rückwegproblem, Asymmetrie, NACL/Firewall oder Ziel antwortet nicht.
• REJECT inbound/outbound: Eine Policy-Schicht blockiert aktiv (kann SG, NACL oder Firewall sein, je nach Plattform).
• Gar keine Flows sichtbar: Traffic verlässt den Host nicht (App/OS), geht an ein anderes Ziel (DNS), oder wird vorher abgefangen (Proxy/Sidecar).

AWS-spezifisch sind VPC Flow Logs eine zentrale Quelle für Evidence. Für Azure und GCP sind entsprechende Flow-/Firewall-Logging-Mechanismen ähnlich wertvoll, weil sie „gesehen vs. nicht gesehen“ objektiv machen.

Drop-Rate als Messgröße statt Gefühl

Wenn Sie eine Zeitreihe aus Flow Logs oder Metriken haben, ist eine einfache Drop-Rate oft hilfreicher als Einzelfehler:

$\mathrm{DropRate}=\frac{D_{\mathrm{dropped}}}{D_{\mathrm{dropped}}+D_{\mathrm{accepted}}}$

Steigt die DropRate nur in Peaks, deutet das eher auf Kapazitäts-/Burst-Probleme (Queues, NAT, Firewall-State) oder Retry-Verstärkung hin. Ist sie konstant hoch, ist es eher eine stabile Fehlkonfiguration.

Schritt 4: Security Group in beide Richtungen verifizieren (Stateful ≠ sorglos)

Security Groups sind in vielen Clouds zustandsbehaftet: Wenn ein Outbound-Flow erlaubt ist, ist der Rückverkehr typischerweise ebenfalls erlaubt. Das führt zu einem Denkfehler: Teams prüfen nur die Inbound-Regel am Ziel und ignorieren Egress oder umgekehrt. Prüfen Sie immer:

• Inbound am Ziel: Erlaubt die SG den Traffic aus der Quelle (CIDR oder SG-Referenz)?
• Egress an der Quelle: Erlaubt die Quell-SG den Traffic zum Zielport und Ziel-CIDR?
• Protokollgenauigkeit: TCP vs. UDP vs. ICMP (ICMP wird oft vergessen, ist aber für PMTUD/Diagnose wichtig).
• SG-Referenzen: SG-to-SG funktioniert nur im erwarteten Scope (z. B. gleiche VPC oder kompatible Konstrukte); bei Peering/Transit gelten andere Regeln.

Ein häufiger Sonderfall: Ein Load Balancer steht dazwischen. Dann muss nicht nur der Client zum LB, sondern auch der LB zu den Targets passen – inklusive Source-IP-Verhalten und Health-Check-Ports. Bei AWS sind das häufige Ursachen für „SG korrekt, aber trotzdem down“ in Kombination mit Target Groups und Health Checks. Als Startpunkt hilft ELB Security Groups.

Schritt 5: Network ACLs und stateless Filter prüfen (der Klassiker bei „SG stimmt“)

Network ACLs (oder vergleichbare stateless Filter) sind die klassische zweite Fehlerquelle: Security Groups erlauben, aber NACLs blockieren – oft nicht in der Richtung, die man erwartet. Weil NACLs zustandslos sind, müssen Hin- und Rückrichtung explizit passen.

• Ephemeral Ports: Rückverkehr kommt häufig auf dynamischen Ports zurück. Wenn NACLs zu eng sind, scheitert die Verbindung trotz korrekter SG.
• Richtungslogik: Inbound und Outbound müssen jeweils erlauben; „nur 443“ reicht für TCP nicht zwingend, wenn Rückports nicht abgedeckt sind.
• Regelreihenfolge: NACLs arbeiten oft nach Regelnummern; ein früher „deny“ kann spätere „allow“ aushebeln.

Wenn Sie NACLs nutzen, ist es sinnvoll, eine standardisierte NACL-Baseline zu haben, statt pro Subnet individuelle Regeln zu pflegen.

Schritt 6: Asymmetrisches Routing ausschließen (wenn Antworten nie ankommen)

Ein typisches Muster: Der Client sendet SYN, aber SYN-ACK kommt nie zurück. Oder HTTP-Requests gehen raus, aber Antworten bleiben aus. Wenn Security Groups „grün“ sind, ist Asymmetrie ein Hauptverdächtiger – insbesondere bei Transit/Peering, zentralen Firewalls, VPN/Dedicated Links oder Policy-basiertem Routing.

• Hinweg über Pfad A, Rückweg über Pfad B: Stateful Geräte droppen Rückverkehr, weil sie den Zustand nicht kennen.
• Mehrere Exits: Unterschiedliche Default Routes pro Subnet/AZ, Egress-Gateways, NAT-Gateways.
• Überlappende CIDRs: Falsche Route greift, weil Longest Prefix Match etwas anderes entscheidet als gedacht.

Praktisch verifizieren Sie das mit Flow Logs in beiden Segmenten und, wenn möglich, mit einem Trace über Zwischenhops. Wenn Sie Hybrid Connectivity betreiben, sind BGP- und Präferenzregeln häufig die Ursache für „plötzlich asymmetrisch“.

Schritt 7: MTU, PMTUD und „Blackhole“-Effekte testen

Wenn kleine Requests funktionieren, große aber hängen, ist das ein starkes Signal für MTU-/Fragmentierungsprobleme. Das wird oft fälschlich als „Security Group droppt“ interpretiert, weil es ebenfalls in Timeouts resultiert.

• Symptom: Kleine TCP-Verbindungen ok, größere Transfers stall; TLS kann bei großen Handshakes scheitern.
• Ursachen: Encapsulation (VPN), falsche MTU auf Hosts, ICMP geblockt (Fragmentation Needed), PMTUD scheitert.
• Verifikation: Tests mit unterschiedlichen Payload-Größen; ICMP-Regeln prüfen; MTU konsistent setzen.

Schritt 8: Packet Capture gezielt einsetzen (wenn Logs nicht reichen)

Wenn Sie nach DNS, Routing, SG, NACL und Flow Logs immer noch keine klare Antwort haben, ist ein gezielter Paketmitschnitt oft der schnellste Weg zur Wahrheit. Wichtig ist: nicht „alles mitschneiden“, sondern eine kurze, fokussierte Capture um den konkreten Flow herum.

• Am Client: Sehen Sie SYN rausgehen? Sehen Sie Retransmits? Kommt je ein SYN-ACK zurück?
• Am Ziel (wenn möglich): Kommt SYN überhaupt an? Wenn ja, antwortet der Dienst oder blockt das OS?
• Auf Zwischenkomponenten: Falls Sie eine Appliance/Firewall haben, prüfen Sie Session-Logs und Drops.

Dieses Vorgehen trennt „Netzpfad“ von „App/OS“. Wenn SYN-ACK nie auftaucht, ist es selten die Applikation. Wenn SYN-ACK ankommt, aber TLS scheitert, ist es oft SNI/Zertifikat/Proxy oder Timing.

Typische „Security Group ist korrekt“-Fallen und wie Sie sie beweisen

Einige Muster tauchen so häufig auf, dass sich ein kurzer Katalog lohnt. Die Stärke liegt darin, dass jedes Muster eine klare Verifikationsidee hat.

• Falsches Zielobjekt: DNS zeigt auf andere IP/LB/Endpoint → Beweis: aufgelöste IP aus dem betroffenen Workload loggen.
• Falsche Quelle: NAT/Proxy/Load Balancer ändert Source-IP → Beweis: Flow Logs am Ziel zeigen andere Source als erwartet.
• Health Checks vergessen: LB-Health-Check-Port nicht freigegeben → Beweis: Targets „unhealthy“, aber Direktzugriff klappt.
• NACL blockt Rückverkehr: SG erlaubt, NACL nicht → Beweis: Flow Logs/NACL Counters zeigen Drops in einer Richtung.
• Asymmetrie: Rückweg geht über anderen Gateway → Beweis: outbound sichtbar, inbound fehlt, korreliert mit Routing-Änderungen.
• IPv6 gewinnt: AAAA wird bevorzugt, aber Regeln/Routes fehlen → Beweis: Ziel-IP ist IPv6, v4-Regeln irrelevant.
• MTU-Blackhole: Kleine Pakete ok, große hängen → Beweis: Problem korreliert mit Payload-Größe, ICMP/PMTUD.

Ein belastbares Verifikations-Playbook für Incidents

Damit Sie im Incident nicht jedes Mal neu anfangen, hilft ein Playbook, das in 10–20 Minuten eine klare Ursache-Kategorie liefert. Die folgenden Schritte sind bewusst in einer Reihenfolge, die schnelle Beweise priorisiert.

• FQDN → IP verifizieren: Am betroffenen Workload, A/AAAA getrennt, TTL notieren.
• Flow identifizieren: Quelle, Ziel-IP, Zielport, Protokoll, Zeitpunkt.
• Flow Logs prüfen: ACCEPT/REJECT/gar nicht sichtbar, jeweils inbound/outbound.
• Security Group beidseitig: Inbound am Ziel, Egress an der Quelle, SG-Referenzen vs. CIDR.
• NACL/Firewall: Stateless Regeln und Rückrichtung, Ephemeral-Port-Bereiche, zentrale Appliances.
• Routing/Asymmetrie: Route Tables, Transit/Peering, mehrere Exits, BGP-Änderungen.
• MTU-Test: Große vs. kleine Payloads, ICMP/PMTUD prüfen.
• Packet Capture (kurz): SYN/SYN-ACK/ACK sichtbar? Retransmits? TLS-Handshake-Phase?

Prävention: Wie Sie verhindern, dass „SG korrekt, aber droppt“ zum Dauerproblem wird

Viele dieser Incidents entstehen, weil Konfigurationen zwar existieren, aber nicht als System betrieben werden. Prävention heißt: Standards, Observability und kontrollierte Changes.

• Standardisierte Patterns: SG-Templates pro Serviceklasse (Web, DB, Worker) und klare Regeln für LB/Health Checks.
• NACL-Minimierung: Wenn möglich, NACLs als grobe Guardrails statt als feingranulare Policy nutzen.
• DNS-Governance: Split-Horizon und Private Zones dokumentieren; automatische Verknüpfung neuer Netzwerke via IaC.
• Flow Logs by default: Aktivieren und segmentiert auswerten (Subnet, AZ, Ziel-CIDR, Port).
• Change-Disziplin: Routing- und Security-Änderungen canaryen, Blast Radius begrenzen, Rollback planen.
• Timeout-/Retry-Standards: Verhindern, dass kleine Drops zu Retry-Stürmen werden, die Symptome verschleiern.

Outbound-Referenzen für vertiefende Details

• AWS: Security Groups in der VPC
• AWS: VPC Flow Logs zur Verifikation von Traffic
• Azure: Network Security Groups (NSG) – Konzepte und Regeln
• Google Cloud: Firewall Rules – Grundlagen und Verhalten
• RFC 793: TCP – Verbindungsaufbau und Zustandsmodell

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.