10.9. Radius Relay

Overview

The cOS Core feature RADIUS Relay is designed for telecom scenarios, such as Mobile Data Offloading (MDO), where User Equipment (UE), such as a smartphone, switches from an operator's wireless network to communicating using WiFi via an Access Point (AP). The AP connects the UE to resources, such as the Internet, via a Clavister firewall with the firewall controlling this access.

To gain access to the resources behind the firewall, the UE must authenticate itself via the AP using a RADIUS server. A RADIUS authentication request is sent to cOS Core by the AP which relays it to a RADIUS server. The server's reply is relayed back to the AP and authenticated users are entered into the cOS Core user list so that they can then be granted access to resources based on cOS Core security policies.

Event Sequence During RADIUS Relay Authentication

The following sequence of events occurs with radius relay:

  1. The UE requests network access from an AP.

  2. The AP sends a RADIUS Access-Request to cOS Core. Providing the cOS Core radius relay feature has been set up, this request is forwarded to the configured RADIUS server.

  3. The RADIUS server either authenticates or does not authenticate the UE by sending a RADIUS Access-Accept or Access-Reject message back to cOS Core. The content of these messages is examined by cOS Core as they are relayed back to the AP.

  4. If it is authenticated by the RADIUS server, the UE issues a DHCP request and a DHCP IP lease from the configured cOS Core DHCP server is sent back to the UE.

    The DHCP server must be configured so that leases are only be distríbuted to authenticated clients (the LeasesRequireAuth option is enabled).

  5. Successful authentication also means that cOS Core includes the UE's username in its list of logged in users (visible with the CLI userauth command and through the Web Interface) and this allows the UE access to resources determined by predefined cOS Core security policies.

Using Group Membership

cOS Core security policies can be based on group membership where the UE's membership in a group determines if access is allowed. If this is the case, the RADIUS server must be specially configured to send back the group name of the user during authentication. In addition, RADIUS servers communicating with cOS Core must have the Vendor ID set correctly. Doing this is described further at the end of this section.

It is also important that the IP policy that allows access by the UE must use a User Group object as Source User Group. The User Group object must contain the same group name sent back by the RADIUS server. Doing this is described further in Section 10.4, IP Policies Requiring Authentication.

If validation with group membership is not required then the pre-defined Anyone User Group object can be selected as Source User Group on the IP Policy's advanced filter.

A symptom that the group name has not been specified correctly on the Source User Group object is that the connection will be dropped after the Idle Timeout period of the RADIUS Relay object has elapsed, even though traffic has been flowing during that time.

[Important] Important: Enable the DHCP server LeasesRequireAuth option

If RADIUS relay is being used in the cOS Core configuration, all DHCP servers must be configured to only distribute leases to configured clients. This is done by enabling the LeasesRequireAuth property in the CLI and in the Web Interface or InControl, enabling the option Distribute leases only to RADIUS relay authenticated clients.

If this is not done on all DHCP servers, irrespective of whether they are used with RADIUS relay or not, it could possibly create a security vulnerability and allow an unauthenticated client access to protected resources.

Radius Relay Object Properties

The important properties of a Radius Relay object are the following:

Separate Authentication and Data Traffic

It is strongly recommended to set the property Override User Data Interface to the interface used only for the data traffic so that it is different from the interface assigned to the Source Interface property for the authentication traffic. Typically, they will be set to two different VLAN interfaces which will run over the same physical Ethernet interface and which is connected to the AP. This will fully separate the authentication data going to the RADIUS server from the data flowing to the backbone network. Not doing this will pose a security risk.

The following should be noted when using the Override User Data Interface property:

Example 10.10. Configuring Radius Relay

This example shows how to configure a Radius Relay object for the scenario illustrated below. Here, client devices (UE) must access data services through a backbone network via an Access Point (AP). First, they must be authenticated against a RADIUS server and then allocated an IP address. The AP is connected to the physical If1 Ethernet interface of a Clavister firewall and the backbone network is connected to the If2 interface.

The following assumptions are made:

  • Two VLANs are already configured and these cOS Core objects are called vlan_auth for client authentication traffic and vlan_data for data traffic flowing to the backbone.

  • Both these VLANs are already set up to run over the physical Ethernet interface If1 and that the AP has also been correctly configured to use the appropriate VLAN for authentication and data.

  • Authenticated users must belong to the group called ue_group.

  • A Radius Relay object called r_relay1 will be created which will listen for authentication requests on the vlan_auth interface and relay them to a RADIUS server with the IPv4 address radius_ip. The scenario is illustrated in the diagram above.

  • After successful authentication, IP address leases will be handed out by a DHCP server object called rr_dhcp_server. It is assumed that the UEs will be allocated addresses belonging to the network 192.168.10.10-192.168.10.254 that will be defined in an IPv4 address object called client_ip_range.

  • After successful authentication, UEs will be granted access to a backbone network on the If2 interface using an IP policy called client_access_rule.

Command-Line Interface

A. Create the IP4Address object that defines the range of client IP addresses for the UEs:

Device:/> add Address IP4Address client_ip_range
			Address=192.168.10.10-192.168.10.254

B. Create the User Group object and assign to it the group called ue_group:

Device:/> add UserGroup MyGroup
			Members=ue_group

C. Create the DHCPServer object that hands out these addresses:

Device:/> add DHCPServer rr_dhcp_server
			Interface=vlan_data
			IPAddressPool=client_ip_range
			Netmask=255.255.255.0
			LeasesRequireAuth=Yes

D. Create the IPPolicy object that grants access for client data flowing to the backbone network which is connected to the interface If2:

Device:/> add IPPolicy Name=client_access_rule
			Action=Allow
			SourceInterface=vlan_data
			SourceNetwork=client_ip_range
			DestinationInterface=If2
			DestinationNetwork=all-nets
			Service=all_services
			SourceUserGroup=ue_group

E. Create the RadiusRelay object:

Device:/> add RadiusRelay r_relay1
			SourceInterface=vlan_auth
			ClientIPFilter=client_ip_range
			RemoteServerIP=radius_ip
			DHCPServer=rr_dhcp_server
			OverrideUserDataInterface=vlan_data

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

A. Create the IP4Address object that defines the range of client IP addresses for the UEs:

  1. Go to: Objects > Address Book > Add > IP4 Address
  2. Now enter:
    • Name: client_ip_range
    • IP Address: 192.168.10.10-192.168.10.254
  3. Click OK

B. Create the User Group object with the "ue_group" as User Auth Group member:

  1. Go to: Objects > General > User Group > Add > User Group
  2. Now enter:
    • Name: MyGroup
    • User Auth Groups: ue_group
  3. Click OK

C. Create the DHCPServer object that hands out these addresses:

  1. Go to: Network > Network Services > DHCP Servers > Add > DHCPServer
  2. Now enter:
    • Name: rr_dhcp_server
    • Interface: vlan_data
    • Interface Filter: client_ip_range
    • Netmask: 255.255.255.0
  3. Select the Options tab and enable the option:
    Distribute leases only to RADIUS relay authenticated clients
  4. Click OK

D. Create the IP Policy object that grants access for client data flowing to the backbone network which is connected to the interface If2:

  1. Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
  2. Now enter:
    • Name: client_access_rule
    • Action: Allow
  3. Under Filter enter:
    • Source Interface: vlan_data
    • Source Network: client_ip_range
    • Destination Interface: If2
    • Destination Network: all-nets
    • Service: all_services
  4. Under Advanced Filter enter:
    • Source User Group: MyGroup
  5. Click OK

E. Create the RadiusRelay object:

  1. Go to: Network > Network Services > RADIUS Relays > add > RADIUS Relay
  2. Now enter:
    • Name: r_relay1
    • DHCP Server: rr_dhcp_server
    • Source Interface: vlan_auth
    • Client IP Filter: client_ip_range
    • Remote Server IP: radius_ip
    • Override User Data Interface: vlan_data
  3. Click OK

[Note] Note: Configuring the RADIUS server to send the group name

In the above example, it is that assumed the group name ue_group will be sent back by the RADIUS server during authentication. The RADIUS server must be configured to do this.

When configuring the external RADIUS server to provide group information for the logged in user to cOS Core, it is necessary to use the Clavister-User-Group vendor specific attribute. The Clavister Vendor ID is 5089 and the Clavister-User-Group is defined as vendor-type 1 with a string value type.