[strongSwan] unable to install policy

[Martin Willi]

Raoul,

> I have a problem with IOS (ikev1) clients becoming
> blocked/unresponsive (users have use the word "hosed").

> 09[CFG] unable to install policy 0.0.0.0/0 === 10.0.0.5/32 out (mark
> 0/0x00000000) for reqid 179, the same policy for reqid 171 exists

This issue comes from a policy conflict in the kernel, because two
connections use the same selectors on the policy.

>         rightsourceip=10.0.0.0/16

In your case, it seems that two connections use the same virtual IP,
which results in identical policies. I don't see from your log why this
happens; usually each virtual IP should be assigned just once, resulting
in unique policies. This seems not to be the case here.

> 2] I tracked down the "unable to install policy" log message as being
> introduced by the following change:

Before that change charon just refcounted the policy to avoid the
conflict. As the reqid differs, that doesn't really work, though. The
old SA using that policy becomes unusable, and this happens silently
without any error message.

It currently is unclear to me why there is such a conflict, and how that
old SA is related to the new one. If the old one is some left-over from
the same client, reverting that patch might help to work-around the
issue. Possible that this is some kind of race condition, i.e. a virtual
IP gets re-assigned before the related policies could be deleted from
the kernel.

To improve the situation in the long term, I'm currently working on a
global reqid allocation mechanism. That should avoid such conflicts in
most cases, as we reuse the reqid for the same selectors. The
development is done in a separate branch [1]. This is currently
experimental, as the changes are rather large, but the plan is to merge
that for the next release.

> 3] trying to think outside the box I bit: I was wondering if settings
> "uniqueids=no" would help the situation in that it could work around
> the need for the discussed code path.

Hard to say. If it is possible on your setup, just try it. It will avoid
having multiple ISAKMP_SAs with the same peer, which could prevent that
race condition.

Regards
Martin

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