0

When i use an openvpn (UDP connection) VPN, then a tcp connecting saturating the link (i.e. big download in firefox) causes a massive packetloss for all other connections. TCP, UDP and simple ICMP echo (ping) requests lose packets in a way, that even TCP connections time out.

For connections going though a non-vpn interface i do not have such problems, if there are several big downloads, they share the bandwith fairly. Only on the vpn link the connections are "unfair" scheduled.

I do not think its a server side problem, as the server should not do any prioritizing.

typical vpn packet (currently without much load on the vpn) on eth0:

16:06:50.228295 IP x.x.x.x.1149 > y.y.y.y.43560: UDP, length 145
allo
  • 1,524
  • 1
  • 19
  • 35
  • Possible duplicate of [Under what circumstances is TCP-over-TCP performing significantly worse than TCP alone (2014)?](http://serverfault.com/questions/630837/under-what-circumstances-is-tcp-over-tcp-performing-significantly-worse-than-tcp) – kasperd Oct 22 '16 at 12:52
  • Nope, it's a openvpn connection using UDP as underlying protocol. – allo Oct 22 '16 at 13:55
  • I would understand, if there were issues of over-vpn connections vs. non-vpn as non-vpn TCP may win against the UDP packets from openvpn or the UDP packets may saturate the link and drop the UDP packages, but all relevant connections are going over the VPN link. – allo Oct 22 '16 at 13:56
  • The problems you describe sounds a lot like what I'd expect to see with a VPN running over TCP. I'd look on a packet capture of the traffic on the physical network interface to verify if it is really using UDP. – kasperd Oct 22 '16 at 14:03
  • Verified via ``tcpdump``, the VPN uses UDP packets at ``eth0``. – allo Oct 22 '16 at 14:07

0 Answers0