[strongSwan-dev] support for {left,right}allowany in charon?

Mirko Parthey mirko.parthey at informatik.tu-chemnitz.de
Sun May 13 23:58:42 CEST 2012

On Fri, May 11, 2012 at 11:37:59AM +0200, Tobias Brunner wrote:
> An interesting bit is that during reauthentication, after the responder
> changed its IP address, the DELETE is sent to the new address, but the
> following IKE_SA_INIT is sent to the old address, even though the
> previous addresses are copied to the new IKE_SA created during
> reauthentication.  The problem is that the hosts were re-resolved
> unconditionally in 4.6.3 and before so here you get the old address
> again (as the DNS info is not up-to-date yet).  In the master branch
> this is already fixed - for existing releases you can apply the
> corresponding patch [1].

Hi Tobias,

after applying this patch, I can now report success.

With the dual configuration you proposed (specific host + %any),
Charon can start up an IKE SA when only one side has correct DNS
information, and it is not necessary to know beforehand which side this

Further IP address updates are handled by MOBIKE without recourse to DNS,
and the IKE SA survives reauthentication after such address updates.

I'll use this setup for real now, and report back in case of problems.
I am optimistic that there won't be any.

> Now, why does the responder not initiate a new IKE_SA?  Well, it has
> simply no reason to do so.  The initiator properly deleted the existing
> IKE_SA and there is no closeaction=restart to tell the responder to
> reestablish the SA upon a proper DELETE.  As you can imagine
> closeaction=restart is not fully compatible with reauthentication, as
> the proper delete before the reinitiation would trigger an additional
> IKE_SA - which would then be closed due to uniqueness checks -
> triggering yet another IKE_SA and so on (so uniqueids=no would be
> necessary for this to work at least partly).
> The question is, do you actually require reauthentication or would
> regular IKE_SA rekeys do too, if so, you can configure reauth=no to
> avoid reauthentication altogether.

With the first solution now working, I don't want to pursue
closeaction=restart any further, since it has quite some disadvantages,
which you nicely explained.


More information about the Dev mailing list