On Sat, Oct 29, 2016 at 3:23 AM, Hongyi Zhao <hongyi.z...@gmail.com> wrote:
> Thanks for your notes.
>
> >
> > Instead, ping the vpn server's public address (through eth0)
>
> I tried and in most cases this method will fail to respond.
>
> > and compare
> > that with pinging the tunnel's remote endpoint
>
> As Gert has told me, the "topology net30" is used in the server side;
> hence it's impossible to ping the tunnel's remote endpoint.
>
Looking at previous emails, what Gert pointed out was that the second ip
you see in ifconfig's point to point listing is a bogus one for net30.
That is not the remote end point's ip and cannot be pinged. The remote is
usually the first address of the pool, but it need not be. So your best bet
is to use the gateway of the tunnel which is used for setting up the routes.
> > or gateway.
>
> The vpn_gateway is 10.211.254.254, I've used this as the probe for a
> period of time. The command used by me is something as follows:
>
> ping -I tunxx 10.211.254.254
>
Yes, comapring that with directly pinging the vpn server's public address
should give you a good idea of latency through the tunnel. Pinging any
other external IP is liable to give mixed results as some may be "far away"
(in terms of hops and route) through the tunnel but much "closer" in clear.
Selva
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
