How can I increase the performance of OpenVPN over a high packet loss network environment

I am trying to connect my laptop to a server in another continent, and it seems that the link is very unreliable (with about 58% packet loss when pinging).

When using the VPN through a default OpenVPN's secret key setting (which uses UDP), pinging in the VPN reports about 57% packet loss (it bothers me in ways like a slow SSH establishment).

Is there an efficient way to decrease the packet loss rate in this situation? I have administrative control on both my laptop and the server.

Here is part of the traceroute result from my laptop to the server:

 8 221.176.27.254 (221.176.27.254) 16.870 ms 9 * * *
10 221.183.30.246 (221.183.30.246) 197.288 ms
11 223.118.10.30 (223.118.10.30) 201.422 ms

2 Answers

Use UDPspeeder. It trades bandwidth overhead for packet loss resistance.

On server side, start

speederv2_amd64 -s -l 0.0.0.0:1193 -r 127.0.0.1:1194

On client side, start

speederv2_amd64 -c -l 127.0.0.1:1194 -r your_server_ip:1993

Then point OpenVPN UDP client to 127.0.0.1:1194.

Use --fec parameter to tune amount of redundancy.

You can toggle OpenVPN to TCP in the configs (Do both client and server, and maybe ensure your TCP OpenVPN is secure before or if you disable the UDP service). This will have the effect of ensuring all packets get through eventually. This will still be slow, but it's at least worth the experiment. From openvpn.net:

If you want your OpenVPN server to listen on a TCP port instead of a UDP port, use proto tcp instead of proto udp (If you want OpenVPN to listen on both a UDP and TCP port, you must run two separate OpenVPN instances).

As for packet loss, you can only fix the path the packets take. Use traceroute from both ends to find the offending portion of the link and see about bypassing it or making it more robust.

Instead of TCP the whole way, try seeing if you can rent infrastructure time very near the suffering link to tunnel TCP through the weak link to the destination. This would let UDP packets fly as far as possible without having to TCP ack or retransmit for the entire length of your tunnel, only the bad part of it.

If the weak link is mid-way through, you may benefit from renting infrastructure on both ends of the weak link instead of just on one side, but if we're talking Antarctica, maybe that would be difficult.

If you chose to test this route, I recommend udptunnel as one possible solution. (udptunnel is its own package on Ubuntu, but other options like socat or creative netcat piping will work.)