Configuring active eduroam monitoring

Configuring active eduroam monitoring

Introduction - what is active eduroam monitoring

Making sure that your eduroam network is functional for eduroam visitors is an important part of being a member of eduroam. If visitors cannot connect to eduroam at your institution, it leads to dissatisfaction not only with your network but also with eduroam itself. Many members across the world include their eduroam connection as part of their network monitoring. The ideal kind of monitor is for the administrator to be alerted should an interruption to the service occur for whatever reason (RADIUS issue, internet connection outage, NRPS issue etc), and although this monitoring is optional, we have found that where an organisation does have active monitoring, any interruptions to the service has quickly been picked up and the organisation has been able to quickly restore service.

Some monitoring software (like Nagios) comes with such functionality as a module that just needs to be enabled and configured, other software needs some extra things to make it work. The ever popular Windows does not have such functionality, so Windows NPS server administrators are left in the dark about such a vital part of their service. In this article we describe solutions for both Windows and Linux platforms.

So how does active eduroam monitoring work? It's effectively a regular test to see whether a simulated visitor onto your network can reach their home server. Some eduroam operators provide you with a test account that can be used to simulate a visitor, and you can use this together with eapol_test and routine scheduling software to set up active monitoring. If your eduroam operator doesn't provide a username, you can potentially use a made-up username with a well-known domain (like google.com) that you know will be rejected.

How to configure active eduroam monitoring

Generally, configuring active eduroam monitoring is fairly simple. A script or a batch file running in the background at regular intervals (every 10, 15, 30, 60 minutes perhaps) can provide you with forewarning that something is not quite right with your service.

On Windows, a regular Windows task can write into the event log, which in turn you can interrogate for the specific event (depending how often you run it) to see when the problem started.

On Linux, a bash script that simply executes the eapol_test binary (which is part of the wpa_supplicant packages on most Linux platforms) with a configuration file and which evaluates the outcome of the execution is sufficient, provided you monitor your system logs (syslogs). If you use Nagios or something similar, you can get away with using the excellent rad_eap_test script instead. rad_eap_test accepts the test username, test password, the server IP address and secret on the command-line instead of a configuration file, and it returns a simple error code to indicate success or failure. It requires the following utilities (some of which are installed by default):

eapol_test
dig
bc
sed
awk

After a successful run, you should see a successful authentication in your RADIUS server logs for the username you used for the test.

Preparation

Ideally, you should run your active monitor (or heartbeat) on the same server as your RADIUS software. On Windows, this means running the task and the batch file on the same server that your NPS instance is running on. You can however also run the script from another server if you so prefer, but be aware that the success or failure is written into the system log of the server from which you ran it instead.

You must also define a RADIUS client in your RADIUS server software with the IP address from where you run the script as the client address. So if the IP address from where you run the heartbeat script is 192.168.23.45, define a client with the IP 192.168.23.45. Give it a very simple and straight-forward secret. The FreeRADIUS project likes the secret 'testing123' for obvious reasons. You might want to choose a different one.

Note down the secret you defined for the client and the IP address for your RADIUS server. You will need these.

The configuration file for both the Linux script below and the Windows batch file further along is the standard eapol_test configuration. Note: This configuration assumes that your server understands TLS v1.2. If it does not, adjust the first line by setting the tlsv1_0 or tlsv1_1 options to zero, and also schedule an upgrade for your server, as TLS v1.0 and v1.1 are deprecated and ideally must not be used:

network={
  phase1="tls_disable_tlsv1_0=1 tls_disable_tlsv1_1=1 tls_disable_tlsv1_2=0 tls_disable_tlsv1_3=1 peapver=0"
  key_mgmt=WPA-EAP
  eap=PEAP
  identity="<your visiting test username in the userID@realm.tld format>"
  anonymous_identity="<your visiting test username in the userID@realm.tld format>"
  password="<your visiting test password>"
  phase2="eapauth=MSCHAPV2 mschapv2_retry=0"
}

Note: For the the examples below, we call this file eapol_config.cfg and store it in /opt/eduroam_monitor on Linux or C:\eduroamHB on Windows.

Linux

If you do not use Nagios, or you are unable to use the rad_eap_test script mentioned further up, you can use the below script instead. This is a very simple bash script that will log to the syslog if there was a failure or not.

This script requires the following utilities (some of which are preinstalled):

eapol_test
tail
logger

Call it eduroam_monitor_check.sh and store it alongside the config file in /opt/:

#!/bin/sh
# Run a heartbeat
ip=<the IP address for your server>
s=<the secret for the client you created>
bssid=<the BSSID for your eduroam network, in a MAC format like 02:00:00:00:00:01>
# check that eapol_test works
if [[ -x /sbin/eapol_test ]]; then
  if [[ -f /opt/eduroam_monitor/eapol_config.cfg ]]; then
    # get the actual output
    i=$(/sbin/eapol_test -t 5 -c /opt/eduroam_monitor/eapol_config.cfg -N 30:s:$bssid:eduroam -N 32:s:eduroam-monitor -a $ip -s $s |tail -1)
    # output is either success or failure
    /bin/logger eduroam Monitoring: $i
  fi
fi

The result of this script is not a success or failure error code, but rather a line in the system log with the text 'eduroam Monitoring: <result>', along with a successful authentication in your RADIUS server logs for the test user in your configuration.

You can run this script by either adding a line into a crontab for your monitoring user, or you can copy eduroam_monitor_check.sh into /etc/cron.hourly for an hourly run. Alternatively, if you prefer a more frequent run, add a file into /etc/cron.d/ with this contents:

# Run the ten-minute jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=monitor
*/10 * * * * monitor /opt/eduroam_monitor/eduroam_monitor_check.sh

Adjust 'monitor' to your monitoring user if you have one (ideally, you should not run such commands as root as it's not necessary). Restart crond with the 'service crond restart' command.

To test your RADIUS server's connection to your eduroam FLRs, you can use the same script and replace the server IP and secret with the FLR of your choice, along with its secret. This effectively skips your server and tries the FLR directly instead.

Windows

Windows traditionally does not have a process to monitor NPS. As with the Linux script, you will need a configuration file, and the eapol_test utility on Windows, which you can download here.

The eduroam UK team have built, code-signed and published it for Windows, so after downloading, you can right-click the executable, click Properties, and then examine the code signing certificate. It should be signed around March 21 2021.

You will need the configuration file (see above). Note down the location and name because you will need it.

To run eapol_test.exe, place it in the same directory as eapol_config.cfg (or your chosen name). Then, in the same location, create a batchfile with this contents:

@echo off
set ROAMING_IP="<the IP address for your server>"
set ROAMING_SECRET="<the secret for the client you created>"
set BSSID="<the BSSID for your eduroam network, in a MAC format like 02:00:00:00:00:01>"
cd C:\eduroamHB
eapol_test.exe -t 5 -c eapol_config.cfg -N 30:s:%BSSID%:eduroam -N 32:s:eduroam-monitor -a %ROAMING_IP% -s %ROAMING_SECRET% |findstr /R "^SUCCESS$" >nul 2>nul
set MYVAR=%errorlevel%
IF "%MYVAR%" == "0" GOTO EventSuccess
eventcreate /Id 2 /D "eduroam Monitoring: FAILURE" /T ERROR /L system /SO eduroamMonitor >nul 2>nul
GOTO End
:EventSuccess
eventcreate /Id 1 /D "eduroam Monitoring: SUCCESS" /T SUCCESS /L system /SO eduroamMonitor >nul 2>nul
:End

As before, adjust the location of the file and the directories in the batchfile accordingly. You can also use this batchfile to test your connection to the roaming servers by adjusting the ROAMING_IP and ROAMING_SECRET settings to the IP of the FLR of your choice, along with its secret. This will skip your server and test your external connection directly instead.

To create a scheduled task that runs every ten minutes, you should execute this command as an administrator on your server that the batchfile runs from:

SCHTASKS /Create /U <domain\user> /P <password> /SC MINUTE /MO 10 /TN eduroamMonitor /TR "C:\eduroamHB\eduroam_mon.bat" /RU 'NT AUTHORITY\SYSTEM'

Adjust the /U and /P parameters to an admin user and its password.

After every run, you should see an event in the 'System' log in the Event Viewer of your server called 'eduroamMonitor'. An 'Information' type message means it will be a success message. An 'Error' type message will contain an error.

Then check your event log regularly to see whether your external connection is still 'up'.