Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’.
The F5-RADIUS-HealthMonitor-Builder iRule can be used to compute tailordered UDP payload SEND/RECV strings to health monitor RADIUS Server instances.
Problem solved by this Code Snippet
LTMs build-in RADIUS-Monitor has unfortunately the limitation that it always requires a "ACCESS-Accept" RADIUS response to decide that a given Pool Member is healthy.
In the case that a RADIUS Service always responds with a "ACCESS-Challenge" RADIUS response, or in the case you want to probe TOTP-based RADIUS Services which usually requiring time-based tokens instead of fixed password values, you have to use a custom UDP monitor to check the availability of the RADIUS Services.
A couple years ago the DevCentral Users @boneyard, @janholtz_40468 and me had adiscussion on DevCentralhow such RADIUS Services could be monitoried by deploying generic UDP-based Health Monitors with tailordered SEND/RECV UDP payload strings. The outcome of this discussion was then used by F5 to publishK30713256.
I recently run into the problem that the rather static UDP payload used in our initial solution, does not work in more advanced RADIUS Health Monitoring scenarios, where for example a specific USER-NAME / PASSWORD value or a specific NAS-ID value must be used, or when the RADIUS Service requires the use of HMAC-based RADIUS-Request signing.
I ended up to recycle code snippets of myRADIUS Client Stackand wrapped them into a simple iRule hosted Web-Application, which provides an easy to use web interface to constructRFC2865compliant RADIUS requests and RADIUS Response regex signatures.
How to use this Code Snippet
Visit my GitHub Repository for further explanations how the RADIUS Health Monitor Builder can be used to compute tailordered UDP payload SEND/RECV strings to health monitor RADIUS Server instances.