4

Our VPN users experience very slow file transfers (50MB can take 20 minutes with a 20Mbps FiOS connection on each side). If the file is transferred over HTTP or FTP, it's just as fast as you expect. I suspect this has something to do with how Windows handles file transfers, as it probably doesn't expect any latency. Is there some way to tweak this?

The VPN is SafeNet IPSec and the clients are XP.

Improve this question

4 Answers 4

Reset to default
10

This is most likely due to the SMB protocol being very "chatty", and requring many requests/acknowledgements before and during transfer. Here a couple of things that may help:

  • Adjust TCP windowing to be optimal for your network. A google search will bring up many tutorials
  • Upgrade to Server 2008 AND Vista machines (requires both to take advantage), as they use SMB2.0 which specifically targets this issue.
  • Install a WAN accelerator on either end, be it a dedicated device like a Riverbed device, or the BranchCache feature in Server 2008 R2.
Improve this answer
1
  • I'm glad to hear Vista/2008 has addressed this!
    – user640
    May 11, 2009 at 14:02
1

We had problems in the past because the VPN system used UDP as its underlying protocol. The problem with that is the routers between the VPN user and the network would depriortize/drop UDP packets.

Switching the underlying connection to TCP seemed to solve this issue for us.

Improve this answer
2
  • The poster said IPSec. That is the underlying protocol.
    – Commander Keen
    May 11, 2009 at 15:50
  • Many VPN providers run IPSec over another transmission protocol. For example, our Cisco router provides IPSec / UDP and IPSec / TCP.
    – Simon Johnson
    May 11, 2009 at 15:57
-1

There's more about BranchCache on www.BranchCache.com if you're interested. The combination of SMB 2.1 and BranchCache in Win7/Server 2008 R2 should really speed things up.

Improve this answer
-2

OpenVPN also has the ability (may be default?) to redirect all traffic over the VPN while connected - not just traffic destined for your private network.

If this is the case, and you have many simultaneous users connected, the connection itself may be busy with other traffic.

I would suggest only using openVPN for traffic destined for your internal network, if possible. (but read comment below re: security concerns.)

Improve this answer
1
  • 1
    I advise care here. This attribute is called "split tunneling", and opens a vulnerability where the client machine can be accessed from the internet, then the internal network accessed over the tunnel. Don't do it unless you are very confident about the state of the client.
    – tomjedrz
    May 11, 2009 at 15:27

You must log in to answer this question.