Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
The following equipment was used for this section:

Cisco AP 1200 Series (802.11g Radio).

The configuration examples used in this document were tested and made on a Cisco Series 1200 with an 802.11g Radio Module and with the following Cisco software:

IOS Version:
Cisco IOS Software, C1200 Software (C1200-K9W7-M), Version 12.3(8)JA2,

C1200 Boot Loader (C1200-BOOT-M) Version 12.2(8)JA, EARLY DEPLOYMENT RELEASE
Setting the Name and IP address

First, an IP address on the BVI interface (the IP address that this Access Point will have for accessing
resources like the RADIUS server) needs to be configured. Also a unique name for this Access Point (ap1200)
will be configured.

ap#configure terminal
ap1200(config)#hostname ap1200
ap1200(config)#interface BVI 1
ap1200(config-if)# ip address
RADIUS/AAA section

In the authentication, authorisation and accounting configuration parameters (AAA), at least one group needs to
be defined (radsrv), which will be assigned later for the several AAA operations. More groups can be defined if
needed for various purposes; one for authentication, another for accounting, and so on. In this example the
RADIUS server has the IP address

ap1200(config)#aaa new-model
ap1200(config)#radius-server host auth-port 1812 acct-port 1813 key <secret>
ap1200(config)#aaa group server radius radsrv
ap1200(config-sg-radius)#server auth-port 1812 acct-port 1813
ap1200(config-sg-radius)#aaa authentication login eap_methods group radsrv
ap1200(config)#aaa authorization network default group radsrv
ap1200(config)#aaa accounting send stop-record authentication failure
ap1200(config)#aaa accounting session-duration ntp-adjusted
ap1200(config)#aaa accounting update newinfo periodic 15
ap1200(config)#aaa accounting network default start-stop group radsrv
ap1200(config)#aaa accounting network acct_methods start-stop group radsrv
Configuring the SSIDs

For each SSID one dot11 ssid <SSID NAME> must be configured. In this section the default VLAN for the SSID
will be configured as well as the authentication framework, the accounting and, if desired, the SSID to be
broadcast (guest-mode).

ap1200(config)#dot11 ssid eduroam
ap1200(config-ssid)#vlan 909
ap1200(config-ssid)#authentication open eap eap_methods
ap1200(config-ssid)#authentication network-eap eap_methods
ap1200(config-ssid)#authentication key-management wpa optional
ap1200(config-ssid)#accounting acct_methods

More SSIDs can be configured. An open SSID for giving information about the institution and/or how to
connect to the eduroam SSID:

ap1200(config)#dot11 ssid guest
ap1200(config-ssid)#vlan 903
ap1200(config-ssid)#authentication open
ap1200(config-ssid)#accounting acct_methods
The Radio Interface

Now the configured SSID's will be mapped to the radio interface, and it will be specified what ciphers will be
used/allowed on each VLAN. If dynamic VLANs are planned, the ciphers for those VLANs must also be
configured even if there is no direct mapping on any SSID (this example shows the usage of the VLANs 906
and 909 for eduroam users)

ap1200(config)#interface Dot11Radio 0
ap1200(config-if)# encryption vlan 906 mode ciphers aes-ccm tkip wep128
ap1200(config-if)# encryption vlan 909 mode ciphers aes-ccm tkip wep128
ap1200(config-if)#ssid eduroam

To bind extra SSID's the previous command, for each SSID to be bound, needs to be repeated.
The following command sets the maximum time (e.g. 300 seconds, which is recommended) for

dot1x reauth-period 300
VLAN interfaces

For each VLAN to be used for wireless clients, two virtual interfaces need to be defined: one on "the air"
(DotRadio) and another on the "wire" (FastEthernet) then they need to be bridged together with the same
bridge group. These VLANs are always tagged with the proper VLAN identifier.

An administrative VLAN needs to be configured as well (for maintenance/management and
authentication/accounting traffic). This VLAN is usually untagged (the command defining the VLAN has to be
suffixed with the keyword "native") and belongs to bridge-group 1. The Radio virtual interface for this VLAN
does not need to be defined since the default will keep the physical interface (Dot Radio 0) in bridge-group 1.

Because VLANs can be from 1 to 4094 and bridge-groups from 1 to 255, it is not necessary to have the same
bridge-group id as the vlan id.

ap1200(config)#interface dot11Radio 0.903
ap1200(config-subif)#encapsulation dot1Q 903
ap1200(config-subif)#bridge-group 3
ap1200(config)#interface fastEthernet 0.903
ap1200(config-subif)#encapsulation dot1Q 903
ap1200(config-subif)#bridge-group 3
ap1200(config)#interface dot11Radio 0.909
ap1200(config-subif)#encapsulation dot1Q 909
ap1200(config-subif)#bridge-group 9
ap1200(config)#interface fastEthernet 0.909
ap1200(config-subif)#encapsulation dot1Q 909
ap1200(config-subif)#bridge-group 9
The multiple (dynamic) VLAN assignment

The example configuration above did not configure dynamic VLAN assignment. Availability of this feature varies between models of the 1200 Series, so please exercise caution when procuring if you wish to make use of this feature. If multiple VLANs are configured on the Cisco AP, it is mandatory to associate each SSID to at least one VLAN, otherwise the Access Point will not activate the SSID's. It is possible however, to put different users who are connected to the same SSID (e.g. eduroam) on different VLANs based, for instance, on the user profile. To activate this feature it is necessary to enter

 "aaa authorisation network default group radiusgroup"

in the Access Point's configuration. The AP then gives priority to the VLANs returned by RADIUS over the ones statically associated with the SSID. This enables the feature dynamic VLAN assignment.

Cisco's Access Points require that two virtual interfaces (a radio and an Ethernet port interface) are configured for each VLAN. If, for example, four VLANs are to be used for eduroam users (for students, admin staff, teachers and visiting eduroam users from other institutions for example) then it is necessary to define one Dot11Radio0.vlanID, and one FastEthernet0.vlanID, and ensure that both have the same encapsulation dot1Q vlanID and the same bridge-group for each VLAN.

Two commands that are also needed are the below, otherwise the access point will not change the user to the received VLAN:

encryption vlan vlanID mode ciphers aes-ccm

broadcast-key vlan vlanID change 600 membership-termination capability-change

Sample configuration

The required configuration can be downloaded as a file from You must then amend the file as indicated by the comments in the file, and then copy and paste the commands into the Access Point in configuration mode (telnet or console access).

Unable to render {include} The included page could not be found.

Error rendering macro 'excerpt-include'

No link could be created for 'H2eduroam:3.3'.

(obsolete section) Appendix A: RADIUS servers

As the eduroam infrastructure is build upon RADIUS servers, the following picture depicting the message flow
inside an institutional RADIUS server might be helpful.

Figure A 1: Message flow in RADIUS server Identity Management System

A.2.6 User authentication: configuring an eduroam IdP

Configuring an IdP involves:

  • Configuring the server as EAP endpoint.
  • Configuring the local database backend.

EAP configuration happens in the file eap.conf (downloadable from This example, eap.conf file is
configured to accept both TTLS and PEAP requests and process them with the same backend. For a
discussion of when to use TTLS and when PEAP, please refer to section of this document. The
following notes refer to different modules within the file:

  • In the tls section, the server certificate that is presented to the users while they authenticate is defined.
    certdir, private_key_... have to point to the appropriate files on the server. It appears confusing for most
    new administrators that tls needs to be defined even though EAP-TLS is not a desired authentication
    method. This is because the ttls and peap sections share the certificate parameters and rely on the
    existence of the tls stanza. Unwanted EAP-TLS authentication can be prevented by pointing cadir to a
    dummy Certification Authority (like the one that is created on first server startup) which never issues
    proper client certificates.
  • The ttls and peap sections denominate a dedicated virtual server to handle the inner tunnel request
    (which happens after the TLS handshake with the supplicant has completed). Note that there needs to
    be an empty mschapv2 stanza in eap.conf to make PEAP work – this is due to internal server workings
  • To include EAP into the virtual server eduroam (see section A.2.4 "Virtual server definition for eduroam:
    sites-enabled/eduroam"), only two lines need to be added; the new virtual server "eduroam-innertunnel"
    (which we defined in eap.conf before) needs be set up to do the actual user authentication, and
    the module eap must be listed at the end of the authorise and authenticate sections.:
    server eduroam-inner-tunnel {
    	authorize {
    	authenticate {
    		Auth-Type LDAP {
    		Auth-Type PAP {
    		Auth-Type MS-CHAP {
    	preacct {
    	accounting {
    	session {
    	post-auth {
    		Post-Auth-Type REJECT {
    	pre-proxy {
    	post-proxy {
    The most notable difference between the inner server and the outer is that the inner tunnel does not do
    EAP. Instead, it uses the ldap module in the authorize and authenticate sections to authenticate users
    against the ldap backend. Note that the ldap module is configured in radiusd.conf. You have to enter
    the appropriate connection details to your LDAP server there and open firewall ports from the RADIUS
    server to the LDAP server if need be.

Also note that this virtual server does not call the suffix module. This means the inner request does not
get proxied elsewhere. This is a standard security measure in eduroam.

The virtual server definition also includes the files module. When doing LDAP authentication, this is
optional. In the example file, we use this module to have test users in the flat file "users" in order to
have a possibility of debugging authentication. Once the authentication against the file works and the
LDAP connection is set up properly, the files module is only needed for advanced topics like VLAN

• For an initial setup of the users file, administrators should delete all existing entries and add only the
following line in the file:

test@domain.tld Cleartext-Password := "hackme"

This creates a test user with the name "test@domain.tld" and a password. It can be used to test authentication.

  • In case a VLAN assignment should be done, the users file needs to contain the corresponding RADIUS
    attributes, like in the following example for VLAN 313:
    DEFAULT <assignment conditions here>
    	Tunnel-Type = VLAN,
    	Tunnel-Medium-Type = IEEE-802,
    	Tunnel-Private-Group-Id = 313
  • The configuration of the ldap module itself happens in radiusd.conf. This config stanza is extensively
    documented in the file, so below just a simple example of a sample configuration (based on an
    eduPerson LDAP schema).
modules {
	ldap {
		server = "localhost"
		identity = "cn=RADIUS,dc=domain,dc=tld"
		password = "<secret for identity dn>"
		basedn = "ou=student,dc=domain,dc=tld"
		filter = "(eduPersonPrincipalName=%{User-Name})"
		start_tls = no


  • If logging of accounting requests to a database is desired (see below), it is also wise to extend the
    accounting key in the acct_unique module to make accounting more robust.
acct_unique {
	key = "User-Name, Acct-Session-Id, Calling-Station-Id, Called-Station-Id, NAS-IP-Address, NAS-Port"

A.2.7 Setting up accounting in the SQL database

All accounting information is logged into the MySQL database. The configuration is in the file
/etc/raddb/sql.conf. The content of this file should be replaced with that found in

A.2.8 Logging the client IP address as Service Provider (Optional)

The client IP address is logged in the DHCP log file. However this information can also be stored in the
ACCOUNTING table with other accounting data and thus provide easy access to that data. A Sysadmin needs
to set-up a script to update the SQL database information with the assigned IP address. The client IP address
is determined by tailing the DHCP log file and monitoring all IP assignments. The script also monitors active
connections and cleans up accounting (closes accounting) for stale connections. SNMP access to Access
Points is required.

The script is available from here:

The access points need to be registered with the script. This is done by entering the needed access point data
into the database:

USE radius;
create table access_points (
           `IP address` varchar(100) PRIMARY KEY NOT NULL,
           `snmp secret` varchar(100) NOT NULL default '',
           `radius secret` varchar(100) NOT NULL default '',
           `root username` varchar(100) NOT NULL default '',
           `root password` varchar(100) NOT NULL default ''

A.2.9 More information

The original Slovenian Eduroam technical specifications and sample configuration site:

ARNES AAI technical support e-mail address:

FreeRADIUS files:

Eduroam-in-a-box web configuration tool:

(obsolete section) Appendix B: Access Points

This section describes the configuration of the Access Points:

  • Cisco Aironet 1200 series.
  • Lancom L-54.

These Access Points have been used extensively by JRA5 activity members, and so their configuration and
suitability for eduroam are well established.

B.1 Cisco Aironet 1200 Series example setup

The required configuration can be downloaded as a file from You must then amend the file as
indicated by the comments in the file, and then copy and paste the commands into the Access Point in
configuration mode (telnet or console access).

B.2 LANCOM L-54 Series Access Points

This series of Access Points offers a wide range of features for a mid-range price. One of the outstanding features in its price class is the ability to use ARP sniffing to determine a client's IP address even if it changes during a user session. Activating this feature fulfils the requirement for MAC to IP correlation from the confederation policy and obsoletes logging of DHCP leases.

The following steps are needed to set up eduroam on a Lancom L-54 or L-300 series access point. It describes the setup via the web interface and is current as of LCOS Version 8.0. The starting point of this tutorial is a factory-reset device, i.e. it is not configured at all and set up to its defaults.

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
Once the chosen EAP method is configured and the IdP RADIUS server is connected to the authentication backend, the next step is to provision the access configuration to the actual end users.

Many operating systems support IEEE 802.1X and EAP authentication, but the user interfaces in supplicants differ significantly. For some supplicants, manually clicking through a series of GUI pages is the only option. This is sometimes tedious for end users.

If possible, an IdP administrator should prepare pre-configured packages which contain the necessary information to securely connect to eduroam:

  • the SSID: "eduroam"
  • the crypto setting: WPA2/AES
  • the EAP type setting
  • the CA that issued the eduroam IdP server's EAP server certificate
  • the Common Name in the eduroam IdP server's EAP server certificate

The following sections describe a series of tools that can be used to create such auto-installers. The use of one these windows 10 drivers update  is recommended, because it will likely have a positive effect on user uptake, and reduce helpdesk load.

eduroam CAT

Many client platforms are supported by eduroam CAT. Please see the documentation; or visit the production website at



XpressConnect (Cloudpath)




Devices that are compatible with eduroam

The following list is sorted alphabetically by vendors. The table notes which EAP methods are supported. Legend:

CAT - this device/EAP type combination is supported by eduroam CAT; can probably also be configured securely manually

Yes - the device can be configured securely manually for this EAP type

Deficient - the device lacks important security features, but workarounds exist which can make its use safe

Insecure - the device can be configured manually for this EAP type, but not all security parameters can be set up

No - device is known not to support IEEE 802.1X/EAP

? - Unknown

TPS - supported with Third-Party Software (possibly commercial)


Compatibility Matrix

Device/OS Vendor







tested on:

Samsung Galaxy S2

Huawei Sonic u8650


tested on:

Motorola Xoom2




iOS 4.0+






iOS 4.0+





iPod touch

iOS 4.0+




AppleMac OS X10.7+CATCATCATYesNo?Yes
AppleMac OS X10.4-10.6Yes[4]Yes[4]Yes[4]Yes[4]No?Yes[4]
BlackberryPlaybook OS2Yes?????


LinuxNetworkManager CATCATCATCATNo??
Linuxwpa_supplicant CATCATCATCATYes[2]YesYes
















MicrosoftWindows8 / 8.1CATCATCATCATCAT?


MicrosoftWindows Phone7.xNoInsecure[3]?No???
MicrosoftWindows Phone8.xNoDeficient[1]?????


Symbian OS

Series 6




NokiaSymbian OS9.xYesYes?Yes?YesNo
SonyPlaystation3 (PS3)allNoNoNoNoNoNo


SonyPlaystation4 (PS4)allNoNoNoNoNoNo


YollaSailfish OS2YesYes Yes Yes???

[1] Installation and pinpointing of CA possible; verification of expected server name (CN) not possible. A secure configuration is only possible if the Identity Provider deploys a private CA which issues exclusively server certificates for his own eduroam EAP servers. All other Identity Provider deployments are INSECURE.

[2] Version 1.0 or higher required

[3] Verifying that the server is signed by the proper CA is not possible; this means users will not be able to detect fake hotspots and might send their username/password to an unauthorised third party.

[4] Only with 10.6.x (Snow Leopard) and later does OSX allow the configuration of of CA/server trust settings (Pinning 802.1X to specific CA and RADIUS server CommonName)

Reporting a new device

Please let us know in the "Comments" field what device you have, and what EAP method(s) you have found working. We will update the list periodically.

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
  • No labels