Site-To-Site VPN Slow (SMB, FTP)

[ED3573]

I been migrating our sites from Cisco ASA to Meraki (Main Site MX250) (Branch office MX64), I found a lot issues regarding file transfers SMB, FTP is insane, I never had these issues with our ASA even when our ISP circuits were small at that time only 5MB it was saturated at least at 3MB or now we had 15MB on all our remote sites and it doesn't' even pass from 1MB, FTP or SMB, we have 43 branch sites, all the same, we have tested this without AMP, no bandwidth throttling policy, no flow control on the servers, no SMB signing on the servers, Iperf actually use all the bandwidth on the tests, latest beta firmware (without this we had response times between 100ms to 150ms on the branch offices), after the upgrade the latency was reduced between site is 5ms to 20ms, find on the community forum other options that I have already tried netsh int tcp set global timestamps=enabled same issue.

When I call to support I don't get any answers or at least a light on this, just always the same excuse saying that this is on the ISP side, I recently called the ISP we tested the circuits and there is nothing wrong with the circuits, even the speedtest are normal.

I recently found a post from guy in spiceworks mentioning something like this.

Good idea to check your Meraki WAN config for "Do not Fragment packet" statement. Next to the MTU limit.

This will free your flow.

I had the same issue with a Site-to-Site VPN on a Sonicwall NSA 3600.

But I can't find that option to give it a try.

[PhilipDAth]

If this is a non-meraki site to site VPN - make sure you don't use DES.  It has poor performance on MX.

Next, are you using PPPoE for the tails?  If so you may need to get the MSS adjusted.  To test if this is required on a single machine try adjusting the MTU on it down to something like 1400 bytes.

https://support.zen.co.uk/kb/Knowledgebase/Changing-the-MTU-size-in-Windows-Vista-7-or-8 

If this works, then you'll need to open up a support ticket and ask them to reduce it on sites using PPPoE.

I'm a fan of enabling timestamps as it make asymetric circuits work better.  So I'd leave that on.

[ED3573]

All of our branch offices use Meraki and Comcast business for every branch, same as our main office.

[Marcusainokc]

Has anyone found any answers to this slowness issues?

[ACP]

Hello, this is an old question but I have been down extensive tests with SMB and Meraki transfers and found an interesting regedit change to do with "DirectoryCacheEntrySizeMax" which dramatically speeds up file transfer speeds from a pc. (Windows 10)

[PhilipDAth]

I found a whole page of performance tuning options:
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/ 

Another interesting-looking one is DisableBandwidthThrottling.  It says the default is that it DOES throttle bandwidth on higher latency networks by default.

And then there is this section specifically related to client tuning:
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/... 

And I see Microsoft even give examples of specific settings for accessing remote file shares:

[ACP]

Hello, one thing I couldn't find is how SMB2 actually works out if a link is low or perceived to be slow (I was thinking it uses ICMP but then it could also just look at the times on received packets), 20ms is a key value though for latency and if it perceives a slow link then it sounds like it slows itself down. The links above are the ones I found after trawling for quite some time. We are testing with users and I will report back but I have seen dramatic differences. I have previously looked at prioritising TCP 445 in the traffic shaping but that didnt seem to make much difference.

[TomStewart]

Hi,

Did you end up finding any solution to these issues? 

Just in the last month we've suddenly had a lot of complaints about SMB share performance issues, I've tried everything I can think of at this point and still no change.

Thanks