History

UserDocumentation »

EAP-Radius

The eap-radius plugin does not implement an EAP method directly, but it redirects the EAP conversation with a client to a RADIUS backend server. On the gateway, the EAP packets get extracted from the IKE messages and encapsulated into the RADIUS protocol, and vice versa. The gateway itself does not need special support for a specific EAP method, as it handles the EAP conversation between the client and the RADIUS backend more or less transparently.

The eap-radius plugin currently handles authorization only, no accounting operations are performed.

RADIUS servers

The plugin should work with any RADIUS server, we tested it successfully with FreeRADIUS and the NPS Server included with Windows Server 2008 R2.

For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys; Unfortunately, FreeRADIUS before 2.1.10 did not include these attributes when used with EAP-MSCHAPv2.

Installation

To compile strongSwan with the eap-radius plugin, add 

--enable-eap-radius
to the ./configure options.

Configuration

To let a connection definition in ipsec.conf use the RADIUS backend server, define

  rightauth=eap-radius

in the corresponding section (assuming right is remote).

Configuration for the RADIUS plugin itself is done in strongswan.conf, in the section

charon {
  plugins {
    eap-radius {
       ...
    }
  }

Basic configuration

Starting with version 4.4.1, the plugin supports multiple servers. The configuration format has slightly changed (but the old format is still supported).

To define a RADIUS backend server, add a new section to the servers subsection with a name of your choice:

servers {
  server-a {
    address = 1.2.3.4
    secret = R4diu5-shared-$ecreŧ
    # nas_identifier = ipsec-gateway
  }
}

The address parameter specifies the RADIUS server IP address or DNS name. The secret is used to authenticate the packets exchanged with the RADIUS server.

In untrusted networks, make sure to use a strong secret with enough entropy. This secret might be subject to dictionary attacks.

The nas_identifer (default: strongSwan) identifies the gateway against the RADIUS server and allows it to enforce a policy, for example. If you need an UDP port different from the RADIUS default (1812), use the port option.

Accounting

Starting with release 4.6.2, strongSwan supports RADIUS accounting. It is disabled by default and can be enabled using the accounting option. A non-standard port can be specified using the acct_port option in the server section. The new auth_port option is an alias for the port option.

accounting = yes
servers {
  server-a {
    address = 1.2.3.4
    auth_port = 1812   # default
    acct_port = 1813   # default
  }
}

Currently strongSwan sends Start and Stop Accounting requests. The Start message contains the Username and Framed-IP attributes, the Stop message additionally Session-Time, Input-Octets and Output-Octets. Gigaword attributes are sent if requried.

Parallel RADIUS sessions

The EAP exchange over RADIUS might need several packets, and depending on the RTT, several fractions of a second. As a single RADIUS client port can handle only one concurrent authentication session, multiple client ports can be used to do parallel authentication for high load scenarios.

The per-server sockets option (default: 1) defines the number of pre-allocated sockets to use. A value of 5 allows the gateway to authentication 5 clients simultaneously over RADIUS.

Multiple servers

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

The used server for an authentication session is selected randomly. If a server is under load (that is, 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 if it becomes available again.

Preferring servers

With the preference paramter 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 if it is 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:

  • 0: Default, fair selection based on server load
  • 1: Prefer the server, as long as it is completely unloaded
  • 50: Prefer the server, unless more than half of the sockets are in use
  • 99: Always prefer the server, unless no sockets are currently available
  • 101: Always prefer the server, unless it gets unreachable

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

Identity exchange

The 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

  eap_identity=test@example.com

in an ipsec.conf section.

To do an EAP-Identity exchange with the client and ask for an EAP-Identity, set

  eap_identity=%identity

Another option is to let the RADIUS server itself initiate the EAP conversation by sending an EAP-Start message. Set eap_start = yes 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 gateway.

The id_prefix option in the same section 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).

Group selection

The plugin optionally interprets the class attribute sent in the RADIUS-Accept message as group membership information. An ipsec.conf configuration with

  rightgroups="sales@strongswan.org, finance@strongswan.org"

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 class_group in the eap-radius plugin subsection must be set to yes.

Example configuration

ipsec.conf

# ....

# sales and finance have access to some servers only
conn sales-finance
  # ...
  leftsubnet=10.0.1.2/32,10.0.4.5/32
  # require groups specified as Distinguished Name. As the groups are
  # specified with commas, separate the RDNs with slashes.
  rightgroups="O=strongswan/OU=sales,O=strongswan/OU=finance" 
  rightauth=eap-radius
  # request EAP-Identity
  eap_identity=%identity
  auto=add

# research has access to testing lab
conn research
  # ...
  leftsubnet=10.0.2.0/24
  rightgroups="O=strongswan/OU=research" 
  rightauth=eap-radius
  eap_identity=%identity
  auto=add

strongswan.conf


charon {
  plugins {
    eap-radius {
      class_group = yes
      eap_start = no
      servers {
        primary {
          address = radius1.strongswan.org
          secret = $ecreŧxyz
          nas_identifer = ipsec-gateway
          sockets = 20
          # use secondary only if overloaded/non-responsive
          preference = 99
        }
        secondary {
          address = radius2.strongswan.org
          secret = $ecreŧabc
          nas_identifer = ipsec-gateway
          sockets = 5
          # uses custom RADIUS authentication port
          port = 12345
        }
      }
    }
  }
}