Warum „Security Group ist korrekt“, aber Traffic droppt? (Debug-Checkliste)

„Security Group ist korrekt, aber Traffic droppt“ ist eines der häufigsten und frustrierendsten Troubleshooting-Szenarien in Cloud-Netzwerken. Die Security Group (SG) ist in AWS zwar ein zentraler Control Point, aber sie ist selten der einzige. Selbst wenn Inbound- und Outbound-Regeln auf den ersten Blick stimmen, kann der Datenpfad an vielen anderen Stellen scheitern: falsche Route, falsches Subnetz, NACL blockt Ephemeral Ports, DNS löst auf ein anderes Ziel, eine andere ENI trägt die relevante SG, ein Load Balancer nutzt andere Security-Controls, oder der Traffic wird zwar zugelassen, aber auf Applikationsebene verworfen. Zusätzlich erschweren Caching, asymmetrische Pfade und Multi-AZ-Setups die Diagnose, weil das Problem nur für einen Teil der Requests auftritt. Dieser Artikel liefert eine praxisorientierte Debug-Checkliste, mit der Sie systematisch von Symptom zu Ursache kommen – ohne sich in Vermutungen zu verlieren.

Grundprinzip: Erst klären, ob „Drop“ wirklich ein SG-Drop ist

Bevor Sie Regeln ändern, müssen Sie sauber definieren, was „droppt“ bedeutet. In der Praxis meinen Teams damit alles von TCP-Timeout über sporadische Retries bis hin zu 403/5xx. Diese Symptome haben völlig unterschiedliche Ursachen. Security Groups verursachen typischerweise Timeouts (weil der Traffic still verworfen wird), während ein Load Balancer, ein Proxy oder eine Applikation eher explizite Fehlercodes erzeugt.

• TCP Timeout: oft Netzwerkpfad/Firewall/NACL/SG/Route
• Connection Refused: Ziel erreichbar, aber Port/Service nicht offen (Host-Firewall, Prozess, Listener)
• HTTP 403/401: Auth/WAF/Policy/Applikationslogik, selten SG
• HTTP 502/504: Load Balancer/Upstream-Health/Timeout-Settings, häufig kein SG-Problem

Minimaler Wahrheitscheck

• Ist das Ziel überhaupt die erwartete IP/ENI/Instanz?
• Ist das Problem reproduzierbar oder nur intermittierend?
• Passiert es nur aus bestimmten Subnetzen/AZs/Clusters?

Checkliste 1: Sie prüfen die „falsche“ Security Group

Der Klassiker: Die SG-Regel ist korrekt – aber sie hängt nicht an der ENI, die tatsächlich den Traffic verarbeitet. In modernen Setups existieren mehrere Interfaces (Primär-ENI, zusätzliche ENIs, LB-Interfaces, EKS-Node-ENIs, Pod-ENIs, RDS-ENIs). Ebenso kann ein Service über einen Load Balancer laufen, obwohl Sie „direkt“ testen wollten.

• Falsche ENI: Instanz hat mehrere ENIs, Traffic kommt über eine andere
• Falsches Ziel: DNS liefert eine andere IP (Public statt Private, anderer AZ-Endpoint)
• Load Balancer dazwischen: Client spricht LB, aber Sie prüfen SG der Backend-Instanzen (oder umgekehrt)
• Managed Service: RDS/ElastiCache/EKS haben eigene SGs; die Workload-SG reicht nicht

Praxis-Tipp: „Wer ist wirklich das Ziel?“

• Auf Client: Name auflösen (A/AAAA), Ziel-IP notieren
• In Cloud: Ziel-IP einer ENI zuordnen
• Dann: SGs genau dieser ENI prüfen (nicht der „vermuteten“ Ressource)

Checkliste 2: Outbound (Egress) ist nicht so offen, wie Sie denken

Viele Teams fokussieren Inbound-Regeln, obwohl Outbound mindestens genauso oft die Ursache ist. Eine Security Group ist stateful, aber das bedeutet nicht, dass Egress automatisch erlaubt ist. Wenn Egress restriktiv ist (was aus Security-Sicht oft richtig ist), scheitern Verbindungen still, obwohl Inbound am Ziel korrekt wäre.

• Client-SG blockt Egress: Zielport/Protokoll nicht erlaubt
• Ziel ist ein anderer Port: Applikation nutzt nicht 443/5432, sondern z. B. 8443/15443
• DNS/NTP blockiert: Requests scheitern indirekt, weil Namensauflösung oder Zeit-Sync nicht funktioniert
• Proxy-Pflicht: Egress ist nur via Proxy erlaubt, App versucht direkt zu gehen

Fehlerbild: „Nur manche Requests“

Wenn Clients mehrere Ziel-IPs (Round Robin DNS) bekommen, kann restriktiver Egress zufällig nur einen Teil der IPs erlauben. Das wirkt wie „intermittierend“.

Checkliste 3: NACLs droppen – und SG kann nichts dafür

Network ACLs (NACLs) sind stateless und gelten auf Subnetz-Ebene. Sie sind eine der häufigsten Ursachen für Timeouts, obwohl Security Groups sauber wirken. Besonders tückisch: NACLs brauchen Inbound- und Outbound-Regeln, inklusive Ephemeral Ports für Rückverkehr.

• Ephemeral Ports fehlen: Rückverkehr wird verworfen, Verbindung hängt
• Regelreihenfolge: „first match wins“ – eine breite Deny-Regel blockt vor einer Allow-Regel
• Nur eine Richtung erlaubt: Inbound offen, Outbound blockiert (oder umgekehrt)
• Falsches Subnetz: Sie prüfen die NACL des falschen Subnetzes (Client oder Ziel)

Quick-Check: Warum Ephemeral Ports so wichtig sind

Bei TCP-Verbindungen nutzt der Client einen temporären Quellport. Wenn NACLs den Bereich dieser Ports nicht passend erlauben, kommt die Antwort nicht zurück. Ergebnis: Timeout, obwohl Server-Port „offen“ ist.

Checkliste 4: Routing ist falsch (und SG sieht trotzdem „richtig“ aus)

Security Groups entscheiden nur, ob Traffic erlaubt wäre – nicht, ob er den richtigen Weg findet. Routing-Probleme führen zu denselben Symptomen wie ein SG-Drop. Prüfen Sie immer die Route Tables beider Seiten und mögliche transitive Abhängigkeiten.

• Keine Route zum Ziel-CIDR: falsche Route Table am Subnetz
• Falscher Next Hop: Traffic geht zum NAT/IGW statt zum Peering/TGW
• Asymmetrisches Routing: Hinweg anders als Rückweg (häufig mit Appliances/Firewalls)
• Overlapping CIDRs: Routing wird unvorhersehbar oder unmöglich
• Security Appliance Drop: zentrale Firewall/IDS dropt, obwohl SG erlaubt

Warnsignal: „Traceroute zeigt etwas, aber nicht das Erwartete“

In Clouds ist Traceroute nicht immer eindeutig, aber auffällige Pfade (z. B. über Egress-Hub) deuten auf falsche Routen oder Policy-based Routing hin.

Checkliste 5: DNS zeigt auf ein anderes Ziel (Split-Horizon, PrivateLink, Caching)

DNS ist oft der unsichtbare Faktor hinter „SG ist korrekt“. Besonders bei Split-Horizon DNS oder Private Endpoints kann derselbe Hostname intern und extern auf unterschiedliche IPs zeigen. Wenn ein Teil Ihrer Flotte einen anderen Resolver nutzt, sehen Sie unterschiedliche Ziele – und damit unterschiedliche Security Groups.

• Split-Horizon Drift: manche Clients bekommen private IP, andere public IP
• PrivateLink/Private Endpoint: Name löst privat auf, aber Endpoint-SG ist nicht erlaubt
• TTL/Caching: alte Antworten bleiben aktiv, Fix wirkt nicht sofort
• IPv6 vs. IPv4: Client nutzt AAAA und trifft andere Pfade/Controls als A

Praktischer DNS-Check

• Antworten aus mehreren Zonen/Subnetzen vergleichen
• AAAA/A getrennt prüfen
• Resolver-Quelle dokumentieren (Cluster-DNS, VPC-Resolver, Custom DNS)

Checkliste 6: Der Load Balancer ist der eigentliche Gatekeeper

Wenn ein Load Balancer beteiligt ist, gelten zusätzliche Regeln: Der LB hat eigene Security Groups (oder Security Policies) und definiert Health Checks, Idle Timeouts sowie Listener/Target-Group-Ports. Ein Fehler dort erzeugt häufig 502/503/504 oder „sporadische“ Timeouts.

• LB-SG blockt Inbound: Client erreicht den Listener nicht
• Backend-SG blockt LB: Backend erlaubt nicht die LB-SG als Quelle
• Health Checks failing: Targets werden aus dem Pool genommen, Traffic wirkt „random“
• Port-Mismatch: Listener-Port ≠ Target-Port, Backend hört auf anderem Port
• Timeouts: Idle Timeout oder Target Response Timeout falsch gesetzt

Checkliste 7: Host-Firewall, OS und Agenten droppen lokal

Viele Teams stoppen beim Cloud-Control-Plane, aber der Drop kann lokal auf der Instanz passieren: iptables/nftables, Windows Firewall, Security Agents, Service Mesh Sidecars oder eBPF-basierte Policy Engines. Das sieht wie ein SG-Problem aus, ist aber Host- oder Pod-Policy.

• iptables/nftables: Regeln droppen oder NATen unerwartet
• Security Agent: Endpoint Protection blockt Ports/Prozesse
• Service Mesh: Sidecar interceptet Traffic, Policy blockt
• SELinux/AppArmor: verhindert Bind/Connect in bestimmten Kontexten

Erkennungsmerkmal

• „Connection refused“ oder sofortige Resets sind oft lokale/Service-Themen
• Timeouts sind eher Netzwerkpfad, aber lokale Drops können auch still sein

Checkliste 8: Intermittierende Drops durch Kapazität, Conntrack und Limits

Wenn „manchmal geht’s“ und manchmal nicht, ist nicht immer eine Regel falsch. Häufig sind es Limits: zu viele neue Verbindungen, zu wenig Ephemeral Ports, Conntrack-Tabellen voll, SNAT-Port-Exhaustion (bei NAT-Gateways) oder überlastete Zwischenkomponenten.

• Conntrack/State Tables voll: Drops unter Last, besonders bei vielen Kurzverbindungen
• NAT/SNAT Exhaustion: Outbound-Verbindungen schlagen zufällig fehl
• Rate Limits: LB/WAF/Service limitiert, wirkt wie Netzwerkfehler
• CPU/Thread Saturation: Service kann nicht akzeptieren, wirkt wie „Netzwerk droppt“

Einfaches Modell: Warum Retries das Problem verschärfen können

Wenn Clients bei Timeouts aggressiv retrien, steigt die Verbindungsanzahl und damit die Last auf NAT/Conntrack/LB. Das kann eine Feedback-Schleife erzeugen.

$\mathrm{Last}\propto \mathrm{Requests}\times (1+\mathrm{RetryRate})$

Checkliste 9: Observability richtig nutzen (Flow Logs, Reachability, Logs)

Wer „Drop“ beweisen will, braucht Telemetrie. In AWS sind VPC Flow Logs besonders hilfreich, weil sie zeigen, ob Traffic am ENI akzeptiert oder verworfen wurde. Ergänzend helfen Reachability Analyzer (Pfadanalyse) und Load-Balancer-Access-Logs. In Azure/GCP gibt es vergleichbare Flow-Log-Mechanismen.

• Flow Logs: zeigen ACCEPT/REJECT (je nach Plattform) und Ports/IPs
• Reachability/Connectivity Analyzer: modelliert den Pfad und findet fehlende Routen/Rules
• LB Logs: klären, ob Requests am LB ankommen und wie Backends antworten
• DNS Query Logs: belegen, welche IPs tatsächlich genutzt werden

Vertiefung: AWS VPC Flow Logs, AWS Reachability Analyzer, Azure NSG Flow Logs, GCP VPC Flow Logs.

Debug-Runbook: Copy-Paste-Checkliste für den On-Call

Diese Reihenfolge ist so gewählt, dass Sie zuerst häufige, schnelle Ursachen abklären und erst danach in tiefere Details gehen. Sie können sie als Incident-Runbook direkt übernehmen.

• 1) Symptom klassifizieren: Timeout vs. refused vs. HTTP-Fehlercode; Zeitpunkt und Scope erfassen.
• 2) Ziel verifizieren: DNS-Auflösung (A/AAAA), Ziel-IP, zugehörige ENI/Service bestimmen.
• 3) SG am richtigen Objekt: Welche SGs hängen an der ENI, die den Traffic tatsächlich sieht?
• 4) Egress prüfen: Client-SG Outbound für Zielport/Protokoll/Range; Proxy-Pflicht?
• 5) NACL prüfen: Client- und Ziel-Subnetz; Inbound/Outbound; Ephemeral Ports; Rule Order.
• 6) Routing prüfen: Route Tables beider Subnetze; Next Hop; Peering/TGW; Asymmetrie.
• 7) LB/Proxy prüfen: Listener/Target Ports, Health Checks, LB-SGs, Timeouts, WAF/Policies.
• 8) Host/Pod-Policy prüfen: iptables/nftables, Agenten, Service Mesh Policies, Listener läuft?
• 9) Flow Logs/Analyzer: ACCEPT/REJECT belegen, betroffene Ports/IPs isolieren.
• 10) Intermittierend?: Limits (NAT/Conntrack), Retries, Lastspitzen, AZ-spezifische Ausfälle analysieren.

Häufige „False Positives“: Fälle, in denen SG wirklich korrekt ist

• Applikationsauth blockt: 401/403 oder mTLS-Fehler werden als „Netzwerk droppt“ missverstanden.
• Health Checks falsch: LB nimmt Targets raus; Requests wirken zufällig fehlgeschlagen.
• DNS driftet: Ein Teil der Clients geht privat, ein Teil öffentlich; SGs wirken inkonsistent.
• Asymmetrisches Routing: Hinweg okay, Rückweg über Firewall droppt.
• NACL/Firewall: Subnetz- oder Hub-Policy droppt, SG ist irrelevant.

Outbound-Links für weiterführende Quellen

• AWS: Security Groups
• AWS: Network ACLs
• AWS: VPC Flow Logs
• AWS: Reachability Analyzer
• Azure: Network Security Groups
• GCP: VPC Firewall Rules

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.