TCP-Handshake-Fail: SYN/SYN-ACK/ACK im NOC-RCA

Ein TCP-Handshake-Fail gehört zu den häufigsten und gleichzeitig missverständlichsten Fehlerbildern im operativen Betrieb: Anwender melden „Service down“, Monitoring zeigt „Connection timeout“, und die beteiligten Teams diskutieren, ob Netzwerk, Firewall, Load Balancer oder Anwendung verantwortlich sind. Der entscheidende Vorteil für das NOC liegt darin, dass der TCP-Verbindungsaufbau eine klare, beobachtbare Sequenz hat: SYN, SYN-ACK, ACK. Wenn Sie im Rahmen einer NOC-RCA (Root Cause Analysis) sauber feststellen, welcher Schritt scheitert und wo das Paket verloren geht oder verworfen wird, schrumpft der Suchraum drastisch. Ein SYN, der nie am Ziel ankommt, ist ein anderes Problem als ein SYN-ACK, das zurückkommt, aber wegen asymmetrischem Routing oder fehlendem State verworfen wird. Und ein ACK, das nicht zurück zum Server gelangt, führt zu Symptomen wie „SYN-ACK Retransmits“ oder „half-open connections“ und wird oft fälschlich als Server-Overload interpretiert. Dieses Playbook zeigt, wie Sie Handshake-Fails entlang von SYN/SYN-ACK/ACK operativ trennen, welche Telemetrie in der Praxis aussagekräftig ist, wie Sie typische Middlebox- und Dual-Stack-Edge-Cases erkennen und wie Sie Ihre RCA so dokumentieren, dass Ownership und Fix-Pfad eindeutig sind.

Warum der TCP-Handshake für NOC-RCA so wertvoll ist

Im Gegensatz zu vielen Layer-7-Problemen ist der Handshake mechanisch eindeutig. Der Client sendet ein SYN, der Server antwortet mit SYN-ACK, der Client bestätigt mit ACK. Erst danach gilt die Verbindung als etabliert und Anwendungsdaten (z. B. TLS-Handshake, HTTP) können folgen. Scheitert der Verbindungsaufbau, lassen sich die Ursachen oft entlang dieser drei Schritte gruppieren. Das NOC kann damit in Minuten eine belastbare Hypothese liefern, statt breit „Netzwerk prüfen“ zu eskalieren.

• SYN fehlt: Der Server sieht den Verbindungsversuch nie. Verdacht auf Pfad, Filter, DNS/Ziel-IP, Routing.
• SYN-ACK fehlt: Der Client bekommt keine Antwort. Verdacht auf Server/Listener, Firewall/Policy, Rückweg, Last.
• ACK fehlt: Der Server sendet SYN-ACK, aber die Verbindung bleibt halb-offen. Verdacht auf Rückweg/Asymmetrie/Stateful Drops oder Client-seitige Probleme.

Für die Protokollgrundlage sind RFC 9293 (TCP) und für Host-Anforderungen RFC 1122 die wichtigsten Referenzen.

Begriffsklärung: „Handshake-Fail“ ist nicht gleich „Connection Refused“

Operativ werden mehrere Fehlerbilder vermischt. Ein Handshake-Fail bedeutet meist, dass die Verbindung nicht in den Zustand „ESTABLISHED“ kommt. Das kann durch Timeouts entstehen (keine Antwort), aber auch durch aktive Ablehnung (RST) oder Policy-Mechanismen.

• Timeout: SYN oder SYN-ACK erreicht die Gegenstelle nicht (oder kommt nicht zurück). Der Client wartet und retransmittiert.
• Connection Refused: Zielhost oder Middlebox lehnt aktiv ab (typisch per RST), Handshake wird sofort beendet.
• Handshake-Loop/Flap: Verbindungsaufbau startet immer wieder, bricht ab, erzeugt Retransmissions und Lastspitzen.

Die 5-Minuten-Triage: Scope und Signal vor Ursachen

Bevor Sie SYN/SYN-ACK/ACK detailliert debuggen, klären Sie drei Dinge: Scope, Richtung und Wiederholbarkeit. Damit vermeiden Sie, dass Sie am „falschen“ Ende suchen.

• Scope: Betrifft es alle Clients, nur einen Standort, nur ein Subnetz, nur IPv6, nur einen Service?
• Zieltyp: Direkter Host, Load Balancer, Proxy, Ingress, Service Mesh, NAT-Gateway?
• Wiederholbarkeit: Konstant (immer fail) oder intermittent (nur manche Flows/Zeiten)?
• Nur neue Sessions? Bestehende Sessions stabil, neue Verbindungen scheitern → Verdacht auf State/NAT/Backlog.

Handshake-Phase 1: SYN verlässt den Client – kommt er am Ziel an?

Wenn der Client SYNs sendet, der Server sie aber nie sieht, liegt das Problem in der Regel vor dem Server: falsche Ziel-IP, Routing-Blackhole, ACL/Security Group, falsche VRF, asymmetrischer Pfad über Filter oder ein kaputter ECMP-Teilpfad. In der Praxis ist „SYN kommt nicht an“ eines der schnellsten Ausschlusskriterien für „Server ist schuld“.

Typische Ursachen, wenn SYN nicht ankommt

• DNS/Service Discovery zeigt auf falsche IP: alte Records, falscher VIP, falsches Cluster.
• Routing-Fehler: falsche Route, fehlender Next Hop, VRF-/Tenant-Isolation, Route Leak/Policy.
• Security Filter: NACL/SG/ACL droppt den SYN, häufig ohne Logging.
• ECMP „bad member“: nur manche Flows betroffen, weil ein Pfad droppt.
• L2/L3-Inkonsistenz: ARP/ND-Probleme am ersten Hop, falsches Gateway, Neighbor Resolution failed.

Bestätigung im NOC: Was Sie schnell prüfen können

• Flow-Logs/Firewall-Counter: Kommt der Flow überhaupt an der Perimeter-Komponente an?
• Infrastruktur-Telemetrie: Interface discards, ACL drops, policer drops, ECMP-Mitglieder.
• Pfadcheck: Traceroute als Indikator (nicht als Beweis), plus Routing-Table-Checks am relevanten Hop.

Handshake-Phase 2: SYN-ACK kommt nicht zurück – Server antwortet nicht oder Rückweg ist kaputt?

Wenn SYN am Server ankommt, aber der Client kein SYN-ACK sieht, gibt es drei Hauptklassen: (1) der Server antwortet nicht, (2) ein Gerät in der Nähe des Servers verwirft oder verzögert, (3) der Rückweg zum Client ist defekt oder asymmetrisch über stateful Geräte.

Server antwortet nicht: Listener, Backlog, Host-Overload

• Kein Listener: Port nicht offen oder Service down; dann kommt oft RST statt Timeout, abhängig vom Stack/Policy.
• SYN-Backlog voll: Der Server nimmt SYNs an, kann aber keine neuen Verbindungen abschließen; SYN-ACKs fehlen oder werden verzögert.
• CPU/IRQ/softirq überlastet: Pakete kommen an, aber Verarbeitung/ACK-Generierung ist zu langsam.
• Host-Firewall: lokales Filtering droppt SYNs oder SYN-ACKs.

Rückweg- oder Middlebox-Problem: Der häufige „False Blame“

• Asymmetrisches Routing über Firewall/NAT: SYN geht über Gerät A, SYN-ACK kommt über Gerät B ohne State und wird verworfen.
• Conntrack/State-Table Issues: „no session“, „invalid state“, Table voll, aggressive Timeouts.
• Load Balancer-Fehlverhalten: VIP nimmt SYN an, aber kann nicht an Backend weiterleiten; je nach Implementierung sieht der Client keinen SYN-ACK oder erhält RST.

Operative Bestätigung: Welche Indikatoren Sie suchen

• Server-seitig SYN-ACK Retransmits: Wenn der Server wiederholt SYN-ACK sendet, kommt das ACK nicht zurück (Phase 3) oder SYN-ACK wird unterwegs gedroppt.
• Firewall-Logs „no session“: Starkes Signal für Asymmetrie oder State-Probleme.
• NAT Allocation Failures: Besonders bei Edge-Gateways; neue Sessions scheitern, bestehende laufen weiter.

Handshake-Phase 3: ACK kommt nicht an – half-open Connections und SYN-ACK-Retransmits

Ein klassisches RCA-Muster im NOC ist: „Der Server sieht SYN, sendet SYN-ACK, aber die Verbindung wird nicht established.“ Das passiert, wenn das ACK des Clients nicht beim Server ankommt (oder vom Server verworfen wird). Der Server retransmittiert dann SYN-ACKs und hält halboffene Zustände (SYN-RECEIVED). In Load-Balancer- oder Webserver-Flotten kann das schnell zu sekundären Effekten führen: Backlogs füllen sich, CPU steigt, Monitoring kippt – und der Eindruck entsteht, der Server sei das Problem, obwohl der Trigger im Rückweg liegt.

Typische Ursachen, wenn ACK fehlt

• Asymmetrie: ACK nimmt einen anderen Rückweg als SYN/SYN-ACK und trifft auf stateful Drop.
• Client-seitige Filter/VPN: Client empfängt SYN-ACK, aber lokale Policy/VPN-Stack lässt ACK nicht raus oder NAT/Firewall auf Client-Seite blockt.
• PMTUD/MTU-Edge-Case: Bei reinen ACKs selten, aber bei bestimmten Offload-/Encap-Szenarien kann auch der Rückweg betroffen sein.
• Offload/Checksum Issues: selten, aber in virtuellen Umgebungen möglich; führt zu Drops im Host-Stack.

Erkennungsmerkmale, die Sie im Ticket explizit nennen sollten

• Server ist in SYN-RECEIVED: viele halboffene Verbindungen, SYN backlog Pressure.
• SYN-ACK wird gesendet, ACK fehlt: eindeutig, wenn Sie an Server oder LB SYN-ACK Retransmits sehen.
• Problem nur bei bestimmten Quellen: deutet auf Pfad/Policy/ECMP-Selektivität oder bestimmte Client-NATs hin.

Timeout-Mechanik verstehen: Warum „Handshake dauert 30 Sekunden“ nicht zufällig ist

Viele Tools zeigen Connect-Timeouts, die wie „willkürliche“ Werte aussehen. In Wirklichkeit entstehen sie oft durch Retransmission-Backoff oder durch definierte Library-Timeouts. Für RCA ist das hilfreich: Ein sehr kurzes Scheitern spricht eher für aktive Ablehnung oder Applikations-/Proxy-Timeouts; lange Wartezeiten sprechen eher für Silent Drops oder Blackholes.

Vereinfachte Gesamtdauer bei exponentiellem Backoff (MathML)

$T\approx \sum _{i=0}\mathrm{RTO}\times 2^i$

Operativ bedeutet das: Wenn SYNs still gedroppt werden, wächst die Wartezeit schnell. Ein „Handshake-Fail nach langer Zeit“ ist daher ein starkes Indiz für Drops/Blackholes, nicht für sofortige Ablehnung.

Dual-Stack-Edge-Cases: Wenn Handshake-Fails nur „für manche“ passieren

In Dual-Stack-Umgebungen werden Handshake-Fails häufig als „intermittierend“ wahrgenommen, weil Clients zwischen IPv6 und IPv4 wechseln oder parallel versuchen. Wenn IPv6 instabil ist, sehen Sie Handshake-Fails auf AAAA-Zielen, während IPv4 stabil bleibt. Das erzeugt das typische Bild: „Bei manchen Users geht es, bei anderen nicht“ oder „es ist langsam“. Für das Verständnis der Client-Strategien ist RFC 8305 (Happy Eyeballs v2) relevant.

• Indikator: Fehler korreliert mit IPv6-Zielen oder bestimmten Resolver-Antworten.
• Typische Ursache: ND/RA-Probleme, IPv6-Policy-Filter, IPv6-PMTUD-Blackhole.
• Bestätigung: getrennte Tests gegen A und AAAA, getrennte Metriken pro IP-Familie.

Middleboxes im Fokus: Firewall, NAT und Load Balancer als Handshake-Verstärker

In modernen Architekturen gibt es selten eine „direkte“ Client→Server-Verbindung. NAT-Gateways, Firewalls, Proxies und Load Balancer sitzen im Pfad und können den Handshake beeinflussen. Für die RCA ist daher entscheidend, ob die Handshake-Pakete auf dem jeweiligen Hop gesehen werden und ob dort State aufgebaut wird.

• Stateful Firewall: SYN erlaubt, aber Rückweg/State fehlt → SYN-ACK oder ACK wird gedroppt.
• NAT: Port-/Session-Limits können neue Handshakes verhindern; Symptome sind oft „nur neue Sessions fail“.
• Load Balancer: Frontend nimmt an, Backend unreachable → je nach Modus RST, Timeout oder Backend-Selection-Fehler.
• Proxy/Service Mesh: Handshake findet zu Proxy statt, nicht zum Backend; „refused“ kann vom Proxy kommen.

Beweiskette aufbauen: Wo Sie messen, wenn Sie nicht überall capturen können

Ein idealer RCA-Ansatz nutzt drei Perspektiven: Client, Pfad (Middlebox) und Server. Wenn Sie nicht überall Paketmitschnitte machen können, arbeiten Sie mit Countern, Logs und Flow-Telemetrie. Das Ziel ist, eine Beweiskette aufzubauen: „SYN gesehen hier, SYN-ACK gesehen dort, ACK fehlt ab diesem Punkt.“

• Client-Perspektive: Connect-Fehlerart, Zeitverhalten, DNS-Auflösung, Quell-IP/Quellport.
• Edge/Middlebox: Session-Logs, Drops („no session“, „policy drop“), NAT-Allocation, SYN rate limits.
• Server/LB: SYN-Backlog, SYN-RECEIVED-Anteil, SYN-ACK-Retransmits, Listener-Status.

RCA-Template fürs NOC: So formulieren Sie die Ursache entlang SYN/SYN-ACK/ACK

Eine gute NOC-RCA beschreibt nicht nur „Handshake fail“, sondern benennt die gescheiterte Phase, den Ort des Verlusts und die wahrscheinlichste Ursache. Damit reduzieren Sie Ping-Pong zwischen Teams.

• Phase: SYN fehlt / SYN-ACK fehlt / ACK fehlt.
• Ort: letzter Hop, an dem das Paket sicher gesehen wurde (Client, Firewall, LB, Server).
• Mechanismus: Drop (silent), Reject (RST), State miss (no session), Capacity (backlog/conntrack), Asymmetrie.
• Scope: alle Clients oder subset (Standort, NAT-Pool, IPv6-only, bestimmter LB).
• Change-Korrelation: relevante Deployments/Policy-Änderungen/Route-Changes vor Incident-Beginn.

Schnelle Mitigation nach Handshake-Phase

Mitigation ist dann am effektivsten, wenn sie zur Phase passt. Ein „SYN kommt nicht an“ löst man anders als „ACK kommt nicht zurück“. Diese Zuordnung sollte im Playbook klar sein, damit Maßnahmen nicht mehr Schaden verursachen als Nutzen.

Mitigation bei SYN-Problemen

• Routing/Policy korrigieren: falsche Route, VRF-Zuordnung, ACL/SG/NACL anpassen.
• ECMP-Bad-Member isolieren: betroffene Pfade entfernen oder Hashing prüfen.
• DNS/Service Discovery fixen: falsche Ziel-IP/VIP korrigieren, TTL/Records prüfen.

Mitigation bei SYN-ACK-Problemen

• Listener/Backend stabilisieren: Service starten, LB-Backend Health wiederherstellen, Ressourcen skalieren.
• Stateful Boundary prüfen: Firewall/NAT State, conntrack-Limits, „drop“ vs. „reject“.
• Rückweg sicherstellen: Routing-Symmetrie über stateful Geräte herstellen.

Mitigation bei ACK-Problemen

• Asymmetrie beseitigen: Pinning/Steering, ECMP über stateful Geräte reduzieren, Failover bewusst steuern.
• Client-/Edge-Policy prüfen: lokale Firewalls, VPNs, Client-NAT, Security-Agents.
• Kapazität entlasten: SYN-Backlog/conntrack entlasten, Rate-Limits sinnvoll setzen, wenn SYN-Flood/Storm vorliegt.

Outbound-Links für Protokoll- und Diagnosegrundlagen

• RFC 9293 (Transmission Control Protocol) für Handshake, Zustände und Retransmission-Verhalten.
• RFC 1122 (Requirements for Internet Hosts) für Host-Stack-Anforderungen und Robustheitsregeln.
• RFC 8305 (Happy Eyeballs v2) für Dual-Stack-Verhalten, das Handshake-Fails als „intermittierend“ erscheinen lässt.
• RFC 793 (historische TCP-Spezifikation) als ergänzende Referenz für klassische Zustandsmodelle und Terminologie.

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.