@basvandijk, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FPtje, @ip1981 and @zimbatm to be potential reviewers.

Please find real reason :) Until then you can override strongswan for your deployment.

@ip1981 configurations written in the old format cannot load on boot because some daemon isn't ready yet and because the old method (the ipsec command) is asynchronous. See the reply to the mail in the mailing list. Surely that's a real reason?

I mean another solution could be to change the service to make sure charon is loaded first, but it would be putting effort into fixing something that's outdated anyway. Strongswan clearly want people to use the new swanctl.

When did this start happening? I had been running strongswan long time without issues.

@ip1981 it appears StrongSwan-5.2.0 started recommending swanctl and the vici plugin. See the second and third point in the release notes:

https://wiki.strongswan.org/versions/52

With regards to the PR do note that the existing StrongSwan tools and NixOS module are unaffected by this commit. The only thing this commit does is fixing the broken swanctl tool and adding the charon-systemd binary.

It should be safe to merge.

Ok, then. Though systemd as a dependency is a trigger :D

:)

Of course I could make the systemd support optional with a enableSystemd flag. But I propose we try this first and see in practice if more people find the systemd dependency problematic. We can always add it later on.

@basvandijk , Thanks a lot for this. Do you have a systemd.services derivation for the daemon?

@unlmtd not yet but I actually just started working on a NixOS module for charon-systemd. I don't have a lot of time to work on it the coming two weeks so expect a PR in about three weeks.