I have a very weird problem with OpenVPN.

Most VPNs work fine, except this one. Here I get very low performance from TCP connections, but the CPU load is low (so, not a CPU issue).

OpenVPN is configured with UDP, AES-256-CBC cipher, SHA256 auth and no compression.

Here are some measurements I did with iperf:

Network connection without VPN:

iperf -c external.ip result:300 - 500mbps (good)
iperf -c vpn.int.ip result: 20-30mbps (not good)

The cpu usage on both ends is low. OK, maybe some ISP shapes or filters the UDP packets.

iperf -c external.ip -b 500M result: no packet loss

Hmm... what if I force UDP stream trough VPN

iperf -c vpn.int.ip -b 100M result: no packet loss
iperf -c vpn.int.ip -b 180M result: packet loss ~0.1%

So, my VPN connection should go up to 180mbps, based on the results with UDP, but it doesn't. I also get very weird graph with tcptrace.

This is how the good test goes (without VPN, using external IPs): TSG of external connection

As you see, the sent packets stay near the yellow line, meaning the receive window is kept almost full. This portion of the graph is near the start of the connection, later, the sent packets are practically on top of the yellow line.

And this graphs is what I get from VPN: TSG of vpn'ed connection

Now here for some reason the sender acts as if the window was very small, even though it is large (it does not matter what I set the window to, tried keeping the default setting and 4MB) and sends the packets only in small bursts.

This is the first time I have seen a graph like this? What could be causing it? Some UDP filtering by the ISP, OpenVPN itself, something else?

EDIT: Running the VPN using TCP instead of UDP results in 10mbps troughput.

  • What happens if you use the TCP transport with openVPN (I suspect its the intermediaries limiting UDP flows - most likely as a defence against amplification attacks) – symcbean Aug 26 '14 at 11:22
  • I will try that, though TCP inside a TCP tunnel is usually a bad idea. However, iperf with UDP (as shown in the question) gets about 500mbps outside of VPN and 180mbps inside. – Pentium100 Aug 26 '14 at 11:25

I have solved it. Or rather, I know how to make it faster, but do not know why it is slow. It seems that AES cipher interferes somehow with TCP on this particular server and results in the low performance. If I change the cipher to, say, 3des (which is slower as reported by "openssl speed"), I get 150mbps. After some trials, I now use this:

cipher camellia-128-cbc
auth sha1
tun-mtu 9000

Now I get 300mbps for a single stream and 450mbps for multiple streams.

| improve this answer | |
  • 1
    It is good to hear if it is fixed, although I see this a little bit mystical. The cipher shouldn't do anything with such problems. I think it was some other bug in your system, which you have now accidentaly avoided. – peterh - Reinstate Monica Aug 27 '14 at 9:04
  • 1
    @PeterHorvath, looks like it. For whatever reason aes+tcp on this particular server results in poor performance. Even using compression (iperf stream is very compressible) results in the same throughput (and lower traffic on the external interface). – Pentium100 Aug 27 '14 at 10:01

maybe you are running into issues with MTU on the connection. take a look at the following two links, they may contains some usefull info.

Configure the MTU with Fragment and MSS

Optimizing performance on gigabit networks

| improve this answer | |
  • 1
    tried setting tun-mtu 1400 and mss-fix 1400 (not at the same time), didn't help one bit. – Pentium100 Aug 26 '14 at 12:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.