SMB-Session-Probleme: Symptome aus Packet Captures lesen

SMB-Session-Probleme gehören zu den häufigsten und zugleich missverständlichsten Störungsbildern in Enterprise-Netzen: Dateiübertragungen hängen, Netzlaufwerke trennen sich, Nutzer sehen „Zugriff verweigert“, „Der Netzwerkpfad wurde nicht gefunden“, Office-Dateien lassen sich nicht speichern oder ein Backup-Job läuft plötzlich in Timeouts. Viele Teams diagnostizieren solche Incidents zunächst auf „Netzwerk“ oder „Storage“, dabei liefert ein sauberer Packet Capture (PCAP) meist in wenigen Minuten die entscheidenden Hinweise: Scheitert der TCP-Transport (Retransmissions, MTU, Reset)? Bricht die SMB-Session (Session Setup, Tree Connect) weg? Oder ist es ein Authentisierungs- und Identity-Thema (Kerberos/NTLM, SPNEGO, Signing/Encryption)? Wer Symptome im Mitschnitt sicher lesen kann, spart Eskalationsschleifen und reduziert die MTTR spürbar. Dieser Artikel zeigt praxisnah, welche SMB- und TCP-Signale in Packet Captures typisch sind, wie Sie sie richtig einordnen und wie Sie aus Sequenzen von Paketen eine belastbare Hypothese ableiten – ohne Rätselraten und ohne vorschnell Layer-3 oder „den Server“ zu beschuldigen.

SMB im Überblick: Was Sie im PCAP überhaupt sehen (und was nicht)

SMB läuft in modernen Umgebungen typischerweise als SMB 2/3 über TCP-Port 445. Im PCAP sehen Sie daher fast immer zwei Schichten gleichzeitig: den TCP-Transport und darüber SMB-Requests/Responses. Ob Sie die SMB-Kommandos in Klartext erkennen, hängt von der Konfiguration ab: SMB Encryption verschlüsselt die Nutzdaten (und Teile der Metadaten), sodass Sie zwar weiterhin TCP-Muster (Retransmits, Window, RTT) sehen, aber weniger SMB-Details interpretieren können. SMB Signing hingegen signiert, verschlüsselt aber nicht zwingend.

• Transport sichtbar: Handshake, Retransmissions, RTO, Window, Zero Window, Resets, FIN, RTT-Schätzung.
• SMB sichtbar: Negotiate, Session Setup, Tree Connect, Create/Open, Read/Write, Close, Echo, Error Codes – sofern nicht verschlüsselt.
• Identität indirekt sichtbar: Kerberos/NTLM über SPNEGO im Session Setup (teilweise), außerdem DNS/LDAP-Korrelationen, wenn diese im gleichen Capture liegen.

Capture-Qualität: Ohne saubere Grundlage wird jede Interpretation riskant

Bevor Sie in Details gehen, prüfen Sie, ob der Capture überhaupt aussagekräftig ist. Die häufigsten Fehler sind einseitige Captures (nur Client oder nur Server), falsche Interface-Position (z. B. hinter NAT ohne Zuordnung) oder zu kurze Zeitfenster, in denen der Abbruch nicht enthalten ist.

• Beidseitig ist besser: Ideal ist ein Capture am Client und am Server oder an einem zentralen TAP/SPAN nahe am Servernetz.
• Zeitsynchronisation: Stimmt die Uhrzeit? Bei verteilten Captures müssen Sie Zeitdrift berücksichtigen.
• Filter sinnvoll setzen: Für SMB häufig „tcp.port == 445“ plus Client-/Server-IP; ergänzend DNS (53), Kerberos (88), LDAP (389/636) je nach Verdacht.
• Verschlüsselung erkennen: Wenn SMB Encryption aktiv ist, verlagert sich die Diagnose stärker auf TCP- und Timing-Indikatoren.

SMB-Session-Lebenszyklus: Die entscheidenden Stationen im Mitschnitt

Viele SMB-Session-Probleme lassen sich einem Schritt im Protokollablauf zuordnen. Das hilft, Symptome zielgerichtet zu interpretieren.

• TCP 3-Wege-Handshake: SYN → SYN/ACK → ACK. Scheitert das, ist es kein „SMB-Thema“, sondern Transport/Policy.
• SMB Negotiate: Client und Server handeln SMB-Version, Dialect, Capabilities aus.
• Session Setup: Authentisierung (Kerberos/NTLM via SPNEGO), Aufbau des Security-Kontexts.
• Tree Connect: Verbindung zum Share (z. B. \servershare), Berechtigungen und Share-Kontext.
• Create/Open: Datei/Verzeichnis öffnen, Oplocks/Leases, Attribute.
• Read/Write: Datenübertragung, ggf. Large MTU, Credits, Pipelining.
• Close/Logoff: Sauberes Ende oder Abbruch durch Reset/Timeout.

Erste Diagnosefrage: Ist es TCP oder SMB?

Die schnellste und wichtigste Weiche: Liegt das Problem im Transport oder im SMB-Protokoll? Viele „SMB-Fehler“ sind eigentlich TCP-Fehlerbilder, die SMB nur als Anwendung „oben drauf“ erlebt.

• TCP-Indikatoren: Retransmissions, Duplicate ACKs, Out-of-Order, Zero Window, Reset (RST), wiederholte SYNs.
• SMB-Indikatoren: SMB Status Codes, Session Setup Failures, Tree Connect Denied, Credit Stalls, SMB2 CANCEL.

TCP-Symptome im PCAP, die SMB-Sessions typischerweise „zerlegen“

Retransmissions und Duplicate ACKs: Der Klassiker bei „Hängern“

Wenn Sie im PCAP viele TCP Retransmissions und Duplicate ACKs sehen, ist das ein starker Hinweis auf Paketverlust oder starke Reordering-Effekte. Für SMB äußert sich das oft als „Explorer friert ein“ oder Copy-Dialog bleibt stehen, bevor ein Timeout kommt.

• Worauf achten: Sequenznummern, die erneut gesendet werden; ACKs, die wiederholt dieselbe nächste erwartete Sequenz bestätigen.
• Interpretation: Verlust kann im Underlay, auf einem WAN-Link, durch Congestion Drops oder durch fehlerhafte NIC/Offloads entstehen.
• Nächster Schritt: Korrelation mit Interface-Countern (CRC, drops), WAN-QoS, Congestion, Pfadwechseln.

RTO und exponentielles Backoff: Wenn SMB „Zeit verliert“

TCP wartet bei Verlust nicht beliebig, sondern arbeitet mit Retransmission Timeouts (RTO). Im PCAP sehen Sie dann wachsende Abstände zwischen Retransmits. Das ist operativ wichtig, weil Nutzer „lange“ Hänger erleben, obwohl der eigentliche Auslöser ein kurzer Loss war.

Zero Window und Window Full: Wenn der Empfänger bremst

Ein häufiges Missverständnis: Nicht jeder „Slow Copy“ ist Netzwerk. Wenn der Empfänger (Client oder Server) mit Zero Window signalisiert, dass sein Receive Buffer voll ist, bremst TCP bewusst. Bei SMB kann das auftreten, wenn der Server unter I/O-Last steht, AV-Scanning blockiert oder ein Storage-Backend saturiert.

• Zero Window: Empfänger kann aktuell keine weiteren Bytes annehmen.
• Window Update: Sobald wieder Platz da ist, erhöht er das Fenster.
• Interpretation: Oft Server-/Storage-Last oder Host-Stack-Engpass, nicht zwingend WAN.

TCP RST: Harte Abbrüche sauber deuten

Ein RST ist ein „harter“ Abbruch einer TCP-Verbindung. Entscheidend ist, wer das RST sendet und in welchem Kontext es passiert.

• RST vom Server: Prozess abgestürzt, Firewall/IPS blockt, Port-Schutzmechanismus, Ressourcenlimit, Anwendung schließt hart.
• RST vom Client: Client bricht ab (User Aktion), Timeout in App, Antivirus/EDR, lokaler Stack.
• RST von Middlebox: Manche Firewalls senden RST aktiv bei Policy-Blocks oder Session-Expiry.

Im PCAP ist die Richtung das wichtigste Indiz. Wenn Sie zusätzlich kurz vorher SMB Errors sehen, ist die Ursache oft oberhalb von TCP. Wenn das RST „aus dem Nichts“ kommt, ist eine Policy- oder Device-Interaktion wahrscheinlicher.

SMB-spezifische Symptome: Was Ihnen Status Codes und Sequenzen verraten

Session Setup scheitert: Authentisierung, Zeit, Policy

Wenn der TCP-Handshake stabil ist, aber der SMB-Dialog früh scheitert, schauen Sie auf SMB2 SESSION_SETUP und die Status Codes. Typische Muster:

• STATUS_LOGON_FAILURE: Falsche Credentials, gesperrtes Konto, Auth-Flow bricht.
• STATUS_ACCESS_DENIED: Policy/Berechtigungen, Signing/Encryption Requirements, Gerät nicht autorisiert.
• STATUS_MORE_PROCESSING_REQUIRED: Normal im Kerberos/NTLM-Handshake (mehrstufig), wird erst kritisch, wenn es in Schleifen endet.

In Captures mit Kerberos/NTLM sehen Sie häufig SPNEGO-Token im Session Setup. Wenn die Session Setup Sequenz in einer Endlosschleife endet oder verzögert wird, ist ein Blick auf zeitgleiche DNS/Kerberos/LDAP-Calls hilfreich.

Tree Connect scheitert: Share- oder Pfadbezogene Probleme

Der Schritt TREE_CONNECT entscheidet, ob der Zugriff auf \servershare gelingt. Häufige Ursachen sind falsch gesetzte Share-Permissions, DFS/Namespace-Probleme oder Namensauflösung auf einen falschen Zielserver.

• STATUS_BAD_NETWORK_NAME: Share existiert nicht oder verweist falsch (DFS/Namespace).
• STATUS_ACCESS_DENIED: Share-/NTFS-Berechtigungen, Conditional Access, Sicherheitsrichtlinien.

Create/Open Probleme: Locks, Leases und Oplocks als Fehlerquelle

Viele „SMB hängt“ Fälle entstehen nicht beim Kopieren selbst, sondern beim Öffnen von Dateien. In Captures sehen Sie dann, dass CREATE-Requests (Open) lange auf Responses warten oder mit Lock-bezogenen Errors antworten. Oplocks/Leases können in Cluster-/Failover-Szenarien oder bei instabilen Clients zu trügerischen Symptomen führen.

• Symptom: Datei lässt sich nicht öffnen, „wird von einem anderen Prozess verwendet“.
• PCAP-Hinweis: Wiederholte Opens, Delays vor Create Response, evtl. SMB2 BREAK-Lease/Oplock Nachrichten.
• Interpretation: Anwendung hält Locks, AV-Filtertreiber, Failover im Backend, File Server Cluster Events.

Read/Write-Stalls: Credits, Pipelining und „Large MTU“

SMB 2/3 arbeitet mit einem Credit-System, um die Anzahl paralleler Requests zu steuern. Wenn Credits knapp werden, kann der Client weniger pipelinen, was wie „Netzwerk langsam“ wirkt. Im PCAP zeigt sich das als reduzierter Request-Durchsatz trotz stabiler RTT.

• Hinweise: Weniger parallele READ/WRITE Requests, längere Lücken zwischen Requests, trotz fehlender Retransmits.
• Interpretation: Serverlimit, CPU/I/O, SMB-Konfiguration, SMB Direct/RDMA-Interaktionen (falls genutzt).
• Abgrenzung: Wenn TCP sauber ist (kaum Retransmits), liegt die Bremse oft in Host/SMB, nicht im Underlay.

„SMB ist verschlüsselt“: Wie Sie trotzdem Symptome lesen

Mit SMB Encryption verlieren Sie Detailblick auf SMB-Kommandos. Trotzdem bleibt der PCAP wertvoll, weil Session-Probleme fast immer Timing- und Transport-Signaturen haben.

• Handshake-Phase: Auch bei Verschlüsselung sehen Sie Negotiate/Setup-Metadaten teilweise und den Zeitpunkt, wann die Datenphase startet.
• TCP-Metriken: Retransmissions, RST/FIN, Window, RTT, Out-of-Order bleiben sichtbar.
• Periodizität: Wiederkehrende Disconnects (alle X Minuten) deuten eher auf Policy/Timeouts als auf „SMB selbst“.

Praktische Leseregeln: Vom Muster zur Hypothese

Damit Sie aus einem Capture nicht nur „viel Verkehr“ sehen, sondern schnell zu einer operativen Hypothese kommen, helfen feste Leseregeln.

• Regel 1: Wenn der TCP-Handshake mehrfach wiederholt wird (SYN-Retries), ist der Fehler vor SMB (Routing/Firewall/Serverlisten).
• Regel 2: Wenn Handshake ok ist, aber frühe SMB-Kommandos mit Errors antworten, ist es meist Auth/Permission/Policy.
• Regel 3: Wenn es erst bei großen Transfers „kippt“ und Retransmits steigen, denken Sie zuerst an Loss/MTU/Congestion.
• Regel 4: Wenn Zero Window dominiert, prüfen Sie Host- und Storage-Performance, nicht nur das Netz.
• Regel 5: Ein RST braucht Kontext: Richtung, Zeitpunkt, vorherige Errors – erst dann interpretieren.

MTU/MSS bei SMB: Warum große Dateien häufiger scheitern

SMB-Transfers sind ein guter „Stresstest“ für Pfade, weil sie viele Datenpakete erzeugen und damit MTU-/Fragmentierungsprobleme sichtbar machen. Wenn PMTUD nicht funktioniert (z. B. ICMP gefiltert), sehen Sie oft Retransmits und Stalls bei bestimmten Segmentgrößen. Ein klassischer Indikator ist: kleine Datei funktioniert, große Datei hängt.

• Hinweis im PCAP: Retransmissions beginnen ab einem bestimmten Zeitpunkt, oft begleitet von Fragmentierungs-/Blackhole-Verhalten.
• Operative Maßnahmen: MSS-Clamping an VPN/WAN-Edges prüfen, ICMP für PMTUD erlauben, Tunnel-Overhead berücksichtigen.

Retransmission-Rate grob quantifizieren (MathML)

Für ein Ticket oder eine RCA ist es hilfreich, eine einfache Kennzahl zu nennen. Eine grobe Retransmission-Rate lässt sich als Verhältnis ausdrücken:

$\mathrm{Rate}=\frac{N}{R}=\frac{\mathrm{Pakete\_retransmitted}}{\mathrm{Pakete\_total}}$

Auch wenn das je nach Tool unterschiedlich gezählt wird: Sobald diese Rate im SMB-Datenfluss deutlich steigt und zeitlich mit Hängern korreliert, ist das ein starker Hinweis auf Transportprobleme (Loss/Congestion/MTU) statt reine Applikationslogik.

Typische Incident-Szenarien und die passenden PCAP-Signaturen

• „Netzlaufwerk trennt sich regelmäßig“: häufig RST/FIN nach Idle, Keepalive/Timeout-Policy, ggf. NAT/Firewall Session Expiry.
• „Kopieren startet schnell und wird dann extrem langsam“: oft Window/Buffering (Zero Window), Server-/Storage-Engpass oder Congestion mit Retransmits.
• „Nur VPN-Nutzer betroffen“: MTU/MSS/Fragmentierung über Tunnel, NAT-T, Paketverlust auf Underlay.
• „Nur manche Benutzer“: Auth- und Gruppenmitgliedschaft (Access Denied), DFS-Referrals, unterschiedliche Pfade (Standorte).
• „Fehler nach Change“: Policy/ACL/Inspection, SMB Signing/Encryption Requirements, Firewall-Application-Control.

Was Sie für eine saubere Eskalation dokumentieren sollten

Ein gutes Ticket verhindert Ping-Pong zwischen Netzwerk-, Windows- und Storage-Teams. Aus dem PCAP lassen sich wenige, aber sehr belastbare Fakten ableiten.

• 5-Tuple: Quell-/Ziel-IP, TCP/445, Zeitraum, betroffene Clients.
• Transportbelege: Retransmits ja/nein, Zero Window ja/nein, RST/FIN Richtung und Zeitpunkt.
• SMB-Phase: Scheitert es bei Session Setup, Tree Connect, Create/Open oder erst bei Read/Write?
• Status Codes: Konkrete SMB/NTSTATUS-Fehler (falls sichtbar) statt „SMB kaputt“.
• Korrelation: Gleichzeitige DNS/Kerberos/LDAP-Auffälligkeiten (wenn im Capture enthalten).

Outbound-Links für weiterführende, belastbare Referenzen

• Microsoft: Troubleshooting SMB für praxisnahe Hinweise zu SMB-Fehlerbildern und Diagnosepfaden.
• Microsoft: SMB-Übersicht für Versionen, Features (Signing/Encryption) und Architekturgrundlagen.
• Microsoft: SMB Security (Signing & Encryption) für Auswirkungen von Sicherheitsoptionen auf Troubleshooting und Sichtbarkeit im PCAP.
• RFC 793 (TCP) als Transportreferenz, um Retransmissions, Windowing und Reset-Verhalten korrekt zu interpretieren.
• Wireshark User’s Guide für Filter-, Analyse- und Expert-Infos, die bei SMB/TCP-Auswertungen besonders hilfreich sind.

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.