pfSense

Aside from the deprecated status of ipsec/stroke we have seen what appear to be random instances of strongswan saying things like this:

Jun 26 14:39:11 firewall charon: 10[CFG] <con2000|2190> looking for a child config for 172.19.122.200/32|/0 === 198.51.59.17/32|/0
Jun 26 14:39:11 firewall charon: 10[IKE] <con2000|2190> no matching CHILD_SA config found

When the CHILD_SA configuration plainly exists in the pfSense and strongswan configuration.

I raised this issue last year on the strongswan mailing list and Tobias responded with this:

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

IT'S RIGHT THERE:

$ ipsec statusall con4000

Status of IKE charon daemon (strongSwan 5.6.3, FreeBSD 11.2-RELEASE-p3, amd64):
 uptime: 2 days, since Oct 27 22:44:06 2018
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10
 loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters
Listening IP addresses:
 203.0.113.121
 192.168.14.1
 172.16.14.1
Connections:
    con4000:  203.0.113.121...198.51.100.49  IKEv1, dpddelay=10s
    con4000:   local:  [203.0.113.121] uses pre-shared key authentication
    con4000:   remote: [198.51.100.49] uses pre-shared key authentication
    con4000:   child:  192.168.14.0/24|/0 === 192.168.16.0/24|/0 TUNNEL, dpdaction=restart
Routed Connections:
    con4000{552}:  ROUTED, TUNNEL, reqid 1
    con4000{552}:   192.168.14.0/24|/0 === 192.168.16.0/24|/0
Security Associations (3 up, 0 connecting):
    con4000[55]: ESTABLISHED 4 hours ago, 203.0.113.121[203.0.113.121]...198.51.100.49[198.51.100.49]
    con4000[55]: IKEv1 SPIs: 6dd2d30fcec4ee45_i* 0007aac07d503b24_r, pre-shared key reauthentication in 2 hours
    con4000[55]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    con4000[55]: Tasks queued: INFORMATIONAL
    con4000[55]: Tasks active: QUICK_MODE

> 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

I am fairly-well convinced that pfSense can do something smarter/better here.

I'm looking this over. A few more useful links:

swanctl.conf format:
https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

swanctl directory layout:
https://wiki.strongswan.org/projects/strongswan/wiki/Swanctldirectory

usable examples with both old and new formats to compare:
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

Applied in changeset commit:c6220dcf7faf3492713c6c30bb86d3971b2772a9.

This has been in for a while and working well. If any new problems come up they can be handled in their own separate issues.