strongSwan

h1. Plugin Load Options

{{>toc}}

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

h2. Currently Loaded Plugins

The list of loaded plugins is [[LoggerConfiguration|logged]] by the daemon and can also be seen in the output of e.g. [[IpsecCommand|ipsec statusall]] or  [[IpsecPki|pki --help]].

h2. Compile Time Plugin Configuration

The recommended way to enable or disable plugins is during compile time. The [[AutoConf|./configure]] script has many --enable/--disable options to enable or disable specific plugins. The daemon and other tools automatically load the plugins enabled/disabled during ./configure; there is no need to manually specify the plugins to use during runtime. 

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

* Proper load order of all plugin (since version:5.1.0 this it not so important anymore, the order simply indicates the preference if two plugins provide the same feature)

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

h2. Runtime Plugin Configuration

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

h3. Modular Configuration

Since version:5.1.2 the _charon.load_modular_ option enables the dynamic construction of the list of plugins to load.

If the option is enabled the plugin loader uses the individual _load_ setting for each plugin (_charon.plugins.<plugin>.load)

to decide whether to load it or not.  Besides simply enabling/disabling plugins the _load_ 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 default load order, unknown plugins with the same priority are loaded first and in alphabetical order.

The default priority is 1, and can also be negative to simplify moving a plugin to the end of the list.

The _load_modular_ option can also be enabled for other components, but only for charon are the default configuration snippets

installed in [[strongswanDirectory|strongswan.d/charon]] and included in the default [[strongswan.conf]] file (see source:conf/strongswan.conf).

But the default snippets are also installed in the @$prefix/share/strongswan/templates@ directory for reference.

h3. 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 (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.

h4. Disable Warning

If you really need to define a static plugin load directive, you can disable the warning by setting

<pre>

starter {

    load_warning = no

}

</pre>

in [[strongswan.conf]] or by providing the @--disable-load-warning@ option during [[InstallationDocumentation|configuration]].

h4. Strict 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 ! to its name.