RADSEC keep TLS connections open with keep-alive

[Michal Moravec]

Hey Alan,

> On 20. 2. 2025, at 13:16, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Feb 20, 2025, at 5:58 AM, Michal Moravec <michal.moravec at macadmin.cz> wrote:
>> Is it possible to configure FreeRADIUS server not to close TCP/TLS RADSEC connection between NAS and RADIUS server after completing a single request?
> 
>  Huh?  The server doesn't do that.
> 
>  If the connection is closed after one request, it's likely that the other end is closing it.
Thank you for pointing me in the right direction. I read this somewhere and interpreted the situation I saw under a wrong assumption. Sorry! :-)

What actually happened was the server closing the connection after 30 seconds which is the default idle_timeout in both listen and client/limit (<- even when undefined) stanzas in tls (radsec) configuration file.
After changing idle_timeout to higher value in both in client/limit and listen stanzas, the server keeps the tcp connection open for defined amount of time.

>> Some network vendors support sending keep-alive messages through the connection in order to keep it established and re-use it for subsequent requests.
> 
>  This is the Status-Server packet.  FreeRADIUS supports this.
In this case the vendor is Cisco Meraki. It seems they don't send "Status-Server".
NAS sends TCP keep-alive message (empty TCP header with ACK flag) every 270 seconds until it reaches "RADSec TLS idle timeout" (default 15 minutes) which I interpret as connection being open for X minutes without any actual application-level traffic.

So I tried this:
1. EAP authentication from a client which makes NAS to open the tcp radsec connection to FreeRADIUS
2. RADIUS with idle_timeout = 330 then says "Waking up in 324.8 seconds."
3. Some time after that NAS sends TCP keep-alive
4. RADIUS wakes up as scheduled and closes the connection with "Reached idle timeout on socket auth+acct from client (A.B.C.D, 42471)"

I guess the answer is to use higher value for idle_timeout since TCP keep-alive does not seem to affect this?

Best,
Michal