Plugin Load Options

Many strongSwan components have a modular design. Features can be added or removed using a growing list of plugins. This allows us to keep the footprint small while adding new functionality.

Currently Loaded Plugins

The list of loaded plugins is logged by the IKE daemon and can also be seen in the output of swanctl --stats. Other tools often list the plugins they load in the output of the --help option like e.g. pki or swanctl itself.

Compile Time Plugin Configuration

The recommended way to enable or disable plugins is during compile time. The ./configure script has many --enable/--disable options to enable or disable specific plugins. The daemon and other tools automatically load the plugins enabled with ./configure. There is no need to manually specify the plugins to use during runtime.

Using this compile time generated plugin list has some advantages, including:

  • Proper load order of all plugin (since version 5.1.0, this has not been as important because the order only indicates the preference when two plugins provide the same feature).

  • Gets updated automatically with new strongSwan releases: This is important as we might move core functionality you rely on to new plugins.

Runtime Plugin Configuration

The plugins to load can be specified in strongswan.conf. There are two means to do so.

Plugin-Specific Configuration

The plugin loader refers to plugin-specific load settings to decide whether a plugin is loaded at runtime:

charon.plugins.<plugin>.load = yes | no | <priority>

Besides simply enabling/disabling plugins, the setting accepts a numeric priority value, which the plugin loader uses to decide in which order plugins are loaded. Plugins with the same priority are loaded according to the compile time load order. Priorities can also be negative to simplify moving a plugin to the end of the list. The default priority is 1.

By default, the setting modifies the compile time plugin list:

  • Plugins on that list don’t require an explicit load setting

  • Plugins absent from that list are not loaded, even if load = yes is explicitly set

Modular Configuration

The above limitations may be avoided with the charon.load_modular setting.

With load_modular enabled, the list of plugins is constructed dynamically, solely based on the plugin-specific load settings. That list then completely replaces the compile time list.

This means that only plugins with explicit load setting are considered, and plugins not on the default list may be loaded. Note that the compile time list is still consulted when ordering plugins with equal priority. Unknown plugins with the same priority are loaded in alphabetical order before known plugins.

The load_modular setting can also be enabled for other components, but only for charon are the default configuration snippets installed in strongswan.d/charon and included in the default strongswan.conf file. Additionally, the default snippets are also installed in the ${prefix}/share/strongswan/templates directory for reference.

This feature is also useful for distributions if plugins are shipped in separate, optional packages, to avoid trying to load plugins that are not installed but still on the compile time list.

Static Load List

Most components can read the plugin list from strongswan.conf. For example, the IKE daemon charon reads the charon.load key to load plugins, but only if the charon.load_modular option is disabled (see above).

It is not recommended to specify the plugin list manually unless you exactly know the implications!

The load directive is helpful for developers or for testing frameworks. While you might get your scenario running with a manually specified plugin list, it might not work anymore after a strongSwan update. Use the generated plugin list instead.

For example, you see a lot of load statements in the strongswan.conf files of the example scenarios of our testing environment because we enable all strongSwan plugins during compile time but use only a small subset of them while running an individual test scenario.

Critical Plugins

In the static load directive, you can mark specific plugins as critical. If loading a critical plugin fails, the daemon does not start. To mark a plugin as critical, append a ! character (exclamation mark) to its name.

Static Plugin Features

Plugin features, which are usually loaded dynamically from a plugin via the

plugin_t::get_features

callback (see src/libstrongswan/plugins/plugin.h#L51) may also be added statically from a (modified) library or executable by using the

plugin_loader_t::add_static_feature

method (see src/libstrongswan/plugins/plugin_loader.h#L61).