Connection-Tracking-Exhaustion in Firewall/CGNAT: Symptome und Response-Plan

Red Snapper

1 month ago

Das Hauptkeyword „Connection-Tracking-Exhaustion in Firewall/CGNAT: Symptome und Response-Plan“ beschreibt eine Störungsklasse, die in Provider- und Enterprise-Umgebungen besonders teuer wird: Das Netzwerk wirkt „halb kaputt“, Links und Routing sind scheinbar stabil, aber neue Verbindungen scheitern, bestehende Sessions werden instabil, und die Fehlersuche driftet schnell in Aktionismus ab. Ursache ist häufig nicht Bandbreite, sondern ein erschöpfter Zustandsraum (State) in zustandsbehafteten Systemen wie Firewalls, Carrier-Grade NAT (CGNAT), Load Balancern oder Service-Chains. Connection Tracking (Conntrack) muss für jede relevante Verbindung Einträge anlegen und verwalten: Quell-/Ziel-IP, Ports, Protokoll, Status, Timeouts, ggf. Übersetzungsinformationen (NAT). Dieser State ist begrenzt durch Speicher, Lookup-Leistung und die Rate, mit der neue Einträge erstellt werden können. Wenn Tabellen voll laufen oder die Create-Rate an die Grenze stößt, kippt die Servicequalität abrupt – und zwar oft selektiv: Bestimmte Anwendungen (HTTPS, VPN, Gaming, VoIP) brechen zuerst, während andere „noch irgendwie gehen“. Ein professioneller Response-Plan kombiniert deshalb schnelle Symptomklassifizierung, belastbare Telemetrie, ein abgestuftes Mitigation-Set und saubere Nacharbeit (RCA, Capacity Sizing, Guardrails), damit die gleiche Lage nicht erneut eskaliert.

Was Connection Tracking in Firewall und CGNAT eigentlich leistet

Connection Tracking ist das Gedächtnis eines zustandsbehafteten Netzsystems. Bei TCP folgt es dem Handshake und dem Session-Lebenszyklus, bei UDP wird ein „Pseudo-State“ über Timeouts geführt, um Rückverkehr zuzuordnen und Policies anzuwenden. In CGNAT kommt zusätzlich die Port- und Adressübersetzung hinzu. In beiden Fällen entsteht pro Flow ein Eintrag, der Speicher belegt, regelmäßig aktualisiert wird und bei jedem Paket einen Lookup benötigt.

Firewall-Conntrack: entscheidet, ob ein Paket zu einer erlaubten Session gehört oder verworfen wird (Stateful Inspection).
CGNAT-Conntrack: speichert NAT-Mappings (innen → außen) und sorgt dafür, dass Rückverkehr korrekt zum Subscriber zurückfindet.
Hybride Ketten: In Service-Chains kann derselbe Flow mehrere State-Tables durchlaufen (z. B. DDoS-Filter → Firewall → CGNAT), was die Wahrscheinlichkeit einer Erschöpfung erhöht.

Die technische Basis für TCP-Verbindungslogik ist in RFC 9293 (TCP) dokumentiert, UDP-Grundlagen in RFC 768. Für NAT als Konzept ist RFC 3022 eine etablierte Referenz.

Warum Conntrack-Exhaustion so schwer zu erkennen ist

Conntrack-Exhaustion ist tückisch, weil sie häufig keine „harten“ Down-Events erzeugt. Interfaces bleiben up, BGP bleibt up, IGP bleibt stabil, und die CPU wirkt manchmal sogar moderat – bis sie es nicht mehr ist. Stattdessen sehen Sie ein Gemisch aus Degradation (Time-outs, Retransmits), partiellen Ausfällen (nur neue Sessions) und scheinbar zufälligen Kundeneffekten. Besonders problematisch ist, dass verschiedene Applikationen unterschiedlich auf State-Engpässe reagieren: Ein Browser baut viele parallele HTTPS-Verbindungen auf, ein VPN nutzt wenige, aber empfindliche Handshakes, und IoT-Geräte erzeugen oft sehr viele kurzlebige UDP-Flows.

Symptome sind indirekt: „TLS Handshake hängt“ statt „Link down“.
Selektivität: Bestehende Sessions können weiterlaufen, neue gehen nicht mehr auf.
Asymmetrie: Wenn Hin- und Rückweg nicht identisch sind, kann State an einem Gerät fehlen, obwohl Traffic sichtbar ist.

Typische Symptome: So zeigt sich Conntrack-Exhaustion im Feld

Ein schneller, strukturierter Symptomcheck spart im Incident die meiste Zeit. Die folgenden Muster sind in Firewall- und CGNAT-Umgebungen besonders häufig.

Symptome auf Kundenseite und Applikationsebene

Neue Verbindungen scheitern: Webseiten laden nicht, App-Logins schlagen fehl, API-Calls laufen in Timeouts.
VPN-/Tunnel-Setups brechen: IKE-/TLS-Handshakes kommen nicht durch, während bestehende Tunnel teils noch leben.
„Einige Dienste gehen, andere nicht“: Oft abhängig von Port/Protokoll und Session-Anzahl.
Intermittierende Effekte: Kurze „Erholungen“, wenn Timeouts Einträge freigeben, gefolgt von erneutem Kollaps.

Symptome auf Netzwerkebene

Anstieg von TCP Retransmits und SYN Retries: Session-Setups werden wiederholt, weil SYN/ACK oder ACK nicht sauber verarbeitet werden.
ICMP-Fehler/Port Unreachable (selektiv): je nach Schutzmechanismen und Konfiguration.
Drop-Counter in Richtung State-Engine: „table full“, „resource limit“, „session create failed“.

Gerätesicht: Was Sie auf Firewall/CGNAT typischerweise sehen

Conntrack/NAT Table Utilization hoch: z. B. > 80–90% dauerhaft.
New sessions/s am Limit: Plateau in der Create-Rate trotz steigender Requests.
CPU-Spikes im Control Path: Lookup/Insert-Kosten steigen, Garbage Collection läuft häufiger.
Logging/Export Backpressure: NAT-Logging, IPFIX oder Syslog können das System zusätzlich bremsen.

Hauptursachen: Warum Tabellen voll laufen

Conntrack-Exhaustion ist selten „einfach nur zu wenig RAM“. Häufig ist es eine Kombination aus Traffic-Charakteristika, Timeouts und Designentscheidungen.

DDoS oder Scans: SYN Floods, UDP Floods, Reflection-Noise oder aggressive Portscans erzeugen massenhaft neue Flows.
Subscriber- oder Client-Verhalten: Viele kurzlebige Verbindungen (z. B. Browser, CDN-Clients, IoT), fehlkonfigurierte Geräte mit Retries.
Timeout-Missmatch: Zu lange UDP-Timeouts füllen Tabellen, zu kurze TCP-Timeouts reißen legitime Sessions ab und erhöhen Retries.
NAT-Portknappheit: In CGNAT kann Port-Exhaustion neue Mappings verhindern, was wie Conntrack-Full wirkt.
Asymmetrisches Routing: Return Traffic läuft nicht über das stateful Gerät, Einträge werden nicht sauber bestätigt/abgebaut.
Skalierungsfehler in Clustern: Ungünstiges Hashing oder Stickiness führt dazu, dass einzelne Nodes überlaufen.

Capacity-Grundlogik: Warum Timeouts und Raten entscheidend sind

Für die Dimensionierung reicht es nicht, „max entries“ zu kennen. Entscheidend ist, wie schnell Einträge entstehen und wie lange sie im Schnitt bestehen bleiben. Als grobes Modell für die durchschnittliche Tabellenbelegung gilt:

Entries_avg ≈ NewFlowsPerSecond × Timeout_avg

Wenn entweder NewFlowsPerSecond oder Timeout_avg steigt, wächst die Tabelle. In der Praxis bedeutet das: Ein moderater Anstieg der Flow-Rate kann bei zu langen Timeouts genauso gefährlich sein wie ein Angriff. Umgekehrt kann das Absenken von Timeouts kurzfristig entlasten, aber auch legitime Flows beschädigen. Genau deshalb braucht ein Response-Plan klare Stufen und „Safe Settings“.

Telemetrie, die Conntrack-Exhaustion zuverlässig sichtbar macht

Wer im Incident nur auf Interface-Gbps und CPU schaut, sieht zu spät, was passiert. Provider-Grade Observability für Conntrack-Lagen besteht aus State-Metriken, Rate-Metriken und Qualitätsmetriken. Idealerweise sind sie pro Scope (Zone, VRF, Pool, Subscriber-Group) auflösbar.

State-Utilization: aktuelle Einträge, Maximalwert, Prozent-Auslastung, Watermarks.
Create-Rate: neue Sessions/s getrennt nach TCP/UDP/ICMP; zusätzlich „failed creates“.
Drop-/Fail-Counters: „table full“, „no ports“, „syn backlog overflow“, „policy deny (state missing)“.
Timeout-Histogramme: nicht nur Durchschnitt, sondern Verteilungen (lange Tail-Werte sind gefährlich).
Top Talkers nach Sessions: Wer erzeugt die meisten neuen Flows (nicht nur die meisten Bytes)?
QoE-Signale: TCP Handshake Success Rate, TLS Handshake Time, DNS Success Rate, VPN Setup Success.

Für Flow-Analysen sind IPFIX/NetFlow/sFlow weiterhin Goldstandard, um Muster in new flows und Portverteilungen zu erkennen. Ein Einstieg zu IPFIX ist RFC 7011.

Schnelldiagnose: Conntrack-Exhaustion vs. Bandbreitenengpass vs. Routing-Problem

Ein Response-Plan beginnt mit einer schnellen, belastbaren Einordnung. Die folgenden Abgrenzungen funktionieren in der Praxis gut.

Hinweise auf Conntrack-Exhaustion

State-Table > 80–90% und gleichzeitig steigende „create failed“ oder „table full“ Counter
Viele kurze Flows, hoher Anteil neuer Sessions, aber geringer Byte-Anteil („pps/flows dominiert“)
Symptom: neue Verbindungen scheitern, bestehende laufen teils weiter

Hinweise auf Bandbreiten-/Queue-Engpass

Interface-Utilization nahe Line-Rate, Queue Drops, Tail-Drops, AQM-Indikatoren
Allgemeiner Throughput-Einbruch, auch für bestehende Sessions
Paketrate und Bandbreite steigen proportional, nicht nur new flows

Hinweise auf Routing/Path-Problem

Prefix- oder Pfadänderungen (BGP/IGP), erhöhte Latenz oder Loss über definierte Pfade
Symptome korrelieren mit bestimmten Destinationen/ASNs, nicht mit Session-Rate
State- und Create-Metriken bleiben unauffällig

Response-Plan: Stufenmodell für den Incident

Ein gutes Response-Plan-Design ist abgestuft: Erst Stabilisierung und Scope-Reduktion, dann gezielte Entlastung, danach Ursachenbehebung. Wichtig ist, jede Maßnahme mit Telemetrie zu verifizieren, um „Mitigation-Blindheit“ zu vermeiden.

Stufe: Stabilisieren und Scope bestimmen

Scope: Welche Zones/VRFs/CGNAT-Pools sind betroffen? Ist es regional, per Node, per Customer-Group?
Symptomtyp: Nur neue Verbindungen oder auch bestehende? TCP-dominiert oder UDP-dominiert?
Ingress-Quelle: DDoS/Scan-Muster oder legitimer Peak? Flow-Daten nach new flows und Ports prüfen.

Stufe: Sofortmaßnahmen zur Entlastung (mit geringem Kollateralschaden)

Rate-Limits für „new sessions“: Wenn das System es unterstützt, caps pro Subscriber/Zone setzen, um Noisy Neighbors zu begrenzen.
Gezielte Filter gegen offensichtlichen Müll: z. B. Drop von klar erkennbaren Scan-Quellen oder offensichtlichen Angriffssignaturen am Edge.
Logging drosseln: Temporär NAT-/Firewall-Logging reduzieren, wenn Export/IO zum Engpass wird (nur kontrolliert und dokumentiert).
Timeout-Profile vorsichtig anpassen: Besonders UDP-Timeouts können Tabellen füllen; Änderungen nur mit Monitoring und klaren Rückrollkriterien.

Stufe: Maßnahmen mit mittlerem Impact

Traffic-Steering/Load-Verteilung: Sessions gleichmäßiger über Cluster-Nodes verteilen, Hashing/Stickiness prüfen.
Scrubbing/DoS-Mitigation aktivieren: Wenn Flow-Daten DDoS zeigen, Umleitung/Filterung vor den State-Systemen.
CGNAT Portpool-Adjustments: Wenn „no ports“ sichtbar ist, Poolgrößen und Public-IP-Zuteilung prüfen; kurzfristig kann ein zusätzlicher Pool entlasten.

Stufe: Notfallmaßnahmen (hoher Impact, klar begrenzen)

Blackholing/RTBH für eng definierte Ziele bei massiven Angriffen, wenn der Dienst nicht haltbar ist.
Hard Drops für spezifische Ports nur, wenn eindeutig keine legitime Nutzung betroffen ist und die Evidenz klar ist.
Controlled Failover nur, wenn State-Synchronisation und Rückfallpfad verstanden sind; sonst drohen Session-Loss-Spiralen.

Entscheidend ist, jede Stufe nach Wirkung zu prüfen: sinkt Table Utilization, sinkt Create-Failure, steigen Handshake-Erfolgsraten? Wenn nicht, war die Maßnahme entweder zu klein, am falschen Punkt oder die Hypothese stimmt nicht.

Kommunikation im Incident: Was Sie intern und extern sauber benennen müssen

Conntrack-Exhaustion erzeugt „weiche“ Kundensymptome und viele Einzeltickets. Gute Kommunikation reduziert Chaos und beschleunigt die Behebung.

Symptomformulierung: „Neue Verbindungen/Session-Setups beeinträchtigt“ ist präziser als „Internet down“.
Scope: Region/Pool/Service klar benennen, damit Frontline nicht im Dunkeln sucht.
Workarounds: Temporär weniger parallele Verbindungen, alternative DNS/VPN-Endpunkte (nur wenn verifiziert).
ETA vermeiden, wenn unsicher: Stattdessen Meilensteine: „Mitigation aktiv“, „State stabilisiert“, „Rückrollphase“.

Nach dem Incident: RCA, Guardrails und nachhaltige Fixes

Conntrack-Lagen sollten immer in strukturelle Verbesserungen münden. Eine RCA ist dann „sauber“, wenn sie nicht nur den Auslöser nennt, sondern auch erklärt, warum das System keine Reserve hatte und warum die Erkennung nicht früher griff.

Trigger: DDoS, Scan, Peak-Event, Client-Bug, Timeout-Missmatch, Routing-Asymmetrie.
Limit, das getroffen wurde: max entries, create-rate, memory, portpool, sync-capacity.
Detection-Gap: Welche Metrik hätte früher alarmieren müssen? Fehlen Histograms, fehlen per-scope Views?
Mitigation-Learnings: Welche Maßnahme wirkte, welche verursachte Kollateralschaden?
Engineering-Actions: Sizing, Timeout-Profile, per-subscriber caps, bessere Load-Verteilung, Anti-Spoofing und DDoS-Frontdoor.

Ein bewährtes Ziel ist, Guardrails technisch zu erzwingen: Wenn Table Utilization einen Schwellenwert erreicht, greifen abgestufte, getestete Schutzmechanismen automatisch (z. B. new-session caps, aggressiveres Garbage Collection Profil, gezielte Filter gegen offensichtliche Anomalien). Das reduziert die Abhängigkeit von manueller Reaktion unter Stress.

Best Practices für Design und Betrieb: Conntrack-Exhaustion vorbeugen

Die nachhaltigsten Maßnahmen sind meist unspektakulär, aber wirkungsvoll: klare Sizing-Regeln, saubere Timeouts, isolierte Failure Domains und Telemetrie, die Sessions sichtbar macht.

Dimensionieren Sie auf Sessions/s und Concurrent Entries: Nicht nur auf Gbps; planen Sie Peak-Flow-Raten ein.
Timeouts als Produktentscheidung: UDP-/TCP-Timeouts pro Serviceklasse definieren, nicht „one size fits all“.
Isolieren Sie Pools und Regionen: CGNAT-Pools und Firewall-Zones so schneiden, dass ein Incident nicht das ganze Netz trifft.
Top Talkers nach Flows begrenzen: Per-subscriber Rate-Limits und Fairness-Mechanismen gegen Noisy Neighbors.
Asymmetrien minimieren: Stateful Geräte brauchen konsistente Pfade; wenn das nicht möglich ist, Architektur anpassen (z. B. stateless DDoS-Frontdoor vor stateful Geräten).
Anti-Spoofing konsequent: Reduziert Angriffsflächen und verhindert, dass Downstreams als Verstärker missbraucht werden. Referenzen: RFC 2827 und RFC 3704.

Outbound-Links für Standards und vertiefende Informationsquellen

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.