Verbindungsabbrüche analysieren: Wie ich mit Wireshark TCP-Probleme in Unternehmensnetzen aufspüre

Irgendwann trifft es jedes Unternehmensnetz. Der Helpdesk läuft heiß, die Meldungen häufen sich: „Die Verbindung bricht immer wieder ab.” „Das ERP reagiert nicht mehr.” „Der RDP-Session friert ein.” Auf den ersten Blick klingt das nach einem klaren Fall – aber wer schon mal tiefer in solche Probleme eingestiegen ist, weiß: Verbindungsabbrüche sind eines der vielschichtigsten Troubleshooting-Themen überhaupt.

Dahinter können sich TCP Retransmissions verstecken, stille Packetverluste, ein überlasteter Uplink oder schlicht ein falsch konfiguriertes Gerät irgendwo im Pfad. Wer mit Ping und Traceroute alleine antwortet, schaut meistens am falschen Ende hin. Dieser Artikel richtet sich an alle, die tiefer einsteigen wollen – mit Wireshark, mit Methodik, und mit dem Anspruch, Ursachen wirklich zu verstehen statt nur Symptome zu bekämpfen.

Typisches Szenario: Wenn die Verbindung „einfach so” abbricht

Ein Szenario, das ich in Kundenprojekten regelmäßig antreffe: Ein mittelständisches Unternehmen, etwa 200 Mitarbeiter, arbeitet mit einer zentralisierten Anwendung – oft ein ERP, eine CRM-Lösung oder eine Terminal-Server-Umgebung. Die Nutzerbeschwerden kommen meist zwischen 9 und 11 Uhr morgens, also genau dann, wenn der Betrieb auf Hochtouren läuft.

Das Tückische: In vielen Fällen sind es keine totalen Ausfälle. Die Verbindung kommt zurück. Aber jedes Mal, wenn sie abbricht, kostet das Zeit, Nerven und – bei Transaktionssystemen – im schlimmsten Fall auch Datenkonsistenz.

Klassisches Bild beim ersten Blick auf die Infrastruktur: Alles sieht normal aus. Ping funktioniert, die Switches zeigen keine Fehler, der Firewall-Log schweigt. Und trotzdem bricht die Session immer wieder ab.

Genau hier beginnt die eigentliche Analyse.

Technischer Hintergrund: Was hinter TCP-Verbindungsabbrüchen steckt

Um Verbindungsabbrüche zu verstehen, muss man kurz in die TCP-Mechanismen einsteigen. TCP (Transmission Control Protocol) ist verbindungsorientiert und garantiert die zuverlässige Übertragung von Datenpaketen. Dafür nutzt es Bestätigungsmechanismen (ACKs), Sequenznummern und diverse Fehlerkorrekturmechanismen.

Wenn ein Paket verloren geht oder zu spät ankommt, reagiert TCP mit Retransmissions – also erneuten Sendeversuchen. Das ist per se kein Fehler, sondern ein Feature. Aber wenn Retransmissions gehäuft auftreten, ist das ein verlässliches Warnsignal: Irgendwo im Übertragungspfad stimmt etwas nicht.

Noch kritischer sind sogenannte TCP Zero Window-Situationen. Dabei signalisiert der Empfänger dem Sender, dass sein Empfangspuffer voll ist – er kann gerade keine neuen Daten annehmen. Dann friert die Verbindung ein, bis der Puffer wieder freigegeben wird. Passiert das zu häufig oder zu lange, wird die Session vom Betriebssystem oder der Anwendung terminiert.

Weitere relevante Mechanismen:

• TCP Retransmissions entstehen, wenn ACKs ausbleiben – etwa durch Packetverlust oder hohe Latenz
• Duplicate ACKs und Fast Retransmit sind frühe Indikatoren für Congestion
• RST-Pakete (Reset) bedeuten: Eine Seite hat die Verbindung hart abgebrochen – oft ein Hinweis auf Firewalls, Load Balancer oder Timeouts
• Überlastverhalten im Netz führt zu Tail Drop oder – bei modernen Switches – zu aktiver Queuing-Strategie (RED/WRED)

Ein Bottleneck muss nicht immer laut sein. Manchmal ist es ein einzelner Uplink mit 100 Mbit, der in Stoßzeiten sättigt. Manchmal ist es ein Windows-Server mit zu kleinem TCP-Receive-Window. Manchmal ist es auch schlicht ein defektes SFP-Modul, das vereinzelt Frames korrumpiert.

Analyse mit Wireshark: Schritt für Schritt zur Ursache

Wireshark ist das Standardwerkzeug für diese Art von Analyse – und gleichzeitig eines der mächtigsten Open-Source-Tools der Netzwerkwelt. Richtig eingesetzt liefert es Antworten, die kein Monitoring-System geben kann.

Schritt 1: Mitschnitt am richtigen Punkt platzieren

Der häufigste Fehler: Der Capture wird am falschen Ort durchgeführt. Ich empfehle grundsätzlich bidirektionale Captures auf beiden Seiten der Verbindung – also einmal clientseitig, einmal serverseitig. Nur so lässt sich sicher sagen, ob ein Paket nie gesendet wurde, auf dem Weg verloren ging, oder ankam, aber nicht bestätigt wurde.

Wer keinen TAP oder SPAN-Port zur Verfügung hat, kann auf dem Windows-Client oder -Server Wireshark direkt laufen lassen. Für Linux-Systeme ist tcpdump mit anschließender Analyse in Wireshark oft praktikabler.

Schritt 2: Capture-Filter setzen

Um den Mitschnitt handhabbar zu halten, empfehle ich gezielte Capture-Filter:

Dieser Filter beschränkt die Aufzeichnung auf den relevanten Host und Port. Das reduziert Rauschen erheblich.

Schritt 3: Display-Filter für TCP-Probleme

Nach dem Capture geht es an die Auswertung. Wireshark markiert TCP-Anomalien farblich, aber die eigentliche Arbeit beginnt mit gezielten Display-Filtern:

TCP Retransmissions sichtbar machen:

TCP Zero Window Situationen identifizieren:

RST-Pakete finden:

Alle TCP-Fehlerflags auf einen Blick:

Schritt 4: I/O Graph und TCP Stream analysieren

Der I/O Graph in Wireshark (Statistiken → I/O-Diagramm) zeigt, wann im Zeitverlauf Anomalien auftreten. Ich überlagere dort regelmäßig die Gesamtrate mit der Rate der Retransmissions – das macht Lastspitzen und Korrelationen sofort sichtbar.

Für den detaillierten Blick auf eine einzelne Verbindung nutze ich Follow TCP Stream (Rechtsklick auf ein Paket → Follow → TCP Stream). Dort sieht man den kompletten Gesprächsverlauf zwischen Client und Server – inklusive der Stellen, wo nichts mehr kommt.

Schritt 5: TCP Stream Graph (Round-Trip-Time)

Besonders wertvoll: Statistiken → TCP Stream Graphs → Round Trip Time Graph. Dieser zeigt die Schwankungen in der RTT über die Zeit. Spitzen im RTT-Graph korrelieren fast immer mit Retransmissions oder Congestion-Ereignissen. Das ist oft der erste harte Beweis dafür, dass das Problem netzwerkseitig ist und nicht in der Anwendung liegt.

Häufige Ursachen bei Verbindungsabbrüchen

Nach dutzenden Projekten kristallisieren sich immer wieder dieselben Verdächtigen heraus:

1. Überlastete Uplinks oder WAN-Leitungen Besonders bei MPLS- oder DSL-basierten Anbindungen. Das Überlastverhalten zeigt sich in Wireshark als burst-artige Retransmission-Wellen, oft kombiniert mit steigender RTT.

2. Duplex-Mismatch Ein Switch-Port auf Auto-Negotiation, ein Endgerät auf Half-Duplex hardkodiert – oder umgekehrt. Das erzeugt massive Fehlerzähler auf dem Switch-Interface und im Capture sieht man eine hohe Rate an Late Collisions und Retransmissions. Klassiker, der heute immer noch vorkommt.

3. TCP Zero Window durch ausgelastete Server Wenn Anwendungsserver unter Last geraten – zu wenig RAM, langsame Storage, hohe CPU – verlangsamt sich die Applikation bei der Abholung der Daten aus dem Empfangspuffer. Das führt zu TCP Zero Window-Signalisierung, die im schlimmsten Fall in einem Connection Timeout mündet.

4. Stateful Firewalls mit aggressiven Timeouts Viele Firewalls (insbesondere ältere Checkpoint- oder ASA-Konfigurationen) schließen TCP-Sessions nach einem konfigurierten Idle-Timeout – auch wenn die Verbindung aus Applikationssicht noch aktiv sein sollte. RST-Pakete direkt vom Firewall-Interface sind hier der Fingerabdruck.

5. MTU-Probleme und PMTUD-Blackholes Wenn die Path MTU Discovery (PMTUD) scheitert – was bei ICMP-Filterung leicht passiert – werden Pakete nicht fragmentiert, sondern schlicht verworfen. Das äußert sich in Verbindungen, die sich aufbauen, aber dann bei großen Datenmengen einfrieren.

6. Defekte Hardware Klinkt sich unspektakulär an, ist aber häufiger als man denkt. Ein failing NIC, ein SFP-Modul mit Lichtleistungsproblemen oder ein Patchkabel mit intermittierendem Kontakt erzeugen sporadische Packetverluste, die im Capture als vereinzelte Retransmissions erscheinen – schwer zu pinnen, aber eindeutig im Vergleich beider Capture-Seiten.

Lösung und Best Practices

Nach der Diagnose kommt die Umsetzung. Ein paar Grundsätze, die sich in der Praxis bewährt haben:

Netzwerkseitig:

• QoS konsequent konfigurieren: Geschäftskritischer Traffic (ERP, RDP, VoIP) gehört in priorisierte Queues. Kein Unternehmen kann sich leisten, dass ein Backup-Job die ERP-Session verdrängt.
• MTU-Konsistenz sicherstellen: Im gesamten Pfad, inkl. VPN-Tunnel. Standard ist heute 1500 Byte – aber bei Tunneling (IPSec, VXLAN) muss der Overhead berücksichtigt werden. Jumbo Frames nur, wenn durchgehend unterstützt.
• SPAN-Ports oder TAPs permanent einplanen: Troubleshooting ohne Capture-Möglichkeit ist Stochern im Dunkeln. Eine dauerhafte TAP-Infrastruktur an kritischen Netzwerksegmenten zahlt sich aus.

Serverseitig:

• TCP Receive Window und Autotuning prüfen: Unter Windows ist netsh interface tcp show global ein guter Startpunkt. Autotuning sollte aktiviert sein – es sei denn, es gibt konkrete Gründe dagegen.
• Ressourcen monitoren: Verbindungsabbrüche durch TCP Zero Window sind oft ein sekundäres Symptom. Das primäre Problem liegt in der Serverauslastung.

Firewall und Netzwerkkomponenten:

• Session-Timeouts überprüfen: TCP-Idle-Timeouts von 30 Minuten sind für viele Anwendungen zu kurz. Besser: An die Applikations-Keepalive-Mechanismen anpassen.
• ICMP nicht pauschal blockieren: PMTUD benötigt ICMP Typ 3, Code 4. Wer das filtert, riskiert MTU-Blackholes.

Fazit und Handlungsempfehlung

Verbindungsabbrüche sind selten trivial. Sie entstehen meist aus dem Zusammenspiel mehrerer Faktoren – und lassen sich ohne saubere Paketanalyse kaum sicher diagnostizieren. Wireshark ist dabei kein Nice-to-have, sondern ein unverzichtbares Werkzeug für jeden, der Netzwerkprobleme professionell lösen will.

Meine Empfehlung: Warten Sie nicht auf den nächsten Ausfall. Etablieren Sie eine Baseline. Wissen Sie, wie Ihr Netz unter normaler Last aussieht – dann erkennen Sie Abweichungen sofort, wenn sie auftreten.

Wenn Sie akute Verbindungsabbrüche in Ihrem Netz haben oder eine strukturierte Netzwerkanalyse durchführen möchten, lohnt sich der Einstieg mit einem gezielten Packet Capture an den betroffenen Segmenten. Was dabei ans Licht kommt, überrascht selbst erfahrene Admins regelmäßig.

FAQ: Häufige Fragen zu Verbindungsabbrüchen und Netzwerkanalyse

Was sind TCP Retransmissions und warum sind sie ein Problem? TCP Retransmissions entstehen, wenn gesendete Pakete nicht bestätigt werden – etwa weil sie verloren gingen oder zu spät ankamen. Einzelne Retransmissions sind normal. Gehäufte Retransmissions signalisieren jedoch Paketverluste, Überlast oder instabile Verbindungen und können zu deutlichen Performance-Einbußen oder Verbindungsabbrüchen führen.

Wie erkenne ich mit Wireshark, ob das Problem am Netz oder an der Anwendung liegt? Ein guter Indikator ist der TCP Stream Graph (Round-Trip-Time). Wenn die RTT stabil niedrig ist und trotzdem Abbrüche auftreten, liegt das Problem eher in der Anwendung oder dem Server. Steigt die RTT vor einem Abbruch an oder häufen sich TCP Retransmissions, deutet das auf ein Netzwerkproblem hin. Parallel helfen RST-Pakete als Fingerabdruck: Kommen sie vom Endgerät oder von einer Zwischenstation (z. B. Firewall)?

Was bedeutet TCP Zero Window und wie gefährlich ist es? TCP Zero Window bedeutet, dass der Empfänger seinen Eingangspuffer nicht schnell genug leert und den Sender auffordert, das Senden zu pausieren. Kurze Zero-Window-Phasen sind tolerierbar. Halten sie länger an oder wiederholen sie sich häufig, kann die Session terminieren. Ursache ist oft ein ausgelasteter Server oder eine langsame Applikation – nicht das Netz selbst.

Welche typischen Bottlenecks führen zu Verbindungsabbrüchen in Unternehmensnetzen? Die häufigsten Ursachen sind überlastete WAN-Leitungen, Duplex-Mismatches, MTU-Probleme (PMTUD-Blackholes), aggressive Firewall-Timeouts und ausgelastete Server-Ressourcen. Seltener, aber heimtückisch: defekte Hardware wie failing NICs oder SFP-Module mit intermittierenden Fehlern.

Muss ich für die Netzwerkanalyse mit Wireshark Spezialist sein? Für grundlegende Analysen reichen ein paar gezielte Display-Filter und das Lesen von TCP-Flags. Für komplexe Szenarien – etwa die Unterscheidung zwischen Netz- und Applikationsproblem oder die Analyse von Zero-Window-Kaskaden – braucht es Erfahrung im Umgang mit TCP-Internals und Protokollverhalten. Wer regelmäßig mit Verbindungsabbrüchen konfrontiert ist, sollte in die systematische Packet-Analyse-Kompetenz investieren.