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

These algorithms do not directly relate to plugins. To "disable" them, you must specify a set of proposals that exclude those algorithms
in the ike or esp settings of the related conns (or conn default to set defaults for all conns), if you use ipsec.conf or, if you use swanctl.conf, don't set them in connections.<conn>.proposals or connections.<conn>.children.<child>.esp_proposals and connections.<conn>.children.<child>.ah_proposals. Do not set connections.<conn>.children.<child>.ah_proposals, unless you want this CHILD_SA to use the AH protocol instead of ESP or UDPENCAP (if NAT is detected or UDPENCAP is enforced).

If you want to enforce certain (strong) algorithms in the certificate chain of the peer, you can enforce that using the leftauth/rightauth settings in ipsec.conf or in the corresponding local or remote authentication round, if you use swanctl.conf. The details are explained on the man page.
Here is an example for enforcing the use of sha256, sha348 or sha512 in the PKI and to reject any other hashing algorithms. The same can be done for the algorithm of the actual pubkey (RSA or ECDSA).


rightauth = pubkey-sha256-sha384-sha512
rightauth = pubkey-sha256-sha384-sha512-rsa
rightauth = pubkey-sha384-ecdsa

You must not specify several rightauth settings in a conn though. You have to decide on one. If you want to allow several algorithms, just append them to the string, like it is done for the integrity algorithms
in the examples.
The same can be done for leftauth.


If you use ipsec.conf, you have to add an exclamation mark (!) to the end , otherwise the default proposals are appended, which might contain algorithms you do not want to use.

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. An alternative is to use a DROP policy in the configuration with a higher priority
than the "normal" IPsec policies. This approach is only possible by setting the priority of the policies manually
and with the swanctl configuration backend. It is not possible with the ipsec configuration backend.
If you NAT traffic into the tunnel by using DNAT, SNAT or MASQUERADE, the TS of the DROP policy must be adjusted accordingly.
The IPsec SPD or charon don't know about your firewall's NAT rules. The priority of the DROP policy must be higher than the
one of your normal policies. If you do not know the priority of your normal rules, check it with `ip x p. The priorities
of the IPsec policies that charon insert depend on the exact settings of the connection and the TS

connections {
   shunts {
      rekey_time = 0
      local_addrs =
      remote_addrs =

      children {
         # prevent unprotected traffic from any network to the roadwarriors
         drop-rwv4 {
            # internet
            local_ts  =
            # roadwarrior subnet
            remote_ts =
            mode = drop
            start_action = trap
         # enabling policies_fwd_out is necessary for other children to avoid forwarded traffic from getting dropped

In the following example, the REJECT target is used to give the user a clear error message.

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

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.

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, and reload the secrets
    ipsec update and ipsec rereadsecrets, or swanctl -q.

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 does not include the modp1024 group anymore since 5.6.1 and even before that included many stronger
DH groups.

Because of that, a strong group is commonly agreed on (unless the peer insists on using a weak group). strongSwan
supports modp768 to modp8192 and ECDH groups via the openssl and botan plugins, plus x25519 via the curve25519
and botan plugins. If the user did not misconfigure any of the peers, all connections should be secure enough
to withstand the Logjam attack. Windows only uses modp1024 by default, unless explicitly configured via Registry
or PowerShell. Blackberry OS only seems 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.