[OpenWireless Tech] openvpn bandwith throttling?

[John Gilmore]

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

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).

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.

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.

	John Gilmore