Openvpn – How to improve OpenVPN reliability over a high latency link

openvpn

We are running a OpenVPN VPN over a BGAN satellite link where ping times are about 3 seconds. We use it in a tun configuration, and we're running on Linux (CentOS). It is primarily email that will be sent over the link, but as soon as the mail contains large attachments, the VPN seems to stall.

The "I can ping through the tunnel, but any real work causes it to lock up. Is this an MTU problem?" question in the OpenVPN FAQ seems to describe my problem exactly, but using mssfix and fragment still does not seem to do much to improve the situation.

My main test is to copy a 2MB file over the VPN with scp. It will copy about 192kbytes, and then report a – stalled – state. If I wait a couple of seconds it will start copying again, and then stall again after another couple of kbytes.

This stalling occurs whether or not I've set the fragment or mssfix options in my OpenVPN configuration (although setting fragment 1000 did seem to reduce the stalling, but not eliminate it). The OpenVPN mtu-test reported 1542 as the MTU size.

I've searched the internet for more advice on how and when to use mssfix and fragment, but I only find pages saying the same as the FAQ, and not giving details as to how and when to use which parameters.

My questions then is:

  • When do I use mssfix and fragment?
  • Do I use mssfix and fragment in combination?
  • If mssfix and fragment are the solution, what are the tun-mtu, link-mtu and mtu-disc parameters for?

Furthermore, I've been using the tool iperf to measure the bandwidth. Without the VPN, it constantly measures in the order of 210Kbits/sec.

When using iperf over the VPN ($ iperf -c remoteserver -t60 -i5), it would start at 10Kbits/sec, then steadily go up until it reports 1.2Mbits/sec, and then it will seem to stall, where it reports 0kbits/sec for a number of iterations (I think the 1.2Mbits/sec may be because of some OpenVPN buffering or so on)

Is iperf the best way to measure the bandwidth?

Any help with this situation will be greatly appreciated.

Best Answer

1542 as an MTU? Never heard of that for a WAN link. Usually, MTU is the max payload, ip packet size minus the header for IP (20 bytes) and ICMP (8 bytes). That means MTU=1500 for a traditional Ethernet LAN. Furthermore, most VPN's introduce an overhead for their packet encapsulation. A typical VPN MTU is 1400.

In modern networks, it is difficult to conclude what MTU will be at any moment, as ingress and egress paths may be different, and they may also change due to automatic path re-routing. For a network like this, it may be more effective to set the MTU low on your hosts that are on either side of the VPN link, such as 576.

MSS (maximum segment size) is MTU minus the IP+TCP headers (40 bytes). This is typically negotiated by the network stack, and usually does not have the same negotiation issues as MTU, unless MTU is wrong. (MTU negotiation is usually impaired by blocked ICMP or black hole routers).

The first thing I would do is do a network packet capture on your sending end, and sort the display by frame size (you may need to add this column in Wireshark). You should verify that you aren't sending any frames that are oversize, what you would expect them to be. It's not unusual for modern network cards to send oversize frames if options such as Large Send Offload or Jumbo Frames are enabled. I've seen 30,000+ byte frames when these options are enabled.

Related Topic