Requesting Help and Reporting Bugs

Before you request help or ask questions, 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 quickstart 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 strongSwan features, browse the Configuration, Features and Howtos sections in the documentation first.

Finding Problem Solutions Effectively and Efficiently

For other problems please follow these steps:

Read the Frequently Asked Questions (FAQ).
Read the manuals (i.e. the man pages that come with your strongSwan version).
Make sure your version of the man pages correspond 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.
Make sure you put the files into the right directories. On distributions that stem from RHEL (Red Hat Enterprise Linux), strongSwan configuration files are stored under /etc/strongswan.
If the charon daemon crashes, try these things first.
Make sure your strongSwan version is up to date. A lot of actual bugs (not user errors) are fixed in the latest strongSwan versions.
Search issues and discussion threads using GitHub’s search function for keywords from the logs or keywords that describe your problem.
Perhaps also search the old bug tracker via its search function or the old mailing list archives (e.g. via site:lists.strongswan.org in a search engine).
However, it’s usually easiest to use your favorite search engine directly as you might also find answers on Stack Exchange etc.
Now, you may ask for help. Please write your posts in English only. Do not write your posts in any other language. Please include or attach your complete config files (strongswan.conf, swanctl.conf, etc.) and a complete log file showing the problem. Please supply text files. Pictures are not useful. If you are told to provide the data in the IRC channel of strongSwan, then please use a pastebin of your choice 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 (swanctl.conf or ipsec.conf, depending on the configuration interface you are using)
The complete current status of the daemon ( swanctl --list-conns and swanctl --list-sas or ipsec statusall)
The complete firewall rules (output of iptables-save and ip6tables-save on Linux, analogously on other operating systems using the corresponding commands)
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 addr 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 logfile 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.

AppArmor

The information about AppArmor was taken from this article. All commands have to be executed with root privileges.

Check if AppArmor is active

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

aa-status or aa-enabled

Set complain mode for strongSwan temporarily

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

e.g sudo aa-complain /usr/libexec/ipsec/charon.

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

sudo aa-teardown

Unknown if this works on anything but Arch Linux.

Selinux

The information about Selinux was taken from this article.

Check if Selinux is active

sestatus

Set permissive mode for strongSwan temporarily

sudo semanage permissive -a <domain of the strongSwan process>

e.g. sudo semanage permissive -a strongswan_t*.

You can find out what the domain is by either checking ps auxZ or if strongSwan isn’t running, by examining the contents of the packages that provide strongSwan on the system.

Set permissive mode globally temporarily

sudo echo 0 > /sys/fs/selinux/enforce

Set enforce mode globally temporarily

sudo echo 1 > /sys/fs/selinux/enforce

Configuration Snippets

On Windows, use a different path from /var/log/… or /tmp/. Use e.g. 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 in strongswan.conf for version < 5.7.0

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

Use the following snippet in strongswan.conf for version >= 5.7.0

  filelog {
    # any 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
      net = 1
      enc = 1
      asn = 1
      job = 1
      ike_name = yes
      append = no
      flush_line = yes
    }
  }