9

I've set up a server to run OpenVPN, with the purpose of clients accessing Samba shares remotely.

The server is running CentOS 5.6, a decent quad-core Xeon CPU and plenty of RAM. The client I've tested it on is a Windows 7 x64 machine, also with quite high specs.

The result is that uploads and downloads to the client run at about 60KB/s. I understand that Samba is very inefficient in the way it makes a lot of repeat trips, but even so - the client has a bandwidth of 50Mbps downstream and 4Mbps upstream. Even if the client's upload speed was the bottleneck, it's still some 9 times slower than that.

CPU usage is negligible on the server and client during transfers, so this must rule out cipher speeds.

The appropriate OpenVPN port is open on both server and client; the OpenVPN cipher is AES-128-CBC with a 160-bit SHA1 HMAC; a TLS key is also being used, as well as comp-lzo compression.

Any idea what this could be? I know Samba is slow... but surely this can't be right!

melkamo
  • 213
  • 1
  • 2
  • 6
  • 1
    Have you tried any other type of file transfer over the VPN? Say scp'ing a file to a linux server? – EEAA Apr 30 '11 at 01:15
  • I tried FTP which was about 3 times faster - still slow though. I just tried an SCP from the server to a Linux client on the same connection as the Windows machine, with the same OpenVPN client config, and it maxed out the 50Mbps connection. – melkamo Apr 30 '11 at 02:25
  • 1
    In that case, I think you've answered your own question. Short of using some sort of WAN accelerator (expensive), you may just have to deal with the slow speeds. – EEAA Apr 30 '11 at 02:31

6 Answers6

3

Make sure that your OpenVPN tunnel is using UDP, and not TCP. Additionally, ensure that the tunnel is using compression by using the 'comp-lzo' directive in your OpenVPN config file on both ends.

Lastly, it may be worth setting the MTU and MSS clamp values for the tunnel, but this depends on the type of internet connection you're using, and if incorrectly set, would usually result in timeouts rather than slow transfers anyway.

tun-mtu 1500
mssfix 1212

The MSS clamping would also need to be set to something like 1300 one level lower than OpenVPN, for the PPP connection itself. However, as I've said, I have no clue what type of connectivity you're using - MSS clamping would only be useful on a non-Ethernet network such as ADSL, etc.

Richard Keller
  • 2,040
  • 2
  • 19
  • 31
1

In my case (OpenMediaVault NAS, debian based) I had the same issue. Also with PPTP VPN on a Synology NAS.

My solution besides MTU setting was that I had to configure the VPN server to send out DNS server address thru it's DHCP.

After this I could use my full bandwidth.

Hope this helps you and others!

FreeStyle
  • 11
  • 1
0

Do you have openvpn set to use TCP? That can cause the problem you're seeing. You should use UDP.

As ErikA said, you should do a SCP (or ftp) transfer (over the internet and over the VPN) for comparisons purposes.

Steven
  • 3,029
  • 20
  • 18
  • No, I'm using UDP, as I was aware of some Samba issues over TCP. An FTP transfer on the Windows client was still very slow, and an SCP on a Linux client was fast, both on the same connection. I'll try an FTP transfer on the Linux client to see if Windows is causing the issue. – melkamo Apr 30 '11 at 02:28
  • To make another test, you could mount a samba share on a linux machine and see if it is that slow too. – laurent May 03 '11 at 01:17
0

I already used samba on a vpn (openvpn) connection during a time and I found the unique way to work on the windows machines was to copy the files, work and place back... while the linux machines with ssh mounted drive or samba shares were working "ok" on the same vpn connection but my connection speed was 10 times less than yours.

laurent
  • 2,055
  • 16
  • 14
0

I realize this is somewhat of a late answer, but besides the obvious transport issue (UDP vs. TCP), the cipher, MSS, MTU and fragmentation method also play a role.

There is a very good article on the OpenVPN wiki on how to tease most performance out of a Gigabit network. The facts that can be found there are pretty insightful even below Gigabit speed.

Key findings

  • Blowfish cipher allows for best speed overall. Optimal MTU on a Gigabit network was 48000.
  • Even with AES-256 cipher you can tease out better speed by using MTU 24000 instead of default.
0xC0000022L
  • 1,516
  • 2
  • 22
  • 42
-3

I also had the problem > I tried to access from a Windows 7 Client to a SAMBA share over OPENVPN .. at the beginning I could access the different directories, but when I tried to open a file, it was just possible with 1kb-Textfiles, no chance with pdf or docx - then I added the mssfix parameter to the openvpn-file > also no difference .. then I tried to play around with the amount of MTU and mssfix, finally I had a MTU of 1500 and decreased mssfix to 500 and Voila > then I could open files, browse through the directories, and the SSH-Tunnel also didn't break up anymore ...