iRule based RADIUS Health Monitor Builder
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 a discussion on DevCentral how 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 publish K30713256.
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 my RADIUS Client Stack and wrapped them into a simple iRule hosted Web-Application, which provides an easy to use web interface to construct RFC2865 compliant 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.
Code Snippet Meta Information
- Version: 1.0
- Coding Language: TCL