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