Way to verify RADIUS status-server of proxy server over RadSec / TLS
Hi guys 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. 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 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). Based on the documentation of radclient, it does not support RadSEC / TLS natively. And no, I don’t know, how to implement it… 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? Regards Dominic
On May 8, 2025, at 2:31 PM, Dominic Stalder <dominic.stalder@bluewin.ch> 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.
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 <aland@deployingradius.com>:
On May 8, 2025, at 2:31 PM, Dominic Stalder <dominic.stalder@bluewin.ch> 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
On May 8, 2025, at 3:29 PM, Dominic Stalder <dominic.stalder@bluewin.ch> wrote:
That is, what I assumed as well and was told by our upsream RADIUS provider as well.
It's also what you see by reading RFC 6614.
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
That's an issue with socat. It's an error returned by the local kernel, and has nothing to do with RADIUS or with anything else. socat is trying to send a packet to the address family "0", which is invalid.
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).“
Please don't use AI for this kind of thing. It's garbage, and it lies to you. It's *worse* than doing nothing.
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?
FreeRADIUS doesn't proxy Status-Server, but it can proxy other packets.
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:
So why set up another "ping" check, if the logs show that the next server is up, and is responding to packets?
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.
Get what path? Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
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).“
Please don't use AI for this kind of thing. It's garbage, and it lies to you. It's *worse* than doing nothing.
Funny. Wonder if the AI confused RADIUS over TLS with DNS over TCP? Almost the same, I guess. At least for "intelligence" based on simple extrapolation. If you know how one UDP based protocol translates to a stream, then you can guess how all other UDP based protocols translates to streams. Bjørn
participants (3)
-
Alan DeKok -
Bjørn Mork -
Dominic Stalder