Re: Way to verify RADIUS status-server of proxy server over RadSec / TLS

Hi Alan

thanks for your feedback.

> That should be fine.
> Uh, what?
> No.  They're just RADIUS packets over TLS.  There is no 2 byte length prefix.

That is, what I assumed as well and was told by our upsream RADIUS provider as well.


> socat might work.  Did you try it?  If so, what happened?

I tried indeed and got this output:

root@id-radiustest1:~# socat -v OPENSSL:130.59.31.25:2083,cert=/etc/freeradius/certs/radsec-id-radius.unibe.ch.pem,key=/etc/freeradius/certs/radsec-id-radius.unibe.ch.key,cafile=/etc/freeradius/certs/edupki-root-ca-cert.pem,verify=0 UDP-RECV:11812
< 2025/05/08 19:56:11.230844  length=38 from=0 to=37
\f..&\f..Z8 .F@./....%P..p......|..y...x> 2025/05/08 19:56:11.233741  length=38 from=0 to=37
...&J...UGM..A...:.4P.<..\r\bdq....]....2025/05/08 19:56:11 socat[2226675] E sendto(7, 0x55d313d26000, 38, 0, AF=0 "<anon>", 0): Invalid argument
root@id-radiustest1:~# socat -v OPENSSL:130.59.31.25:2083,cert=/etc/freeradius/certs/radsec-id-radius.unibe.ch.pem,key=/etc/freeradius/certs/radsec-id-radius.unibe.ch.key,cafile=/etc/freeradius/certs/edupki-root-ca-cert.pem,verify=0 UDP-RECV:11812
< 2025/05/08 19:56:56.736886  length=38 from=0 to=37
\f..&...\v....4..JC...P..MJjf.0*.......e> 2025/05/08 19:56:56.739755  length=38 from=0 to=37
...&.44../5.jB
..\f.`P..M.&d.L_.2..R%.n2025/05/08 19:56:56 socat[2226678] E sendto(7, 0x55b73ba0a000, 38, 0, AF=0 "<anon>", 0): Invalid argument

To be honest, I let this interpret by an AI and this is what the AI told me: "You’re trying to receive UDP packets on port 11812 and send them via TLS/TCP using socat. That conceptually makes sense — it’s what RADIUS-over-TLS (RadSec) does — but unfortunately, RADIUS over TLS is not just “UDP in TLS over TCP”. RadSec uses a specific framing: each RADIUS packet must be prefixed with a 2-byte length field when encapsulated over TCP/TLS (per RFC 6614).“


> Or, set up a local RADIUS proxy which accepts UDP, and sends packets over TLS to the remote server.

I read about the radsecproxy application, to achieve this. But would it also be possible to use my FreeRADIUS instance for this; this does exactly this: receives RADIUS / UDP packets and sends them for „unknown“ realms to the proxy server over RadSec / TLS. But is it also possible, to proxy somehow the RADIUS status-server messages like this?


 > But this doesn't really tell you a lot.  If your proxy is sending packets to the remote server, just check the stats and logs on your local proxy.  It will complain if the remote server is down.

I am already extrackting the FreeRADIUS stats from our FreeRADIUS servers and return them to PRTG (our monitoring tool) as well and show them there graphically:

cat <<EOF | radclient -x localhost:18121 status adminsecret
FreeRADIUS-Statistics-Type = ALL
Message-Authenticator = 0x00
EOF“

I would need to have a look at the different stats there and decide, if I can create an alarming based on them.

But if - by any chance - there is a way to achieve it with the given „tools“ (like our FreeRADIUS server itself), I would like to get that path; also out of curiosity.

Regards
Dominic

> Am 08.05.2025 um 20:49 schrieb Alan DeKok <[email protected]>:
> 
> On May 8, 2025, at 2:31 PM, Dominic Stalder <[email protected]> wrote:
>> Recently, we migrated some of our RADIUS proxy servers from RADIUS (UDP) to RadSec (TCP) and I would like to still be able to monitor the upstream proxy servers.
>> 
>> When we were still using RADIUS (UDP), I was able to send a status-server RADIUS message to the upstream server directly, like this and report that back to PRTG (our monitoring tool):
>> 
>> echo 'Message-Authenticator = 0x00' | radclient -x 1.2.3.4 status secret
>> 
>> Now I would like to achieve something similar, after we migrated the proxy server 1.2.3.4 to TLS only.
> 
>  It's a little more complex, but it shouldn't be hard.
> 
>> My initial try was to setup something like this:
>> 
>> 1. start a local socat listener on port UDP/11812 and tunnel it to 
>> 
>> socat -v OPENSSL:1.2.3.4:2083,cert=/etc/freeradius/certs/radsec.pem,key=/etc/freeradius/certs/radsec.key,cafile=/etc/freeradius/certs/edupki-root-ca-cert.pem,verify=0 UDP-RECV:11812
>> 
>> 
>> 2. send a standard RADIUS (UDP) status-server packet to the localhost port UDP/11812:
>> 
>> echo 'Message-Authenticator = 0x00' | radclient -x localhost:11812 status radsec -t 1
> 
>  That should be fine.
> 
>> 3. unfortunately, this isn’t straight forward:
>> 
>> You’re trying to receive UDP packets on port 11812 and send them via TLS/TCP using socat. That conceptually makes sense — it’s what RADIUS-over-TLS (RadSec) does — but unfortunately, RADIUS over TLS is not just “UDP in TLS over TCP”. RadSec uses a specific framing: each RADIUS packet must be prefixed with a 2-byte length field when encapsulated over TCP/TLS (per RFC 6614).
> 
>  Uh, what?
> 
>  No.  They're just RADIUS packets over TLS.  There is no 2 byte length prefix.
> 
>> Does anybody have an idea, how to implement a simple RadSec / TLS status-server test, maybe with a „workaround“ or a detour over the FreeRADIUS configuration?
> 
>  socat might work.  Did you try it?  If so, what happened?
> 
>  Or, set up a local RADIUS proxy which accepts UDP, and sends packets over TLS to the remote server.
> 
>  But this doesn't really tell you a lot.  If your proxy is sending packets to the remote server, just check the stats and logs on your local proxy.  It will complain if the remote server is down.
> 
>  Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html