Implementing eduroam Roadmap - Part 2

Download as PDFDownload as PDF

On this page sections 10 - 15:

  1. RADIUS server proxying configuration and attributes filtering
  2. Wi-Fi service and establishment of a VLAN/network service for eduroam
  3. Firewall configuration to support eduroam network service
  4. RADIUS server software configuration for Home service / interoperation with user database
  5. DNS Name Server Configuration
  6. Test facilities on eduroam Support Server / Visitor Test / Testing a new ORPS

See Part 1 for sections 1 - 9:

  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
  8. Add your ORPS to the eduroam(UK) RADIUS Infrastructure via Support website and acquire your shared secrets
  9. Firewall configuration to permit RADIUS servers to work with NRPS

See Part 3 for sections 16 - 22:

  1. RADIUS server log keeping and interpretation of logs
  2. Monitoring your own service
  3. Workstation/Laptop Setup/MS Vista issue
  4. Q.A. test of your eduroam implementation
  5. Promote eduroam at your organisation - your eduroam web site
  6. Keep your configuration details data on the eduroam Support server up to date
  7. Planning Ahead and Developing your eduroam Implementation

Part 2

10. RADIUS server proxying configuration and attributes filtering

In this section:

  • Addition of NRPS as RADIUS clients
  • Configure Realm Handling, Proxying and Load Balancing
  • FreeRADIUS Example Configuration - proxy, client and foreign realm handling with unlang
  • Testing your Configuration - shared secrets check; authentication against local database; remote authentication
  • Configure Peering with orther RADIUS servers on your network
  • Configure Attribute Filtering
  • Configure Injection of Operator-Name Attribute (FreeRADIUS, Radiator, Aruba ClearPass, latest Cisco ACS/ISE  only)
  • Configure Rejection of Malformed Usernames
  • FAQs/Resources

10.1 Configure Peering with NRPSs

This step is to complete the peering of your ORPS with the NRPS by setting the NRPS as clients of your ORPS

To complete the process of peering your ORPS with the NRPS you must add all three NRPS as RADIUS clients on all of your ORPS systems (hint - edit clients.conf and proxy.conf files). Roaming0.ja.net, roaming1.ja.net and roaming2.ja.net (194.82.174.185 ; 194.83.56.233 ; 194.83.56.249) must have full authentication and accounting passes - allowed as clients on your ORPS.

If you use hostnames rather than IP addresses in your proxy configuration (FreeRADIUS: proxy.conf) 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/1813 (authentication and accounting). The NRPS will not listen on anything other than the proper RADIUS ports 1812 and 1813. 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. 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.

Resources:

10.2 Configure Realm Handling, Proxying, RADIUS server timeouts and Load Balancing

This step is to configure your ORPS to handle auth requests originating from your network APs/controllers: forwarding Access-Requests from Visitors to the NRPS and (if applicable) forwarding Access-Requests from local users to your local  authentication system.

The next stage is 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 configuration carried via GUI. 

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.

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 'userID@camford.ac.uk') 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 user@myorganisation.ac.uk, but during the auth process encounters an innerID of user@camford.ac.uk - your ORPS must drop this auth request).

c) It is essential that your ORPS does 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) (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.

e) 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.

f) 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.

g) 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 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).

h) RADIUS server timeout should be set to ensure that authentication requests forwarded to the NRPS (for onwards forwarding to your visitors' home ORPS) is sufficiently long to allow a response to be provided. 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. So taking the example of Microsoft NPS, the following settings are suggested:

Number of seconds without response before request is considered dropped: 30

Max number of dropped requests before servier is identified as unavailable: 5

Number of seconds between requests when servier is identified as unavailable: 30

i) 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 recieves 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 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

10.4 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.

eapol_test is included in wpa_supplicant which is an opensource supplicant that can be acquired from http://w1.fi/wpa_supplicant/

The eapol_test commands would be:

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

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

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

See https://www.systutorials.com/docs/linux/man/8-eapol_test/

For hints on how to build the test.conf file see https://www.systutorials.com/docs/linux/man/5-wpa_supplicant.conf/

(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>@eduroam.ac.uk 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> roaming0.ja.net 1812 <shared secret for roaming0>

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

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

10.5 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.

10.6 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
       MS-MPPE-Send-Key
       MS-MPPE-Recv-Key
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 {

      attr_filter.pre-proxy

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

DEFAULT

      Service-Type == Framed-User,

      Service-Type == Login-User,

      Login-Service == Telnet,

      Login-Service == Rlogin,

      Login-Service == TCP-Clear,

      Login-TCP-Port <= 65536,

      Framed-IP-Address == 255.255.255.254,

      Framed-IP-Netmask == 255.255.255.255,

      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.7 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).

10.8 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 eduroam.org 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 at:www.wireless.bris.ac.uk/netcomms/eduroam-realm-checks.conf.

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.10 Resources/FAQs

Troubleshooting Microsoft IAS as a RADIUS server and as a RADIUS proxy

This link to the MS TechNet site should be useful:

Is it possible to authenticate EAP-PEAP against Novell Directory Services?

While it is not possible to authenticate EAP-PEAP against the default non-reversible hash used in NDS, it is now possible to configure a "Universal Password" in NDS which stores users' passwords in a reversibly encrypted format. This will permit the authentication of EAP-PEAP against NDS through RADIUS servers such as FreeRADIUS and Radiator.

How do you configure FreeRADIUS against Novell eDirectory?

Novell has produced documentation on configuring FreeRADIUS against eDirectory:

Are there any example configurations for Radiator available?

We currently don't have any direct cut'n'paste for Radiator that is clearly available for any site due to the uniqueness of each site requirement (backend authentication and such).

However, Radiator supplies many example configuration file snippets and templates.

eg ntlm_eap_multi.cfg which is a simple config which handles Radius PAP, CHAP, MSCHAP and MSCHAPV2 and also handles the outer and inner requests for TTLS and PEAP. In this case, the <AuthBy NTLM> sub-handler is doing the work. Of course this is only suitable for Active Directory. If sites are using passwords or eDirectory etc then the requirements will be different.

Also appendix A.2 of the Geant2 Roaming Infrastructure Service and Support Cookbook provides useful information on configuring the ORPS server software.

Are there any example configurations for FreeRADIUS available?

We don't have any direct cut'n'paste configurations for FreeRADIUS that would be suitable for all sites due to the uniqueness of each site requirement (backend authentication etc).

However there are some hints and tips on the eduroam Support website and there is some useful information in the following case study, which is a practical description of how University of Bristol implemented and complies with the Technical Specification using FreeRADIUS in an AD environment: A Case Study in Complying with the Technical Specification.

Also appendix A.2 of the Geant2 Roaming Infrastructure Service and Support Cookbook provides useful information on configuring the ORPS server software.

FreeRADIUS integration with Active Directory

The received way of setting up FreeRADIUS to authenticate users against Active Directory is to use Samba/winbind/ntlm_auth:

FreeRADIUS Active Directory Integration Howto - from FreeRADIUS Wiki

University of Bristol implemented FreeRADIUS in an AD environment, the following case study contains useful information: A Case Study in Comlying with the Technical Specification.

How do I change the IP address of our ORPS? (Is there a procedure we need to go through?)

You need simply to use the https://support.roaming.ja.net eduroam support site. Go to your ORPS configuration page and select your ORPS, change the name of the RADIUS server and press [Update RPS]. Check that the passphrase does not change (it should not). The final step is to remove the old ORPS entry and add the new one. The passphrase will be different then. The changes are propagated to the NRPS on the hour.

11. Wi-Fi Service and Establishment of a VLAN/Network Service for eduroam

eduroam Wi-Fi service

The steps involved in establishing an eduroam Wi-Fi service are:

  • Enabling 802.1X on your Access Points or Wireless LAN Controllers
  • Peering APs/WLC with your ORPS (ORPS are RADIUS servers to APs and APs are RADIUS clients of ORPS)
  • Set up radios and wireless LAN  - RF bands to be used for each standard, define WLANs, enable WPA2/AES cipher
  • Setup eduroam SSID
  • eduroam VLAN setup
  • Configure authenticated user connection policy - VLAN connection/dynamic VLAN assignment
  • Tune EAP timers, RADIUS server timeout and other WLAN parameters

Most organisations provide eduroam over a Wi-Fi service although eduroam may alternatively or in addition be provided over wired infrastructure. Wi-Fi is typically the 'front-end' by which most users would prefer to connect, since this supports the laptop, tablet and  smartphone devices that are most popular with users.

Many organisations have used the deployment of eduroam to simplify their wireless network offering. This can result in reduced management overhead and improved overall Wi-Fi performance and can be achieved by combining eduroam as the primary ESSID with multiple dynamically assigned VLANs as described below, together with a further small number of ESSIDs e.g. for an open captive portal network for first time users to provide access to device setup utilities or for a guest network for non-eduroam visitors.

To establish an eduroam Wi-Fi service, you need to configure the organisation's APs to broadcast the eduroam SSID, the APs need to be set to use 802.1X/AAA-RADIUS-authentication and be defined as clients of the RADIUS server. Then the APs need to be configured to forward authentication requests from the Wi-Fi devices associating to the eduroam SSID to your RADIUS server(s). Upon receipt of an validated authenticated request (an Access-Accept) the APs must connect the device to your eduroam network, described below.

If you want to use dynamic VLAN assignment as described below (assigning users to specific VLANs based on information received from the RADIUS server) then the APs must be configured to do this. (Other activities performed by the APs include exchange keying material (initialisation vectors, public and session keys, etc.) with client systems to prevent session hijacking).

Resources:

eduroam network

Visited organisations must implement one (or more) dedicated network/VLAN(s) to provide eduroam network services. All eduroam networks must comply with the eduroam(UK) Tech Spec (access to the Internet permitting use of (at least) the defined key ports and protocols - see Firewall section). Any eduroam network/VLAN must not be shared with any other network service. Authenticated Visitors must be connected to such an eduroam network service.

Most participating organisations permit their own users to connect via the organisation's eduroam Wi-Fi service. If this is not permitted, this must be clearly stated on the organisation's eduroam Service Information web page. Organisations may connect local users to the mandatory Visitors' eduroam network service, but alternatively may connect them to a more appropriate local network. This can be achieved through 'dynamic VLAN assignment' (which is the more efficient alternative to the fixed SSID-VLAN mapped solution). Such local networks may be used to for example satisfy the following requirements:

  • provide access to local resources that the organisation wishes to be accessed only by its own users/specific groups of users
  • provide a security environment required for local users/specific groups of users
  • enable local users connecting their own personal devices to be connected onto an 'untrusted network'
  • provide a remedial network environment for devices requiring AV updates, OS-patches etc.

Detailed information about how to set up dynamic VLAN assignment is beyond the scope of this guide, but essentially involves configuring your RADIUS server to return a value in the relevant attribute in the Access-Accept based on the policy you define for the particular user or user-group. The AP needs to be configured to act upon the attribute value and to connec the device to the appropriate VLAN. There are many guides available on the Internet, one of which is Allied Telesyn's How To user 802.1X VLAN Assignment.

Nb. The minimum set of open ports and protocols for eduroam network services defined in the eduroam(UK) Tech Spec does NOT apply to non-eduroam network services that a participating organisation may choose to connect local users to.

Requirements for eduroam network/VLANs:

  • The Wi-Fi service that connects to the eduroam network service must use a broadcast SSID of 'eduroam' (which must be lowercase)
  • DHCP must be employed to allocate IP addresses
  • Only IEEE 802.1X is permitted for the eduroam network; no form of WRD/captive portal is permitted, although you may implement this on other networks such as device setup and remediation networks
  • IEEE 802.1X NASs must support symmetric keying using keys provided by the Home organisation within the RADIUS Access-Accept packet
  • Only a single user is permitted per NAS port except where 'thin client'/controller-based systems are employed
  • IPv4 addresses must be allocated to visitors using DHCP
  • The IPv4 addresses allocated to visitors and the corresponding MAC addresses must be logged
  • NAT address mappings, if used must be logged
  • Routing of IPv6 on the eduroam visitor VLAN ideally should be supported
  • NAT is permitted
  • WEP must not be implemented on the eduroam Wi-Fi service that connects to the eduroam network service
  • TLS interception proxies/filters must not be employed on the eduroam network service for visitors

Visited organisations may implement IPv4 and IPv6 filtering between the visitor VLAN and other external networks, providing that this permits the forwarding protocols detailed in the Firewall Configuration section.

Resources:

12. Firewall Configuration to Support eduroam Network Service

If not done already, your organisational firewall must now be made ready for the eduroam Visitors network service.

An important aim of eduroam is to provide visitors with unimpeded access to the Internet, not least because this maximises the probability of a visitor’s applications working as expected. The Tech Spec therefore requires that at least the core list of protocols listed in the talble below must be permitted. You may of course open additional ports and protocols if your local policy is more liberal.

Note, if member organisations wish to absolutely ensure that their own users, when roaming, have or a wider range of ports/specific additional ports available than the minimum listed, they could provide their users with a (supported) VPN service through which the home site could control the availability of required ports and protocols.

Similarly, the Visited service providing organisation need only comply with the list for their eduroam visitor network. If you connect your own users (through your eduroam Wi-Fi service) to an alternative network service more appropriate for local users, you are not required to adhere to the minimum list (and you may be more restrictive or more open).

One approach worth considering is to offer a fairly open Visitied service network with just the ports and protocols suggested in the following document blocked and also SMTP/port 25 blocked https://community.ja.net/library/janet-services-documentation/blocking-lan-service-ports. Your own users when at home could be connected to a network service compying with your policy for local users.

Mandatory Open Ports and Protocols:

Passive (S)FTP: TCP/21 egress and established
SSH: TCP/22 egress and established
IPv6 Tunnel Broker Service: IP protocol 41 egress and established
PPTP:

IP protocol 47 (GRE) and TCP/1723

egress and established
ESP: IP protocol 50 egress and established;
AH: IP protocol 51 egress and established
HTTP: TCP/80 egress and established
POP: TCP/110 egress and established
NTP: UDP/123 egress and established
IMAP4: TCP/143 egress and established
IMAP3: TCP/220 egress and established
LDAP: TCP/389 egress and established
IMSP: TCP/406 egress and established
HTTPS: TCP/443 egress and established
ISAKMP: and IKE: UDP/500 egress
LDAPS: TCP/636 egress and established
SMTPS: TCP/465 egress and established
Message submission: TCP/587 egress and established
IMAPS: TCP/993 egress and established
POP3S: TCP/995 egress and established
OpenVPN: UDP 1194 and TCP 1194 egress and established
Citrix: TCP/1494 egress and established
SQUID Proxy TCP/3128 egress and established
RDP: TCP/3389 egress and established
IPv6 Tunnel Broker NAT traversal: UDP/3653 and TCP/3653 egress and established
IPSec NAT traversal: UDP/4500 egress and established
VNC: TCP/5900 egress and established
AFS: UDP/7000 through UDP/7007 inclusive egress and established
HTTP Proxy: TCP/8080 egress and established
Cisco IPSec NAT traversal: UDP/10000 and TCP/10000 egress and established

You may have additional ports and protocols open as permitted by your local policies.

The above list is subject to change, so you should refer to the current published eduroam(UK) Technical Specification, which provides the definitive listing.

13. RADIUS server configuration for Home service - interoperation with user database

Configure Authentication of Preferred EAP Types

Home organisations must configure their RADIUS server (eg.edit the eap.conf file) to authenticate one or more EAP (Extensible Authentication Protocol) types as specified in the Technical Specification.

Interoperation with User Database

For each home realm authentication request handled by the ORPS, the RADIUS server generally has to interrogate the user database (LDAP, NDS, AD). The interoperation of the RADIUS server with the backend user database is often the most problematic part of implementing 802.1X. Whilst there are a number of well known techniques and software combinations, since each institution 's environment is unique, detailed guidance about this is beyond the scope of this overview.

However, for FreeRADIUS with LDAP based systems, the auth handling flow is as follows: after the prefix module has run, the 'Stripped-User-Name' attribute gets populated with the userID part of the username (e.g. 'a123467') - you then use that in your LDAP configuration (ie %{Stripped-User-Name}) with the relevant CN/DN/ON that you require in LDAP.

Again, 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.

A word on the format of user names: when migrating to an 802.1X authenticated network, it is often tempting to permit simple usernames to continue to be authenticated rather than requiring a full username including a realm element to be used. Since an eduroam username must include a realm component, the Tech Spec now requires that the username should always include the realm component, even for eduroam networks for local users only and for users who might be thought to not roam to other eduroam sites.

It is particularly important to not permit simple usernames to be used in single-SSID eduroam networks where 'eduroam' is used for both guest users and local users.

By requiring that the full 'user@organisation.ac.uk' type credentials are used, you can ensure that the same credentials are used by users both on the home network and when roaming. Thus problems associated with use of incorrect creadentials can be avoided. For the user, there is no confusion and after the first time that the credentials are entered into the supplicant, there is no additional work involved resulting from the adoption of this policy.

Configure RADIUS server to reject PAP requests from the NRPS

PAP is useful to have configured against a local test account during the early stages of service implementation. However, once you have used it to test port 182 transit and NAT/PAT if applicable, since there will be no production PAP traffic, you should confgiure your RADIUS server to reject any PAP requests coming from the NRPSs.

Configure load balancing if deploying multiple RADIUS servers servicing your WLAN

If you are deploying multiple RADIUS servers to service your WLAN, think about how you are going to share the load evenly between these and your failover mechanisms.

A note on working with usernames in Microsoft NPS Windows 2008R2

Many organisations implement eduroam in an existing MS Windows network environment where usernames are stored in AD in a simple userID form without a realm component (or in some cases the realm component doesn't match the eduroam realm, e.g. eduroam realm = @camford.ac.uk but AD realm = @ad.camford.ac.uk). For eduroam authentication, usernames must be in the form userID@realm, therefore a means must be found of presenting the username in a form that can be successfully authenticated. (In the mismatching realms case, the eduroam realm needs to be made authenticatable). In IAS and earlier NPS versions, a perfectly workable solution has hitherto been to simply strip the realm component by using for example the find-replace rule in the Connection Request policy which is the standard Find “(.*)@(.*)”  Replace “$1”. This however is no longer possible in later versions of NPS.

In NPS Windows2008R2 and later, whilst you can implement the above, the results is authentication fails even though the actual realm stripping seems to work - the stripped username is found in the AD, but still the authentication fails, (almost as if the password is wrong). Interestingly you could even strip the original .ac.uk type realm component (e.g. @camford.ac.uk) and replace it with a local one (e.g. @ad.camford.ac.uk or @camford.local) that matches a valid username in AD, but the result would be the same.

This is because in Windows 2008R2 Microsoft decided to change the way that NPS deals with realms. In 2008R2 a stripped realm no longer passes EAP security requirements and thus the stripping of a User-Name always results in an authentication failure.

The fix for this is to do one of the following:

1) Configure the realm stripping rules on the front-end NPS server to modify the identity in the Access-Request and then forward the request to a second NPS server for authentication OR just send the Access-Request to a second (earlier release) Microsoft RADIUS server (older NPS or even ancient IAS box) to do the stripping and authentication.

2) The recommended solution is to add your eduroam realm as another global UPN to your AD so you don't need to strip the realm in the first place.

3) Use a different RADIUS server platform!

Set up logging

Logging on the ORPS must be set up in accordance with the Technical Specification. All transactions with the NRPS, including some mandatory attributes, must be logged and records held for at least 3 months, with a recommended maximum of 6 months (subject to your own policies).

RADIUS Accounting

RADIUS Accounting is not required by eduroam(UK) but some overseas countries do use Accounting information inside their own borders for various reasons. Since eduroam Europe Operations does not interfere with forwarded Accounting packets, ORPS at Home service organisations may receive accounting records from their own users when they roam to a non-UK hotspot for which RADIUS Accounting has been turned on. Note that the number and content of attributes in the Accounting packets varies greatly due to the underspecification in RFC2866; you can not rely on any single Accounting attribute being present. The best option is for your to simply discard Accounting packets which cannot be correctly understood by your RADIUS server.

Visited sites should turn off RADIUS Accounting.

Resources:

14. DNS Name Server Configuration

All(*) participants providing a Home (IdP) eduroam service should ensure that the DNS zone relating to their realm contains a NAPTR record (Name Authority Pointer) enabling the NRPS to be indirectly defined as hosts for radsec services via SRVs. (*)With the exception of .ac.uk participants using Windows Server 2003 as their DNS server (since this does not support NAPTR records - Windows 2008 R2 is fine). This ensures improved authentication performance for your users when using eduroam outside of the UK.

It should be noted that it is mandatory for organisations using non-.uk realm names (e.g. camford.edu and camford.org to configure NAPTR records in their DNS zones and so such organisations must ensure that their DNS name server supports NAPTR records. This is because top-level international RADIUS routing for 'special' top level domain names is now achieved using RadSec DD.

The background, rationale and method of achieving insertion of NAPTR records are documented in Advisory: Improving Efficiency of International Authentication through utilisation of RadSec at National Level 

15. Test facilities on eduroam Support Server / Visitor Test / Testing a New ORPS

eduroam administrators at participating organisations are able to carry out a number of tests themselves to verify the correct configuration of their ORPS/user database for authentication of their roaming users via eduroam. The Support server also supports a background monitoring test using NAGIOS which continually tests the status of all ORPSs.

15.1 eduroam Support Server ORPS/Authentication Tests

Tests available to eduroam administrators at participating organisations from the eduroam Support server enable testing on demand of :

a) basic dead or alive status of your ORPS

b) authentication of one of your users visiting another organisation, using authentication protocols: PAP, EAP-PEAP, EAP-TTLS.(*)

c) authentication of a user visiting your site from another organisation (ie that your ORPS is forwarding RADIUS packets correctly and handling attributes within RADIUS-challenge/response etc. packets ok).(*)

(*) EAP-TLS - test facilities are not available at present due to the complexities relating to the digital certificate requirements (clients require unique server and client certificates).

How to use the tests:

1) A test user account must first be registered on the eduroam Support Server web site with details including the test user name, password, the realm that the organisation wishes to test and the EAP method or PAP required. If you have multiple realms registered on the Support server you can select which of these you wish to be appended to the test account name.

2) The test user account should be created in the organisation's user database that is authenticated against by eduroam. This should allow at least five failed authentication attempts without being locked. Nb The test account credentials will only ever be known to Technical Support.

3) Log in to the eduroam Support server, click on 'eduroam UK configuration' left hand menu item, click on your organisation name (which opens your main config page) and select 'Test' from the drop down list in the left hand menu. The test page appears in the tight hand panel.

The available test functions are:

  • ORPS Status Check - ICMP ping status test. This is to ensure an ORPS is up and running at the participant's site. Click on the [Test ICMP] button
  • Remote User Authentication Tests. To check that one of your users at a remote site can be authenticated by your systems. Click on the relevant [Test] button.

PAP authentication - this tests a clear-text authentication attempt, such as those generated by web redirect systems (although not necessary for 802.1X implementation it is nevertheless required that all sites enable PAP for the test user account).

EAP-PEAP authentication test - PEAP is commonly used for 802.1X authentication. This option will work for most RADIUS servers. Some servers, e.g., Radiator, may require peaplabel=1 configuration to interoperate with PEAPv1. In this case the following test should be tried:

EAP-PEAP (peaplabel=1) authentication test

EAP-TTLS has various inner types, choose the appropriate one for your site:

EAP-TTLS (inner PAP)

EAP-TTLS (innerMD5)

EAP-TTLS (inner MSCHAPv2)

Remember that when testing a user from your own organisation authenticating using your 802.1X network, if the user can be authenticated on your network, then provided that proxying works, the user will be able to successfully authenticate at any compliant visited organisation.

15.2 Visitor Authentication Simulation Test

Purposes:

  • Testing visiting user authentication during implementaton of a new Visited service to check correct RADIUS forwarding to NRPS
  • Verify correct injection of Operator-Name by invoking the automatic O-N check test on the Support server
  • Monitor operational status of your ORPS (forwarding to NRPS function) and operational status of NRPS

You can test vistor authentication without needing to request a set of credentials from Janet or a mentor/buddy organisation. The eduroam Support Server will return Access-Accepts for authentication requests for a test user with a userID of 'your_realm' at the realm 'eduroam.ac.uk'. The password is the same password you registered on eduroam Support for your local test user account. Note: until the new Support server goes into production in Q3 2016, Visited-only member organisations are not by default able to use this test service. If you do not have a realm registered with eduroam(UK) Support you should request enabling of this test by sending an e-mail to JSD.

If you have already set up 802.1X authentication on your network, you can use a network-connected laptop/tablet/smartphone or workstation to test authentication of a visitor. Alternatively you can run authentication tests directly from your ORPS using radeaptest, radpwtst or NTRadPing (for FreeRADIUS, Radiator and IAS/NPS respectively).

Key points:

  • use your realm as the actual user identity rather than your test account user name (this is to ensure a unique test user name for each participant - several sites have chosen the same name for their test accounts)
  • the following realms are supported: roaming.ja.net, janetroaming.net, eduroam.ac.uk, eduroam.org.uk Use whichever/all preferred or relevant to the purpose of your test (.ac.uk, .net, .org.uk are the most commonly encountered eduroam TLDs in the UK)
  • use your test account password for this test (not your eduroam Support server password)
  • disable certificate validation as this is not currently supported for this test
  • the test supports the Chargeable User Identity (CUI) attribute, so if your ORPS sends Operator-Name and CUI with the value 'nul' in the Access-Request, the Support server will reply with a CUI for that user in the Access-Accept

For example, if your realm is "camford.ac.uk" and you have a test account enabled on the eduroam(UK) Support server (as described previously) with the password "password1", then to do a visitor user test at your site, you would simply use the following credentials when promted by your supplicant:

camford.ac.uk@eduroam.ac.uk
password1

The alternative way to perform a visitor test is to run test commands from your ORPS. Using radeaptest with FreeRADIUS (via roaming2) this would be as follows:

Radeaptest your_realm@eduroam.ac.uk <password> roaming2.ja.net 1812 <shared secret for roaming2>

You can also use the eapol_test tool which can be found in wpa_supplicant. See http://deployingradius.com/scripts/eapol_test/

The service supports PEAP, EAP-TTLS/PAP and EAP-TTLS/MSCHAPv2.  (Basic PAP and the use of the FreeRADIUS radtest tool was discontinued since there is no PAP based authentication in eduroam post-captive portal!)

Participants are permitted to use the visitor authentication simulation test for their own monitoring solutions but should configure any such solutions to not query this service more often than once every 5 minutes.

15.3 eduroam(UK) Monitor of ORPS

The eduroam(UK) Support server runs a Nagios monitoring system service for organisations asserting operational services. There are several components of this monitor:

  • ICMP 'are you alive' ping (or TCP 2002 for Cisco ACS CSA sites)
  • EAP authentication of test account from a remote site (applicable to operational 'Home' and 'Home & Visited' service sites only and only for 'full service' ORPS)
  • A scan of the designated URL of your eduroam service information web page for compliance with specified requirements
  • DNS dig check for eduroam NAPTR record

ICMP probes run from the eduroam Support server and from all three NRPS every 5 minutes to check basic connectivity and server status, which is why your firewall must be open for ICMP from the NRPS and Support server as described in section 8, firewall considerations for ORPS. Cisco ACS sites: for RADIUS servers that cannot accept ICMP, ie Cisco ACS RADIUS servers running CSA, an alternative solution using telnet on TCP port 2002 has been implemented. If you are running Cisco CSA with CSA, please request this option during your induction session or by submitting a request via JSD.

RADIUS authentication probes using your preferred EAP method (originally this test used PAP) are made to participants' realms from all three NRPSs every 5 minutes using the test accounts. This tests that the participating organisation has an operational remote user authentication service for the realm. Since we can control from which NRPS the access-request is sent from, we can test that your realm accepts such traffic from all three NRPS. However we cannot direct RADIUS traffic to a particular ORPS at your realm. Therefore in cases where an organisation has multiple ORPS, it is essential that you check that the shared secrets are correct.

The authentication method used by the probe test was extended from the original PAP-only method and now supports PEAPv0/MSCHAPv2, PEAPv1/MSCHAPv2, EAP-TTLS/PAP, EAP-TTLS/MD5 and EAP-TTLS/MSCHAPv2. The EAP method that organisations actually use for their users can be selected on the site's eduroam configuration page on the eduroam Support web site.

For technical reasons we do not send out automated notifications of failures, however eduroam site administrators now have access to the Nagios system for their particular site (feature added March 2010). After logging on to the eduroam Support server, under the 'eduroam configuration' menu on the left hand pane, select 'Nagios LG'. This looking glass view gives eduroam admins access to the results of the relevant Nagios monitoring processes for their site/realm. Access to this tool should help participants to see more readily underlying issues.

15.4 Testing a new ORPS within eduroam Infrastructure before bringing it into production use

The Support server provides the facility for you to set up peering of a (new) ORPS with the NRPS in a protected/test mode. This allows you to carry out your own tests without a specified ORPS becoming part of the production infrastructure and without it being sent live production or Nagios test traffic. Nb, the eduroam Support on demand EAP tests are also effectively disabled in this mode.

Setting an ORPS to protected/test mode can be achieved by designatating the ORPS as 'test/development' via the eduroam Support server eduroam configuration/Radius Proxy Server menu. Once an ORPS has been set to protected test-mode, only traffic with 'test' prefixed to your realm name will be sent to your test/development server. This enables you to carry out 'loopback' tests using eg: testuser@test.yourorganisation.ac.uk. Nb. When you set an ORPS as test/dev the test. sub-realm is automatically configured in the eduroam(UK) infrastructure, you do not need to set up the sub-realm on the Support realms page.

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.

For full details see: ORPS role designation feature on eduroam(UK) Support Server.

FAQs:

Why do I get only "Re-sending Access-Request" when testing authentication via the support server?

Ensure that your firewall is configured to permit UDP ports 1812, 1813 and 1814. RADIUS does not use TCP!

You should also check that your firewall is not discarding UDP fragments. If it is then the configuration should be changed to allow UDP fragments to pass. [Specifically for ipf firewall users, (to be found on Solaris systems) the config script can be changed to PASS fragments using the keep frag keyword].

Rationale - with certain EAP communications, eg EAP-TLS, the RADIUS packet sizes can get much bigger than the usual MTU of 1500. This means that the RADIUS packets get fragmented in transit. Many firewalls are configured to drop UDP fragments (as security against DoS attacks), however this will, of course, break such RADIUS communications. If your firewall is doing such dropping then it will need to be configured to ALLOW such traffic from NRPS<->ORPS. This will affect more sites as people migrate to full 802.1X implementations and use eg EAP-TLS or other EAP methods which use larger packets.

I'm trying to test my ORPS, but I get Reply-Message = "Misconfigured client: unknown AC.UK site from janetroaming.net. Rejected by <eduroam UK>." when I run the PAP auth test

If you have configured your OPRS into the Support server config page correctly, the above error is returned because you have set your ORPS as 'Test/Development'. This is resulting in preventing the NRPS from sending any auth traffic, including test traffic to you realm (only traffic with the 'test.' realm prefix will be sent). Refer to  ORPS role designation features on JANET Roaming Support Server.

Resources: