[strongSwan] problems with charon in 4.5.2 (was: 4.4.1)

Martin Willi martin at strongswan.org
Wed Jun 1 16:41:34 CEST 2011


Hi,

> Of course i would like the two hosts to try harder to re-establish
> their connection again. did something go wrong at that point? how can i
> increase the number of reconnection attempts in case of loss of SA?
> %forever sounds long to me, but hey. should i just put a really big
> number here?

The keyingtries parameter in IKEv2 applies to initial connection setup
only, but not for ordinary exchanges. To try reestablishing the tunnel,
you could enable dpdaction=restart (but optionally with a dpddelay=0).
Then the keyingtries parameter will apply when the tunnel is restarted
after an ordinary exchange times out.

The problem with dpdaction is: We currently use the same value as the
so-called "close-action", defining what we should do if the remote end
closes the tunnel. And this is problematic if you enforce duplicate
checking, i.e. with uniqueids. We really should split up these two
parameters to be separately configurable.

If you'd like to try this approach, you should consider the attached
patch to disable the close-action for now.


Another variant to realize always-up tunnels is to have a "routed"
policy, and establish tunnels on traffic. If the tunnel fails, it will
get reestablished. There are some problems with policy management (as
the kernel does not support identical policies), hence I currently can't
recommend it. Tobias has tried to solve these issues at [1], I'll do
some testing with his work to see if this could be an option for you.

Best regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/policy-history

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-CHILD_SA-close_action.patch
Type: text/x-patch
Size: 1085 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110601/487ee9ae/attachment.bin>


More information about the Users mailing list