Todo #9603


Strongswan stroke is deprecated, move to swanctl/vici

Added by Chris Linstruth almost 3 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:


Strongswan says:

Management Commands¶

The powerful swanctl command starts, stops and monitors IPsec connections.
The legacy ipsec command is deprecated but currently still supported.

Look at manipulating strongswan using swanctl/vici instead of ipsec/stroke.

Actions #1

Updated by Chris Linstruth almost 3 years ago

  • Private changed from No to Yes

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|/0 ===|/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|/0 ===|/0
Oct 30 18:06:43 pfSense_2.4.4 charon: 06[IKE] <con4000|55> no matching CHILD_SA config found


$ 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:
    con4000:  IKEv1, dpddelay=10s
    con4000:   local:  [] uses pre-shared key authentication
    con4000:   remote: [] uses pre-shared key authentication
    con4000:   child:|/0 ===|/0 TUNNEL, dpdaction=restart
Routed Connections:
    con4000{552}:  ROUTED, TUNNEL, reqid 1
    con4000{552}:|/0 ===|/0
Security Associations (3 up, 0 connecting):
    con4000[55]: ESTABLISHED 4 hours ago,[]...[]
    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


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

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.



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

Actions #2

Updated by Chris Linstruth almost 3 years ago

I submitted a private comment and it changed the bug to private. Since his comment was on a public list there is no reason to keep it private I suppose.

Actions #3

Updated by Jim Pingle over 2 years ago

Moving to swanctl means rewriting all the code that outputs the config to change from ipsec.conf to swanctl.conf style.

There is a guide at but given how complex the config generating code is, it's going to be a significant amount of work.

Actions #4

Updated by Jim Pingle over 2 years ago

  • Private changed from Yes to No
Actions #5

Updated by Jim Pingle over 2 years ago

  • Tracker changed from Bug to Todo
  • Status changed from New to In Progress
  • Assignee set to Jim Pingle

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

swanctl.conf format:

swanctl directory layout:

usable examples with both old and new formats to compare:

Actions #6

Updated by Jim Pingle over 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #7

Updated by Florin Samareanu over 2 years ago

Jim Pingle wrote:

Applied in changeset c6220dcf7faf3492713c6c30bb86d3971b2772a9.


My setup has ipsec vti tunnels and since this change was pushed my tunnels don't come up automatically on reboot. My internet connection is pppoe over vlan and the thing I noticed is that sometimes it's slow to connect on reboot (pfsense takes few minutes to reboot while the internet connection gets established after 5-10 minutes).
What logs do you want me to provide?

Actions #8

Updated by Jim Pingle over 2 years ago

Don't post anything here, but start a thread at with a copy of your /var/etc/ipsec/swanctl.conf , logs from when it starts up, and any other relevant details you can think of.

Actions #9

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to Resolved

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.


Also available in: Atom PDF