Requesting Help and Reporting Bugs » History » Version 25

« Previous - Version 25/28 (diff) - Next » - Current version
Noel Kuntze, 30.07.2020 06:40
Snippets work for Windows now too

Requesting Help and Reporting Bugs

Before you request help or report bugs, please give the following items some consideration to avoid wasting your and our time and for optimizing the time it takes to find a solution.

If you are new to strongSwan please read the introduction.

If you look for help regarding configuration, base your configuration on the usable examples first to avoid generic problems.

If you have problems with traffic not reaching hosts via VPN, read the documentation regarding forwarding traffic, split-tunneling and MTU/MSS issues.

If you are reporting a security issue, refer to the dedicated security flaw reporting instructions.

If you require help with configuring special features of strongSwan, look at the how-tos for those features first.

Finding solutions for your problems effectively and efficiently

For other problems please follow these steps:

  1. Read the Frequently Asked Questions (FAQ)
  2. Read the manuals (i.e. the man pages that come with your version of strongSwan)
    And make sure your version of the man page corresponds to strongSwan and not FreeS/WAN, Openswan or Libreswan.
    The software that a man page belongs to is usually printed in the center top of the man page when it's initially opened.
  3. Make sure you put the files into the right directories. On distributions that stem from RHEL, strongSwan configuration files are under /etc/strongswan.
  4. If charon crashes, try these things first.
  5. Make sure your version is up to date. A lot of actual bugs (not user error) are fixed in newer versions of strongSwan.
  6. Search the bug tracker using the search function for keywords from the logs or
    keywords that describe your issue. Make sure to include issues.
  7. Search the mailing list archives. You may also use your favorite search engine by restricting the results to (usually the syntax is
  8. Now, you may ask for help. Please write issues and emails to the mailing lists in English only. Do not write your messages in any other language.
    Please attach your complete config files (ipsec.conf, strongswan.conf, swanctl.conf etc.) and a complete log file showing the problem.
    Please supply text files. Pictures are not useful. If the files are large (over 1 MB), please use a pastebin of your choice or host it somewhere
    yourself. If you are told to provide the data in the IRC channel of strongSwan, then please use a pastebin and provide links to your pastes. Use different pastes for different data.

    We generally require all of the following from you:

    • The complete log from daemon start to the point where the problem occurs
    • The complete configuration (ipsec.conf or swanctl.conf, depending on which configuration backend you are using)
    • The complete current status of the daemon (ipsec statusall or swanctl -L and swanctl -l)
    • The complete firewall rules (output of iptables-save and ip6tables-save on Linux, analogously on other operating systems using the corresponding command(s))
    • The complete contents of all routing tables (output of ip route show table all on Linux, analogously on other operating systems)
    • The complete overview over all IP addresses (output of ip address on Linux, analogously on other operating systems)

When you create a log file, use the log settings from the bottom of the page, unless we tell you otherwise.
If you (or your distribution) use a Linux Security Module (LSM), like AppArmor, Selinux, YAMA or TOMOYO, you need to allow the IKE daemon (charon, charon-systemd etc.) to create and write to that file first, or disable the LSM for the time of the debugging. Obviously, allowing the daemon to create and write the file is preferred.

Dealing with Linux Security Modules (LSM)

In order for strongSwan to be able to write the logfile, it has to be allowed by the OS. If the OS implements an LSM, like CentOS with Selinux or Ubuntu like AppArmor, it is likely that the LSM prevents strongSwan from writing the logfile. If that is the case, there will be a log record for that in the audit log (ususally under /var/log/audit/audit.log or /var/log/audit.log). Setting the LSM into permissive mode for strongSwan while logging is required is one of the acceptable ways of allowing it to do that. The following subsections show the commands to do that.

All advice in this section applies only temporarily. After a reboot, the previous configured status applies again. For example, if AppArmor was active in enforce mode before you put it in permissive mode, it will likely be in enforce mode again after the reboot.


The information about AppArmor was taken from the article about AppArmor on

Check if AppArmor is active

Run at least one of the following commands to determine if AppArmor is active

aa-status or aa-enabled

The command has to be executed with root privileges.

Set complain mode for strongSwan temporarily

aa-complain <path to charon/charon-systemd binary>

The command has to be executed with root privileges.

Example: aa-complain /usr/lib/ipsec/charon

The command has to be executed with root privileges. You can find out what the path is by either checking ps aux or, if strongSwan isn't running, by examining the contents of the packages that provide strongSwan on the system.

Disable AppArmor mode globally temporarily


The command has to be executed with root privileges. Unknown if this works on anything but Arch Linux.


The information about Selinux was taken from the article about Selinux on the ArchWiki.

Check if Selinux is active


Set permissive mode for strongSwan temporarily

semanage permissive -a <domain of the strongSwan process>

Example: semanage permissive -a strongswan_t

The command has to be executed with root privileges. You can find out what the domain is by either checking ps auxZ or searching the

The command has to be executed with root privileges.

Set permissive mode globally temporarily

echo 0 > /sys/fs/selinux/enforce

Set enforce mode globally temporarily

echo 1 > /sys/fs/selinux/enforce

Configuration snippets

IMPORTANT: On Windows, use a different path from /var/log/... or /tmp/. Use, for example, just charon.log, which creates the file in the working directory of the process (if it is allowed to do so).

Use the following snippet for strongswan < 5.7.0

    filelog {
            /var/log/charon_debug.log {
                    time_format = %a, %Y-%m-%d, %%H:%M:%S
                    default = 2
                    mgr = 0
                    net = 1
                    enc = 1
                    asn = 1
                    job = 1
                    ike_name = yes
                    append = no
                    flush_line = yes

Use the following snippet for strongswan >= 5.7.0

    filelog {
            # since 5.7.0 the path to the log file has to be specified in a separate setting if it contains dots,
            # use an arbitrary name without dots for the section instead of the one given here
            charon-debug-log {
                    # this setting is required with 5.7.0 and newer if the path contains dots
                    path = /var/log/charon_debug.log
                    time_format = %a, %Y-%m-%d, %H:%M:%S
                    default = 2
                    mgr = 0
                    net = 1
                    enc = 1
                    asn = 1
                    job = 1
                    ike_name = yes
                    append = no
                    flush_line = yes