Your cart is currently empty!
Remote workers often rely on Cisco Secure Client (formerly AnyConnect) or Cisco Secure Cloud VPN services to access on‑premises file servers. While these solutions provide strong encryption and simple connectivity, users sometimes experience painfully slow performance when accessing SMB/CIFS file shares over VPN. Opening documents, browsing directories or copying files can take minutes instead of seconds. This article explains why SMB traffic can be sluggish over VPN, explores specific factors that affect performance on Cisco‑based solutions, and outlines steps you can take to improve speeds.
What Are Cisco Secure Cloud VPN and SMB?
Cisco Secure Client / Secure Cloud VPN is a remote access platform that creates an encrypted tunnel between a user’s device and corporate resources. It secures traffic using IPsec or SSL/TLS and supports split tunneling, posture checks and advanced threat detection. The VPN runs on firewalls such as Cisco ASA/Firepower or Cisco Secure Firewall, and it can be delivered as a cloud‑hosted service.
SMB (Server Message Block) is the protocol behind Windows file sharing. SMB is designed for low‑latency local networks and is chatty: the client and server exchange numerous small packets to enumerate directories, negotiate file access and acknowledge data. It performs well on local LANs but struggles across high‑latency connections like the public internet. When SMB traffic travels through a VPN, the combination of latency, encryption overhead and protocol behavior can dramatically reduce throughput.
Why Does SMB Perform Poorly Over VPN?

1. SMB Is Sensitive to Latency
SMB was built for LAN conditions. Its throughput is constrained by round‑trip time: each request waits for an acknowledgement before continuing. On a LAN with <10 ms latency, a single TCP flow can achieve >200 Mbps; on a link with 30 ms latency, that drops to ~70 Mbps for a single flow. When a VPN adds 20–30 ms of extra latency, directory listings and small file operations become noticeably slower. The problem is worse when copying many small files because each file triggers multiple SMB commands and acknowledgements
2. Encryption and Encapsulation Overhead
VPN tunnelling encapsulates packets, adding headers and encryption metadata. IPsec and SSL/TLS consume around 20 % of the available bandwidth and the encryption process introduces additional processing delay on the client and firewall. If the firewall is under heavy load or the VPN uses software encryption, throughput can drop further. Cisco head‑end devices might throttle services when CPU resources are taxed.
3. MTU and MSS Mismatch
Encapsulation reduces the effective Maximum Transmission Unit (MTU) and forces packet fragmentation if not adjusted. Fragmentation adds processing overhead and can cause retransmissions. Reducing the MTU on VPN endpoints to 1400 or 1350 bytes and adjusting the TCP Maximum Segment Size (MSS) to a similar value can prevent fragmentation.
4. TCP Tuning and Window Scaling
SMB uses TCP, so parameters like window scaling, timestamps and congestion control influence performance. Asymmetric links—where one direction has higher latency—can cause repeated TCP acknowledgements and stalled transfers. Enabling timestamps on Windows clients and servers (netsh int tcp set global timestamps=enabled) helps handle asymmetric timing.
5. SMB Version and Client/Server Settings
Older SMB versions (v1/v2) lack optimizations present in SMBv3+, such as SMB Multichannel (multiple TCP flows) and Receive Side Scaling (RSS). Without multichannel, a single TCP stream limits throughput; with it, two or more streams can double or quadruple performance. Additionally, default Windows settings may throttle bandwidth or have small cache sizes. Tweaking parameters like MaxCmds, FileInfoCacheEntriesMax and DirectoryCacheEntriesMax improves remote enumeration.
6. Network Path and Device Constraints
Sometimes the issue is not the VPN appliance or protocol but the network path. Asymmetric routing, congested circuits or poor last‑mile ISP performance can introduce jitter and packet loss. Slow SMB downloads from hub to spoke networks may point to high latency in one direction. Resource constraints on firewalls (CPU/memory) or misconfigured QoS policies can also degrade performance.
7. Cisco‑Specific Factors
Cisco Secure Client can operate using either TLS or DTLS tunnels. DTLS uses UDP rather than TCP to transport the encrypted payload and is generally more efficient for real‑time or latency‑sensitive traffic. If SMB traffic is traversing a TLS tunnel, switching to DTLS (enabled by default on modern head‑ends) may help. Additionally, ensure that the firewall software is up to date; some versions include fixes for SMB performance bugs. Cisco head‑ends should support hardware encryption and have sufficient throughput to avoid bottlenecks.
Diagnosing the Problem
To pinpoint why SMB is slow over your Cisco VPN:
- Test latency and bandwidth – Use
pingand tools likeiperfto measure round‑trip time and compare raw throughput over the VPN versus direct internet. High latency (>20–30 ms) will limit SMB throughput dramatically. - Compare protocols – Transfer large files over FTP/SFTP or RDP. If those perform well but SMB is slow, the issue lies with the protocol.
- Check MTU/MSS – Run a path MTU discovery test or use
ping -f -l <packetSize>to find the maximum unfragmented size. Adjust the VPN appliance or client accordingly. - Monitor firewall resources – On Cisco ASA/Firepower/FTD, monitor CPU and memory usage. High utilization during file transfers indicates encryption overhead or resource exhaustion.
- Review logs – Look for TCP retransmissions, duplicate ACKs or drops. Tools like Wireshark or Cisco SecureX can help analyse flows.
How to Improve SMB Performance Over Cisco Secure Cloud VPN
Reduce MTU and Adjust TCP MSS
Lowering the MTU on the VPN interface to 1400 bytes and matching the MSS reduces fragmentation. On Cisco devices you can set crypto ipsec df‑bit clear and sysopt connection tcpmss 1350, or configure the Secure Client profile to adjust MSS.
Enable DTLS and Optimise VPN Protocols
Cisco Secure Client supports both TLS (TCP) and DTLS (UDP) tunnels. In the VPN profile or on the head‑end, enable DTLS and ensure UDP ports are allowed through firewalls. Users often report better file transfer speeds when DTLS is active because it reduces retransmission overhead.
Upgrade SMB and Use Multichannel
Ensure both server and client run SMB v3 or later and enable SMB Multichannel, which uses multiple TCP flows to improve throughput. Verify that network adapters support Receive Side Scaling (RSS); many laptops’ NICs do not. On Windows, you can check with Get-NetAdapterRSS and enable multichannel using Set-SmbServerConfiguration -EnableMultichannel $true and Set-SmbClientConfiguration -EnableMultichannel $true.
Tune Windows Client and Server Settings
Use PowerShell to modify SMB parameters:
- Increase command and cache limits:
Set-SmbClientConfiguration -MaxCmds 1024
Set-SmbClientConfiguration -FileInfoCacheEntriesMax 8192
Set-SmbClientConfiguration -DirectoryCacheEntriesMax 4096
- These settings increase the number of outstanding SMB commands and enlarge directory and file caches, reducing the number of round‑trips required.
- Disable bandwidth throttling –
Set-SmbClientConfiguration -EnableBandwidthThrottling 0prevents Windows from limiting throughput across high‑latency links. - Lower the window size threshold –
Set-SmbClientConfiguration -WindowSizeThreshold 1ensures multichannel engages on slower links.
Optimise Network Path
- Use quality circuits – Choose ISPs with low latency and symmetrical bandwidth. For site‑to‑site networks, avoid asymmetric routes and ensure adequate speed at both sites.
- Add local file services – Place a file server closer to remote workers or replicate files to the cloud. Hosting file shares in Azure/AWS and connecting via ExpressRoute or AWS Direct Connect can reduce latency.
- Leverage caching – Technologies like BranchCache or third‑party WAN accelerators cache frequently accessed files closer to users. Microsoft recommends using OneDrive or BranchCache to work around SMB limitations.
Consider Alternative File‑Transfer Methods
For large transfers, SCP, SFTP, Rsync or cloud‑based services often outperform SMB. If your workflow allows, replicate data to a cloud storage solution (e.g., SharePoint, OneDrive, Google Drive) and use those platforms for remote access rather than direct SMB shares.
Conclusion
Slow SMB performance over Cisco Secure Cloud VPN is primarily caused by the chatty, latency‑sensitive nature of the SMB protocol, compounded by VPN encryption overhead, MTU issues and sub‑optimal client/server configurations. By reducing MTU and MSS, enabling DTLS, upgrading to SMB v3 with multichannel, tuning Windows parameters and optimising the network path, you can significantly improve file‑share performance. If the underlying latency cannot be reduced, consider alternatives like cloud file services, BranchCache or remote desktop solutions. Ultimately, understanding how SMB and VPN technologies interact will help you build a more responsive remote working environment.