ipsec.conf or swanctl.conf? Pick one strongSwan frontend

A working IKEv1 profile from an older guide lands on Ubuntu 24.04, and the first attempt fails because the daemon never read the file. The usual response is to edit the profile again. The real question is which strongSwan frontend is installed and which one the running service uses. Until that is answered, every edit is aimed at a loader that may not exist.

Two files, two loaders, one daemon

The legacy starter arrangement reads ipsec.conf and hands connections to charon through its legacy management integration. Its operational entry point is the ipsec command.

The swanctl arrangement loads definitions through VICI, reads swanctl.conf, and is driven by the swanctl command. The systemd-native charon daemon integrates with that approach.

Both can be installed on the same machine, and that is where the confusion starts. A file under /etc proves only that someone wrote it, not that the running process loaded it. Installing every alternative to see which one works creates a host with two management paths and no clear owner. Pick one arrangement and remove or disable the other.

Read the installed packages and units

Start read-only. The package names on Ubuntu 24.04 are separate: strongswan-starter, strongswan-swanctl, and charon-systemd. A missing package is useful information, not an instruction to install it.

Inventory the packages and the units in one pass:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Then inspect the active unit and its startup command. The unit name tells you which daemon owns the configuration, and the command line confirms which files it was told to read. A unit that is enabled but inactive tells a different story from one that is running now.

If the active unit is strongswan-starter, ipsec.conf is the file that matters. If it is charon-systemd with swanctl, ipsec.conf is decoration.

Use the matching control path

Each frontend has its own view of connections and associations. swanctl --list-conns shows loaded definitions and swanctl --list-sas shows active associations. The legacy path uses ipsec statusall.

Mixing them produces misleading errors. A missing VICI socket or a refused control request is a management-path problem, not evidence that the peer rejected authentication.

Read the view that belongs to the running daemon, then interpret the result. If the connection is absent from that view, the problem is loading, not negotiation.

Format is not the IKE version

A legacy profile selects IKEv1 with keyexchange=ikev1. A swanctl connection uses a version setting, where 1 selects IKEv1. Those are two vocabularies for the same idea, not a conversion.

Peer addresses, local and remote identities, credential sources, proposals, and child selectors each have to be mapped on purpose. Pasting a left/right block into swanctl syntax does none of that.

Changing only the protocol version is the most common half-migration. It produces a file that loads and then fails to authenticate for reasons unrelated to the version. IKEv1 itself is deprecated by RFC 9395, so an existing peer that still requires it deserves a documented compatibility constraint and a migration path, not a new default.

Check the loader before touching the profile

Run the loader check first, then load the intended connection, then evaluate negotiation, then the protected traffic path. Each stage has a different failure signature.

The two control paths answer the loading question directly:

swanctl --list-conns
ipsec statusall

Only one of those commands belongs to your host. Running both and comparing the output is a way to discover which one is lying to you, not a diagnostic method.

Treat package ownership, configuration loading, and protocol compatibility as three separate questions. A file that is valid for one frontend will otherwise be edited again and again while a different daemon is the one running.