Implementing eduroam Roadmap - Part 2

Download as PDFDownload as PDF

Page updated 25/07/2022

On this page sections 8 - 11:

  1. Firewall configuration to permit RADIUS servers to work with NRPS
  2. Acquire shared secrets and add your ORPS into the eduroam(UK) RADIUS Infrastructure using Support Server
  3. RADIUS Server Proxying to Support a Visited Service and Attributes Filtering
  4. RADIUS Server configuration to support Home User Auth Exchanges on Campus/Roaming and Attributes Filtering

See Part 1 for sections 1 - 7:

  1. Concepts and terminology
  2. Deciding your service type and planning your eduroam implementation
  3. Choose RADIUS server platform and plan connectivity for ORPS
  4. Joining eduroam(UK) and selecting your realm
  5. The eduroam Support Server website; input organisation/site details, realm name, test account
  6. Install your RADIUS Server (ORPS)
  7. Acquire server certificate for ORPS/NAS

See Part 3 for sections 12 - 20:

  1. Wi-Fi service and establishment of a VLAN/network service for eduroam
  2. Firewall configuration to support eduroam network service
  3. RADIUS server software configuration for Home service / interoperation with user database
  4. DNS Name Server Configuration - NAPTR record
  5. Test facilities on eduroam Support Server / Visitor Test / Testing a new ORPS
  6. RADIUS server log keeping and interpretation of logs
  7. Monitoring your own service
  8. Workstation/Laptop Setup/MS Vista issue
  9. Q.A. test of your eduroam implementation

See Part 4 for sections 21 - 23:

  1. Promote eduroam at your organisation - your eduroam web site
  2. Keep your configuration details data on the eduroam Support server up to date
  3. Planning Ahead and Developing your eduroam Implementation

Part 2

8. Firewall configuration to permit RADIUS servers to work with NRPS

The next step is to ensure  that your RADIUS service will be able to communicate with the national RADIUS Proxy servers through your firewall.

RADIUS communication is based on the User Datagram Protocol (UDP). In early RADIUS deployments port 1645 was utilised, but RFC 2865 officially assigned port number 1812 and this is the port that RADIUS servers listen on in eduroam. Therefore your firewall must be configured to allow UDP communication with all of the eduroam (UK) National Roaming Proxy Servers.

The NRPS also perform ICMP probes to your ORPS, as does the eduroam(UK) Support server. This is to check for and monitor basic network connectivity. By exception, Cisco ACS systems with CSA hardening reject ICMP and so TCP probes on port 2002 can be used instead.

a) Firewall configuration to allow UDP for ORPS-NRPS RADIUS/ICMP for Support server:

The firewall protecting your ORPSs must be configured to permit RADIUS communication between the three eduroam(UK) NRPSs and your ORPS(s) using the following protocols on the port numbers indicated:

  • UDP/1812 inbound and outbound (used for authentication)
  • ICMP
  • ICMP must also be permitted for eduroam New Support server        2001:630:1:7:5bd:5f3e:bb1c:6f27

IP Addresses of the NRPS:

  • Roaming0          2001:630:1:128::185
  • Roaming1            2001:630:1:132::34
  • Roaming2            2001:630:1:133::50

The address of the eduroam(UK) Support server:

  • New Support server        2001:630:1:7:5bd:5f3e:bb1c:6f27

Historical notes: old implementations of RADIUS used UDP/1645 inbound and you would only permit inbound on this port if your ORPS required this (1645 was deprecated may years ago since this conflicts with the 'datametrics' service). Nb. Old eduroam Support server  was at  2001:630:1:5::62  (no longer required).

Note: FreeRADIUS can under extreme load burst proxied auth requests to ports other than 1812. FreeRADIUS 2 used to use UDP/1814 in these circumstances but FR 3 uses various random ports now. There may be some circumstances in which you would need to open additional UDP ports on your firewall, but the Tech Spec specifies that auth requests sent to the NPRS MUST be via port 1812.

b) Firewall configuration to not reject fragmented UDP packets: 

To eliminate a potential cause of problems, your firewall should be configured to allow UDP packets from the NRPSs without any restriction on packet size or fragmentation state. This is because certain EAP methods (EAP-TLS) and RADIUS server configurations result in the generation of very large RADIUS messages and UDP packets (due to the length of user/server certificates) and it is common for such packets to be fragmented by routers during transit. It is vital to the RADIUS exchange that these fragments are not discarded - a RADIUS exchange may comprise a dozen or more messages each of which may consist of multipe UDP packets and since UDP is connectionless, the loss of a single packet will result in the whole authentication attempt having to be re-started from the beginning.

Firewall discard/reject fragmented UDP packets rule:

  • No not apply reject (allow UDP fragment packets)

[Hint - If you are using Solaris ipf firewall the config script can be written to pass fragments using the keep frag keyword]

It is technically possible with some RADIUS implementations, in the RADIUS IdP config., to adjust the default maximum UDP packet size to be used for the RADIUS exchange, thereby reducing the possibility of fragmentation by routers in the transmission path. However, due to  capability limitations of some RADIUS servers and overseas IdPs being outside UK authority, it would not be sensible for us to make RADIUS packet length recommendations. Instead, the eduroam(UK) policy focusses on firewall rules such that any UDP packet to or from the NRPS must be permitted without fragmentation/size restriction.

c) RADIUS server configuration to managing UDP packet size - this may need to be done after configuration of RADIUS policies:

Whilst this guide recommends configuring firewalls to not reject UDP packet fragments, it cannot be guaranteed that all UK member organisations will configure their firewalls in this way, so your users roaming to a site where the firewall rejects fragmented UDP may experience authentication problems. The chances of experiencing difficulties increases the further your users roam, particularly outside of the UK where eduroam(UK) has no influence over deployments. In addition, the more data links and routers that the user's authentication packets have to traverse before reaching your RADIUS server, the greater the possibility is that fragmentation will be applied and fragmentation-unfriendly routers will be encountered. So the aim should be to reduce the chances packets being fragmented en-route to/from your RADIUS server - and this can be achieved by reducing the negotiated size of the UDP packets.

The default maximum transmission unit (MTU) size that a number of RADIUS servers and clients use for EAP payloads is 1500 bytes, but this size of payload results in the maximum size Ethernet frame and consequently a high risk of being fragmented by routers as it traverses multiple links in the path. There are exceptions to this - Cisco ISE has a fixed 1,002 byte maximum. It is therefore recommended that you check the value your RADIUS server is using and adjust it to a reasonable value if possible. With some RADIUS servers this is pre-set at a modest size and is not adjustable. But on others, the MTU can be changed.

How to adjust the MTU - for RADIUS there is the Framed-MTU attribute which is defined in RFC 2865, but "This Attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that value, but the server is not required to honor the hint." Neither the Cisco ISE nor the Microsoft NPS RADIUS servers take any notice of any Framed-MTU attribute recieved from a client device in an Access-Request!  

Aruba ClearPass - the default value of default maximum transmission unit (MTU) is 1100. This should be fine in most cases. You can modify the relevant 802.1X Authentication Profile using the WebUI. Select your users profile and change the settings for the parameter Framed MTU. This sets the framed MTU attribute sent to the authentication server. Click Pending Changes. and in the Pending Changes window, select the check box and click [Deploy changes].

Cisco ISE - you do not need to worry about trying to adjust the EAP payload size, indeed, it is not possible to change the maximum packet size. ISE always tries to send e.g. EAP-TLS fragments (usually Server Hello with Certificate) that are 1002 bytes long (although the last fragment is usually smaller). Even if a client should send a Framed-MTU attribute in an Access-Request it will not be honoured. It is not possible to reconfigure ISE to send larger EAP fragments.

Microsoft NPS - the default maximum transmission unit (MTU) used for EAP payloads is 1500 bytes. Whilst NPS ignores Framed-MTU in an Access-Request from a client, you can add a Framed-MTU attribute and set its value via the Network Policy that is handling the authentication of your users - and that Framed-MTU will be used by NPS to manage the size of the packets sent back to your remote user. The Microsoft documentation suggests setting a value of 1344 or lower. Suggested value - 1100.

  • Go to Network Policies and in the Details pane double-click the policy that you want to configure (e.g. local authentication)
  • In the policy Properties dialog box, click the Settings tab
  • In Settings, in RADIUS Attributes, click Standard.
  • In the details pane, click Add. (The Add Standard RADIUS Attribute dialog box opens.)
  • In Attributes, scroll down to and click Framed-MTU, and then click Add. (The Attribute Information dialog box opens.)
  • In Attribute Value, type a value equal to or less than 1344. (Suggested value: 1100) Click OK,
  • Click Close, and then click OK.


(Old TechNet reference:

d) Testing Port 1812 firewall transit and NAT/PAP if applicable: you can verify that port 1812 is open through your firewall and any NAT/PAT translation (if applicable) is working by using the visitor simulation authentication test on the Support server, with eapol_test, optionally together with packet capture on your RADIUS server (eg tcpdump for linux/BSD/unix or Wireshark on Windows). eapol_test is now available (courtesy of eduroam(UK)) as a Windows executable. When you run the visitor authentication tests you will also be able to see the requests logged on your RADIUS server and also there will be entries in the Support server RADIUS logs view. For info on how to run the test, jump to part 2 section 15 of this guide.

Nb. Once you have configured RADIUS forwarding and EAP authentication methods as described in the next section and section 13 respectively, you will be able to make use of the further authentication/certificate tests on Support server - which, if they are successful prove that you have UDP/1812 enabled.

9. Acquire shared secrets and add your ORPS into the eduroam(UK) RADIUS Infrastructure using Support Server

In this step you will add your ORPS to the NRPS RADIUS configuration as a Client and add the NRPS to your ORPS RADIUS config as Authenticators - this readies your ORPS to support a Visited service which requires sending authentication requests to the NRPS

Adding your ORPS into the eduroam infrastructure to support Visited service interaction: (Not applicable to Home-only deployments  - which make no provision for visitors). You now need to peer your ORPS(s) with the NRPSs so that RADIUS messages can be exchanged for eduroam visitors to your campus. (Wi-Fi/network configuration is covered in section 12 below). Configuration of your ORPS for the support of a Home service for your roaming users is detailed in section 11, but you may combine the RADIUS peering operations at this stage if you wish. 

With respect to setting up a Visited service, since a there are two ends of a RADIUS conversation there are two operations:

  1. Addition of your ORPS to the RADIUS clients configuration of the NRPSs - so the NRPS accept RADIUS packets from your ORPS
  2. Addition of the NRPS to the RADIUS proxy/authentication servers (remote RADIUS servers) configuration of your ORPSs - so your ORPS can send RADIUS packets to the NRPS

The first operation is completed by you registering your ORPS via the eduroam(UK) Support Server portal. Your ORPS details will be added to the NRPS configuration file and that will be uploaded to the NRPSs at the next hourly configuration refresh. RADIUS server peering requires mutual trust and this is achieved through the use of shared secrets. In eduroam(UK) each NRPS-ORPS pair shares an alphanumeric key. The shared secrets for the NRPS are generated when you begin the registration process. You will need to copy each key and paste this into your RADIUS server configuration. 

As stated in section 6, your ORPS needs to have a public facing IP address and a fully qualified domain name i.e. an address record in DNS. Your ORPS will be configured in the NRPS clients and AuthBy tables with their IP addresses, but you need to provide us with the FQDNs. This reduces scope for error, facilitates IPv4 and v6 support and enables you to change the IP address in the future with a single click and save on Support Server.

9.1 Adding your first ORPS via Support Server Portal and Acquire your Shared Secrets

Log in to Support Server: via

Click on the 'Configure' tab.

In the green 'RADIUS servers' panel click on the [Add server] button. A popup box will appear which will enable you to add the necessary details of your ORPS and you will see the unique shared secrets that are generated when the form is opened. You will need to copy each key and paste this into your RADIUS server configuration for the NRPS. 

Entered your required settings - see able below. When complete and you have clicked on the 'Save' button at the bottom of the form, the details will be added to the ORPS config file on Support and at the next hourly NRPS config update, will be propagated to all three NRPS. Therefore new additions and subsequent ORPS status changes can take up to one hour to take effect! The updated configuration is loaded into the NRPS in the order: Roaming0, Roaming2 then Roaming1, with there being a few minutes between RADIUS reloads to ensure continuity of service.

Enter ORPS configuration details required:

IP connectivity

Fully qualified domain name:  The fully qualified domain name of the RADIUS proxy server.
You cannot use the IP address
This field is mandatory. Be sure to update your DNS zonefile to include the server and think about the TTL which will be important if you ever change the IP address
The IPv4 and IPv6:  These are automatically populated Support server performs DNS lookup when you click on one of the address fields
Authentication port:  Default value is 1812 This field is mandatory. The NRPSs listening on this port for authentication requests from your ORPS. For legacy reasons you have the option to change the RADIUS communication port, but strongly advise use of the default 1812. The only alternative port allowed is 1645

RADIUS settings

Copy shared secrets: Relevant when you register multiple ORPS: Default is 'none' i.e. new unique secrets.
You can choose an existing ORPS to copy the secrets from
When you have an existing ORPS you have the option to copy shared secrets from that ORPS. This is useful with clustered servers if all members of a cluster need to have the same shared secrets. To prevent accidents, you cannot change the shared secrets for an existing server, but you can certainly delete and recreate it with new or copied secrets
Shared secrets: Cut and paste into your config for the NRPSs You need these to configure your ORPS to authenticate against the NRPS
Authenticate requests (role of your ORPS): Default is Client only (sends auth requests to NRPS).
Tick if this ORPS is an authenticator too (processes auth requests)
Tick this box if this ORPS can/should authenticate requests from your roaming users. If this is not selected, the server will only be able to forward authentications for visiting users to the NRPS, but will not be used as authenticating server (Client only)
Test and development: Tick to set ORPS as test/dev Select this if you have a live service and the server you are adding is for testing only and should not handle production traffic. The NRPS will then only forward test realm traffic to it. The test realm is in the format of test.yourrealm.tld and does not need to exist in DNS
Disabled: Tick to set ORPS as inactive If you mark a server as disabled it will be removed from the NRPS configuration, however all settings and the shared secrets will be kept on the support server so they can be reinstated later

Server information

Server (host)name: Short name A short name for this server which should be unique within your own set of ORPSes
Server operating system: Choose from drop down list This data allows us to tailor the options you see in this portal and assists us in supporting your system both in response to support requests and pro-actively
Operating system version: Enter OS s/w version As above
RADIUS software name: Choose from drop down list As above
Software version: Enter RADIUS s/w version As above

When complete, click on [Save].

You will see the new ORPS listed in the 'In production' box in the RADIUS servers panel - unless you ticked 'Test and development'. By clicking on this or any other ORPS you create, the the details will be displayed in a popup box. You can view the shared secrets and edit the ORPS settings and details. You must hit the [Save] button if you wish to save any changes. 

Note that you may see a 'Status server' tick box when the edit ORPS popup is displayed. You should only see this option if your platform supports it. If you have configured status server on your ORPS you should tick this box. Support Server will then check that the it gets a status server response from your ORPS. Since enabling status server without it actually being operational on your ORPS would prevent service, you cannot enable this setting without a successful test outcome (if the test fails the box is de-selected).

Your ORPS will be added to the NRPS client configuration on the next scheduled update. This occurs approx 6 minutes past the hour every hour.


  • Status-Server: If your ORPS supports it and you wish the NRPS to use Status-Server to check the operational status of your ORPS, tick the box. Status-Server packets very helpfully allow a RADIUS server to determine whether or not another server is alive should no response be received to Access-Request packets. Some RADIUS platforms (FreeRADIUS, Radiator, radsecproxy) support this - if yours does then opting to use this will be beneficial. For further information see: Status-Server Advisory.  Nb. This function was suspended (Sept 2016) on Support Server v 1 and is planned to be reintroduced in Support Server v2.
  • Test/Development: Relevant to organisations which already have an operational service and wish to peer a new additional OPRS with the national proxies. Servers marked as test/dev will not receive production or eduroam test/monitor traffic; only 'anyuser'@test.'your_realm' traffic will be sent to the test/dev ORPS. This enables you to carry out your own testing - which you must initiate through your production ORPS.
  • Note that there is no Accounting port field: (The port that the RADIUS server is listening on for accounting requests). The value of the port for accounting messages is fixed.

9.2 Add the NRPS as remote RADIUS proxy servers/authenticators on your ORPS

To complete the process of peering your ORPS with the NRPS (for a Visited service) you must add all three NRPS as RADIUS servers on all of your ORPS systems. (The process of peering for a Home service is covered in section 11). 

Configuration details are different for each RADIUS software platorm, generally entail i) defining each remote RADIUS server ii) defining a remote RADIUS group iii) adding the servers to the group iv) setting the weighting/fail over order. You should use the IP addresses as follows, but you may use hostnames: ( ; ( ; (  

(Hint, Microsoft NPS: i) Under (NPS) - Templates Management > Shared Secrets > New RADIUS Shared Secret Template - template name=roaming0 (1) (2), select Manual, enter secret from Support server. ii) Under (NPS) - RADIUS Clients and Servers (folder) > Remote RADIUS Server Groups > 'New' to create a new group, name it e.g. 'NRPS', and [Add] the NRPS IP addresses for all three NRPS; click on Authentication/Accounting tab, select Shared Secrets template, tick 'Request must contain message authenticator attribute, untick 'Forward network access server notifications to this server' [OK]; click on Load Balancing tab and set Load Balancing 33; set timeouts and backoff as per 10.2 (e) below. See section 14 p45 of NPS guide).

(Hint, FreeRADIUS: edit proxy.conf. Nb. If you use hostnames rather than IP addresses in your proxy configuration it is recommended that you add the hostnames and IP addresses of the NRPS to the hosts file rather than relying on your ORPS doing a DNS lookup. This eliminates one potential issue - and ensures that the ORPS are able to send auth requests even if there's a problem with DNS).

The NRPS clients configuration must be set to use UDP ports 1812 (authentication) - accounting is no long supported on the NRPS. The NRPS will not listen on anything other than the proper RADIUS port 1812. If your ORPS needs to use ports 1645/46 (inbound), these should also be configured - the NRPS will send on these if you have set the configuration so, as detailed in section 9 above.

The shared secrets with the NRPS are generated by the Support web site, as described above.

Accuracy is essential when transcribing the shared secrets to the configuration files. It should be remembered that these are used independently to validate and encrypt client (NRPS remote authentication) and proxying (visitor authentication forwarding from ORPS) connections. An error in one of the shared secrets can lead to confusing problems such as i) remote authentication working whilst visitor authentication fails ii) unreliable performance due to authentication failure occuring when one NRPS is utilised whilst successful authentication is achieved through the others.

The following applies to Microsoft NPS and IAS implementations only - it is essential for these systems. When setting up the NRPS as clients in Win2008 NPS it is essential to check that the Vendor Name for the three NRPS is set to ‘RADIUS Standard’ and not ‘Ascend Communications’ in the NPS/RADIUS clients and servers/RADIUS clients configuration tree in the Server Manager. Open Server Manager, navigate down Roles/Network Policy and Access Services/NPS/RADIUS Clients and Servers/RADIUS Clients. The RADIUS clients pane will display the IP Address and Vendor Name (Device Manufacturer) that has been set. Device Manufacturer should be ‘RADIUS Standard’.

In the case of IAS, even if the Client-Vendor name is correctly set in the NRPS client properties to RADIUS Standard, Access-Requests containing Operator-Name will still be dropped. The solution is a little more involved and it is necessary to modify an IAS database file as below. It is however essential that MS IAS sites carry out this fix at the earliest opportunity.

  1. Stop the IAS Service
  2. Make a backup copy of c:\windows\system32\ias\dnary.mdb
  3. Open c:\windows\system32\ias\dnary.mdb in MS Access
  4. Open the 'Attributes' table
  5. Scroll down to attribute number 126
  6. Change the Name to Operator-Name
  7. Change the Syntax to String
  8. Close Access, and start IAS

The dnary.mdb file can be copied to another machine for editing if you do not have Access on your IAS server.

These instructions and the background to this requirement are described in the following Janet Advisory:

Janet Advisory: MS IAS and NPS Operator-Name RADIUS attribute issue (Nov 2010) - notification of critical issue affecting participants that have implemented Microsoft IAS and NPS ORPS - urgent action required.

Setting up your ORPS to forward/proxy RADIUS authentication requests is covered in section 10.

9.3 Adding a Second/any Further ORPS

Register additional ORPS: additional ORPS can be added to the clients config of the NRPS by following the same steps as described above.  It is now quite common practice for organisations to deploy multiple ORPSs, which they may do for resilience or load sharing. You can add as many ORPS as you wish. 

Once an ORPS has been added the NRPSs will automatically communicate with it. NRPS send all traffic to the first ORPS in their config list until it stops responding, the NRPS then try the next ORPS in the list. The order of preference is the order which the ORPS were added to the Support server. (Feature not supported on Support Server 2 - If you want any particular ORPS to be your primary server, set the 'High priority' option on its config on the Support server, as indicated in section 9.1. We may be able to re-introduce this in the future.)  

Test/dev feature: The Support server includes a feature to enable you to connect additional ORPS prior to bringing them into production service. This is achieved through the 'test/dev' setting described above, but full details of this feature can be found in the technical documents section -

Shared secrets for your additional ORPS: Normally every ORPS has a unique set of shared secrets for peering with the three NRPS. This is best practice and the most secure way of employing shared secrets. This remains true even in scenarios in which peered realms contain multiple RADIUS servers.  When an organisation registers a second ORPS, by default a further unique set of shared secrets is generated, different from those for the first ORPS. eduroam administrators must be aware that in deployments where the ORPS form fail-over clusters you cannot simply use the original three shared secrets on both ORPSs by default.

Cloning secrets from an existing ORPS for your additional ORPS: We recognise that there are particular solutions which use and require a common shared database for all clients and so require the same shared secret for each NRPS to be used by all ORPSs. Where two ORPS are deployed in fail-over systems that use the same set of secrets for each ORPS-NRPS proxy/client config. (ie ‘secret0’ for roaming0 for both ORPSs, ‘secret1’ for roaming1 for both ORPSs, ‘secret2’ for roaming2 for both ORPSs). 

When registering your second or subsequent ORPS, as described in the table in section 9.1 above, in the RADIUS settings box, from the drop down option list for 'Copy shared secrets' (default 'none'), select the existing OPRS whose shared secrets you wish to copy for your new ORPS.

If you have previously registerd ORPS with different sets of shared secrets, it is not possible to retrospectively change the secrets yourself via the Support portal. However, we can on request adjust the secrets manually in the database on Support server, (ie we will duplicate the settings for one of your ORPS). If this is required, please submit a service request advising us of the ORPS that has the seed shared secrets and to which ORPS you want the seeds copied.

10. RADIUS Server Proxying to Support a Visited Service and Attributes Filtering 


The next step is to configure handling of authentication requests arising from visitors and forwarding these to the NRPS. This should be implemented in a good neighbourly way to avoid adversely impacting the load on the NPRS and also to ensure that your own service is not adversly affected by poorly configured Home organisations. 

Visited service - Configuring your ORPS to handle local campus authentication requests from your visitors: You will need to configure realm handling and forwarding of authentication requests from your wireless LAN from the eduroam SSID to the NRPSs. (Nb. this is not applicable to Home-only deployments - which have no local Wi-Fi component).  

  • Configure Realm Handling, Proxying and Load Balancing
  • Configure Attribute Filtering
  • Configure Rejection of Malformed Usernames
  • Configure Injection of Operator-Name Attribute (FreeRADIUS, Radiator, Aruba ClearPass, latest Cisco ACS/ISE only)

10.1 Visited service - Configuring your ORPS to forward authentication requests from your visitors on campus to the NRPS

This step is to configure your ORPS to handle auth requests from network APs/controllers, from the eduroam SSID, for Visitors. Such auth requests must be forwarded to the NRPS: You need to configure the handling of RADIUS Access-Request packets from your network NAS systems (APs, WLCs and [if you support wired .1X connection] switches) by your ORPS. The aim is to handle Access-Request packets arising from your users authentication requests locally while Access-Requests arising from visiting users need to be forwarded to the NRPS servers. How you go about achieving this is dependent on the RADIUS platform you have deployed. FreeRADIUS and Radiator use unlang script language/PERL and in the case of FR, virtual servers which are dedicated to particular tasks and which can be tuned for best performance, whilst Microsoft NPS and Cisco ACS/ISE require policies to be defined and configured via GUI; Aruba Clearpass requires a 'service' to be defined and configured using the GUI. 

Since there are so many RADIUS servers to choose from, it is beyond the scope of this guide to provide detailed instructions for all the possible solutions. Nevertheless we have produced a configuration guide for Microsoft NPS and there are links to other guidance in the resouces section. You will also find links to these in the green Library panel on the Troubleshoot page of the Support server portal. 

(Hint, Microsoft NPS: Create a Connection Policy for Visitors and if regex expression condition is matched, forward to NRPS server group).

Authentication of your own users should be considered as a separate logical process from Access-Request packet handling/'proxying'. This is covered later in section 13.

To save having to revisit this part of your configuration at a later stage, it is worthwhile tackling the issue of dealing with badly-formed usernames during this setup stage. Due to the huge number of users of eduroam and explosive growth over recent years, this is an important topic. Dealing with badly formed usernames applies to both local authentication of your own users and forwarding of auth requests for visitors. The object of filtering invalid realms is covered in the separate advisory document Filtering of Invalid Realms. How put this into practice with FreeRADIUS is covered below in section 10.3 and for Microsoft NPS the Microsoft NPS 2008R2 config to avoid bad usernames flooding NRPS document and in the eduroam(UK) NPS Implemention Guide to be published shortly.

If using FreeRADIUS it is recommended you review our FreeRADIUS Demystified seminar material. [Configuration will include editing your proxy.conf file to define your local realm and editing the authorize section of radiusd.conf to program the proxying logic. More details in section 10.3 below.] When setting up a FreeRADIUS server we'd recommend you run the server in full debug mode (freeradiusd -X  or radiusd -X depending on whether it was installed by APT or from source) to enable you to see exactly what is going on for each packet and the decisions/checks the server is making as you develop the configuration.

How requests are handled and how different RADIUS server modules should authenticate and authorise the users must be configured.

10.2 Visited Service Considerations - Request Proxying, RADIUS server timeouts and Load Balancing

a) (Advisory applicable only to FreeRADIUS and Radiator) - it is possible to set up your ORPS to be too "open" with regard to forwarding authentication requests, which can make interpretation of logs very difficult. A unsatisfactory situation can arise if your ORPS is configured to forward requests based on inner identities in addition to forwarding based on the mandatory outer ids. The default on FreeRADIUS is too open and should be closed down. By default Radiator is fine, but it is possible to set up undesirable forwarding based on inner id.

b) Only error-free authentication requests should be forwarded to the NRPS. So for example if your ORPS receives a RADIUS packet with a bad EAP-Authenticator then that packet should be dropped at your ORPS. Bad EAP-Authenticators can arise if internal NAS systems on your network (APs and WLCs) have incorrect shared secrets with your ORPS. If the NRPS receives an Access-Request containing a bad EAP Message-Authenticator, the packet will be dropped and an error entry will be made in the NRPS log. This is potentially a very serious situation since your systems could flood the NRPS with bad packets - which will result in us applying a block to your ORPS.

c) The order in which your ORPS communicates with the three NRPS should be considered. Many participants are tempted to order the three NRPS in the order: roaming0, roaming1, roaming2. The effect of this would be that roaming0 becomes the most heavily loaded of the three national proxies. In order to ensure the best responsiveness for your ORPS and to help avoid overloading any particular NRPS, it is recommended that you order the NRPS in your proxy configuration randomly.

d) Load balancing of communications with the NRPSs should be set up. However the method used must be such that all RADIUS conversation in relation to any one particular authentication event is directed through only one NRPS for the duration of the conversation. Problems arise if proxy state and conversation sequence do not tally at the NRPS.

Radiator 3.1 and up, MS IAS, NPS, Cisco Secure ACS and FreeRADIUS 2.x and 3.x all have good EAP load balancing capability, but older software, such as FreeRADIUS 1.x, must only be used in 'fail over' mode rather than 'load balance' (ie. use fail_over in proxy.conf, not round_robin).

e) RADIUS server timeout should be set sufficiently long to ensure that authentication requests forwarded to the NRPS (for onwards forwarding to your visitors' home ORPSs) is sufficiently long to allow a response to be provided. Do not rely on the default settings. Bear in mind that some visitors may be from distant eduroam federations and that several RADIUS hops may be involved. A timeout of 30 seconds is recommended.

For Microsoft NPS, edit RADIUS Server dialog box, select the Load Balancing tab. The following settings are suggested:

  • Request timeout: Number of seconds without response before request is considered dropped (default 3) - 30
  • Retransmits: Max number of dropped requests before server is identified as unavailable - 5
  • Server back off timeout: Number of seconds between requests when server is identified as unavailable (default 30) - 30

For Cisco ISE, (capability introduced with ISE release 2.7)  the following can be adjusted (through the webUI): 

Request timeout: 'Server Timeout' (valid range 1 - 120) - 30

Retransmits: 'Connection Attempts' (valid range 1 - 9) - 5

Server back off timeout: 'RADIUS Proxy Failover Expiration' (valid range 1 - 600) - 30

For Aruba ClearPass, the following can be adjusted (through the webUI): 

  • Request timeout: Maximum time, in seconds, that the controller waits before timing out the request and resending it - 30 (Default: 5 seconds)
  • Retransmits: Maximum number of retries sent to the server by the controller before the server is marked as down - 5 (Default: 3)
  • Server back off timeout: the backoff time before a server marked as down is retried - it is not clear how this can be adjusted, if at all 

f) It is essential that your ORPSs do not mark all of the NRPS as 'dead' should no reply be received from the NPRS when handing off visitors' authentication requests to the NRPSs for onward authentication by the visitors' Home ORPS. There are logical reasons why the NRPS may not reply to your ORPS and whilst you should configure fail-over between the NRPSs in case of genuine NRPS unavailability, potentially serious communications breakdown can occur if your ORPS marks the NPRSs as dead for the wrong reason.

Remember it is not the NRPS that authenticate your visitors, it is the Home sites. The NRPS simply acts as proxy and waits for a response from the Home site. This can take some time, especially if the visitor is from outside the UK. It should also be noted that some RADIUS implementations (e.g. Microsoft NPS) behave in an unhelful manner if they receive authentication requests they have difficulties with. If they recieve a request for an unknown user or if the request contains an unknown attribute, rather than respond with an Access-Reject, they simply drop the request and remain silent. The NRPS keeps the connection open, waiting for a reply, tying up NRPS resources and your ORPS receives no response from the NRPS. The NRPS do retry the remote Home server a second time, but if there is no further response, the next Home ORPS is tried. NRPSs only act as proxies, cannot act as EAP end points and so cannot formulate Access-Rejects containing reason for failure messages. They will only forward error messages returned in RADIUS packets from the legitimate remote Home site.

Since your ORPS only knows about its immediate neighbours, i.e. the NRPSs, it may appear that the NRPS has not responded to a proxied authentication request. If your ORPS marks the NRPSs as unresponsive, zombie or dead, a serious communication breakdown can develop. The problem is that the NRPS is not dead, it is simply waiting for a response from the users' home server. So if your ORPS stops talking to the NRPS it was in dialogue with, when the NRPS sends an Access-Request for one of your roaming users and your ORPS does not respond, your ORPS will be marked as dead. (Due to hierarchical nature of RAIDUS communications, the NRPS are entitled to make this decision, you OPRSs are not).

You must configure your ORPS to avoid rogue behaviour - i.e. it is essential that your ORPSs do not mark all of the NRPS as 'dead' should no reply be received from the NPRS when forwarding visitors' authentication requests. If your RADIUS server supports Status-Server (FreeRADIUS and Radiator) you should set up your ORPS to use that.

10.3 Configure Attribute Filtering

Frequently organisations make use of attributes within RADIUS packet during the Access-Request / Challenge and Accounting exchanges to check user/machine parameters or to control how users are given access to the network. Such exchanges are frequently of local relevance only and can cause problems during remote authentication attempts. Filtering of all but the most essential RADIUS attributes from the returning packets should therefore be implemented to avoid the local access point at the Visited site receiving attributes it doesn't know how to handle.

Once you have configured attribute filtering, you can test your filter by selecting the 'Poisonous Access-Accept packets' option for the Visitor Authentication Simulation test - which will result in the returned Access-Accept containing a set of attributes that are known to cause problems. See section 15 for further details about the Visitor Auth Simulation test and this feature.

Hint, for FreeRADIUS ORPS - you can determine what attributes are being sent in Access-Request packets by running your server in debug mode or you can run radmin to see what attributes you are sending to the NRPS. Alternatively you could packet capture and then look at the packets in Wireshark.

First off though, the following is the set of attributes required (at a minimum) to support eduroam, as listed in the Technical Specification. These must NOT be filtered out:

RADIUS Access-Request or Access-Challenge message attributes:

1.    User-Name
18.  Reply-Message
24.  State
25.  Class
31.  Calling-Station-ID
33.  Proxy-State
79.  EAP-Message
80.  Message-Authenticator
89.  Chargeable-User-Identity
126. Operator-Name

RADIUS Accounting messages:

1.    User-Name
25.  Class
33.  Proxy-State
40.  Acct-Status-Type
44.  Acct-Session-ID

This list has been determined following a small number of incidents involving roaming eduroam users being unable to connect at certain institutions (both here in the UK and elsewhere) owing to over-restrictive attribute filtering. Please note that implementation of the list is likely to become a mandatory feature of eduroam.

How to set up attribute filtering? Hint for FreeRADIUS ORPS sites - in your pre-proxy section activate filtering:

pre-proxy {


Then in attrs.preproxy set your attributes.  Something like:


      Service-Type             == Login-User,
      Login-Service            == Telnet,
      Login-Service            == Rlogin,
      Login-Service            == TCP-Clear,
      Login-TCP-Port          <= 65536,
      Framed-IP-Address    ==,
      Framed-IP-Netmask   ==,
      Framed-Protocol        == PPP,
      Framed-Protocol        == SLIP,
      Framed-Compression == Van-Jacobson-TCP-IP,
      Framed-MTU                  >= 576,
      Framed-Filter-ID             =* ANY,
      Reply-Message               =* ANY,
      Proxy-State                   =* ANY,
      EAP-Message                 =* ANY,
      Message-Authenticator   =* ANY,
      MS-MPPE-Recv-Key        =* ANY,
      MS-MPPE-Send-Key        =* ANY,
      MS-CHAP-MPPE-Keys      =* ANY,
      State                             =* ANY,
      Session-Timeout            <= 28800,
      Idle-Timeout                 <= 600,
      Calling-Station-Id            =* ANY,
      Called-Station-Id             =* ANY,
      Operator-Name               =* ANY,
      Chargeable-User-Identity =* ANY, 
      Port-Limit                       <= 2

  Make sure you properly test any changes.

For more information on this topic see:

10.4 Configure Rejection of Malformed Usernames

Sending Access-Request packets to the national proxy infrastructure with malformed 'bad' usernames, more particularly those with errors in the realm component, is bad practice; definitely not good-neighbourly. Due to the prevalence of misentered usernames in laptops and mobile phones and in the case of the latter, the 'auto-correct' feature of the phone software compounds this problem, the NRPS are bombarded with Access-Requests that will never result in successful authentications. Instead, the finite resources of the NRPS become tied up waiting for responses from the Home ORPS or from the ETLRs in the case of non-existent non-UK realms. To avoid the above situation you should configure your ORPS to drop authentication attempts by clients with bad usernames. Bad usernames are essentially those that do not conform to 'username@FQDN' - the formal description can be found in RFC 4282, which is largely correct.

To avoid the above, FreeRADIUS depoyments should utilise the Policy engine. There are now numerous examples included in the FreeRADIUS config. It is also possible to avoid the above situation is described

For Microsoft NPS and IAS this is described at: Microsoft NPS 2008R2 config to avoid bad usernames flooding NRPS.

NB. There is nothing that can be done at present to avoid the RADIUS infrastructure from being hit by Access-Requests from users who have left their organisation but still have eduroam credentials configured in their devices. User education to remove eduroam configuration from devices when they leave is the best current solution.

10.5 Configure Injection of Operator-Name Attribute (FreeRADIUS and Radiator only)

If you are deploying a FreeRADIUS, Radiator, Aruba ClearPass or Cisco ACS v5.4, you should configure your system to inject the Operator-Name attribute, correctly formed for your organisation, into Access-Request packets forwarded to the NRPS. The background, rationale and one method of achieving this are documented in Advisory: Injection of Operator-Name attribute (Aug 2011).

11. RADIUS Server configuration to support Home User Authentication when Roaming and on Campus; and Attributes Filtering


In this step you will a) add the NRPSs to your ORPS RADIUS configuration as Clients and b) add your ORPS to the NRPS config as Authenticators - this readies your ORPS to support a Home service and enables the NRPS to send authentication requests to your ORPS. You will also need to take steps to ensure that your authentication service is not vulnerable to harmful attributes being sent by sites your users roam to and that you do not send harmful attributes that may 'poison' your roaming users' authentication attempts. 

Although the GUIs/config files for various RADIUS platforms are different, there are similar broad steps that need to be taken:

  1. Defining the client RADIUS servers (the NRPSs) and lumping them into an eduroam RADIUS client group
  2. Setting the conditions to identify authentication request types and determine how these types are to be handled (setting Network Policies/Authentication conditions) for the three types i) your roaming users ii) your users on campus iii) visitors
  3. Configuring authentication of your own users against your user directory 

In this section, (i) and (ii) are addressed. Authentication is covered in section 14.


  • Addition of NRPS as RADIUS clients in your ORPS configuration
  • Addition of your ORPS as authenticators in the NRPS configuration
  • FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang
  • Special note for Microsoft NPS Configuration - setting the Framed-MTU attribute in Roaming User Network Policy
  • Testing your Configuration - shared secrets check; authentication against local database; remote authentication
  • Configure Peering with other RADIUS servers on your network
  • Configure Attribute Filtering
  • FAQs/Resources

Home service - Configuring peering of your ORPS with the NRPS to support authentication requests from for your own roaming users: You now need to peer your ORPS(s) with the NRPSs so that RADIUS messages can be exchanged to authenticate your users when they roam to eduroam campuses operated by other member organisations. (Nb. This is not applicable to Visited-only deployments).

With respect to setting up a Home service, since a there are two ends of a RADIUS conversation there are two operations:

Addition of your ORPS to the remote RADIUS servers/authenticators configuration of the NRPSs - so the NRPS send RADIUS packets to your ORPS
Addition of the NRPS to the RADIUS clients configuration of your ORPSs - so your ORPS are able to receive RADIUS packets from the NRPS.

(After you have completed the peering operation you will need to configure authentication of requests received from the NRPSs against your user directory (AD/LDAP) - see section 14).

Home service - Configuring your ORPS to support authentication requests from your own users on your campus: You will need to configure realm handling and local authentication of auth requests from your wireless LAN from the eduroam SSID against your user directory (AD/LDAP). (Nb. this is not applicable to any Home-only deployments that do not have a local Wi-Fi service).  

11.1 ​Home service - Add your ORPS as remote RADIUS servers/authenticators on the NRPSs

This step configures the NRPS to send authentication requests from your roaming users to your ORPS, necessary for your ORPS to support a Home service: This will configure the NRPS to send RADIUS authentication request packets to your ORPS.

  • If not already logged in, log in to Support Server: via
  • Click on the 'Configure' tab.
  • In the green 'RADIUS servers' click on the relevant ORPS line. The server details popup box will appear.
  • Scroll down to the RADIUS settings box and click on the 'Authenticate requests' tickbox.
  • Scroll down and click [Save]. The new setting will be added to the ORPS config file on Support and at the next hourly NRPS config update, will be propagated to all three NRPS.

11.2 Home service - Add the NRPSs as RADIUS clients on your ORPS

This step configures your ORPS to accept RADIUS authentication request packets from the NRPS. The addition of the NRPS to the RADIUS clients configuration of your ORPSs allows your ORPS to receive RADIUS packets from the NRPS thereby supporting your roaming users.

  • If not already logged in, log in to Support Server: via
  • Click on the 'Configure' tab.
  • In the green 'RADIUS servers' click on the relevant ORPS line. The server details popup box will appear. In the RADIUS settings box  you will see the unique shared secrets that were generated when your registered your RADIUS server. You will need to copy each key and paste it into the relevant RADIUS clients configuration files/fields on your ORPS servers. Accuracy is essential when transcribing shared secrets. Ensure that there are no extra characters (white space at beginning or end of the shared secret) and ensure that you are copying and pasting with a correct UTF-8 or ASCII buffer so that characters do not get adjusted when pasting from your web browser.

There are three NRPSs and any one may try to communicate with your ORPS systems, so you must allow all NRPS to talk to your ORPSs. 


FreeRADIUS: edit clients.conf file

Microsoft NPS: in Templates Management create RADIUS Shared Secret Template and in RADIUS Client and Servers, create RADIUS Clients

Aruba Clearpass: i) Configuration>Network>Devices>Add. Enter the NRPS names, IP addresses, shared secrets. Use 'IETF' as Vendor Name. No not enable RADIUS CoA for the NRPS (only for your WLCs).  ii) Configuration>Network>Device Groups>Add. Create a group for the eduroam NRPSs (e.g. 'eduroam NRPSs') and add the NRPSs to the list of servers in the group. 

Conditions: For roaming user authentications do NOT define Conditions based on RADIUS attributes that are not guaranteed to be in the Access-Request from your roaming users at a Visited sites you have no control over! e.g. Do NOT specify NAS-Port-Type=wireless-802.11 (19). The only attributes that are guaranteed to be present are listed in section 2.1 of the Technical Specification.

(For authentication - step 14: Configuration>Services>Add. Create a Service for your roaming users (e.g. Requests From NRPS). Click on Service tab and define the Conditions to be matched: a) Connection, ‘Src-IP-Address’ belongs to server group 'eduroam NRPSs' b) Authentication, 'Full-username' matches regex - see Clearpass guide. You will also need to specify the authentication method you are supporting and the authentication source e.g. servername of your domain controller/LDAP database). 

Cisco ISE: Configuration for eduroam

IP Addresses or FQDNs?:

We recommend that the NRPS are added to your systems using explicit IP addresses and not the roaming1/2/ FQDNs. Using IP addresses keeps things simple and means that you are not dependent on DNS lookups when you reboot your servers. 

(The NRPSs support IPv6 and the addresses are resolvable through DNS. Windows 2012R2 and above NPS users note - NPS is IPv6-aware so if FQDNs are used the ORPS will do a DNS lookup and may select the v6 address and if your site is not fully IPv6 enabled, the ORPS will attempt to tunnel v6 via v4 resulting in communications failure with the NRPS).

RADIUS Accounting: In the past you needed to configure your ORPS for, and clients to have Accounting passes as well as being set as RADIUS clients and servers for authentication handling, hence needing to support 1812 and1813 on UDP, but Accounting is now not handled by the NRPS and forwarding to the national proxies MUST NOT be enabled. 


11.3 Authentication request handling for your own users a) when roaming and b) when on-campus

The next step is to configure authentication of your own users: 

  • You will need to configure your ORPS to authenticate requests received from the NRPSs against your user directory (AD/LDAP).
  • And you will need to configure your ORPS to authenticate requests received from the local campus network for your own users against your user directory (AD/LDAP).

Since there are so many RADIUS servers to choose from, it is beyond the scope of this guide to provide detailed instructions for all the possible solutions. Nevertheless we have produced a configuration guide for Microsoft NPS and there are links to other guidance in the resouces section. You will also find links to these in the green Library panel on the Troubleshoot page of the Support server portal. 

Points to consider:

a) It is a requirement that ALL users (home users and visitors) authenticating via eduroam MUST have a realm component in their username (ie must be of the form '') and that the Visited site realm handling logic drops any authentication request without a realm name in the outer id. This is to avoid a situation where your users have used a simple username eg. 'fred' to authenticate whilst connecting to eduroam at your organisation and then find that they cannot gain authentication when visiting another eduroam site. The problem would be that the Visted site ORPS will not recognise the user name and should drop it, but even if it did forward the Access-Request to the NRPS, the NRPS will not know where to forward the request to and so will drop it, returning an Access-Reject including explantory text. Do NOT permit authentication based on a simple username - insist that the username contains @realm.

b) Consideration should be given as to how both "outer" stage 1 identities and "inner" stage 2 identites are handled. You should not permit proxying of inner ID off to other organisations in cases where the inner ID realm is not your organisation - such authentication attempts should be allowed to fail. (E.g. Your RADIUS server handles an authentication request for outerID, but during the auth process encounters an innerID of - your ORPS must drop this auth request).

c) It is essential that your ORPS must not forward an authentication for a user from your own realm or a sub-realm to the NRPS. That would create a potential authentication loop as the NRPS would rightly return the request to your ORPS. Because such authentication loops are highly resource-hungry this situation would create a threat to the eduroam service. The NRPS have anti-auth-loop logic which drops such loop-forming requests, which protects against this threat - but please note that sending auth-loop triggers are explicitly prohibited by the Technical Specification.

d) When forming your handling conditions for handling authentication requests in policies and service rules, be careful to avoid setting conditions that can cause unexpected behaviour or failures. For instance, do not set a condition for your roaming users based on an attribute that may not be forwarded from a remote visited organisation's AP/WLC. You must not make NAS-Port-Type = Wireless-802.11 a condition in the roaming user policy/service rule!

11.4 FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang

We have put together an example configuration of a FreeRADIUS ORPS (both v 1.1.x and 2.x) here: example FreeRADIUS ORPS configuration on eduroam Support server

The first section covers configuration of the NRPS servers as proxy authenticatprs and clients.

About a third of the way down there is script for the authorize stanza in your proxy.conf file for your default virtual server to:

a) enforce use of full userID@realm username format

b) reject bad usernames against a sequence of common error criteria, returning reason for rejection in the reply-message

c) check for properly formed usernames in auth requests and only for valid forms, detect your local realm and hand off to local realm processing

d) hand off auths for non-local realms to eduroam realm processing

or Microsoft NPS Configuration - Setting the Framed-MTU Attribute in Roaming User Network Policy

By default NPS uses a maximum size of 1500 (was 2000) bytes for its datagrams. If it is sending a certificate (whose size may exceed this), the Ethernet packet created will probably be fragmented and this may result in the datagram to be lost in transit where packet fragmentation is rejected (this is why we specify you must NOT configure reject fragments at your firewall). If this happens, the EAP interaction will never complete. This causes NPS to log a discard for your roaming user authentication, for some reason claiming that the incoming packet was incorrectly formatted. Even if the client sends a Framed-MTU attribute itself, NPS will ignore it. However, if you set the Framed-MTU attribute in the Network Policy involved, NPS will use the value you specify for its own packets.

[The author of this tip notes: 'We were seeing this problem initially with responses to the test authentication requests that the NRPSs send every few minutes. I got the details from a Cisco article ( Since implementing the change, I've noticed that authentication attempts from a number of clients which were failing previously are now working.']

How to set the Framed-MTU attribute size in Microsoft NPS:

From the NPS console, double-click Policies, click Network Policies, and then in the details pane double-click the policy that you want to configure - refer to our NPS config guide for the policy that forwards Visitor authentication requests to the NRPSs.

In the policy Properties dialog box, click the Settings tab.

In Settings, in RADIUS Attributes, click Standard. In the details pane, click Add. The Add Standard RADIUS Attribute dialog box opens.

In Attributes, scroll down to and click Framed-MTU, and then click Add. The Attribute Information dialog box opens.

In Attribute Value, type a value equal to or less than 1344. Click OK, click Close, and then click OK.

11.5 Special Note for NPS Configuration - Tuning NPS for authentication with eduroam

11.6 Testing your Configuration

Once the ORPS(s) have been configured, authentication can be tested using the test tools on the eduroam Support web site as described in section 12.

Shared secrets check. In scenarios involving multiple ORPSs, it is advisable to test each ORPS independently for correct configuration. Shared secrets can be checked by simply running a command line test on each of the ORPS. Note that whilst FreeRADIUS, Radiator and MS IAS/NPS include utilities for cleartext password based authentication methods such as PAP, this is no longer supported by the eduroam(UK) infrastructure, so please do not attempt to use radtest, radpwtst or NTRadPing.

a) If you have not hooked your Wi-Fi service in to your RADIUS server, the simplest test involves using a command line tool to try to send Access-Request packets to the NRPS for forwarding to the eduroam Support ORPS for a test user belonging to the eduroam(UK) realm. (This is a command line variation of the standard visitor authentication simulation test - see section 12 below). Nb As specified in section 5 above, you must register a test user account complete with password for your site on the Support server. You should also create a test user account with the registered credentials as a local account on your RADIUS server or an account in your user database). Remember, any changes your make to your config on eduroam Support can take up to an hour to take effect.

Test tools (linux and Windows):

NTRadPing (PAP/CHAP test only - do not attempt to use this!): Support server no longer supports plain PAP authentication.

Radius Test:

eapol_test is included in wpa_supplicant which is an opensource supplicant that can be acquired from

The eapol_test commands would be:

eapol_test -c<test.conf> -p1812 -s<shared secret for roaming0>

eapol_test -c<test.conf> -p1812 -s<shared secret for roaming1>

eapol_test -c<test.conf> -p1812 -s<shared secret for roaming2>


For hints on how to build the test.conf file see

(Radpwtst for Radiator may include PEAP/EAP alternatives to PAP for the more advanced user.)

b) If you have peered your Wi-Fi controller/AP to the RADIUS server you can simply use the test account credentials to try to send authentication requests for the user <your realm> to the NRPS

Authentication tests against your local realm user database / test auth requests from remote sites In order to carry out this test you must have a test user account on your site with a valid password (eg. a local account on the RADIUS server or an account in your user database) and registered it on the eduroam Support server as specified in section 5. You then have a variety of options for testing authentication at your realm - using the remote eduroam Support server or locally from (one of) your ORPS. The tests described below involve interaction with the NPRS, you can however use radtest locally against a specific host.

The eduroam Support server has a remote user test feature for ORPS in normal 'production' mode - see section 12.

If you wish to run authentication tests involving the NRPS from (one of) your ORPS you must first set the target ORPS as a 'test-development' server in the eduroam infrastructure. This can be done via the relevant RADIUS proxy servers page on the eduroam Support server. With this setting, ONLY packets with 'test' prefixing your realm name will be sent to your ORPS. This facility is detailed in section 12; Testing a new ORPS within eduroam Infrastructure before bringing it into production use. CAUTION - there is a danger that auth-loops can be created, so it is essential that the local test user account is valid and that you use credentials accurately. At the end of your test session, you must check your logs to ensure that no auth-loop has been initiated.

If you (temporarily) configure the test ORPS forwarding policy to send all access-requests with realm ('@xxx') suffixes to the NRPS, then when you use 'testuser@test.yourrealm' with radtest, the NRPS will process the request and send the access-request back to your ORPS. (Nb. if you have a group of ORPSs then this request could be sent to ANY one of the individual servers since the NRPS sends to the first ORPS in its list that it finds is not busy). Nevertheless the three lines of radtest commands are useful to verify that the ORPS can talk to all three NRPS - ie that there are no bad secrets and no firewall problems! If you do have multiple ORPSs you could always turn off the other ORPSs while doing each test - which would guarantee that only the ORPS being tested would be sent the return access-request. This would verify that the ORPS under test could be reached from each NRPS in turn).

Assuming that the test account can be authenticated using PAP, the FreeRADIUS command would be:

Radtest testuser@test.your_realm <password> 1812 <shared secret for roaming0>

Radtest testuser@test.your_realm <password> 1812 <shared secret for roaming1>

Radtest testuser@test.your_realm <password> 1812 <shared secret for roaming2>

11.7 Configure Peering with other RADIUS servers on your network

If you choose to implement multiple organisation RADIUS proxy servers for resilience or performance/load sharing, you will have to configure peering between them.