strongSwan

h1. Frequently Asked Questions

{{>toc}}

h2. IKEv1

h3. Multiple subnets per SA

*Q:* _Can I tunnel several subnets in one CHILD_SA?_

*A:* If you use IKEv2, you can. If you use IKEv1, you need to be a roadwarrior and use the _UNITY_ extension (strongSwan implements it with the [[UnityPlugin|Unity]] plugin). In any other case, you need to define a seperate CHILD_SA per subnet pair.

If you're a roadwarrior and use a proprietary implementation, please read the notes about [[UserDocumentation#Interoperability|interoperability]]. If you use strongSwan, try setting @rightsubnet=0.0.0.0/0@

and enable the [[UnityPlugin|Unity]] extension. You also need to make sure that the plugin is loaded to be able to use it.

An easy to manage example for a site-to-site setup follows:

<pre>

conn myikesettings

    keyexchange=ikev1

    left=10.0.0.1

    right=10.0.0.2

    leftcert=mycert.pem

    rightcert=othercert.oem

    ike=aesgcm16-prfsha256-modp3072!

    esp=aesgcm16-modp3072!

conn sa_1

    leftsubnet=192.168.1.0/24

    rightsubnet=192.168.51.0/24

    also=myikesettings

    auto=route

conn sa_2

    leftsubnet=192.168.2.0/24

    rightsubnet=192.168.52.0/24

    also=myikesettings

    auto=route

</pre>

h3. "no proposal chosen" returned by ZyXEL/Linksys/x router

*Q:* _I'm trying to set up a VPN tunnel with a ZyXEL/Linksys/X router but the other side keeps on telling me "no proposal chosen" when strongSwan initiates the connection._

*A:* Make sure that the peer supports all the algorithms (including the key lengths) which strongSwan proposes for IKE and ESP. In terms of IKE, the proposal consists of the following parts: Encryption algorithm, hash algorithm (PRF) and DH group. In terms of ESP the proposal includes the following: Encryption algorithm, hash algorithm, pfs group (DH group) and *compression algorithm*. There are lots of IPsec implementations out there that do *not* support compression or have implemented it erronously. So the first thing to try in this situation is to switch compression off on the peer. strongSwan's default setting is

<pre>

compress=no

</pre>

See also Chapter "14.1 Authentication and encryption algorithms":http://www.strongswan.org/docs/readme4.htm#section_14.1 of the strongSwan documentation. It has good information about the relevant parameters.

h3. "no RSA public key known for '...'"

*Q:* _I'm getting the error message "no RSA public key known for '....' ". What am I doing wrong?_

*A:* If you are using RSA based signatures for authentication strongSwan needs to have the peer's RSA public key in order to verify its authentication. This public key can be provided either by using the @rightrsasigkey@ directive in [[ipsecconf|ipsec.conf]] which was popular with FreeS/WAN or it can be extracted from the peer's X.509 certificate. This certificate can in turn be preloaded via the @rightcert@ directive if it is available locally or it can be requested from the remote end with a _certificate request_. Now if the certificate is missing one reason might be that the remote end refused to send it. Another reason could be that strongSwan did not send a _certificate request_. This happens if you set the @nocrsend@ option to @yes@. The Astaro Security Gateway which uses strongSwan behind the scene is known to do that. In order to make the IPsec connection work in that scenario you need to set @leftsendcert@ to @yes@ on the other end. With @leftsendcert=yes@ strongSwan sends its certificate across even if no _certificate request_ was received. This helps to interoperate with some misconfigured peers.

h3. "invalid HASH_V1 payload length, decryption failed?"

*Q:* _I'm getting the error message "invalid HASH_V1 payload length, decryption failed?" when using PSK authentication. What could be the reason?_

*A:* This is most likely due to an incorrect PSK on one of the peers. Since the PSK is incorporated into the key material used so secure the IKEv1 packets they can't be decrypted properly if the PSKs don't match.

Note that the PSK whose associated identities/IPs matches best is used. So if the local identity is configured with every PSK every PSK will basically match to some degree. Which is why only remote identities/IPs should be associated with PSKs.

For IKEv1 the first lookup is always based on the IP addresses (i.e. every secret that lists the local IP will match). If no PSK is found an initiator will use the configured identities for a second lookup. As responder identities can only be used if aggressive mode is used ([[FAQ#Aggressive-Mode|which should never be used with PSK]]). However, if a configuration is found (based on the IPs) a lookup based on the configured identities is done (all matching configs are considered until a PSK is found).

h3. Aggressive Mode

*Q:* _Does strongSwan support IKEv1 Aggressive Mode?_

*A:* Since [[5.0.0|version 5.0.0]] the answer is _yes_. For previous releases, where the IKEv1 protocol was handled by the pluto daemon, the answer is and remains _no_. 

However, the strongSwan developers still recommend to avoid its use with pre-shared keys. This is due to a known weakness of the protocol. With Aggressive Mode, a hash of the pre-shared key is transmitted in clear-text. An eavesdropper can capture this hash and run an offline brute-force attack against it. Once the pre-shared key is known "MITM attacks":http://en.wikipedia.org/wiki/Man-in-the-middle_attack to gather the XAuth credentials can easily be executed. Aggressive Mode is therefore incompatible with the basic principles of the strongSwan project which is to deliver a product that meets high security standards. That's why, in order to use Aggressive Mode with pre-shared keys as responder (i.e. on gateways) it is required to set @charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes@ in [[strongswan.conf]]. As promised often in numerous public and private talks strongSwan then changes its name to *weakSwan*. It is not required to set this option for clients as they often have no other choice.

To avoid Aggressive Mode with pre-shared keys (and other short-comings of IKEv1 Main or Aggressive Mode) the best option is to switch to *IKEv2*. But even for IKEv1 strongSwan [[5.0.0]] now provides an easy to deploy alternative: {{tc(ikev1/xauth-id-rsa-hybrid, hybrid authentication)}}.  This mode uses a certificate to authenticate the gateway and only XAuth to authenticate the client, during Phase 1 (Main or Aggressive Mode) the client is not authenticated.

h3. Public key authentication fails with retransmissions

*Q:* _strongSwan fails to initiate a connection to a peer. I'm using RSA authentication and I noticed the two error messages: @'discarding duplicate packet; already STATE_MAIN_I3'@ on the initiator side and @'max number of retransmissions (2) reached STATE_MAIN_R2'@ on the responder side._

*A:* This problem might be related to the Path MTU (Maximum Transmission Unit). The IKE protocol is transported in UDP datagrams. As result the UDP datagrams also contain the X.509 certificate you are using. Now, if you're using a large certificate the UDP datagram might get bigger than the PMTU. That's the point where IP fragmentation kicks in and cuts your IP packet / UDP datagram in two or more pieces. There are some firewalls out there that strictly block IP fragments and therefore hamper your IKE connection. Large X.509 certificates could result from long Distinguished names or from long RSA keys (2048 bit). As a workaround you can reconfigure your firewall, try to make your certificates smaller or preload the certificates on both sides and thereby get away without transmitting the certificates over UDP.

Since version:5.0.2 strongSwan supports the proprietary IKEv1 fragmentation extension, which can be enabled with the _fragmentation_ option in [[ConnSection|ipsec.conf]].

h3. NAT between Windows L2TP/IPsec clients and older strongSwan servers

*Q:* _I want to set up strongSwan to interoperate with Microsoft Windows using L2TP/IPsec. I'm getting the error message "NAT-Traversal: Transport mode disabled due to security concerns" which results in strongSwan sending an encrypted notification BAD_PROPOSAL_SYNTAX_

*A:* Here is a quote from strongSwan lead developer Andreas Steffen on how to deal with this problem:

> NAT-Traversal with IPsec transport mode has some inherent security risks. Since Microsoft doesn't care about this please compile strongSwan with the option

> <pre>

  ./configure  --enable-nat-transport</pre>

h3. "ignoring CERT_PKCS7_WRAPPED_X509 certificate request" with Juniper device

*Q:* _I'm trying to setup strongSwan to interop with a device from Juniper. The connection setup fails. I found the following message in the log file: @'ignoring CERT_PKCS7_WRAPPED_X509 certificate request payload'@._

*A:* The problem is that Juniper expects strongSwan to send its certificate[s] in CERT_PKCS7_WRAPPED_X509 format which is quite unusual. strongSwan can parse such payloads (e.g. Windows XP sends them if there is a multi-level certificate chain) but currently cannot construct them since there was never a need. We have full PKCS#7 functionality in our scepclient tool but it hasn't be integrated into the pluto daemon.

Are you using a multi-level certificate hierarchy and if yes could you import the root and all intermediate CA certificates statically on your Juniper box? Or just use a simple certificate hierarchy with path length 0?

h3. "next payload type of ISAKMP Message has an unknown value: 33"

*Q:* _I'm trying to set up a connection using a pre-shared key configuration. I get the following error message: @'packet from 10.x.x.30:500: next payload type of ISAKMP Message has an unknown value: 33'@._

*A:* This error message usually points to a difference in the pre-shared key configured on the two server. With the wrong key the receiver is not able to correctly decrypt the incoming traffic. Please check the configured PSKs in [[ipsec.secrets]].

h2. IKEv2

h3. Disabling NAT traversal?

*Q:* _How can I turn off NAT traversal in charon (IKEv2)?_

*A:* NAT traversal cannot be disabled in the charon daemon. If you don't like automatic port floating to UDP/4500 due to the MOBIKE protocol (RFC 4555) which happens even if no NAT situation exists then you can disable MOBIKE by adding

<pre>

mobike=no

</pre> to [[ipsecconf|ipsec.conf]] in the connection definition.

h3. Public key authentication fails with retransmissions

*Q:* _My IKEv2 connection fails with retransmits during the IKE_AUTH exchange when using RSA certificates, but works when a PSK is used. Why?_

*A:* This is probably related to the Path MTU(Maximum Transmission Unit). The IKE_AUTH messages that contain the certificates and certificate requests can get pretty big, therefore, the IP packets transporting these UDP datagrams could get fragmented. Some firewalls might block IP fragments and will therefore hamper your IKE connection.  If you can't configure the responsible firewall(s) to accept fragments you could try to preload the certificates on both sides and then configure _rightsendcert=never_ in [[ConnSection|ipsec.conf]] to prevent the daemon from sending certificate requests. With the default setting of _leftsendcert=ifasked_ the own certificate will not be sent (this could be enforced with _leftsendcert=never_). Using ECDSA instead of RSA will also reduce the size of the IKE_AUTH messages as keys/certificates will be significantly smaller.

Since version:5.2.1 support for the "IKEv2 fragmentation extension":https://tools.ietf.org/html/rfc7383 is available, which can be enabled with the _fragmentation_ option in [[connsection|ipsec.conf]] (the default since version:5.5.1).

h2. General Questions

h3. Capturing outbound plaintext packets with tcpdump/wireshark

*Q:* _When using tcpdump/wireshark to sniff traffic secured by IPsec, incoming packets show up twice: encrypted i.e. as ESP packets and unencrypted as plaintext packets. However, for outgoing traffic, only ESP packets show up. How can I get incoming *and* outgoing packets as plaintext?_

*A:* That's a peculiarity of the Linux kernel. Capture the (UDP encapsulated) ESP packets and use wireshark to decrypt them. See http://wiki.wireshark.org/ESP_Preferences

Run the following command to determine the encryption algorithms and the symmetric keys used by the kernel. Depending on your configuration, strongSwan periodically changes encryption keys. Keep this in mind if you are capturing traffic over an extended period of time.

<pre>

ip xfrm state

</pre>

There's also a [[CorrectTrafficDump|document]] about traffic dumps, that shows the ways to dump different traffic on the IPsec endpoint.

h3. Non-standard IKE ports

*Q:* _Can I use a local non-standard port for IKE?_

*A:* The default socket implementation _socket-default_ can only listen on two, predetermined ports (by default, one is used for NAT Traversal). There are compile time flags and two settings in [[strongswan.conf]] to determine these ports, but clients usually will only use the default ports (500/4500). However, strongSwan as a client can use an arbitrary remote port, which may be configured via _rightikeport_.

There is also another socket implementation called @socket-dynamic@, which is experimental and can send IKE messages from any port (specified with _leftikeport_).

You can also use the @DNAT@ and @SNAT@ targets in iptables to move ports around, if you so desire.

h3. Using strongSwan on an AWS EC2 instance

*Q:* _Can I use strongSwan on an AWS EC2 instance?_

*A:* strongSwan works just fine on an AWS EC2 instances, as in any other virtual machine. If you want to set up a site-to-site or roadwarrior connection, where

the EC2 instance acts as a router, you have to disable the source and destination check of the EC2 instance, additionally to setting up the connection itself, routing and firewalling correctly.

That is because if the source and destination check is enabled (which it is by default), the VPC will drop the forwarded packets, as the source does not match the IP address

of the node that was assigned via DHCP by the VPC.

There is a [[AwsVpc|special article]] about using strongSwan in a VPC with some example configurations.

h3. strongSwan crashes

*Q:* strongSwan sometimes crashes and I don't know why. What should I do?

*A:* If you [[InstallationDocumentation#Compile-yourself|compiled it yourself]], make sure your cleaned the build directory before compiling. If you do not do that, you can end up linking objects of different strongSwan versions together and that can cause crashes. If you don't use the same configure options when building a newer version uninstalling/removing the previous binaries/libraries is required (the same applies if you previously had strongSwan installed from a distribution package). Then recompile it and reinstall it. If the crash persists, use the "search function":https://wiki.strongswan.org/projects/strongswan/search and try to find a similar bug report and read it. If you can not find one, open a new issue on the "issue tracker":https://wiki.strongswan.org/issues. If you are not using the latest version, it is very likely that the crash you experienced was already fixed.

If you installed it as [[InstallationDocumentation#Distribution-packages|binary package]], check the corresponding distribution's issue track for reports or use the "search function":https://wiki.strongswan.org/projects/strongswan/search here and try to find a similar bug report and read it. If you can not find one, open a new issue on the "issue tracker":https://wiki.strongswan.org/issues. If you are not using the latest version, it is very likely that the crash you experienced was already fixed.

h3. Plugin is missing

*Q:* I need some [[PluginList|plugin]], but it seems my version of charon doesn't load it! What should I do?!

*A:* Check if you [[PluginLoad|customized the list of loaded plugins]]. If so, make sure the plugin you need is included (see below for details on modular plugin loading). Then make sure the plugin is actually installed. For that, run @find@ (check the man page of @find@ for the syntax) with the required syntax to search your hard drive for the plugin's _.so_ file. If it exists and is in a plausible directory, then it should be installed. Then restart the daemon.

If your installation of strongSwan is configured for [[PluginLoad#Modular-Configuration|modular loading]] (the default since version:5.1.2) and @strongswan.conf@ includes the _strongswan.d/charon/_ directory, check if the plugin specific configuration file in _/etc/strongswan.d/charon/_ contains @load = yes@ in the plugin specific configuration section. If the file does not exist, the plugin is likely not installed.

If you compiled strongSwan yourself, rebuild it with the required plugins [[AutoConf|enabled]].

If you got strongSwan from the [[InstallationDocumentation#Distribution-packages|repositories of a distribution]], look for additional packages. It is likely the distribution ships the plugin you're looking for in another package. If you still can not find it, search the issue tracker of that distribution for a bug report or feature request that requests the plugin you want. If you found one, weigh in on it, if it is not already closed or a plausible reason was given why the request can not be fulfilled.

If you did not find a bug report of feature request in the issue tracker of that distribution, open one stating your request for the plugin you're looking for to be included.

h3. configuration compatibility with freeswan, openswan and libreswan

*Q:* Are configuration files of freeswan, openswan and libreswan compatible with the ones of strongswan?

*A:* They are not compatible. Although the format of _ipsec.conf_ is identical between the different swans, they files are not compatible, because several options have different meanings and a variety of different

options are absent from some versions and others exist. Do not attempt to reuse configuration files between different swans.