Preventing proxy loops

classic Classic list List threaded Threaded
5 messages Options
| Threaded
Open this post in threaded view
|

Preventing proxy loops

Arnaud LAURIOU
Hello,

We have freeRADIUS proxies dedicated to eduroam, version 3.0.21.

Some of our clients are sending us Access-Request ... with their realm.
We forward them to their home_server (the same as the client) and
they send them back to us again. This sometimes creates loops.

How can we prevent our proxies from these loops ? Knowing that :
- We don't have access to the clients/home server organizations RADIUS
configs.
- We tried a filter in the pre-proxy section :
        if (Realm && ("%{home_server:ipaddr}" == "%{client:ipaddr}")) {
                update request {
                        &Module-Failure-Message += 'Rejected: loop prevent'
                }
                reject
        }
But this rule is too strict for the monitoring requests used by some
organizations.
- Another way ?

Regards,

Arnaud Lauriou


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Preventing proxy loops

Alan DeKok-2
On Sep 1, 2020, at 5:19 AM, Arnaud LAURIOU <[hidden email]> wrote:
>
> We have freeRADIUS proxies dedicated to eduroam, version 3.0.21.
>
> Some of our clients are sending us Access-Request ... with their realm.
> We forward them to their home_server

  Why?

  The only packets you should get from Eduroam are ones for your realm.  All other packets should be rejected immediately.

        if (Realm != "renate.fr) {
                reject
        }

  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.

  Their users will complain that they can't get online.  They will then fix the issue.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Preventing proxy loops

Arnaud LAURIOU


On 9/1/20 1:51 PM, Alan DeKok wrote:

> On Sep 1, 2020, at 5:19 AM, Arnaud LAURIOU <[hidden email]> wrote:
>> We have freeRADIUS proxies dedicated to eduroam, version 3.0.21.
>>
>> Some of our clients are sending us Access-Request ... with their realm.
>> We forward them to their home_server
>    Why?
>
>    The only packets you should get from Eduroam are ones for your realm.  All other packets should be rejected immediately.
>
> if (Realm != "renate.fr) {
> reject
> }
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.
>
>    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 ?

Regards,

Arnaud Lauriou
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Preventing proxy loops

Alan DeKok-2
On Sep 1, 2020, at 9:14 AM, Arnaud LAURIOU <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Preventing proxy loops

Alan Buxey
hi,

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

are they trying to monitor themselves via the national roaming proxies?

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

+1 for this - its how we dealt with initial loop prevention when
moving to RADSEC . i think theres an eduroam recipe for freeradius
lying around on the GÉANT confluence wiki somewhere

>   Monitoring packets shouldn't contain EAP-Message, so the above rule should catch only EAP authentication requests.

well, all non EAP should be blocked incoming at national proxy level
anyway so monitoring should be an EAP method just like real clients...

alan

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html