EAP-TLS authentication

Starting with strongSwan 4.5.0, charon supports EAP-TLS authentication. EAP-TLS uses a TLS handshake to authenticate client and server (or an AAA backend) mutually with certificates.

While EAP-TLS is a secure and very flexible protocol, it is rather slow when used over IKE. Depending on the fragment and certificate size, it requires 6-10 additional IKE exchanges compared to traditional IKEv2 certificate authentication. But there are other reasons to use EAP-TLS, such as Windows 7 smartcard authentication or if you require certificate authentication against a centralized AAA backend server.

As EAP-TLS authenticates the client and the EAP server mutually, it is possible to skip IKEv2 server authentication and use the EAP-only authentication mechanism.


The EAP-TLS backend uses its own TLS stack shipped with strongSwan. This stack supports TLS versions 1.0, 1.1 and 1.2 and has been tested against:

- OpenSSL 0.9.8 server via FreeRADIUS EAP-TLS (TLS 1.0)
- Windows 7 client via IKEv2 EAP-TLS (TLS 1.0)
- Windows 7 client via IE9 (TLS 1.0, 1.1, 1.2)
- GnuTLS server via Apache mod_gnutls (TLS 1.1)
- NSS client via Firefox 3.6.8 (TLS 1.0)
- Self (TLS 1.0, 1.1, 1.2)


To enable EAP-TLS, pass --enable-eap-tls to the ./configure options.



EAP-TLS is configured as any other EAP method. The client uses leftauth=eap, the server selects EAP-TLS for the client using rightauth=eap-tls. strongSwan supports AAA backend servers via RADIUS, rightauth=eap-radius also works in conjunction with EAP-TLS.

By default, the Gateway uses IKEv2 certificate authentication to prove its identity to the clients. But as EAP-TLS is a mutual authentication protocol, EAP-only authentication can be used by specifying leftauth=eap.

Certificates for EAP-TLS are configured the same way as for traditional IKEv2 certificate authentication, using ipsec.d/cacerts, ipsec.secrets and leftcert=/rightcert=. CRL and OCSP revocation is supported in TLS, too.

If a Gateway uses different certificates for IKEv2 and for EAP-TLS authentication, the EAP-TLS certificate may be loaded using the leftcert2= keyword.

For authentication against an AAA backend server, the Gateway usually uses a different identity in IKE than the AAA backend in EAP. To specify a different AAA identity on the client, the new aaa_identity ipsec.conf keyword has been introduced. It defaults to the IKEv2 identity defined with rightid. A Gateway terminating the EAP-TLS authentication locally may use the aaa_identity within EAP-TLS, but requires a certificiate with such a subject/subjectAltName.

EAP-TLS options

The EAP-TLS plugin has an option in strongswan.conf to control the fragment size:

charon {
  # ...
  plugins {
    eap-tls {
      fragment_size = 512

The default fragment size is 1024 bytes.

TLS stack options

There is usually no cipher suite configuration required, the TLS stack enables all secure algorithms that it has registered crypto backends for. Depending on the plugin configuration, the TLS stack supports the following cipher suites:

ECDHE and ECDSA require a third-party crypto backend. Since 5.9.2, EdDSA may also be used with ECDSA cipher suites. ECDHE support is limited to the named curves SECP256R1, SECP384R1, SECP521R1, SECP224R1 and SECP192R1 with uncompressed points. Since 5.9.2, Curve25519 and Curve448 are also supported. CAMELLIA encryption requires either the openssl or gcrypt backend.

NULL encryption is automatically disabled if the stack is used for purposes other than EAP-TLS where only the handshake of TLS is used.

The minimum and maximum TLS versions may be configured via libtls.version_min and libtls.version_max in strongswan.conf.

To limit the cipher suites by algorithms, there are three strongswan.conf options:

libtls {
  key_exchange = ecdhe-ecdsa, ecdhe-rsa, dhe-rsa, rsa
  cipher = aes256gcm, aes128gcm, chacha20poly1305, aes256, aes128, camellia256, camellia128, null
  mac = sha384, sha256, sha1

Only cipher suites using the specified algorithms are enabled.

To specify the list of suites directly, use the suites option and a comma separated list of the cipher suites above:

libtls {

Since 5.9.2, the ECDH groups and signature schemes may be configured with:

libtls {
  ke_group = curve448, curve25519, ecp521, ecp384, ecp256, ecp224, ecp192
  signature = ed448, ed25519, ecdsa_sha521, ecdsa_sha384, ecdsa_sha256, rsa_pss_rsae_sha512, rsa_pss_rsae_sha384, rsa_pss_rsae_sha256, rsa_pkcs1_sha512, rsa_pkcs1_sha384, rsa_pkcs1_sha256