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

On May 8, 2025, at 3:29 PM, Dominic Stalder <[email protected]> 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.

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