History

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.

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.

Session-Timeout and Dynamic Authorization Extension¶

Release 4.6.3 introduces support for the RADIUS Session-Timeout attribute and the Dynamic Authorization extension, RFC 5176.

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

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 section in the eap-radius configuration:

dae {
  listen = 0.0.0.0  # listen address, default to all
  port = 3799       # port to listen for requests, default
  secret = xxx      # shared secret to verify/sign DAE messages
}

RADIUS attribute forwarding¶

Starting from version 4.6.3, 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:

forward {
  ike_to_radius = Reply-Message, 11
  radius_to_ike = 36906:12
}

Both options define a comma separated list of RADIUS attributes to forward in each direction. Attributes can be defined by name or attribute number. The number in front of a colon defines a Vendor-Specific attribute to forward.

An IKE peer can use the radattr plugin to provide/print such attributes.

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
        }
      }
    }
  }
}

strongSwan

Documentation¶

Resources¶

Wiki