FreeRADIUS 3.0.1 [Proxy To Another Radius if Reject Received]
Hi Everybody, 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? Kind regards, Ibrahim --
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
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
--
On Jul 11, 2016, at 7:52 AM, Ibrahim Almahfooz via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
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.
My simple answer is "don't do that". Your design is wrong. There is no security gained by hiding RADIUS 2 from the BRAS, or by hiding database 2 from RADIUS 1. Alan DeKok.
My simple answer is "don't do that". Your design is wrong. There is no security gained by hiding RADIUS 2 from the BRAS, or by hiding database 2 from RADIUS 1.
Thank you Alan for your answer however I will be waiting for Stefan help regarding the other method. We need such a setup to be implemented temporary for two-three months then we will remove it. On 11 July 2016 at 16:07, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 11, 2016, at 7:52 AM, Ibrahim Almahfooz via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
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.
My simple answer is "don't do that". Your design is wrong.
There is no security gained by hiding RADIUS 2 from the BRAS, or by hiding database 2 from RADIUS 1.
Alan DeKok.
--
On Jul 11, 2016, at 10:56 AM, Ibrahim Almahfooz <ibrahim.nezar@gorannet.net> wrote:
Thank you Alan for your answer however I will be waiting for Stefan help regarding the other method. We need such a setup to be implemented temporary for two-three months then we will remove it.
The server cannot turn a Reject into a proxied packet via unlang. It doesn't matter if the setup is temporary. Your requirements are based on bad ideas about security. Your design is wrong. It adds complexity, and doesn't add security. What you want to do is impossible. Fix your design to follow the recommendations given on this list. Alan DeKok.
Let's say our idea is wrong, impossible and bad. If the server can not do it by unlang, is there any module or any workaround for such a thing (Proxy rejected packets)? On 11 July 2016 at 18:35, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 11, 2016, at 10:56 AM, Ibrahim Almahfooz < ibrahim.nezar@gorannet.net> wrote:
Thank you Alan for your answer however I will be waiting for Stefan help regarding the other method. We need such a setup to be implemented temporary for two-three months then we will remove it.
The server cannot turn a Reject into a proxied packet via unlang.
It doesn't matter if the setup is temporary. Your requirements are based on bad ideas about security. Your design is wrong. It adds complexity, and doesn't add security.
What you want to do is impossible. Fix your design to follow the recommendations given on this list.
Alan DeKok.
--
On Jul 11, 2016, at 1:10 PM, Ibrahim Almahfooz <ibrahim.nezar@gorannet.net> wrote:
Let's say our idea is wrong, impossible and bad.
If the server can not do it by unlang, is there any module or any workaround for such a thing (Proxy rejected packets)?
Perhaps the word "impossible" is not clear to you. You cannot do it. It's impossible. You have a choice. Either follow the advice on this list, or keep asking the same question over and over and over and over again until you get unsubscribed, and banned from the list. Alan DeKok.
Never wanted to complicate the subject just wanted to get more out of my question since it is impossible to implement then I guess I have to accept your answer. No hard feelings. Again I would like to thank you for your time. On 11 July 2016 at 20:47, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 11, 2016, at 1:10 PM, Ibrahim Almahfooz < ibrahim.nezar@gorannet.net> wrote:
Let's say our idea is wrong, impossible and bad.
If the server can not do it by unlang, is there any module or any workaround for such a thing (Proxy rejected packets)?
Perhaps the word "impossible" is not clear to you.
You cannot do it.
It's impossible.
You have a choice. Either follow the advice on this list, or keep asking the same question over and over and over and over again until you get unsubscribed, and banned from the list.
Alan DeKok.
--
participants (3)
-
Alan DeKok -
Ibrahim Almahfooz -
Stefan Winter