Preventing proxy loops
Alan DeKok
aland at deployingradius.com
Tue Sep 1 15:22:10 CEST 2020
On Sep 1, 2020, at 9:14 AM, Arnaud LAURIOU <arnaud.lauriou at renater.fr> wrote:
>
> Yes but maybe I didn't make myself clear : I'm talking about our .fr federation level eduroam proxies,
> not our 'renater.fr' RADIUS server.
Ah, OK.
>> If they're sending packets for their realm to you, then you have no obligation to be polite. Don't send the packets back. Just reject them.
> Yes, I tried a solution in pre-proxy section (described in my prevous email) but it's NOK for monitor requests like
> nagios@<realm>.fr when client and home_server are the same.
>
> Do I need to go further with this solution (e.g. use a specific CLI attribute so that these requests can be handled
> separately) or is there a completely different way to protect our proxies from loops with FR ?
The simplest way is perhaps to just add a vendor-specific attribute. If you see a packet without that VSA, you forward it. If you see a packet with that VSA, you know it's looped, and you reject it.
That presumes the other server doesn't filter out that VSA, though.
The other way is as you tried, with a small change:
if (Realm && EAP-Message && ("%{home_server:ipaddr}" == "%{client:ipaddr}")) {
update request {
&Module-Failure-Message += 'Rejected: loop prevent'
}
reject
}
Monitoring packets shouldn't contain EAP-Message, so the above rule should catch only EAP authentication requests.
And yes, beat up the admins who have broken configurations. They're causing problems for everyone else.
Alan DeKok.
More information about the Freeradius-Users
mailing list