Jump to content
Not connected, Your IP: 18.117.154.134

Search the Community

Showing results for tags 'shaping'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • AirVPN
    • News and Announcement
    • How-To
    • Databases
  • Community
    • General & Suggestions
    • Troubleshooting and Problems
    • Blocked websites warning
    • Eddie - AirVPN Client
    • DNS Lists
    • Reviews
    • Other VPN competitors or features
    • Nonprofit
    • Off-Topic
  • Other Projects
    • IP Leak
    • XMPP

Product Groups

  • AirVPN Access
  • Coupons
  • Misc

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Twitter


Mastodon


AIM


MSN


ICQ


Yahoo


XMPP / Jabber


Skype


Location


Interests

Found 1 result

  1. 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.
×
×
  • Create New...