When combining Samba (SMB/CIFS) with OpenVPN, we often encounter performance that's orders of magnitude slower than expected network capabilities. Let's examine a real-world scenario where a quad-core Xeon server with CentOS 5.6 and Windows 7 x64 client achieves only 60KB/s transfer rates despite having 50Mbps/4Mbps bandwidth available.

The encryption layer (AES-128-CBC with SHA1 HMAC) isn't the culprit here - CPU utilization remains low during transfers. The real issues stem from protocol interaction:

# Typical problematic OpenVPN config snippet:
cipher AES-128-CBC
auth SHA1
comp-lzo
tun-mtu 1500
fragment 1300
mssfix 1300

Samba's chatty protocol suffers dramatically from packet fragmentation. Try these adjustments:

# Optimized OpenVPN server.conf additions:
tun-mtu 1400
mssfix 1360
fragment 0
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

Add these to your smb.conf under the [global] section:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
min receivefile size = 16384
use sendfile = true
strict locking = no
oplocks = no
level2 oplocks = no

For cases where tuning doesn't yield sufficient improvements:

• Consider NFSv4 over VPN instead of SMB for Linux clients
• Try WebDAV with SSL as an alternative file sharing protocol
• Implement rsync for large file transfers with delta updates

Test your improvements with these commands:

# Network baseline testing:
iperf -c your.vpn.server.ip -t 20

# Samba-specific testing:
smbclient -U user //server/share -c "get largefile.bin" -m SMB3

For Linux servers, consider these sysctl adjustments:

# Add to /etc/sysctl.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0

When configuring Samba shares to be accessed through OpenVPN tunnels, many administrators encounter unexpectedly slow transfer speeds - often in the range of 50-100KB/s despite having high-bandwidth connections. The original poster's setup with CentOS 5.6 server and Windows 7 client demonstrates a classic case where hardware capabilities far exceed the actual performance.

The primary issues causing slow Samba-over-OpenVPN performance typically stem from:

• TCP-over-TCP tunneling inefficiencies
• Encryption overhead compounding
• MTU and packet fragmentation problems
• Samba protocol chatter amplification

Here are the most effective tuning parameters for both OpenVPN and Samba configurations:

OpenVPN Server Config (server.conf)

tun-mtu 1400
mssfix 1360
fragment 1300
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
comp-lzo no  # Disable compression for modern networks

Samba Performance Tweaks (smb.conf)

[global]
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
min receivefile size = 16384
getwd cache = yes
write cache size = 262144
strict locking = no

For particularly problematic cases, consider these alternatives:

1. SSHFS: Often performs better than Samba in VPN scenarios
2. NFS over VPN: Less chatty protocol than SMB
3. WebDAV: HTTP-based protocol that tunnels efficiently

After applying these optimizations to a similar setup (CentOS 7 server, Windows 10 client):

Use these commands to identify specific bottlenecks:

# Check actual MTU in VPN tunnel:
ping -M do -s 1472 -c 1 vpn_server_ip

# Monitor OpenVPN performance:
sudo watch -n 1 "cat /proc/net/dev | grep tun"

# Samba client statistics:
smbstatus -S