Transmission at reduced speed through SMB protocol on a VPN connection
Transmission at reduced speed through SMB protocol on a VPN connection
Hey everyone, this situation has left our network tools puzzled—our ISP, network installer, and hardware supplier aren’t able to solve it. If you have a clue, we really appreciate it. At the office we use a 12-bay Synology NAS connected through a gigabit Ethernet LAN. We also have a Draytek 3910 firewall managing our VPN and a high-speed fiber connection offering 900 Mbps down and 500 Mbps up. My NAS holds a large file (over 20GB) that moves quickly over the LAN at about 112MB/s. I moved it to my home PC workstation via the LAN, which is connected to the office through VPN. My home internet is 420/50 Mbps, same as the office provider. When accessing the NAS web interface from our public IP, the download speed is around 50MB/s. Through VPN, it’s about 42.6MB/s. Using the local VPN IP, it still pulls at roughly 25MB/s. Switching to L2PT protocol reduces the speed even more to around 10MB/s. But when transferring through the web UI from the same local IP, speeds stay above 40MB/s. It’s strange—there seems to be a big difference depending on the connection method and protocol. Any insights would be super helpful. Thanks in advance for your help!
Hi, your question is clear. Is this a typical problem? I’d like some guidance on how to fix it. Our Draytek Vigor 3910 firewall router manages the VPN and DHCP services. Draytek says there shouldn’t be any issues, but switching VPN protocols seems to affect our speeds noticeably. They didn’t mention SMB packets either. Could you suggest a solution or a workaround?
After additional testing, I found these details: All transfers remain linked through our VPN using SSL. Downloading via web GUI from public IP (VPN bypassed) reached 50MB/s; from local IP it was 41MB/s. Downloading through File Explorer on Windows 10 with local IP came to 25MB/s. I understand there will be some extra load with the VPN, which explains the drop from 50 to 41. However, the significant difference when using File Explorer is surprising—could be related to packet type or something else? Thanks for your help in advance.
The challenge lies in SMB being a block-oriented protocol while HTTP operates as a continuous stream. SMB 1.0 struggled significantly with this, limiting it to 64k at once and requiring repeated requests for more data, which adds considerable overhead. Each packet had to be encrypted and decrypted, making the process slow. SMB 2.0 improved somewhat but remains far from the efficiency of streaming protocols like HTTP or FTP/SFTP. You might want to check if your transfer is using SMB 1.0 or 2.0, as it could be reverting to the older version. Regardless, it will never match the performance of a streaming solution. Refer to Microsoft’s blog for details on SMB 1.0 issues (from 2004): https://docs.microsoft.com/en-us/archive...-wan-links
NAS A (SMB2): Download via SSL VPN with File Explorer: 25MB/s NAS B (SMB1): Same method: 29MB/s It seems the 25-29MB/s range splits between the two when we download from both at once. If I pull from one NAS over the VPN and also fetch another file from it through the public IP, the full bandwidth gets shared. I’ve attached some examples to help illustrate. Thanks again!
It's noteworthy that several elements play a role here, with the protocol version being just one factor. You might improve performance by expanding the TCP window size. In short, the TCP window represents the data sent prior to receiver acknowledgment. Once it reaches its limit, the sender halts and waits for an ACK or retransmits. This approach is common in Long Fat Networks (LFN) where bandwidth is abundant but latency remains high—such as with satellite connections. Because of the delay, fewer ACKs are needed, allowing more data to be sent before waiting. Be mindful though; not all firewalls support large windows, and this isn't a universal fix. Most systems auto-tune TCP windows, so manual settings aren’t required. I’m also unsure it would fully resolve the issue, as SMB is inherently inefficient for high-latency links. It’s worth testing, but further analysis is needed before committing.
Hi Guys, Another update, just to confuse things EVEN FURTHER... I have just discovered that if I connect to our VPN via IKE v2 in OSX then there is absolutely no issue at all, my download hit almost 50MB/s immediately! Great! The only problem is.. I simply cannot connect this way in Win 10. I've tried via both the Windows VPN setup and also the Draytek Smart VPN Client, both methods appear to reach the server and ask for username/password, but as soon as I enter them they both produce these errors: IKE authentication credentials are unacceptable I'm using the exact same login details as I used in OSX, and that connects instantly! Any ideas? Thanks