Lots of packet loss and high ping when torrenting through PIA vpn
I'm connecting to privateinternetaccess VPN from my pfSense router, and behind that is a torrenting box. Only the torrenting box is being routed through the VPN, the rest of my network isn't. I have a 250/40 connection with a average ping of 10ms (To my ISP's gateway), but when the torrent box starts downloading something, my average ping shoots up to 80ms, and i get 40% packet loss, even though the torrent is only downloading with 1 megabyte a second. Can someone explain what is causing this? My pfSense router has 4 cores assigned, and 4 gigabytes of ram. If i run the torrent box through my normal connection and not the VPN, the ping stays about the same, and there isn't any packet loss. The reason the high ping is a problem is because i'm hosting a TeamSpeak 3 server at home, and VoIP and high pings/packetloss don't go well together.
The problem only occurs with torrent traffic, if i download a normal file through the VPN the ping stays low and there is no packet loss.
This is what it looks like when the torrent has been going for 5 minutes…
I have the same issue with PIA on CentOS 7 using the Southampton server.
I have not found a permanent solution but as a work around set a limit on my overall peers to 500 and per torrent peers to 50. I tried adjusting the MTU as low as 1200 without any success.
Let me know if you find a solution, there dosen't seem to be much online regarding this.
I also ran into this issue since my ISP started throttling / rate limiting my connection speed and I saturate the WAN link with VPN traffic. Easy to reproduce using speedtest.net.
This is typical behavior when an upstream service is throttling or rate limiting throughput, packets are delay (but not dropped) in order to choke back the downstream connection speed.
The problem your experiencing is because Gateway monitor uses dpinger, which has a configured limit on how long it waits for responses before determining they are "lost". What's important to note is the Loss % is not actual data loss, but "missed" ping responses, because they arrived too late to be counted.
Key item that indicates this is RTTsd; RTT is of course the aggregate ping transit time, but the RTTsd is the Standard Deviation between each received ping response. When the link is quiet the RTTsd will generally be fairly low, but when the RTTsd goes up it means that something up stream is intermittently delaying packets resulting in a larger deviation between each ping attempt. Thus if the pings are delayed beyond the configured wait time, they are considered "lost" even if they still arrive.
I was able to get around this by going to System >> Routing >> Gateways and edit each gateway to increase the "Loss Interval" under the advanced section to increase the time that dpinger waits for responses before considering them "lost". After that, my loss percentages dropped to near 0%, but then I started seeing the real latency of the delayed packets skyrocket, so had to tweak with the Latency threshold values as well to keep the gateway from dropping out from excessively high latency when it is saturated with traffic.
You'll need to do some testing with traffic saturation on your VPN/WAN in order to come up with monitor values that do not cause the gateway monitor to considered the link offline. I ended up having to configured some pretty high values on the upper latency threshold to keep the link from being knocked offline when running heavy traffic loads.