[OpenWireless Tech] openvpn bandwith throttling?

["Andy Green (林安廸)"]

On 12/02/2012 08:17 AM, the mail apparently from John Gilmore included:

> VPNs are not free; they come with a bunch of headaches.  My suggestion
> that this list avoid the VPN rathole does not come from ignorance.
>
>> Bandwith at the server is about 100 Mbps, the internetconnection at the
>> AP-owner runs at 25 Mbps but with the openvpn tunnel in place this
>> reduces to only 8 Mbps. Even without encryption and compression bandwith
>> is only aroun 10 Mbps.
>
> When I sponsored the Linux IPSEC implementation, years ago when
> encryption software was illegal to publish in the United States, the
> non-US team that built it discovered all sorts of system-level issues
> that arose from VPN tunnels.  For example, issues around the MTU
> (maximum transmission unit, also known as packet size).  For example:
>
>    *  Because the encrypted packet has a short header on it, you
>       can't send full-size Ethernet packets down the VPN tunnel.
>
>    *  The tunnels are thus configured in the kernel to have a lower
>       MTU value.
>
>    *  However, end systems that send packets usually send full-sized
>       packets and rely on intermediate systems to report back when
>       the packets are too big (by setting the don't-fragment flag
>       in each packet).  This is called "Path MTU Discovery", RFC 1191.
>
>    *  Oversized packets with the don't-fragment flag are rejected by the
>       host that can't handle them.  It sends back an ICMP packet that
>       reports the error, includes the first part of the dropped packet,
>       and also reports the MTU of the path that couldn't handle the
>       packet.
>
>    *  Unfortunately, many firewalls throw away all ICMP packets,
>       as a possibly-misguided security measure.
>
>    *  If the sender is behind such a firewall, they will keep throwing
>       too-big packets at the tunnel, which will keep rejecting them,
>       so the data transfer will stall out.
>
> It took a lot of debugging, years ago, to figure this out, and there
> is no really good way around it (other than replacing or disabling
> buggy firewalls that are somewhere in the path, possibly somewhere
> that you do not control, like near the far end somewhere in the
> Internet).  Often this problem can be noticed, if not solved, because
> short packets get through (like HTTP requests) but long packets don't
> (like HTTP replies).
>
> Here's a Cisco paper on MTUs and VPNs and lions and tigers and bears:
>
>    https://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Here's a suggestion... in vpn-only case the APs all issue the same BSSID 
and have the same logical connection in NetworkManager or whatever. 
Just set it to 500 there and 500 in all the compatible APs.  The cost of 
running too low a mtu is just the ratio of UDP/IP headers to data 
increases, so efficiency takes a little hit.  But all those problems 
mentioned above disappear.

> This is a major reason why a VPN's throughput might suffer, but there
> are others -- for example, many low powered routers such as home
> routers can switch packets among their interfaces in hardware, but do
> all their encryption in software.  So if you ask such a wimpy home DSL
> router to encrypt, everything slows down.  Bad ISPs may also have
> policies that deliberately throttle (selectively drop) encrypted
> traffic, on the bogus theory that if you're encrypting you are
> probably doing it to evade their rules (e.g. against running
> BitTorrent or home servers).

I am not sure it's done on the basis it's 'encrypted'... at least the 
bigger enemy there is bandwidth capping rather than rate limiting.  If 
I'm mooching someone else's wifi then I'm grateful if I can check my 
mail, for other's it'll be Facebook, I don't mind if my link is quite 
slow under those circumstances.

Bandwidth capping though is another reason people will have to not share 
anything, encrypted or unencrypted due to a fake scarcity of their 
allocation.  It might help if the AP can be set to top out at 1GByte for 
the month by the operator, and he can throttle client connections 
accordingly to eke that out if that's all he can contribute.

So on that basis, if in some regions the average throughput from 
participating APs is relatively low, a few 10kbps, it's still a huge 
step up from 0.

> Many on this list seem to advocate using a VPN to "bypass" the rules
> of the local ISP, and eliminate its ability to monitor or control the
> contents of your traffic.  This bypasses one problem but introduces
> another.  There will be a remote ISP at the far end of the VPN tunnel,
> and it will also have rules, and it can also spy on the contents of
> your traffic (right after it decrypts the traffic, or anywhere else
> along the way to its destination).  You have added a third party whom
> you must trust.

Yes exactly.

This problem goes away if home routers are offering vPN service.

> What you ARE able to do with a VPN is to have a *choice* of remote
> ISPs.  You can choose one with good terms and a reputation for not
> screwing its customers.  When it comes to local ISPs, the
> state-enforced "duopoly" in most places in the US restricts high speed
> home Internet access to being solely offered by two companies.  When
> no competitors can come in to take away their customers, both
> providers naturally offer you bad terms.  This is the root of the
> "network neutrality" problem -- the fact that customers dissatisfied
> with their local ISP can't switch to -- nor create -- a competing ISP
> that has policies that would satisfy them.

Yes it's a big problem in the US.

Again though vpn-only back to the client's home router is neutral from 
that POV.

-Andy