Security Group wirkt korrekt, aber Traffic droppt: Kann L2/Overlay sein

Wenn eine Security Group korrekt wirkt, aber Traffic droppt, entsteht in vielen Teams ein reflexartiges Debugging-Muster: Regeln prüfen, Ports vergleichen, CIDRs kontrollieren, „Allow all“ zum Testen setzen – und wenn es dann immer noch nicht zuverlässig funktioniert, beginnt die Ratlosigkeit. Genau hier lohnt sich ein Perspektivwechsel: Security Groups (oder vergleichbare Cloud-Firewall-Konstrukte) beschreiben, was erlaubt ist, aber sie garantieren nicht, dass Pakete auch tatsächlich sauber zugestellt werden. In der Cloud ist der Datenpfad eine Kombination aus virtuellem Switch, Overlay/Underlay, Routing, Encapsulation, Host-Stack und teils verteilten Load-Balancern. Sobald Pakete unterhalb der Security-Group-Logik verloren gehen – etwa durch MTU-/Encapsulation-Probleme, intermittenten Paketverlust im Underlay, ARP/ND-Instabilität, MAC-Flapping oder BUM-Effekte – sieht es im Monitoring so aus, als ob „die Firewall blockt“, obwohl die Regeln objektiv korrekt sind. Für SREs, Platform Engineers und NetOps ist deshalb entscheidend, diese Fehlerklasse zu erkennen und sauber von echten Policy-Drops zu trennen. Dieser Artikel zeigt typische Symptome, eine praxisnahe Diagnose-Strategie und Mitigations, wenn die Security Group stimmt, aber der Datenpfad in L2/Overlay-Schichten kollabiert.

Warum „Regeln sind korrekt“ kein Beweis für Connectivity ist

Security Groups sind in vielen Cloud-Designs zustandsbehaftet (stateful) und wirken logisch eindeutig: inbound erlaubt, outbound erlaubt, fertig. In der Realität gibt es aber mehrere Ebenen zwischen „Regel ist erlaubt“ und „Paket kommt an“.

• Policy-Ebene: Security Group, Network ACL, Host-Firewall, Kubernetes NetworkPolicy, Service-Mesh-Policies.
• Datenpfad-Ebene: virtuelles Switching, Encapsulation (Overlay), Routing (Underlay), Queueing, NIC/Driver, Host-Stack.
• Zustandsebene: Conntrack/State, Caches (ARP/ND), Flow-Hashes (ECMP), Load-Balancer-Backends.

Die häufigste Fehlannahme ist: „Wenn SG offen ist, muss es funktionieren.“ Tatsächlich bedeutet SG „nicht blockiert“, aber es sagt nichts über Paketverlust, Fragmentierung, Jitter oder Pfadinstabilität. Als Schichtenrahmen hilft das OSI-Modell, weil es Symptome (Timeout, Retransmit, Reset) sauber zwischen Layer 2–7 einordnen kann.

Typische Indizien: Wann ein L2/Overlay-Problem wahrscheinlicher ist als ein Policy-Problem

Viele Teams verlieren Zeit, weil sie bei Timeouts automatisch an Firewall/Policy denken. Diese Indizien sprechen dagegen und deuten auf L2/Overlay oder Underlay hin.

• Intermittency: 80% der Requests funktionieren, 20% droppen oder timeouten – ohne Regeländerung.
• Tail-Latenz kippt: p50 bleibt stabil, p95/p99 steigen stark (Queueing, Retransmits, Pfadprobleme).
• Pfad-/Node-Scope: Problem tritt nur in bestimmten AZs, Subnetzen, Nodepools oder bei bestimmten Backends auf.
• Payload-Abhängigkeit: kleine Antworten funktionieren, größere scheitern (MTU/Fragmentierung/Encapsulation).
• TCP-Symptome: Retransmissions steigen, SYNs werden wiederholt, Verbindungen „hängen“ beim Connect oder TLS-Handshake.

Für TCP-Verhalten und Retransmissions ist RFC 9293 eine belastbare Referenz.

Der versteckte Gegner: Overlays, Encapsulation und effektive MTU

In Cloud- und Container-Umgebungen ist Overlay-Technik weit verbreitet – nicht immer sichtbar für das Anwendungsteam. Overlays kapseln Daten (z. B. VXLAN) in ein äußeres Paket, um logische Netze über ein IP-Underlay zu transportieren. Der Preis ist zusätzlicher Header-Overhead. Wenn die Underlay-MTU nicht passend ist oder Path MTU Discovery nicht zuverlässig greift, werden Pakete fragmentiert oder gedroppt. Das wirkt wie „Security Group blockt“, weil die Verbindung nicht zustande kommt oder TLS-Handshake ausfällt – tatsächlich fehlen aber nur wenige Byte MTU.

Effektive MTU als Faustformel

${\mathrm{MTU}}_{\mathrm{eff}}={\mathrm{MTU}}_{\mathrm{underlay}}–O_{\mathrm{encap}}$

• Symptom: „Ping geht, App nicht“, oder nur bestimmte Requests scheitern (größere Payloads, Zertifikatsketten, HTTP2).
• Warum das flaky wirkt: PMTUD hängt von ICMP-Signalen und Pfadverhalten ab; ECMP kann unterschiedliche MTU-Pfade nutzen.
• Mitigation: MTU end-to-end messen, Encapsulation-Schichten reduzieren, MSS/MTU bewusst konfigurieren statt „blind“ zu clampen.

Für VXLAN als häufiges Overlay ist RFC 7348 die Primärquelle.

ARP/ND und Neighbor-Instabilität: „L2 fühlt sich in der Cloud unsichtbar an“

Auch wenn Cloud-Netzwerke „L3-first“ wirken, existieren Neighbor-Mechaniken weiterhin: ARP für IPv4 und Neighbor Discovery (ND) für IPv6. In virtualisierten Umgebungen mit hohem Churn (Pods/VMs) können Neighbor-Tables unter Druck geraten, Einträge veralten oder Zustände inkonsistent werden. Ein einzelner Node oder ein virtuelles Gateway kann dann sporadisch keine korrekte Zuordnung finden – Pakete verschwinden, ohne dass eine Policy sie blockiert.

• Indiz: kurze Brownouts nach Deployments, Rescheduling oder Autoscaling.
• Scope: häufig node- oder subnet-spezifisch, selten global und dauerhaft.
• Mitigation: Rollouts staffeln, Connection Reuse erhöhen, „Churn-Spitzen“ vermeiden, betroffene Nodes isolieren.

Grundlagen finden sich in RFC 826 (ARP) und RFC 4861 (IPv6 Neighbor Discovery).

Wenn es nicht L2 ist, aber auch nicht die Security Group: Asymmetrische Pfade und State

Viele Security-Group-Modelle sind stateful: Rückverkehr wird „automatisch“ erlaubt, wenn ein Zustand existiert. Genau das kann in Kombination mit asymmetrischem Routing oder NAT zu „phantom drops“ führen. Ein klassisches Muster: Der Hinweg nimmt Pfad A, der Rückweg Pfad B – und irgendwo dazwischen geht der Zustandsbezug verloren (z. B. bei unterschiedlichen Egress-Gateways, ungleich verteilten NAT-Devices oder Load-Balancer-Pfaden). Dann sieht es so aus, als ob „SG blockt“, obwohl die Regeln identisch sind.

• Indiz: Verbindungen klappen sporadisch; bestehende Sessions halten, neue brechen.
• Scope: häufig nur bei bestimmten Ziel-IP-Ranges, bestimmten Gateways oder nach Änderungen am Routing.
• Mitigation: Rückpfade deterministischer machen (Egress-Design), Source-NAT konsistent halten, Load-Balancer- und Gateway-Topologie prüfen.

Noisy Neighbor und Queueing: Wenn Drops „kapazitiv“ sind

Nicht jeder Drop ist ein „Hard Fail“. In Cloud-Umgebungen sind viele Ressourcen geteilt: NIC-Queues, virtuelle Switches, Underlay-Links, Gateways. Wenn Nachbarn (andere Tenants oder andere Workloads im gleichen Host) Traffic-Spitzen erzeugen, entstehen Microbursts, Queueing und Drops. Das trifft besonders latency-sensitive Anwendungen, weil TCP-Recovery Zeit kostet und Tail Latency stark steigt.

• Indiz: p99 steigt, Retransmissions steigen, aber keine klaren Policy-Deny-Logs.
• Scope: oft zeitabhängig (Peak Hours) oder auf bestimmte Hosts/Instanztypen begrenzt.
• Mitigation: Workloads verteilen, „hot“ Nodes entlasten, Pod-/VM-Affinitäten prüfen, Bandbreiten-Limits und QoS bewusst einsetzen.

Diagnose-Playbook: So trennen Sie Policy-Drops von L2/Overlay-Drops

Das Ziel ist eine kurze, belastbare Evidenzkette. Nicht jedes Team hat Zugriff auf Underlay-Telemetrie, aber schon mit systematischem Testen lässt sich die Fehlerklasse meist klar eingrenzen.

Schritt 1: Scope bestimmen – logisch oder topologisch?

• Logisch (Policy wahrscheinlicher): nur bestimmter Port, Namespace, Label-Set, ServiceAccount, nur Ingress oder nur Egress.
• Topologisch (L2/Overlay wahrscheinlicher): nur bestimmte AZ, Subnet, Nodepool, nur bestimmte Backends eines Load Balancers.

Schritt 2: Transport-Signale prüfen

• Retransmissions hoch: spricht für Drops/Queueing/MTU, nicht für „clean block“.
• SYN ohne SYN-ACK: kann Policy oder Drop sein; dann Payload- und Pfadtests ergänzen.
• RST sofort: eher Service/Endpoint/Host-Firewall; nicht typisch für Overlay-MTU.

Schritt 3: Payload-Tests (MTU-Indiz)

• Klein vs. groß: Wenn kleine Antworten zuverlässig gehen, große aber scheitern, ist MTU/Encapsulation sehr wahrscheinlich.
• TLS-Handshake separat betrachten: scheitert TLS häufiger als reine TCP-Connects, kann das auf MTU, Drops oder CPU/Queueing deuten.

Schritt 4: Pfadvarianten erzwingen

• Backend-Variation: andere Zielinstanz, anderer Pod, anderer AZ-Backend-Pool.
• Rescheduling: Client-Pod auf anderen Node verschieben; wenn das Problem „mitwandert“, ist es topologisch.
• Alternative Egress/Ingress: anderer NAT/Gateway-Pfad, falls vorhanden.

Mitigation ohne Blindflug: Was kurzfristig stabilisiert, ohne die Ursache zu verschleiern

In vielen Incidents ist der größte Schaden nicht der Drop selbst, sondern der Retry-Sturm, der daraus entsteht. Eine gute Mitigation stabilisiert das System und verbessert gleichzeitig die Diagnosefähigkeit.

• Retries disziplinieren: Backoff + Jitter, Retry-Budgets, damit Drops nicht zu Lastlawinen werden.
• Rollouts drosseln: reduziert Churn und Neighbor-Pressure, verbessert Stabilität und Signalqualität.
• Hotspots entlasten: gezieltes Rescheduling aus auffälligen Nodes/Backends.
• MTU bewusst angleichen: nicht „zufällig clampen“, sondern eine konsistente, getestete MTU-Policy etablieren.
• Segmentierung der Telemetrie: nach AZ/Node/Backend, um den topologischen Scope sichtbar zu machen.

Warum „SG korrekt“ trotzdem falsch sein kann: Häufige Irrtümer bei Security Groups

Auch wenn dieser Artikel L2/Overlay betont, lohnt sich eine kurze Qualitätsprüfung der Security-Group-Annahmen. Manche „korrekten“ Regeln sind nur scheinbar korrekt, weil implizite Abhängigkeiten fehlen oder weil nicht alle Ebenen betrachtet werden.

• Nur SG geprüft, aber NACL ignoriert: stateless ACLs können Rückverkehr oder Ephemeral Ports blockieren.
• Nur Ingress geprüft, Egress vergessen: DNS, Identity Provider, Datenbanken oder Telemetrie benötigen Egress.
• Richtungsfehler: „Allow inbound 443“ hilft nicht, wenn der Client outbound nicht darf oder Rückpfade anders laufen.
• Falscher Scope durch Targeting: SG hängt am falschen Interface/ENI oder nicht an allen relevanten Backends.

Observability, die die Wahrheit zeigt: Welche Signale Sie brauchen

Ohne die richtigen Signale bleibt „SG vs. L2/Overlay“ ein Glaubenskrieg. Die folgenden Messpunkte sind in der Praxis besonders wertvoll, weil sie unabhängig von einer einzelnen Vendor-Implementierung funktionieren.

• Transport-Metriken: Connect-Time p95/p99, TCP Retransmissions, Timeout-Raten, Reset-Raten.
• Pfad-Dimensionen: AZ, Subnet, Nodepool, Backend-ID, Source→Destination (Service-Paar).
• Änderungsannotation: Rollouts, CNI-Updates, MTU-Änderungen, Gateway-Changes zeitlich markieren.
• Flow-Logs (wenn verfügbar): nicht nur „ACCEPT“, sondern auch Drop-/Reject-Gründe und Richtung.

Für standardisierte Instrumentierung in verteilten Systemen ist OpenTelemetry eine bewährte Grundlage, weil sich damit Metriken, Logs und Traces konsistent korrelieren lassen.

Outbound-Referenzen für vertiefende Informationen

• RFC 9293: TCP – Retransmissions, Congestion und Timeout-Verhalten
• RFC 7348: VXLAN – Overlay-Kapselung und Overhead
• RFC 826: ARP – Neighbor-Resolution in IPv4
• RFC 4861: IPv6 Neighbor Discovery (ND)
• OSI-Modell: Schichtenorientiertes Troubleshooting
• OpenTelemetry: Observability-Standard für Metriken, Logs und Traces

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.