MacOS – Improve file transfer performance over VPN

afpmacososx-serversmbvpn

I have two Apple machines: a server and a client. Both are running the newest builds of macOS Sierra 10.12.6. The “server” machine is running macOS Server running VPN and file sharing. Both machines are connected to Gigabit Internet (1Gbps up and down) but are located thousands of miles apart. The disk read/write speeds on both ends are above 100 MBps (800Mbps).

I connect my client to the server VPN (L2TP) and then file share over AFP. I regularly shuttle large files and folders to the server from the client. However, the highest speed I can get is 5 MBps (40 Mbps) sustained transfer, with a max peak of 12 MBps. If I’m moving files the other way (server to client), but transfers all initiated on the client machine), I can get as high as 10 MBps (80Mbps) sustained transfer. However, I can never get higher than that. Even with the VPN’s overhead, I was hoping to get a higher speed than, at most, 10% of the rated speed.

My questions are:

  • Is this low speed normal for a VPN (factoring in overhead)?

  • What can I do to improve my transfer performance (for large files, not large folders with lots of small files)?

Best Answer

Both machines are connected to Gigabit Internet (1Gbps up and down) but are located thousands of miles apart.

This doesn't mean that there is a low latency, gig pipe between your two sites, it just means there's a gig pipe from/to you and your Internet providers. What happens after it leaves your ISPs networks is the critical part of the equation.

Properly determining actual bandwidth

There is an excellent (cross platform including Mac, Windows, Linux, iOS, etc.) utility called iPerf that can measure file transfer speeds between points. For this particular test, it's actually pretty simple:

  • at each end-point in your VPN, install the iPerf utility (it's just a single executable binary file)

  • on a node at one of the VPN's end-points, run iPerf as a server

      $ iperf3 -s
    
  • on another node at the other end of the VPN, run iPerf as a client

      $ iperf3 - c <hostname/IP>
    

You will then get some output similar to below (I'm doing this demo on an internal network):

[  4] local 192.168.10.133 port 64041 connected to 192.168.10.113 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   169 MBytes  1.42 Gbits/sec
[  4]   1.00-2.00   sec  49.7 MBytes   417 Mbits/sec
....
[  4]   8.00-9.00   sec   192 MBytes  1.61 Gbits/sec
[  4]   9.00-10.00  sec   186 MBytes  1.56 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1.63 GBytes  1.40 Gbits/sec                  sender
[  4]   0.00-10.00  sec  1.63 GBytes  1.40 Gbits/sec                  receiver

This will give you an accurate bandwidth measurement accounting for everything between your two end-points: satellite up-links, firewalls, routers, etc. The bandwidth number you get here is the number you should be looking at to evaluate your transfer speed over VPN.

Reduce Latency

As mentioned previously, AFP and SMB protocols don't perform well in high latency environments. There are a few things you can do to reduce the latency of your connection:

  • Prioritize VPN traffic so it's not slowed down by others using the same Internet connection
  • Ensure VPN traffic can use the maximum amount of bandwidth possible. It's conceivable that your provider/network admin may be packet or traffic shaping VPN traffic to (as you mentioned) 10% of your available bandwidth.
  • Turn off Finder's icons and icon previews and try to always view in List mode(CommandJ)

Turn to the Cloud

If all else fails, a more convenient method to move files is via the cloud. Services like OneDrive for Business gives you a secure method to access your corporate files that synchronized between servers without the latency of a VPN. If that solution is still to small, you could light up an Azure File Sever or an AWS instance that would act as or synchronize with an on-prem server.

Related Question