eap-tls Plugin


The eap-tls plugin for libcharon supports EAP-TLS authentication. EAP-TLS uses a TLS handshake to mutually authenticate client and server (or an AAA backend) based on X.509 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 based 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 plugin is disabled by default and can be enabled with the ./configure option



The EAP-TLS backend uses its own TLS stack shipped with strongSwan. This stack supports TLS versions 1.0, 1.1, 1.2, and 1.3 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, 1.3)



EAP-TLS is configured as any other EAP method. The client uses

connections.<conn>.local.auth = eap

and the server selects EAP-TLS for the client using

connections.<conn>.remote.auth = eap-tls

strongSwan supports AAA servers via RADIUS, i.e.

connections.<conn>.remote.auth = eap-radius

also works in conjunction with EAP-TLS.

By default the VPN 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

connections.<conn>.local.auth = eap

on the gateway side.

Certificates for EAP-TLS are configured the same way as for traditional IKEv2 certificate-based authentication, using the swanctl certificate and key directories as well as the swanctl.conf definitions




on VPN client and gateway, respectively. CRL and OCSP revocation is supported by TLS, too.

For authentication against an AAA backend server, the VPN gateway usually uses a different identity via IKE than the AAA backend via EAP. To specify a different AAA identity on the client use the swanctl.conf attribute


It defaults to the IKEv2 identity defined by


A VPN gateway terminating the EAP-TLS authentication locally may use the aaa_id within EAP-TLS but requires a certificate with such a subject or subjectAltName.

EAP-TLS Options

The eap-tls plugin is configured using the following options in the charon.plugins.eap-tls section of strongswan.conf:

Key Default Description



Maximum size of an EAP-TLS packet



Include length in non-fragmented EAP-TLS packets



Maximum number of processed EAP-TLS packets (0 = no limit)

TLS Options

The eap-tls plugin uses the strongSwan libtls library that can be configured and fine-tuned with the following TLS options.


Figure 1. strongSwan example showing the use of EAP-TLS only authentication.
Figure 2. strongSwan example showing the use of EAP-TLS with AAA server.