Hi,
On Wed, Dec 10, 2014 at 08:31:27AM +1300, Jason Haar wrote:
> LOL! It took Gert to spot the most obvious scenario ;-)
I'm good at breaking things :-)
> That really
> re-enforces what I think about this needing to be an "openvpn ping" type
> solution: it is irrelevant if the server is up or
On 10/12/14 08:09, Gert Doering wrote:
> In what kind of scenario would an OpenVPN server not be available, if
> the server itself still responds to pings?
> "The server process crashed".
LOL! It took Gert to spot the most obvious scenario ;-) That really
re-enforces what I think about this needin
Hi,
On Tue, Dec 09, 2014 at 10:40:01AM +0200, Samuli Seppänen wrote:
> > I also think it should be done with some "openvpn-ping" instead of icmp
> > ping because it confirms the server is available on the protocol/port
> > combination, whereas icmp doesn't
> In what kind of scenario would an OpenV
On 09/12/14 21:40, Samuli Seppänen wrote:
> Would 3 pings and ping replies adequately measure the overall
> performance of OpenVPN server even for one particular VPN session? What
> if there's a temporary congestion somewhere between the "best" server
> and the client? I think that reliably determi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
>
>
> So I propose openvpn itself could solve this problem - if it had some
> application layer way of "pinging" all available openvpn servers and
> choosing the one that responds "best". I'd suggest it only be supported
> for sites using "tls-aut
Hi there
If you have a global network with several openvpn servers, you have a
problem with getting clients to connect to the "best" server(*).
Typically you'd either rely on users manually choosing the best server
(which they can't do well as they don't know the full story), or do
something easy
