In your IT career have you ever Googled an issue or symptom only to find out you are the only person ever to see that issue? Not a good feeling, is it? Do you know what is the polar opposite of that feeling? Try Googling for slow CIFS/SMB performance over VPN. I’ll wait.
No shortage of results there, huh? SMB performance over VPN is an issue we see periodically at our clients. Typically, the client profile is that they have multiple sites with site-to-site VPNs and a centralized file server. Another scenario may be remote workers who connect using VPNs to access file servers.
The issue reported is usually something along the lines of this:
- Internet connections are stable and have decent speed.
- Other file transfers like FTP are fine.
- File transfers using Windows file shares (i.e., SMB (or CIFS) is painfully slow.
Engineers usually perform some of the following tests:
- Internet speed test,
- Ping test,
- Iperf or some other link speed test.
Engineers also usually gravitate to the VPN endpoints themselves. The requests usually come worded as being an issue with the firewall. If you did Google for slow SMB over VPN, you’d see that nearly every network product is reported in association with that issue: Cisco, Fortinet, Juniper, SonicWall, they’re all there. The open source players don’t get off any easier. You’ll find references to Pfsense, IPCop and so on as well.
Here are some things you can try to correct this issue, or at least make it less painful:
- Reduce the MTU size on the VPN endpoints. A lot of devices default to 1500. You can try setting this to 1400 or 1350.
- Adjust the TCP Maximum Segment Size to something around 1400 has been reported to work.
- Get away from the network devices and in to Windows itself, Microsoft has a KB specifically for tuning SMB.
- Change the VPN protocol that is in use. I have seen some instances where SSL yielded better results than IPsec and vice versa.
- Check the resource utilization on the network devices involved. Routers and firewalls are computers too, albeit very specialized computers. If resources become overtaxed, this will cause problems. Some manufacturers, like Fortinet, build code into the OS that throttles services when resource utilization is at higher levels.
- Rule out any other network conditions that are causing packet loss, congestion or latency. (We have a very good comprehensive document about all the places latency occurs with your environment.)
These are all very good suggestions, but they are hit or miss on whether or not they actually work. There’s a reason for this: SMB sucks on high latency connections! In 2009, Microsoft published a paper about planning for bandwidth requirements. Part of the paper compared SMB performance with and without latency. Below is the results of crawling and enumerating a file share over a 10 Mbps connection with 100 ms of latency:
Microsoft has tried to address these issues with newer versions and updates to the SMB protocol. But at its core, SMB is limited by being a block-based protocol. FTP and others will stream the data. SMB is built to constantly chat back and forth with the file server. Here is a nice (but old) blog from Microsoft that lays out some of these issues.
Rather than re-invent the wheel, Microsoft has come up with other solutions to work around the limitations of SMB with tools like OneDrive and features like Branch Cache to help out if your desire is to get shared data to your users quickly and efficiently.