Hey Alan,
On 20. 2. 2025, at 13:16, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 20, 2025, at 5:58 AM, Michal Moravec <michal.moravec@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