strongSwan

h1. Frequently Asked Questions

*Q:* _I'm trying to set up a VPN tunnel with a [[ZyXELL]]/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.

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

<pre>

*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 Andres 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>

end of quote

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

*A:* Quote from Andreas Steffen: "No, strongSwan does *not* support IKEv1 Aggressive Mode and *never* will. Otherwise we would have called the project "weakSwan". "

*Q:* _strongSwan fails to initiate a connection to a peer. I'm using RSA authentication and I noticed the two error messages:

<pre>

discarding duplicate packet; already STATE_MAIN_I3

</pre>

on the initiator side and

<pre>

max number of retransmissions (2) reached STATE_MAIN_R2

</pre>

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.