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