Hi,
On Wed, Aug 10, 2016 at 5:47 PM, Dante F. B. Colò <dante01...@gmail.com>
wrote:
> Hello everyone
>
> I have a issue with a client machine running openvpn 2.3.11 on Windows
> 10 located in London , my server is located here in São Paulo, Brazil
> and there is a high latency between the two endpoints , ping replies to
> each other take around 280 ms, when i try to access some service on my
> network almost everything take much time to respond, it's is pratically
> unusable, i already tried somethings like enable LZO compression ,
> change mtu on client and server tun interfaces , i still don't have much
> experience with openvpn, is this normal ? Is there anything more that i
> can do to improve performance ?
>
If you mean that the latency (round trip time) through the tunnel is much
worse than the underlying link, something may be wrong with the setup. But
I suspect the 280ms number must be close to the round trip time (RTT) of
your Internet link from Sao Paulo to London. If so, it looks quite
reasonable, and you can't do anything much to improve it. Compression won't
alter RTT.
In spite of a long RTT, except for very high speed links, you should get a
throughput as good as or even better (with compression) than the direct
connection. The link should be very much usable unless its primary purpose
is interactive use.
I have helped set up and maintain a few OpenVPN tunnels over some very
erratic and high latency links and our experience has been quite good: in
one case the remote site has only satellite access with latency of ~900 ms,
often disturbed by bad weather including desert storms. Still it works very
well for aggregated data transfer -- they have been transferring about 1GB
overnight almost daily over it for a couple of years now. In fact the speed
over VPN with compression is much better than the direct link as this is
mostly log-shipping of database transactions which compresses well. At the
same time interactive use like remote desktop or real-time database
transactions is hard. Still we do manage to occasionally do some
interactive tasks through it. Another link is over a land line with ~300ms
RTT and pretty usable even interactively once you get a bit used to the
delay. And compared to the satellite link its, relatively speaking, a
pleasure to use. And, the RTT through the tunnel is comparable to that of
the underlying link in both cases.
So, in my experience, if the underlying link is usable, the tunnel cannot
be "practically unusable". The need for tuning of parameters such as mtu or
tcp buffer size is often over-stated. First do some measurements: what RTT
and throughput do you get without the tunnel and how do they compare with
the values through the tunnel? Does the provider (ISP) do any traffic
shaping/throttling?
That said, do not expect to get a highly responsive ssh session or remote
desktop over a trans-Atlantic link.
Selva
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
