[strongSwan] No matching CHILD_SA config found - but it's right there

[Tobias Brunner]

Hi Chris,

> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[NET] <con4000|55> received packet: from 198.51.100.49[500] to 203.0.113.121[500] (460 bytes)
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[ENC] <con4000|55> parsed QUICK_MODE request 3072107701 [ HASH SA No KE ID ID ]
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[CFG] <con4000|55> looking for a child config for 192.168.14.0/24|/0 === 192.168.16.0/24|/0
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> no matching CHILD_SA config found
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> queueing INFORMATIONAL task
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> activating new tasks
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55>   activating INFORMATIONAL task
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[ENC] <con4000|55> generating INFORMATIONAL_V1 request 3147423319 [ HASH N(INVAL_ID) ]
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[NET] <con4000|55> sending packet: from 203.0.113.121[500] to 198.51.100.49[500] (92 bytes)
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> activating new tasks
> Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> nothing to initiate
> 
> IT'S RIGHT THERE:

Not necessarily.  The peer_cfg_t object referenced by the active IKE_SA
might not contain the required child_cfg_t object anymore.

This can happen if the `ipsec reload` command is used while the IKE_SA
was already established.  This command first removes and then re-adds
all configs defined in ipsec.conf.  So first all child_cfg_t objects
with a specific name are deleted from all (globally shared) peer_cfg_t
objects.  Which means the object that the established IKE_SA references
won't have any child_cfg_t objects in it anymore.  Then a new peer_cfg_t
object is added (because the stroke plugin removed the old one from its
list after removing all the associated child_cfg_t objects), while the
active IKE_SA continues to have a reference to the object.  So the
connection listed in the statusall output (under Connections) might
refer to a different object albeit with the same name.  However, that's
not relevant to the IKE_SA, which only operates on it's current
peer_cfg_t object (see #129 [1] for the very old ticket that describes
this).

The vici/swanctl configuration backend avoids this issue by replacing
the child_cfg_t objects in existing peer_cfg_t objects atomically with
those of the new config and not touching child_cfg_t objects in replaced
peer_cfg_t objects.  The deprecated stroke plugin doesn't do that
because of the limited interface between the starter daemon and the
plugin.  But if the config of the active connection (or %default) has
not changed, this problem can be avoided by using `ipsec update` to
reload the config as that only affects modified configs.

Regards,
Tobias

[1] https://wiki.strongswan.org/issues/129