Search the Community
Showing results for tags 'shaping'.
Found 1 result
I'm with Virgin Media in the UK, on 160/12 cable. Last year I had a spate of low speed (3MB/sec hard cap) which I initially blamed on throttling of OpenVPN as I could hit full speed on my naked ISP connection. After some investigation I found it was actually a bug in the ISP supplied router, so I switched to my own and the problem went away. Lately however, I'm having a hard speed cap problem and it really looks like issues caused by either VM's use of DPI and/or OpenVPN throttling/shaping at ISP level. VM operate a whitelist for shaping, so unless the protocol is whitelisted it's shaped by default. VM categorically and publicly deny any form of throttling, shaping or interference with OpenVPN connections. I've been using an Ubuntu torrent as a speed benchmark as it's multi-threaded, consistently very fast, and can be used off-VPN without fear of legal issues. I have tested every port and protocol in Eddie, as well as via Viscosity (to rule out Eddie issues). I also tried the same tests with several other well respected VPN providers with good networks and the results were consistent across them all, Air included. Note that I am using MB/sec in its proper format, meaning megabytes per second. 1MB/sec = 8Mbps. All results are for the same Ubuntu 15.04 x64 torrent downloaded in the latest qBittorrent v3.2.3 on Mac OS X (also verified on Linux, PCBSD and Windows 8.1 Pro). As well as checking against multiple VPN companies, multiple OpenVPN software and multiple operating systems, I also reproduced the results on multiple machines (mid 2012 MacBook Pro and my FX8350 / 16GB DDR3 / Samsung Evo 850 sad / Radeon R9 380 gfx desktop). I repeated the tests with several ethernet cables (to rule out cable issues), as well as with *machine* > router > modem and *machine* > modem (to rule out firmware or routing issues). Every time, regardless of the variable, the results below were consistent. ISP : 19MB/sec OpenVPN 53 UDP : 2MB/sec OpenVPN (all other ports in turn) UDP : 5MB/sec OpenVPN (all ports) TCP : 4 - 5 MB/sec OpenVPN + SSH 22 : 2MB/sec OpenVPN + SSH 80 (or 53) : 13 - 18 MB/sec (lower in peak times, high off-peak) OpenVPN + SSL 443 : 13 - 18 MB/sec (lower in peak times, high off-peak) As we can see, generally SSL and SSH masking the OpenVPN connection allows almost full line speed (minus the encryption overheads). That's great. As soon as it's a bare OpenVPN connection the speeds cap out at around 33% of what they should be. Bare OpenVPN TCP is a little slower than UDP (as you'd expect) but otherwise in accordance with the general 5MB/sec cap experienced on UDP. The only exceptions are UDP:53 and SSH:22 which are both heavily restricted to around 2MB/sec. Now to my mind, knowing what I do of VM's shaping and DPI systems, this would only make sense if they were interfering with OpenVPN either by purposefully throttling it, or else their DPI system is messing up the connection. They further seem to restrict SSH:22 and UDP:53 by protocol but not by port. This actually makes sense, as all other Eddie combinations are quite random whereas SSH:22 (SSH) and UDP:53 (DNS) are established network traffic protocols and thus could be singled out for listing in the shaping systems. If we reverse the protocol/port (to give SSH 53 and UDP 22) we once again obfuscate the tunnel and go back to full speeds! I also get a lot of decrypt/replay errors in the logs on every single port for 'normal' OpenVPN. As soon as I hide the OpenVPN in either SSL or SSH the errors simply don't occur. Ever. This suggests that the extra tunnel is hiding the OpenVPN tunnel from being shaped, or else the DPI process in and of itself is breaking OpenVPN and causing the packets to arrive out of order. Maybe that in and of itself can hurt speed? So there you go. Sorry for the long post but it's an interesting (if thoroughly frustrating and annoying) issue. What do you gurus think? Given I have worked to change the variables one at a time to rule out issues with AirVPN (different providers), the router and/or its firmware (direct connection to modem, bypassing router), wireless issues (used ethernet directly) and OS limits or bugs (used multiple OSs) I can't see anything is left... except issues with the ISP shaping/throttling or else their DPI breaking things. I posted a thread very similar to this in VM's support forums, but for a whole week it has gone unanswered by any staff. Interestingly it is the only thread on the forum to have been ignored. Make of that what you wish. I await your replies with interest. Thanks in advance for reading.