eap-radius Plugin

The plugin supports multiple RADIUS servers. To define a RADIUS backend server, add a new section to the servers subsection with a name of your choice

The EAP exchange over RADIUS might need several packets and depending on the RTT (Round-Trip-Time) will take several fractions of a second to complete. As a single RADIUS client port can handle only one concurrent authentication session, multiple client ports can be used to do parallelize authentication for high load scenarios.

The per-server sockets option with default [1] defines the number of pre-allocated sockets to use. A value of 5 allows the gateway to authenticate 5 clients simultaneously over RADIUS.

Multiple RADIUS servers can be defined for high availability or load sharing purposes. Use additional sections in the servers subsection and configure the individual servers accordingly.

The server used for an authentication session is selected randomly. If a server is under load (i.e. one or more of the defined sockets are in use), the server is degraded in the election process. If a server is unreachable it is further degraded. From time to time a previously non-responsive server is reused to automatically reintegrate it when it becomes available again.

With the preference parameter of a server, priorities for specific servers can be defined. This allows to use a secondary RADIUS server only if the first gets unresponsive or overloaded.

A reachable server gets a priority value between 110 and 210, proportionally to the current use of its sockets (higher is better). Previously unavailable servers get a value of 0-100, only. The defined preference value is added to the calculated priority. Servers with the same calculated value will be elected randomly. The following preference values result in:

Defining a preference of 110 and more is not a good idea, as such a server may always win the election process even if it is not available.

A received Session-Timeout from the RADIUS backend is enforced using Repeated Authentication.

The Dynamic Authorization Extension allows a RADIUS backend to actively terminate a session using a Disconnect-Request or change the timeout of a session using a Session-Timeout attribute in a CoA-Request. The extension is enabled using a dae subsection in the eap-radius configuration:

The following RADIUS attributes are forwarded to clients in corresponding IKE configuration attributes (more details about the attributes can be found in the docs on the attr plugin):

Microsoft DNS/NBNS Servers (defined in the Microsoft namespace 0x000137)

Cisco DNS/NBNS Servers (defined in the Altiga namespace 0x000c04)

Cisco Unity Extensions for IKEv1 (defined in the Altiga namespace 0x000c04)

Arbitrary RADIUS attributes can be forwarded from/to the IKE peer using custom IKEv2 notify payloads. The notify uses the strongSwan specific private notify 40969. Forwarding is configured in a eap-radius subsection called forward:

Both options define a comma separated list of RADIUS attributes to forward in the corresponding direction (ike_to_radius or radius_to_ike, respectively). Attributes can be defined by name or attribute number. The number in front of a colon defines the namespace or Private Enterprise Number (PEN) of a vendor-specific attribute to forward.

An IKE client can use the radattr plugin to provide or print such attributes.

The eap-radius plugin starts the conversation with the RADIUS server directly with an EAP-Identity response using the IKEv2 identity of the peer. To enforce a different identity in this exchange, set

in swanctl.conf. To trigger an EAP-Identity exchange with the VPN client and ask for an EAP identity, set

Another option is to let the RADIUS server itself initiate the EAP conversation by sending an EAP-Start message. Set

in the eap-radius section of strongswan.conf to initiate the conversation with EAP-Start. This kind of operation is not supported by all RADIUS servers. Don’t forget --enable-eap-identity if you use EAP-Identity exchanges initiated by the VPN gateway.

The id_prefix option in the eap-radius section of strongswan.conf prepends a prefix to the negotiated identity. This is useful, as some RADIUS servers interpret such a prefix as a request for a specific EAP method (e.g. 0 as EAP-SIM, 1 as EAP-AKA).

The plugin sends the IKE identity (or EAP identity if the IKE daemon is instructed to do an EAP-Identity exchange) as User-Name attribute to the RADIUS server. As described in the previous section, that same identity is also sent as EAP-Identity response in the first Access-Request message if eap_start=no is configured (the default).

However, whether that identity is validated in any way depends on the RADIUS server’s behavior and configuration. For instance, whether it enforces a match against the client certificate if EAP-TLS is used, or whether it uses it as a lookup key to find a password in case of EAP-MD5/MSCHAPv2. If it doesn’t, the IKE daemon can’t trust that identity.

Moreover, with eap_start=yes, the RADIUS server may perform its own EAP-Identity exchange. This identity can be completely unrelated to the IKE identity that’s passed in the User-Name attribute (e.g. with Windows clients that send their IP as IKE identity). And the IKE daemon won’t know about this even if the RADIUS server changes the User-Name attribute in the Access-Accept reply as the plugin currently doesn’t process this attribute.

Therefore, switching connections or basing other policy decisions on the IKE/EAP identity (e.g. in a script or plugin like ext-auth or whitelist) is potentially unsafe when RADIUS servers are involved. Instead, consider using group selection based on attributes provided by the RADIUS server in the Access-Accept message. However, unless validated, the RADIUS server shouldn’t base this attribute assignment on the User-Name attribute either, but instead use e.g. information extracted from the verified client certificate.

The plugin optionally interprets the class attribute sent in the Access-Accept message as group membership information. A swanctl.conf configuration with

is acceptable only if the RADIUS server includes one of the two groups in the class attribute. As this behavior is not standardized, the boolean flag

in the eap-radius plugin subsection must be set.

Alternatively, the Filter-Id and Tunnel-Type attributes may be used for group selection. If the option

is enabled in the eap-radius plugin subsection and the Tunnel-Type attribute contains an arbitrary one-byte tag, followed by the value 9 in the remaining three bytes in network order which signifies IPsec with ESP in tunnel mode, the value of the Filter-Id attribute will be applied as group name to the IKE_SA.

Here is an example configuration with two RADIUS servers defined in the eap-radius section of strongswan

The eap-radius backend supports multiple XAuth rounds. It initiates multiple XAuth exchanges and for each one the client shows a dialog with an appropriate message. All replies get concatenated to the User-Password attribute, which gets verified over RADIUS.

The number and kind of rounds is configured by so called authentication profiles. You can have multiple profiles defined, each in its own subsection of the eap-radius.xauth section:

This example defines three XAuth profiles, the pinprofile just asking for a PIN, the passandcode profile asking for both a password and a passcode, and the passandcodegerman doing the same in German language. In the latter two, the two answers get concatenated and it is up to the AAA server to correctly verify this answer.

Valid XAuth types to request are: password, passcode, nextpin and answer. For the strongSwan VPN gateway or the AAA server these types are not relevant but the client may show different dialog types (along with the configured message).

To use the configured profiles, you’ll have to refer to them in the connection definitions of swanctl.conf. To do so, append the profile name, separated by a colon, to the xauth-radius method in the remote auth configuration:

The native iOS and macOS clients are known to work fine with multiple authentication rounds.