Re: [Openvpn-users] client seeking server...

[James Yonan <jim@xxxxxxxxx>]

On Fri, 4 Feb 2005, Nik wrote:

> Hi all,
> 
> Apologies for the length of this post.
> 
> I am revisiting my previous attempts to get a Rev 2.0 multi-client 
> server running.
> 
> I am currently running rev 2.0rc6 on clients and server machines.
> 
> The goal is to have a number of laptops configured to automatically 
> connect to the company's network, regardless of the laptop's location.
> 
> For example, when connecting from home, the server has to be contacted 
> using its public IP address over the dial-up (or broadband) interface. 
> When connecting from the office, the server (or a different internal 
> server) is contacted on a private IP address over the wireless 
> interface. etc.
> 
> The firat part is easy: I use multiple --remote parameters to create a 
> search-list.
> 
> However, I have a couple of questions regarding the behaviour and 
> interaction of various openvpn config parameters.
> 
> 1: timeouts.
> One of the issues that I encountered was that with multiple --remote 
> parameters, --ping and --ping-restart have two, somewhat conflicting uses:
> 
> a) prior to connection: determine how long to wait before deciding that 
> a candidate remote host is not available. I want this time to be as 
> short as possible to avoid lengthy delays before connecting due to 
> timing out on a list of remote servers.
> 
> b) after connection: determine how long to wait before deciding the 
> current connection has died. I want this time to be as long as possible 
> to reduce the overhead (bandwidth and cost) on the line.
> 
> I have tried setting --ping and --ping-restart to short values in the 
> client config file, and to push larger values from the server on 
> connection. This seems to work as expected (I see an entry in the client 
> log saying that "timers and/or timeouts have been modified"). The values 
> even seem to reset correctly to the short values on a --ping-restart 
> induced soft restart (very nice).
> 
> However, I now see a new parameter, --keepalive. Is --keepalive just 
> "syntactic sugar" over --ping/--ping-restart, or is it an independent 
> parameter? My initial tests indicate that --keepalive values do *not* 
> affect the connection timeout of usage a) above.

Keepalive and ping-restart are related in that they both trigger restarts 
when a timer expires.

The difference is that with --ping-restart (or --keepalive), the timer is 
reset when an OpenVPN ping message is received.

With keepalive, the timer is reset when a tunnel data packet is received.

The idea is that --ping-restart tests for continued connectivity while 
--inactive tests for continued usage.

> Q1.1 Is it better to set --ping/--ping-restart locally on the client 
> side to control the connection timeout, and push "keepalive x y" from 
> the server?

They are roughly equivalent.

> Q1.2 Is it better for the server to use --keepalive or 
> --ping/--ping-restart?

Keepalive is just a macro to help keep the server config file simple -- 
see the man page for a complete description.
 
> Q1.3 Must both server and client use the same parameter to ensure 
> correct detection of a dropped connection (ie, both must use 
> --keepalive, or both use --ping/--ping-restart)?

Keepalive is designed so that you only need to use it on the server.  It 
will push the appropriate ping/ping-restart options to the client.

> 2. searching after dropout.
> A second issue is that if a connection drops out, I would like the 
> client to retry the server it just dropped out from, rather than 
> starting to search from the top of the list each time. The default 
> behaviour is that the list is searched again from the top after a restart.

This would require patching the code.

> I have tried setting the --persist-remote-ip option in the client 
> config, but this seems to break the server search, so that after a 
> timeout on the first server, the next try is again on the first server, 
> rather than progressing to the second server (ie if the first server is 
> not available, a connection cannot be made.)

> Q2.1 Is this possibly a bug?

No, the behaviour makes sense -- if you use --persist-remote-ip you are
telling OpenVPN to reuse its current remote IP on restart.

> Q2.2 If not, is there some other way I can achieve what I want?
> 
> As a work-around, I tried pushing "persist-remote-ip", but I got an 
> error message telling me that is not allowed, which I think is 
> reasonable - it really should be defined by the client.
> 
> 
> Q4.1 Is there any benefit from using the --client parameter for clients?

Simplicity.  --client is just a macro.

> Q4.2 I presume that --server and --mode server are identical?

No, --server is a macro -- see the man page.

> Q4.3 When would I want to use "redirect-gateway def1", and what 
> behaviour should I expect?
> 

The def1 flag has a certain cleverness about it because it is able to do
its work without temporarily deleting the original default gateway --
there's even an argument to be made that it should be the default.

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users