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

Irgendwann trifft es jedes Unternehmensnetz. Der Helpdesk läuft heiß, die Tickets häufen sich: „Die Verbindung bricht immer wieder ab.“ „Das ERP reagiert nicht mehr.“ „Die RDP-Sitzung friert ein.“ Auf den ersten Blick klingt das nach einem klaren Fall. Wer aber schon mal tiefer in solche Probleme eingestiegen ist, weiß: Verbindungsabbrüche gehören zu den vielschichtigsten Troubleshooting-Themen überhaupt.

Dahinter können stille Paketverluste stecken, ein überlasteter Uplink, eine Firewall mit zu knappem Timeout, ein Server, der nicht hinterherkommt, oder ein defektes Kabel im Pfad. Wer nur mit Ping und Traceroute arbeitet, schaut meist am falschen Ende hin. Dieser Artikel zeigt dir, wie du mit Wireshark und einer sauberen Methodik vorgehst – mit dem Anspruch, die Ursache 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ändler mit etwa 200 Mitarbeitern und einer zentralen Anwendung – ERP, CRM oder Terminalserver. Die Beschwerden kommen meist zwischen 9 und 11 Uhr, wenn der Betrieb auf Hochtouren läuft.

Das Tückische: Meist sind es keine Totalausfälle, die Verbindung kommt zurück. Aber jeder Abbruch kostet Zeit und Nerven – bei Transaktionssystemen im schlimmsten Fall abgebrochene Buchungen.

Bei der ersten Prüfung sieht alles normal aus: Ping läuft durch, die Switches melden keine offensichtlichen Fehler, das Firewall-Log ist unauffällig. Trotzdem bricht die Session immer wieder ab. Netzwerk-Team und Applikations-Team zeigen aufeinander – und keiner kann beweisen, dass er recht hat.

Genau hier beginnt die eigentliche Analyse.

Technischer Hintergrund: Was hinter TCP-Verbindungsabbrüchen steckt

Um Verbindungsabbrüche zu verstehen, brauchst du ein paar TCP-Grundlagen. TCP (Transmission Control Protocol) ist verbindungsorientiert und sorgt dafür, dass Daten vollständig und in der richtigen Reihenfolge ankommen. Dafür nutzt es Sequenznummern, Bestätigungen (ACKs), eine Prüfsumme zur Fehlererkennung und – wenn etwas fehlt – erneutes Senden. Wie eine Verbindung überhaupt zustande kommt, erkläre ich im Artikel TCP Handshake analysieren: SYN, SYN/ACK, ACK.

Geht ein Segment verloren oder bleibt die Bestätigung zu lange aus, reagiert TCP mit Retransmissions. Das ist per se kein Fehler, sondern genau das, wofür TCP gebaut wurde. Treten Retransmissions aber gehäuft auf, ist das ein verlässliches Warnsignal: Irgendwo im Übertragungspfad stimmt etwas nicht. Warum schon wenige Prozent Verlust die Performance massiv drücken, zeige ich in TCP Retransmissions: Der stille Performance-Killer.

Ein anderes Muster ist TCP Zero Window: Der Empfänger meldet, dass sein Empfangspuffer voll ist. Der Sender pausiert und fragt mit Zero Window Probes nach, ob wieder Platz ist – die Verbindung steht still. TCP baut sie deswegen nicht ab, aber nach zu langem Stillstand greift meist ein Timeout der Anwendung. Hintergründe zum Empfangsfenster: TCP Window Size & Scaling einfach erklärt.

Weitere Mechanismen, die du kennen solltest:

• Retransmission Timeout (RTO): Bleibt das ACK aus, sendet der Sender nach einer Wartezeit erneut – bei jedem weiteren Versuch mit doppelter Wartezeit. Darum wirkt ein Paketverlust für Nutzer oft wie ein „Hänger“ von mehreren Sekunden.
• Duplicate ACKs und Fast Retransmit: Fehlt ein Segment, bestätigt der Empfänger mehrfach dieselbe Sequenznummer. Nach drei doppelten ACKs sendet der Sender das fehlende Segment sofort erneut, ohne den Timeout abzuwarten. Duplicate ACKs zeigen also Verlust oder Umsortierung von Paketen an – nicht automatisch Überlast. Mehr dazu in TCP Retransmissions, Dup ACKs & Out-of-Order.
• RST-Pakete (Reset): Eine Seite – oder ein Gerät dazwischen – bricht die Verbindung hart ab, etwa eine Firewall, ein Load Balancer oder ein Timeout. Aber Vorsicht: Viele Anwendungen beenden Verbindungen ganz regulär per RST statt per FIN. Nicht jeder Reset ist ein Fehler.
• Überlast im Netz: Läuft der Puffer eines Switch- oder Router-Ports voll, werden neue Pakete einfach verworfen (Tail Drop). Ist RED/WRED konfiguriert, verwirft das Gerät schon vorher gezielt einzelne Pakete, damit die Sender rechtzeitig bremsen. Wie sie bremsen, regelt der Congestion-Control-Algorithmus – siehe Vergleich der TCP-Algorithmen Reno, CUBIC und BBR.

Ein Bottleneck muss nicht laut sein. Mal ist es ein 100-Mbit-Uplink, der in Stoßzeiten sättigt, mal ein Server, der Daten nicht schnell genug abholt, mal ein defektes SFP-Modul.

Analyse mit Wireshark: Schritt für Schritt zur Ursache

Wireshark ist das Standardwerkzeug für diese Art von Analyse. Richtig eingesetzt liefert es Antworten, die kein Monitoring-System geben kann – weil du keine Durchschnittswerte siehst, sondern jedes einzelne Paket. Das allgemeine Vorgehen beschreibe ich in meiner 5-Schritte-Methodik zum Eingrenzen von Netzwerkproblemen. Menüpfade nenne ich in der englischen Oberfläche.

Schritt 1: Den Abbruch zeitlich festnageln

Noch vor dem ersten Capture: Sorge dafür, dass Nutzer den genauen Zeitpunkt eines Abbruchs melden – Uhrzeit, Arbeitsplatz, Anwendung. Sonst suchst du später in Gigabytes von Mitschnitten die Nadel im Heuhaufen. Prüfe außerdem, ob Client, Server und Capture-Systeme per NTP synchron laufen – nur dann lassen sich Mitschnitte und Logs sauber übereinanderlegen.

Schritt 2: Mitschnitt am richtigen Punkt platzieren

Der häufigste Fehler: Es wird an der falschen Stelle mitgeschnitten. Ich empfehle grundsätzlich Captures an beiden Enden der Verbindung – einmal clientseitig, einmal serverseitig. Nur so lässt sich sicher sagen, ob ein Paket nie gesendet wurde, auf dem Weg verloren ging oder zwar ankam, aber nicht bestätigt wurde.

Ideal ist ein TAP (ein passives Gerät, das den Datenverkehr einer Leitung abgreift) oder ein SPAN-Port (Port-Spiegelung am Switch). Beachte dabei: Ein SPAN-Port kann unter Last selbst Pakete verwerfen und reicht fehlerhafte Frames in der Regel nicht weiter. Fehlt dir im SPAN-Capture ein Paket, ist das noch kein Beweis für Verlust auf der Leitung.

Hast du weder TAP noch SPAN, kannst du Wireshark direkt auf dem Windows-Client oder -Server laufen lassen. Darfst du auf einem Produktivserver keine Software installieren, bringt Windows in aktuellen Versionen mit pktmon einen eigenen Paketmitschnitt mit – die ETL-Datei wandelst du mit pktmon etl2pcap in ein Format um, das Wireshark öffnet. Auf Linux-Systemen ist tcpdump mit anschließender Auswertung in Wireshark oft praktikabler.

Achtung bei Mitschnitten direkt auf dem Host: Netzwerkkarten übernehmen Segmentierung und Prüfsummen oft selbst (Offloading). Im Capture siehst du dann Pakete über 1.500 Byte oder angebliche Prüfsummenfehler – Artefakte des Mitschnitts, keine echten Fehler. Und Frames, die die Karte wegen CRC-Fehlern verwirft, tauchen im Host-Capture gar nicht auf.

Schritt 3: Capture-Filter und Ringpuffer für sporadische Fehler

Ein gezielter Capture-Filter hält den Mitschnitt handhabbar. Filterst du aber nur auf Server und Port, fehlen genau die ICMP-Meldungen, die du für MTU-Probleme brauchst. Und Vorsicht: Auch ein Filter wie host 192.168.1.50 and (tcp port 443 or icmp) reicht nicht immer. Die ICMP-Meldung stammt von einem Router im Pfad – als Absender steht dort die Adresse des Routers, nicht die des Servers. Läuft der Mitschnitt auf dem Client, fällt sie durch den Filter. Besser:

Der Filter beschränkt die TCP-Aufzeichnung auf den relevanten Server und Port, nimmt aber alle ICMP- und ICMPv6-Meldungen mit. Die fallen im Normalbetrieb kaum ins Gewicht.

Weil Verbindungsabbrüche selten auf Zuruf passieren, lasse ich den Mitschnitt meist über Stunden oder Tage mit einem Ringpuffer laufen. Das geht mit dumpcap, das bei Wireshark mitinstalliert wird:

dumpcap schreibt so fortlaufend Dateien mit je rund 100 MB und behält die letzten 50. Mit -s 128 speichert es von jedem Paket nur die ersten 128 Byte. Für die TCP-Analyse reichen die Header, und der Ringpuffer deckt einen deutlich längeren Zeitraum ab. Meldet ein Nutzer einen Abbruch, sicherst du die passenden Dateien, bevor sie überschrieben werden. Die Interface-Nummer liefert dumpcap -D.

Denk an den Datenschutz: Mitschnitte können personenbezogene Daten enthalten, bei unverschlüsselten Protokollen sogar Inhalte. Stimme längere Captures vorab mit dem Datenschutz und gegebenenfalls dem Betriebsrat ab. Der begrenzte Snaplen hilft auch hier, weil die Nutzdaten weitgehend außen vor bleiben.

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

Nach dem Capture geht es an die Auswertung. Einen schnellen ersten Überblick liefert Analyze → Expert Information: Dort fasst Wireshark alle Auffälligkeiten nach Schweregrad zusammen. Die eigentliche Arbeit beginnt aber mit Display-Filtern. Weitere Filter findest du in Wireshark – Die 10 wichtigsten Display-Filter.

Alle TCP-Auffälligkeiten auf einen Blick (ohne die harmlosen Window Updates):

Retransmissions sichtbar machen:

Verbindungsaufbau scheitert (wiederholte SYNs ohne Antwort):

Zero Window und volle Empfangsfenster:

Resets und reguläre Verbindungsenden:

Lange Pausen innerhalb einer Verbindung finden (hier: mehr als 5 Sekunden):

Für den letzten Filter musst du unter Edit → Preferences → Protocols → TCP die Option „Calculate conversation timestamps“ aktivieren. Er ist Gold wert, um genau die Stelle zu finden, an der eine Session einfriert.

Schritt 5: Herausfinden, wer die Verbindung beendet hat

Das ist die Kernfrage jeder Abbruch-Analyse – und oft der Moment, in dem sich das Fingerpointing auflöst. Entscheidend sind die letzten Pakete der Verbindung:

• FIN vom Server: Die Anwendung hat die Verbindung regulär geschlossen. Die Frage geht an das Applikations-Team: Warum?
• RST vom Client oder Server: Ein Endpunkt hat hart abgebrochen – oft nach einem Anwendungs-Timeout oder nach mehreren erfolglosen Retransmissions.
• RST, das nicht vom Endpunkt stammt: Firewalls, Proxys und Load Balancer senden Resets häufig im Namen des Servers, also mit dessen IP-Adresse als Absender. An der IP erkennst du das nicht. Verräterisch ist der TTL-Wert im IP-Header: Weicht er beim RST deutlich von den übrigen Paketen des Servers ab, kommt das Paket von einem anderen Gerät im Pfad.
• Gar kein sauberer Abschluss: Der Client sendet, bekommt keine Antwort, wiederholt mit wachsenden Abständen und gibt auf. Typisch für eine Session, die eine Firewall still aus ihrer Session-Tabelle gelöscht hat.

Tipp: Lege dir das Feld ip.ttl als Spalte in der Paketliste an (Rechtsklick auf das Feld in den Paketdetails → Apply as Column). Dann fällt ein fremder Reset sofort auf.

Schritt 6: I/O-Graph und TCP Stream im Detail

Der I/O-Graph (Statistics → I/O Graphs) zeigt, wann im Zeitverlauf Auffälligkeiten auftreten. Ich lege dort den Gesamtdurchsatz und einen Graphen mit dem Filter tcp.analysis.retransmission übereinander. So siehst du sofort, ob Lastspitzen und Fehlerhäufungen mit den gemeldeten Abbruchzeiten zusammenfallen.

Für den Blick auf eine einzelne Verbindung klickst du ein Paket an und wählst Rechtsklick → Follow → TCP Stream. Das Fenster zeigt die Nutzdaten – bei HTTPS oder RDP allerdings nur verschlüsselten Datensalat. Wichtiger ist der Nebeneffekt: Wireshark setzt den Filter tcp.stream eq N. Nach dem Schließen siehst du in der Paketliste genau diese Verbindung – mit allen Zeitstempeln, Flags und Lücken. Mehr dazu in Wie lese ich einen TCP Stream richtig?

Schritt 7: Den Round-Trip-Time-Graph richtig lesen

Besonders aufschlussreich ist der RTT-Graph unter Statistics → TCP Stream Graphs → Round Trip Time. Er zeigt, wie lange es dauert, bis ein Segment bestätigt wird. Steigt die RTT kurz vor einem Abbruch deutlich an oder häufen sich parallel Retransmissions, ist das ein starkes Indiz für Überlast oder Verlust im Netz.

Ein harter Beweis ist das allein aber noch nicht:

• Der Capture-Punkt bestimmt, was du misst. Nur ein Mitschnitt nahe am Sender zeigt die volle Strecke. Direkt beim Empfänger gemessen ist die RTT fast null – egal wie langsam das Netz ist.
• Nicht jede Verzögerung ist Netzwerk. Bestätigt der Empfänger verzögert (Delayed ACK) oder ist er überlastet, steigt die RTT ebenfalls. Erst der Vergleich mit der Gegenseite trennt Netzlatenz von Verzögerungen im Endgerät.

Achte außerdem auf die Richtung: Der Graph zeigt immer nur eine Seite der Verbindung. Wähle die Richtung, in der die Nutzdaten fließen, und wechsle bei Bedarf über Switch Direction. Wie du RTT-Werte im Detail bewertest, zeige ich in Hohe Latenz im Firmennetz – RTT analysieren.

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-, DSL- oder VPN-Anbindungen von Standorten. Überlast zeigt sich in Wireshark als wellenartige Retransmissions, oft kombiniert mit steigender RTT, weil sich die Puffer der Netzwerkgeräte erst füllen und dann überlaufen. Typisch: Das Problem tritt nur zu bestimmten Tageszeiten auf, etwa wenn Backups, Updates oder Videokonferenzen dieselbe Leitung nutzen.

2. Duplex-Mismatch

Der Klassiker: Das Endgerät ist fest auf 100 Mbit/Vollduplex eingestellt, der Switch-Port steht auf Auto-Negotiation. Weil das Endgerät nicht mitverhandelt, erkennt der Switch zwar die Geschwindigkeit, fällt aber auf Halbduplex zurück. Unter Last steigen dann die Fehlerzähler – auf der Halbduplex-Seite Late Collisions, auf der Vollduplex-Seite CRC-Fehler und Runts.

Diese Fehler siehst du an den Interface-Zählern des Switches, nicht im Capture – dort erscheinen nur die Folgen, also Retransmissions. Da Gigabit über Kupfer Auto-Negotiation voraussetzt, betrifft das heute vor allem ältere Geräte, Drucker, Industriekomponenten oder fest konfigurierte 100-Mbit-Ports.

3. TCP Zero Window durch überlastete Endgeräte

Gerät ein Server unter Last – zu wenig RAM, langsamer Storage, hohe CPU –, holt die Anwendung die Daten nicht schnell genug aus dem Empfangspuffer. Die Folge: Zero Window, im schlimmsten Fall mit anschließendem Anwendungs-Timeout.

Wichtig: Das Zero Window kommt immer vom Empfänger – und das ist nicht zwingend der Server. Auch ein überlasteter Client, etwa ein Thin Client mit schwacher Hardware, kann den Datenfluss ausbremsen. Für das Netzwerk-Team ist das ein Entlastungsbeweis: Die Daten kommen an, nur der Empfänger kommt nicht hinterher. Wie so ein Nachweis zugunsten des Netzes in einem echten Projekt aussieht, zeige ich im Praxisfall: SQL über WAN-Strecke – wenn die Applikation bremst, nicht das Netz.

4. Stateful Firewalls mit Idle-Timeouts

Firewalls merken sich jede Verbindung in einer Session-Tabelle. Fließt eine Zeit lang kein Paket, wird der Eintrag gelöscht – auch wenn die Anwendung die Verbindung noch nutzen will. Das trifft vor allem Verbindungen mit langen Ruhephasen: Connection Pools von Datenbanken, ERP-Clients über die Mittagspause oder Terminalsitzungen.

Viele Firewalls verwerfen das nächste Paket danach kommentarlos: lange Pause, der Client sendet, bekommt keine Antwort, wiederholt – und gibt auf. Andere senden einen Reset mit der IP-Adresse des Endpunkts; hier hilft der TTL-Vergleich aus Schritt 5. Passt die Pausendauer vor dem Abbruch zum Idle-Timeout der Firewall, ist das oft schon der Beweis. Mit dem Filter tcp.analysis.keep_alive siehst du außerdem, ob die Endpunkte überhaupt Keepalives senden – und in welchem Abstand.

Ein Sonderfall ist asymmetrisches Routing: Hin- und Rückweg laufen über unterschiedliche Firewalls, etwa nach einem Failover. Eine Firewall sieht dann nur eine Richtung der Verbindung, hält die Pakete für ungültig und verwirft sie. Auch hier zeigen Captures auf beiden Seiten, auf welchem Weg die Pakete verloren gehen.

5. MTU-Probleme und PMTUD-Blackholes

Die MTU (Maximum Transmission Unit) ist die maximale Paketgröße, die über eine Strecke passt – im Ethernet standardmäßig 1.500 Byte, in VPN-Tunneln durch den zusätzlichen Overhead weniger. TCP setzt in der Regel das „Don’t Fragment“-Bit. Passt ein Paket nicht durch, verwirft der Router es und schickt die ICMP-Meldung „Fragmentation Needed“ (Typ 3, Code 4) an den Sender zurück. Diesen Mechanismus nennt man Path MTU Discovery (PMTUD).

Wird diese ICMP-Meldung irgendwo gefiltert, erfährt der Sender nie, dass seine Pakete zu groß sind – ein sogenanntes PMTUD-Blackhole. Typisch: Der Handshake klappt, kleine Anfragen funktionieren, bei größeren Datenmengen friert die Verbindung ein. In Wireshark siehst du Retransmissions von Segmenten in voller Größe, während kleine Pakete durchgehen. Dieser Filter zeigt die ICMP-Meldungen – oder dass sie fehlen:

6. Defekte Hardware

Klingt unspektakulär, ist aber häufiger, als man denkt. Eine sterbende Netzwerkkarte, ein SFP-Modul mit zu schwacher Lichtleistung oder ein Patchkabel mit Wackelkontakt erzeugen sporadische Paketverluste. Im Capture erscheinen sie als vereinzelte Retransmissions ohne Muster – schwer festzunageln, aber eindeutig im Vergleich beider Capture-Seiten: gesendet, aber nie angekommen.

Prüfe parallel die CRC- und Input-Error-Zähler der Switch-Ports und bei Glasfaser die optischen Werte. Warum ein Ping solche Verluste oft nicht zeigt, erkläre ich in Packet Loss messen – warum Pings oft lügen.

Spickzettel: Vom Wireshark-Symptom zur wahrscheinlichen Ursache

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 gezielt einsetzen: ERP, RDP oder VoIP gehören an Engpässen in priorisierte Queues, damit kein Backup-Job die ERP-Session verdrängt. QoS wirkt aber nur dort, wo tatsächlich Stau entsteht – meist am WAN-Übergang.
• MTU-Konsistenz sicherstellen: im gesamten Pfad, inklusive Tunneln (IPsec, GRE, VXLAN) und deren Overhead. Bewährt hat sich MSS Clamping auf dem VPN-Gateway: Es begrenzt die Segmentgröße schon beim Verbindungsaufbau, sodass TCP gar nicht erst zu große Pakete schickt. Jumbo Frames nur, wenn sie durchgehend unterstützt werden.
• Capture-Möglichkeiten dauerhaft einplanen: Troubleshooting ohne Mitschnitt ist Stochern im Dunkeln. TAPs oder vorbereitete SPAN-Ports an kritischen Segmenten zahlen sich beim nächsten Vorfall aus.
• Interface-Fehler überwachen: CRC-Fehler, Discards und Drops gehören ins Monitoring – oft das erste Anzeichen für defekte Hardware oder volle Puffer.

Serverseitig:

• TCP-Einstellungen prüfen: Unter Windows ist netsh interface tcp show global ein guter Startpunkt. Receive Window Auto-Tuning sollte auf „normal“ stehen – es sei denn, es gibt konkrete Gründe dagegen.
• Ressourcen überwachen: Zero Window ist ein sekundäres Symptom. Das eigentliche Problem liegt bei CPU, RAM, Storage – oder in der Anwendung selbst.

Firewall und Netzwerkkomponenten:

• Idle-Timeouts und Keepalives aufeinander abstimmen: Die Regel ist einfach: Das Keepalive-Intervall muss kürzer sein als der Idle-Timeout jedes Geräts im Pfad. Das TCP-Keepalive greift unter Windows und Linux standardmäßig erst nach zwei Stunden – und nur, wenn die Anwendung es aktiviert. Verkürze also das Keepalive in Anwendung oder Betriebssystem, oder erhöhe den Firewall-Timeout gezielt für die betroffenen Dienste.
• ICMP nicht pauschal blockieren: PMTUD braucht ICMP Typ 3, Code 4 – bei IPv6 die Meldung „Packet Too Big“ (ICMPv6 Typ 2). Wer das filtert, baut sich MTU-Blackholes.

Fazit: Erst messen, dann handeln

Verbindungsabbrüche entstehen meist aus dem Zusammenspiel mehrerer Faktoren und lassen sich ohne saubere Paketanalyse kaum sicher diagnostizieren. Wireshark ist dabei kein Nice-to-have, sondern das Werkzeug, das aus Vermutungen Belege macht. Die wichtigste Frage lautet fast immer: Wer hat die Verbindung beendet – und warum?

Meine Empfehlung: Warte nicht auf den nächsten Ausfall. Erstelle eine Baseline und lerne, wie dein Netz unter normaler Last aussieht. Dann erkennst du Abweichungen sofort, wenn sie auftreten.

Unterstützung bei hartnäckigen Verbindungsabbrüchen

Du hast akute Verbindungsabbrüche, und Netzwerk- und Applikations-Team schieben sich gegenseitig die Verantwortung zu? Genau das ist mein Schwerpunkt: Forensik statt Fingerpointing. Mit gezielten Mitschnitten zeige ich, wo die Ursache liegt – nachvollziehbar für Netzwerk, Applikation und IT-Leitung.

Vereinbare ein kostenloses Erstgespräch – wir schauen gemeinsam, ob und wie eine Paketanalyse dein Problem lösen kann.

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

Was sind TCP Retransmissions und warum sind sie ein Problem?

TCP Retransmissions entstehen, wenn gesendete Segmente nicht rechtzeitig bestätigt werden – etwa weil sie verloren gingen oder die Bestätigung zu spät kam. Einzelne Retransmissions sind normal. Gehäufte Retransmissions deuten jedoch auf Paketverluste, Überlast oder instabile Verbindungen hin 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?

Am zuverlässigsten mit Captures auf beiden Seiten. Werden Pakete gesendet, kommen aber nicht an, liegt das Problem im Netz. Kommen sie an, aber der Empfänger antwortet verzögert, meldet ein Zero Window oder schließt die Verbindung selbst, liegt die Ursache beim Endgerät oder in der Anwendung. Zusätzlich helfen der RTT-Graph und die Frage, wer den Reset sendet – der Endpunkt selbst oder ein Gerät dazwischen, erkennbar am abweichenden TTL-Wert.

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, beendet meist die Anwendung die Session per Timeout. Die Ursache liegt beim Empfänger – Server oder Client – und nicht im Netz selbst.

Ist jedes RST-Paket ein Fehler?

Nein. Viele Anwendungen beenden Verbindungen regulär per Reset, und ein RST als Antwort auf ein SYN bedeutet meist nur, dass auf dem Port kein Dienst lauscht oder eine Firewall die Verbindung aktiv ablehnt. Verdächtig wird ein RST, wenn er mitten in einer aktiven Übertragung auftritt, mit den gemeldeten Abbruchzeiten zusammenfällt oder einen abweichenden TTL-Wert hat und damit von einem Gerät im Pfad stammt.

Welche typischen Ursachen führen zu Verbindungsabbrüchen in Unternehmensnetzen?

Die häufigsten Ursachen sind überlastete WAN-Leitungen, Idle-Timeouts von Firewalls, MTU-Probleme (PMTUD-Blackholes), überlastete Server oder Clients und Duplex-Mismatches. Seltener, aber heimtückisch: defekte Hardware wie sterbende Netzwerkkarten oder SFP-Module mit sporadischen 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 sichere Trennung von Netz- und Applikationsproblem oder sporadische Abbrüche über mehrere Capture-Punkte – braucht es Erfahrung mit TCP-Interna. Wer regelmäßig mit Verbindungsabbrüchen zu tun hat, sollte in Paketanalyse-Kompetenz investieren oder sich für hartnäckige Fälle Unterstützung holen.