0

Working remotely over VPN, when I save a large file to our file server, I am unable to browse any other file shares on the server during that time. Basically, windows explorer hangs up and is stuck, if it does respond it takes several minutes and is very slow. When the file transfer is cancelled or finishes, the folders pop right up.

To reproduce I drag and drop a file from my local (remotely connected) machine to a file share on another device on my work network. While the file is transferring, I try to browse to other folders on the remote file share. For instance, right now, I tried to browse to \\<host ip>\c$\Windows and after 10 minutes it is still trying to load the directory listing with only a couple dozen folders/files shown so far.

I've spent the last couple days working on this. This is an issue specific to connectivity over a WAN / VPN. I experience similar "slow" file browsing behavior on a different network using a different VPN technology - but there it doesn't just sit and do nothing for minutes. The delays are in seconds. I am using Cisco AnyConnect where the problem is really bad.

The problem effects several users (all that I have tested), on any internet connection, over any of our gateways, to any of our servers. However, it only effects SMB. While the file transfer is occurring, no other services are effected. Ping times stay normal, RDP sessions to the same server are responsive, etc.

I've focused on many different possibilities. I've worked with MTU settings with no changes. I see that SMB is running in a single channel mode. I've tried tweaking various SMB client / server settings. I've seen in wireshark traces that the requests aren't being sent until much later after I try to navigate in to a folder. But, there doesn't appear to be any significant lag between the requests and the responses from the server. No CPU cores/threads are maxed out on server or client. I cannot reproduce this type of behavior over a local LAN.

So, is there an explanation to this behavior? Why doesn't the client appear to send the SMB requests until after the file transfer is cancelled or only much later? Is there a queue? A buffer? Is it even possible to use SMB multi-channel over a virtual network adapter like a VPN? Would that even solve the problem? Are there commands I can run to see if the server or client is queuing something? Any other ideas as to what can be tested?

Appleoddity
  • 3,488
  • 2
  • 13
  • 33

1 Answers1

0
  • SMB is generally slow over a slow WAN link. This is a design flow in the protocol, aggravated with the fact that SMB relies heavily on broadcast name requests and other types of name resolving not available in/via WAN.
  • most of the SMB servers usually reside inside the LAN behind the NAT, where path MTU discovery isn't working at all
  • MTU itself and fragmentation/defragmentation issues are only half of the problem, and the other half is TCP MSS. TCP session cal easily be stalled when TCP aren't assembled properly - this leads to multiple retransmits and a premature session closure.

With all of that combined, this gives you a cumulative effect on speed.

P.S. and don't forget 3 locking levels, which work almost flawlessly when the RTTA is small, but ceome a real pain over WAN.

drookie
  • 8,625
  • 1
  • 19
  • 29
  • Thank you for the information. I understand what you are saying, but this doesn't really address the problem I am having. You are basically confirming what I already know. But, while I understand that "slow" access is normal, the performance I experience is completely unacceptable. It should not take 15 minutes to list a few dozen files / folders in a directory simply because I am transferring a file to the server. I don't see that necessarily on other networks and VPN solutions. I need to understand why this is happening and how to solve it, because it can be solved. – Appleoddity Mar 31 '21 at 17:58
  • Specifically I would like to understand why the SMB client is not sending the requests to the server in a timely fashion. I can see in the wireshark trace that it is waiting many seconds, with many seconds in between, before sending the individual requests, and the server responds instantly. There is some behavior in SMB that is the root of this problem, I believe, because a little lag and back and forth communication is not the issue from what I can see on the wire. – Appleoddity Mar 31 '21 at 18:14