I just started noticing this recently… I don’t recall it happening before.
RouterOS’s default radius timeout is 300ms.. This seems to cause unnecessary retransmits and timeouts on the NAS request packets when using free radius’s default reject_delay setting in radiusd.conf and mikrotiks default radius timeout value.
With reject_delay set to any setting greater than 0 I’m seeing an unnecessary amount of retries and timeouts. When I increase the RADIUS timeout on the NAS to something greater than the setting of the reject_delay all is well.
I don’t know if I had the setting disabled before or I just hadn’t noticed it. It would seem this would create an abnormal amount of access-request packets from the NAS to be handled by the server undermining the purpose of the reject_delay setting (to slow down DoS attacks).
Is this normal operation and I just have to increase the radius timeout for the NAS? If it is Mikrotik may want to increase the default radius timeout value to something greater than 1000ms as freeradius comes with the reject_delay set to 1 (1000ms).
FreeRADIUS puts a delay before rejects to ‘slow walk’ brute force attempts as you’re now limited to effectively less than 60 per minute. In my opinion you could argue it both ways. A well protected system that uses RADIUS for administrative tasks and is otherwise slow walking brute force attempts benefits from the responsiveness of immediate failure.
On the other hand many more complicated backend lookups can also take well more than 300ms minus RTT. For my Hotspots I typically raise my timeout limit to 1s (my reject delay is set to 500ms and the database backend being queried can reliably respond in under 100ms - leaving 400ms for RTT, which I can fairly reliably meet anywhere in the US). Middle ground, if you will. I’d support a higher default value.
The default being 300ms would cause a lot of redundant chatter on the network. If you have the reject_delay at 1 its going to try your primary radius server, then because of the time outs hit your secondary, and maybe even be thrown back to the primary before it just times out all together… It seems like it would be stuck in a loop before it just times out all together.
Then the added overhead of all the SQL queries each request is going to generate… multiply that by the amount of NAS’s you have…
hmm I’m changing all my timeouts to 1500ms… and disable the reject_delay until i can do it to the 100+ NAS’s we have…