But it really depends on what is behind the "for a purpose". Maybe there really is a reason why the primary is not allowed to get access to the content of the second database, or why its admission decisions are inferior to and can be preempted by the second server. Without telling us more about the reason why you think this needs to be like that, it's hard to say more.
Thank you Stefan for your answer. The purpose behind that is as you said the secondary DB is not allowed to be accessed by the first FR and vice versa. In addition to that, the secondary radius should not be facing our BRAS network for security reasons. Do you think unlang will help to get this done? BR On 11 July 2016 at 14:18, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
We are an ISP and we have two radius servers. Each is connected to a different Database for a purpose. One of our requirements is to tune the primary radius to proxy requests to the secondary in case those requests got rejected by the primary. Flow is as below:
Request flow need to be Primary to Secondary (One-way ONLY)
Requests are sent to the Primary Radius, then if: a- Access Accept - Okay b- Access Reject - Send same request to the secondary Radius.
Would you be so kind and advise on the above setup? Is it doable and what are the possible methods to implement such?
Much rather than advising how to realise this setup, I'd rather advice to do a different setup :-)
Many RADIUS clients allow to specify a "primary" and a "backup" RADIUS server. If there's no reply from primary, they wait for a timeout and query the second one.
If you need to do two different authentication flows, configure both RADIUS servers to connect to both databases, and use unlang to steer which DB to contect first, and under which circumstances to try the second.
That way you get redundant RADIUS servers for free, and can actually have a *sane* config (the above is pretty much standard stuff).
But it really depends on what is behind the "for a purpose". Maybe there really is a reason why the primary is not allowed to get access to the content of the second database, or why its admission decisions are inferior to and can be preempted by the second server. Without telling us more about the reason why you think this needs to be like that, it's hard to say more.
Greetings,
Stefan Winter
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette
Tel: +352 424409 1 Fax: +352 422473
PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--