Radius Timeout instead of Access-Reject
Hi, I work at an ISP in Brazil, our main radius server is running freeradius 1.X. I'm configuring a new server with freeradius 2.X and doing some tests to see if I find any problem before putting it on production. So far I've found a little problem that doesn't disable me to put it in production, but can confuse in case of a radius failure. When an authentication failure happens, on the nas it appears that the radius server is not responding, it shows a "Radius timeout" message, here is the output of the radius debug: rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 124 NAS-Port-Type = Ethernet User-Name = "modesto" Calling-Station-Id = "BC:AE:C5:9C:87:C5" Called-Station-Id = "isimples" NAS-Port-Id = "LAN" CHAP-Challenge = 0x246ed4d8e9cffc10c7c5120963c5d990 CHAP-Password = 0x0134931ed7c1c7fda0493d9663d658e789 NAS-Identifier = "REDE_ISIMPLES" NAS-IP-Address = 192.168.2.100 # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [chap] Setting 'Auth-Type := CHAP' ++[chap] returns ok ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "modesto", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok [sql] expand: %{User-Name} -> modesto [sql] sql_set_user escaped user --> 'modesto' rlm_sql (sql): Reserving sql socket id: 0 [sql] expand: SELECT id, UserName, Attribute, Value, op FROM radcheck WHERE Username = '%{SQL-User-Name}' AND ativo='S' ORDER BY id -> SELECT id, UserName, Attribute, Value, op FROM radcheck WHERE Username = 'modesto' AND ativo='S' ORDER BY id [sql] expand: SELECT GroupName FROM usergroup WHERE UserName='%{SQL-User-Name}' -> SELECT GroupName FROM usergroup WHERE UserName='modesto' rlm_sql (sql): Released sql socket id: 0 [sql] User modesto not found ++[sql] returns notfound sql_xlat expand: %{User-Name} -> modesto sql_set_user escaped user --> 'modesto' expand: SELECT nas_pool_name FROM naspool WHERE nas_ip=INET_ATON('%{NAS-IP-Address}') -> SELECT nas_pool_name FROM naspool WHERE nas_ip=INET_ATON('192.168.2.100') rlm_sql (sql): Reserving sql socket id: 4 SQL query did not return any results rlm_sql (sql): Released sql socket id: 4 expand: %{sql: SELECT nas_pool_name FROM naspool WHERE nas_ip=INET_ATON('%{NAS-IP-Address}')} -> ++[control] returns notfound ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = CHAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +- entering group CHAP {...} [chap] login attempt by "modesto" with CHAP password [chap] Cleartext-Password is required for authentication ++[chap] returns invalid Failed to authenticate the user. Login incorrect (rlm_chap: Clear text password not available): [modesto/<CHAP-Password>] (from client teste port 124 cli BC:AE:C5:9C:87:C5) Using Post-Auth-Type Reject # Executing group from file /usr/local/etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> modesto attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 4 for 1 seconds Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86 Waking up in 0.6 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86 Waking up in 0.3 seconds. Sending delayed reject for request 4 Sending Access-Reject of id 86 to 192.168.2.100 port 35710 Waking up in 4.9 seconds. Cleaning up request 4 ID 86 with timestamp +41 Ready to process requests. ** The freeradius server is running on a FreeBSD 9-STABLE Jail, there is no firewall rules in the middle that could prevent the packet from being sent. Regards.
Antonio Modesto wrote:
Hi,
I work at an ISP in Brazil, our main radius server is running freeradius 1.X. I'm configuring a new server with freeradius 2.X and doing some tests to see if I find any problem before putting it on production. So far I've found a little problem that doesn't disable me to put it in production, but can confuse in case of a radius failure. When an authentication failure happens, on the nas it appears that the radius server is not responding, it shows a "Radius timeout" message, here is the output of the radius debug:
The timeouts on the NAS are set WAY too low.
Delaying reject of request 4 for 1 seconds Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86
i.e. the NAS didn't see a reply, and retransmitted.
Waking up in 0.6 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86
And retransmitted again 0.3 seconds later.
Waking up in 0.3 seconds. Sending delayed reject for request 4 Sending Access-Reject of id 86 to 192.168.2.100 port 35710
And then the server responded 0.3 seconds later. Fix the NAS so it doesn't have *ridiculous* timeouts. RADIUS timeouts are normally in the multi-second range. Having the NAS retransmit multiple times a second is stupid, wrong, and will create problems. Alan DeKok.
You're right, it worked. The default mikrotik timeout is 300ms, I've set it to 5000 ms and I've got the right answer. One more question, Though I'll reconfigure all the timeout's on my nas'es, why doesn't this problem happen with freeradius 1.X? Is that normal? Or is it something that's causing my freeradius 2.x to take longer to reply the requests 2012/8/7 Alan DeKok <aland@deployingradius.com>
Antonio Modesto wrote:
Hi,
I work at an ISP in Brazil, our main radius server is running freeradius 1.X. I'm configuring a new server with freeradius 2.X and doing some tests to see if I find any problem before putting it on production. So far I've found a little problem that doesn't disable me to put it in production, but can confuse in case of a radius failure. When an authentication failure happens, on the nas it appears that the radius server is not responding, it shows a "Radius timeout" message, here is the output of the radius debug:
The timeouts on the NAS are set WAY too low.
Delaying reject of request 4 for 1 seconds Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86
i.e. the NAS didn't see a reply, and retransmitted.
Waking up in 0.6 seconds. rad_recv: Access-Request packet from host 192.168.2.100 port 35710, id=86, length=145 Waiting to send Access-Reject to client teste port 35710 - ID: 86
And retransmitted again 0.3 seconds later.
Waking up in 0.3 seconds. Sending delayed reject for request 4 Sending Access-Reject of id 86 to 192.168.2.100 port 35710
And then the server responded 0.3 seconds later.
Fix the NAS so it doesn't have *ridiculous* timeouts. RADIUS timeouts are normally in the multi-second range. Having the NAS retransmit multiple times a second is stupid, wrong, and will create problems.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Atenciosamente, * Antônio Modesto Gerente de TI* Praça Getúlio Vargas, 77 – Sala 308 – Centro Santo Antônio do Monte – MG – CEP: 35560-000 Tel:(37) 3281-2800 Contato: isimples@isimples.com.br http://www.isimples.com.br Aviso:Esta mensagem e quaisquer arquivos em anexo podem conter informações confidenciais e/ou privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, por favor, não leia, copie, repasse, imprima, guarde, nem tome qualquer ação baseada nessas informações. Notifique o remetente imediatamente por e-mail e apague a mensagem permanentemente. Atenção: embora a Isimples Telecom, tome seus cuidados para garantir a ausência de vírus neste e-mail, a empresa não se responsabiliza por quaisquer perdas ou danos decorrentes do uso da mensagem e seus anexos. A segurança e ausência de erros na transmissão do e-mail não podem ser garantidas, já que as informações podem ser interceptadas, corrompidas, perdidas, destruídas, atrasadas, chegarem incompletas, ou, ainda, conter vírus. Recomendamos checar se o e-mail e seus anexos contém vírus, uma vez que nem a Isimples Telecom ou o remetente se responsabilizam pela transmissão destes.
Hi, there's reject_delay in radiusd.conf It is typcially set to one second to prevent some attacks. You could set it to zero and then the reject may come through faster. Still, 300 ms is *really* low even for that - depending on the time your auth backend needs to even determine whether it was success or failure may take longer than that. Stefan On 07.08.2012 20:55, Antonio Modesto wrote:
You're right, it worked. The default mikrotik timeout is 300ms, I've set it to 5000 ms and I've got the right answer. One more question, Though I'll reconfigure all the timeout's on my nas'es, why doesn't this problem happen with freeradius 1.X? Is that normal? Or is it something that's causing my freeradius 2.x to take longer to reply the requests
2012/8/7 Alan DeKok <aland@deployingradius.com <mailto:aland@deployingradius.com>>
Antonio Modesto wrote: > Hi, > > I work at an ISP in Brazil, our main radius server is running freeradius > 1.X. I'm configuring a new server with freeradius 2.X and doing some > tests to see if I find any problem before putting it on production. So > far I've found a little problem that doesn't disable me to put it in > production, but can confuse in case of a radius failure. When an > authentication failure happens, on the nas it appears that the radius > server is not responding, it shows a "Radius timeout" message, here is > the output of the radius debug:
The timeouts on the NAS are set WAY too low.
> Delaying reject of request 4 for 1 seconds > Going to the next request > Waking up in 0.9 seconds. > rad_recv: Access-Request packet from host 192.168.2.100 port 35710, > id=86, length=145 > Waiting to send Access-Reject to client teste port 35710 - ID: 86
i.e. the NAS didn't see a reply, and retransmitted.
> Waking up in 0.6 seconds. > rad_recv: Access-Request packet from host 192.168.2.100 port 35710, > id=86, length=145 > Waiting to send Access-Reject to client teste port 35710 - ID: 86
And retransmitted again 0.3 seconds later.
> Waking up in 0.3 seconds. > Sending delayed reject for request 4 > Sending Access-Reject of id 86 to 192.168.2.100 port 35710
And then the server responded 0.3 seconds later.
Fix the NAS so it doesn't have *ridiculous* timeouts. RADIUS timeouts are normally in the multi-second range. Having the NAS retransmit multiple times a second is stupid, wrong, and will create problems.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Atenciosamente, * Antônio Modesto
Gerente de TI*
Praça Getúlio Vargas, 77 – Sala 308 – Centro
Santo Antônio do Monte – MG – CEP: 35560-000 Tel:(37) 3281-2800
Contato: isimples@isimples.com.br <mailto:isimples@isimples.com.br> http://www.isimples.com.br
Aviso:Esta mensagem e quaisquer arquivos em anexo podem conter informações confidenciais e/ou
privilegiadas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, por favor, não
leia, copie, repasse, imprima, guarde, nem tome qualquer ação baseada nessas informações. Notifique o
remetente imediatamente por e-mail e apague a mensagem permanentemente. Atenção: embora a Isimples
Telecom, tome seus cuidados para garantir a ausência de vírus neste e-mail, a empresa não se responsabiliza
por quaisquer perdas ou danos decorrentes do uso da mensagem e seus anexos. A segurança e ausência de
erros na transmissão do e-mail não podem ser garantidas, já que as informações podem ser interceptadas,
corrompidas, perdidas, destruídas, atrasadas, chegarem incompletas, ou, ainda, conter vírus. Recomendamos
checar se o e-mail e seus anexos contém vírus, uma vez que nem a Isimples Telecom ou o remetente se
responsabilizam pela transmissão destes.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
participants (3)
-
Alan DeKok -
Antonio Modesto -
Stefan Winter