Hello wshark_de
and welcome to ask.wireshark
It looks like the connection is suffering from a significant packet loss. The reason for the loss cannot be determined in this short trace. The problem becomes clear with a quick walk through the trace file:
- The TCP connection starts with a SYN from 192.168.0.1
- Please note that the first two SYNs go unanswered, only the third one get's an answer. This in itself is unusual.
- The SYN/ACK in packet 4 arrives with 42 msec, which is within the range that you expect.
- The client completes the 3-way handshake in packet 6 with a retransmission in packet 7. Since we are looking at SMB we can assume that these frames try to establish the SMB dialect / version number to be used for this connection.
- Please note that the server repeats the SYN/ACK in frames 8 and 11. This indicates that the clients ACK from frame 5 was lost in transit, just like the first two SYNs were lost.
- The client dutifully tries to retransmit the ACK to complete the handshake in packets 9 and 12. Even the 178 byte payload from frame 6 is repeated multiple times.
- After 30 seconds the server gives up and terminates the connection with a Reset.
It should be clear, that messages from the client hardly make it to the server. Even the initial SYN requires multiple retransmissions.
Here a couple of things to check in your network:
- Is the problem only related to your Azure server? Or are other services experiencing similar problems?
- If only the Azure server is affected you might want to check the configuration, event log etc.
- If it's not just the Azure server you should check for an overloaded link, bad cables, faulty network equipment and similar issues.
- Is your firewall working ok? An exhausted NAT pool, memory problems etc. can wreak havoc on a connection.
Good luck
Eddi
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
