[strongSwan] ipsec status hangs if the peer is not responding

[Tobias Brunner]

Hi Joern,

> The setup as such is working fine, however I noticed that the command
> “ipsec status” I am using to monitor the vpns hangs, if the
> connection entries are getting started and the peer is not responding
> for whatever reason.

Because the IKE daemon's thread pool is limited to a fixed number of
threads the jobs handled concurrently by the stroke plugin (i.e.
commands received via stroke/ipsec script) are limited too.  Too many
blocking jobs (e.g. to initiate connections to non-responding peers)
would exhaust the thread pool and the daemon would not be able to, for
instance, handle incoming packets.

The maximum number of concurrently handled jobs can be configured with
charon.plugins.stroke.max_concurrent (defaults to 4) in strongswan.conf.
 If you increase that you should consider increasing charon.threads,
which defaults to 16, but about half of these threads (depends on the
loaded plugins) are already used for blocking jobs (e.g. for stroke, the
scheduler, the receiver, or the kernel plugins).

Using the charon.plugins.stroke.timeout option you can let initiate or
terminate commands (ipsec up|down) timeout after the specified number of
milliseconds (the default is 0, i.e. no timeout), thus, avoiding that
jobs will block for the whole retransmission sequence (which takes
nearly 3 minutes, by default).

To alleviate the problem you could also use auto=start instead of
manually starting the connections with 'ipsec up'.  Because even when
run as 'ipsec up conn &' a thread will be blocked until the connection
is either up or failed, which is not the case with auto=start.
Alternatively, you can try the patch at [1], which adds non-blocking
versions for stroke up and down (run as 'ipsec stroke up-nb name').

Regards,
Tobias

[1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=fc32f0b9