FreeRADIUS 3.0.1 [Proxy To Another Radius if Reject Received]

[Ibrahim Almahfooz]

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



--