When transferring larger amounts of data using an OpenVPN client from a specific internet connection, the internet connection from the OpenVPN servers network completely breaks down. Other OpenVPN clients do not result in this performance impact transferring the same data.
The servers network has an asynchronous internet connection with 9600kbit/s upstream (measured with iperf) and about 50MBit/s downstream.
The transfer from the OpenVPN server to the specific client uses only about 2-3MBit/s of the available ~10MBit/s upstream. The client has a much larger downstream, so this can't be the problem.
First I discovered that OpenVPN packets going to that specific client get fragmented so I manually adjusted the tun-mtu setting in OpenVPN using following serverside configuration:
tun-mtu 1492
push "tun-mtu 1492"
This wasn't the problems root so I tried out to configure traffic shaping using tc on the linux router between the modem and the serverside network.
This is the script I use to configure traffic shaping (eth2 is the interface connected to the internet):
tc qdisc add dev eth2 root handle 1: htb default 12
tc class add dev eth2 parent 1: classid 1:1 htb rate 9500kbit
tc class add dev eth2 parent 1:1 classid 1:10 htb rate 2Mbit ceil 9500kbit prio 0
tc class add dev eth2 parent 1:1 classid 1:11 htb rate 2Mbit ceil 9500kbit prio 1
tc class add dev eth2 parent 1:1 classid 1:12 htb rate 2Mbit ceil 9500kbit prio 2
tc class add dev eth2 parent 1:1 classid 1:13 htb rate 1Mbit ceil 9500kbit prio 3
tc class add dev eth2 parent 1:1 classid 1:14 htb rate 1Mbit ceil 3Mbit prio 4
# match tcp ack packets
tc filter add dev eth2 parent 1:0 protocol ip prio 0 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# match OpenVPN traffic in both directions
tc filter add dev eth2 parent 1:0 prio 1 u32 match ip sport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
tc filter add dev eth2 parent 1:0 prio 2 u32 match ip dport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
# match traffic using TOS flags to three bands mainly according to man 8 tc-prio
tc filter add dev eth2 parent 1:0 prio 3 u32 match ip tos 0x10 0x18 flowid 1:11
tc filter add dev eth2 parent 1:0 prio 4 u32 match ip tos 0x02 0x1E flowid 1:13
tc filter add dev eth2 parent 1:0 prio 5 u32 match ip tos 0x08 0x18 flowid 1:13
The aim was to prioritize all traffic higher than OpenVPN traffic an additionally supply only a small amount of the available bandwidth.
This still didn't help. I couldn't figure out any retransmissions when analyzing the traffic using tcpdump.
By saying 'the network connection completely breaks down', I mean that other internet connections nearly always time out and transfer speeds are very slow (slower than 1kbit/s). Trying to use the internet in other ways than the OpenVPN connection doesn't impact the running OpenVPN data transfer that slows everything down.
The 'slow' OpenVPN transfer speed isn't a real problem, in contrast to the 'broken' internet connection of the servers network.
Which causes could be responsible for the network breakdown?
Where could I investigate further?
