RADSEC keep TLS connections open with keep-alive

[Alan DeKok]

On Feb 20, 2025, at 10:34 AM, Michal Moravec <michal.moravec at macadmin.cz> wrote:
> 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.

  That's good.

>>> 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.

  Unfortunately those packets ensure that intermediate firewalls don't close the TCP connection.  But the application doesn't see those packets.

> 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?

  Yes.

  Though there usually isn't a lot of benefit in keeping connections open for 10+ minutes without any traffic.

  Alan DeKok.