Hi,
On 11/08/16 06:56, Selva Nair wrote:
Hi,
On Wed, Aug 10, 2016 at 5:47 PM, Dante F. B. Colò
<dante01...@gmail.com <mailto: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.
I agree with Selva's comments. I've just returned from a holiday in
Brazil and was using an OpenVPN tunnel back to Amsterdam to read email
etc. RTT was well over 300 ms, inside and outside of the tunnel, but it
was definitely "workable". Don't expect to do any gaming, however ;)
Good throughput all depends on the type of underlying connection and on
the protocol used - are you using UDP or TCP? Over a bad connection,
"proto tcp" will almost always fail, due to the infamous tcp-over-tcp
handshake problems. Also, what kind of latency are you seeing without
any VPN?
And finally, at what time are you accessing the link? I've found that
the link from Brazil to Europe goes via the US (usually Miami), so when
the US is "active" then performance is even worse compared to off hours.
There is (or was?) work ongoing to lay a direct line between Europe and
Sao Paolo - I'd expect performance to improve after that.
HTH,
JJK
------------------------------------------------------------------------------
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
