Security Recommendations

There are different important topics when working with IPsec, strongSwan or policy based tunnels.

Broken Algorithms

Algorithms that are broken in regards to security and must not be used.

  • DES
  • 3DES
  • CAST
  • MD5
  • SHA-1
  • MODP512
  • MODP768
  • MODP1024

Tunnel Shunting

As IPsec on Linux is usually policy based, there is no tunnel interface, over which packets are routed.
Instead, XFRM policies and states transform the packet transparently.

Note that any traffic, for which there is no matching IPsec policy, will not be subject to IPsec processing.
This can cause traffic leakage into your LAN and into the attached WAN. Such a scenario can occur, when your
site-to-site tunnel is configured with auto=add, auto=start or start_action=none (swanctl specific)
and your firewall rules do not drop packets, which should be protected with IPsec but aren't.

Usually, it is highly undesired to let such traffic just pass.
Take care to shunt the connections correctly using the policy match module in iptables.

It is strongly advised to use auto=route in site-to-site setups to make sure that the kernel tells strongSwan
to establish a CHILD_SA when there's no SA for a security policy. It is advisable to take a look at the
strongswan.conf setting charon.ignore_acquire_ts when doing this.

RFC1918 networks and others, which are not allowed to be used on the public Internet, must not
occur in the source or destination fields of an IP packet. A suitable method to prevent that is to use an
iptables rule, that rejects or drops packets with such a destination without a matching IPsec policy,
using the policy match module. In the following example, the REJECT target is used to give the user a
clear error message.

Generally, it is important to understand how iptables/Netfilter work together with XFRM to design suitable firewall
rules that protect your network in case tunnels go down or can not be brought up. When NAT is brought into the discussion,
it can be impossible to design a general rule in iptables that just drops the unprotected packets and specific rules need to be inserted
for your specific NATed addresses.

iptables -A FORWARD -d -m policy --pol none --dir out -j REJECT --reject-with icmp-admin-prohibited

Of course, there are more networks than, which fulfill the aforementioned criteria,
including IPv6 subnets. More information on these address ranges can be found in e.g. RFC 1918,
RFC 3927 and RFC 6890.

Cipher Selection

The available ciphers for IKE depend on the crypto modules loaded in the IKE daemon charon. For kernel
processing of ESP and AH packets, the available ciphers depend on the kernel support for them and if
they are supported by XFRM or PF_KEY.

It is advised to adhere to the recommendation of the appropriate security authority when choosing ciphers
to secure the tunnel cryptographically. lists some of the standards for western Europe
and the US. It is strongly advised to use at least 2048 bit key length for MODP Diffie-Hellman groups.

The NIST has mandated, that a minimum cryptographic strength of 128 bit is sufficient for security beyond
the year 2030. This results in the following cipher set:

aes128-sha256-modp3072 (AES-CBC-128, SHA-256 as HMAC and DH key exchange with 3072 bit key length)

For systems without support for SHA-256, SHA-1 might be used instead. SHA-1 must not be used as anything else than a HMAC for IKE.

Alternatively, the Suite B cipher suites defined in RFC 6379 may also be used where supported:

aes128gcm16-prfsha256-ecp256 (AES-GCM-128 AEAD, SHA-256 as PRF and ECDH key exchange with 256 bit key length)
aes256gcm16-prfsha384-ecp384 (AES-GCM-256 AEAD, SHA-384 as PRF and ECDH key exchange with 384 bit key length)

The supported IKE cipher suites are limited to what strongSwan and the different plugins implement.
The supported ESP/AH cipher suites are limited to what the kernel supports, except if you're using libipsec.
If you use libipsec, you can use all supported ciphers for IKE also for ESP.

List of supported IKEv1 cipher suites
List of supported IKEv2 cipher suites

Preshared Keys (PSKs)

A strong alternative to PSKs is the use of RSA and ECDSA keys
PSKs are usually a lot shorter than RSA keys and have a lot less entropy, so cryptographically speaking
they often are a lot weaker than RSA keys. Therefore, to securely use PSKs, they have to be very long and
random. A good way to generate strong PSKs is to Base64-encode data from /dev/urandom (the output of
the following command can be used with the 0s prefix in ipsec.secrets):

dd if=/dev/urandom count=1 bs=32 2>/dev/null | base64

If the PSK is leaked, an attacker can mount a man-in-the-middle attack to impersonate either side and
intercept the traffic over the tunnel.

PSK authentication and aggressive mode

Aggressive mode is inherently flawed, as a hash of the PSK is transmitted in the clear, which an attacker
can use to attack the PSK using an offline dictionary attack. It is strongly advised to avoid aggressive mode.

Authentication with RSA and ECDSA keys

strongSwan supports the use of RSA and ECDSA keys for authentication.
This provides a middle ground between PSK and certificate based authentication.
  • Cryptographically stronger than PSKs
  • More resistant to MITM attacks

In contrast to a VPN with PSK authentication, where an attacker can perform
a MITM attack when the PSK is known, when RSA or ECDSA keys are used,
the attacker requires the private keys of both sides to perform a MITM attack.

The weakness is, that only few implementations support this and that the setup is
a little bit more involved. The keys do not contain any information about the
identity of the peer, so you need to specify what peer authenticates with what
public key. This necessitates that a connection is specified for each identity
and that the public key of a remote peer is known beforehand. These are the same restrictions
you already have with PSK authentication.

Steps to set it up

For this, you can use either openssl, ipsec pki or any other tool that can generate a RSA or ECDSA key.
  1. generate a private key with a minimum cryptographic strength of 128 bit on each peer
    Each of these commands generate a RSA key with 4096 bit length:
    ipsec pki --gen -s 4096 --outform pem > foobar.key
    openssl genrsa -out foobar.key 4096
  2. generate the corresponding public key to the private key
    Each of these commands generates the public key of the key given in the file foobar.key.
    ipsec pki --pub < foobar.key >
    openssl rsa -in foobar.key -pubout >
  3. distribute the public key to each peer via a secure channel.
  4. Set up your own RSA or ECDSA key in ipsec.secrets (or swanctl.conf)
    using the : RSA <filename> or secrets.rsa<suffix>.file keywords, respectively.
  5. set up the public key in ipsec.conf or (swanctl.conf)
    If you are using the old ipsec.conf format, you can also specify the public keys
    directly in ipsec.conf by using the syntax described on the manpage of ipsec.conf
    or the documentation about the page.
    The leftsigkey and rightsigkey can be used in ipsec.conf
    and connections.<conn>.local<suffix>.pubkeys and connections.<conn>.remote<suffix>.pubkeys
    in swanctl.conf.
  6. update or reload the configuration
    ipsec update or swanctl -c.

Certificate based authentication

Certificate based authentication is inherently stronger than PSK based authentication. Certificates are
usually cryptographically stronger and support trust delegation through certificate authorities.

A properly built CA architecture has one root CA and a sub CA, where the sub CA is used to sign other sub
CAs and the root CA is kept safe in a disconnected system or on a secure smartcard. The root CA key is
never stored on an insecure or online system. Securing the root CA enables the user to revoke any certificate
and create the structure from scratch, if any sub CAs are compromised.

Certificate Revocation Lists (CRLs) and the Online Certificate Responder Protocol (OCSP) can be used to
check if a given certificate is revoked for some reason. strongSwan supports local CRLs, as well as fetching
of new CRLs and OCSP information through fetcher plugins (like curl) and the revocation plugin.

CDPs are taken from the certificate or can be added manually using a ca section in ipsec.conf.

CAs should be signed using at least SHA-256. SHA-1 is deprecated and considered broken. MD5 is antique and
broken, too. All CAs must conform to the X.509 standard of the ITU-T.

Perfect Forward Secrecy (PFS)

PFS is a must have for every IPsec tunnel. Using PFS will make the endpoints negotiate a new key for each
IKE and/or IPsec SA upon rekey or reauthentication event. This protects the confidentiality of the traffic,
if the IKE shared secret is leaked. Note, that the keys of the first SA of a new IKEv2 connection are derived
from the IKE shared secret. However, subsequent SAs will use new keys if PFS is used.

PFS for strongSwan 5.x onwards is enabled by appending a DH group to the ESP or AH cipher settings. Using
PFS introduces no significant performance overhead, unless you rekey more than 80 IPsec SAs per second.
Refer to this document for the crypthographic strength and public key handshake speed on some example


Judging from information made public by Edward Snowden, the NSA tries to break IPsec connections, which
are authenticated using PSKs, by using brute force or by searching for matching PSKs in intercepted private
communication, for instance, PSKs mentioned in emails between companies or their admins, router
configurations, and so on. The NSA attacks the PSK with a brute force attack, if it is believed to be weak enough.
To counter the threat, PSK authentication should be avoided and strong DH groups should be used for both IKE
and ESP/AH. Use this document for guidance.

Besides attacks on PSKs, the main attack vector on an IPsec server is compromising the host, where the NSA
uses a rootkit to alter the structure of ESP packets or the strength of the keys, so they can be deciphered
by their interception systems.


LogJam is an attack, that breaks the Diffie-Hellman exchange between the two peers using a brute force attack
on it. To allow it, a weak DH group (with a size of less or equal to 1024 bit) has to be used. strongSwan's default
proposal includes the modp1024 group, however, also longer and therefore stronger groups are contained in it.

Because of that, a strong group is commonly agreed on. strongSwan supports modp768 to modp8192 and ECDH
groups via the openssl plugin. If the user did not misconfigure any of the peers, any connection should be secure
enough to withstand the Logjam attack. Windows and Blackberry OS only seem to support the modp1024 group,
which means that those connections are inherently insecure.


Because of the attack called SWEET32, 3DES and BLOWFISH are now considered insecure.
Use AES instead. 3DES and BLOWFISH use a block size of 64 bits. That enables birthday attacks on the encrypted data packets.
AES uses a block size of 128 bits, which is secure.