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
On Sep 1, 2020, at 5:19 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> 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.
On 9/1/20 1:51 PM, Alan DeKok wrote:
On Sep 1, 2020, at 5:19 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> 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
On Sep 1, 2020, at 9:14 AM, Arnaud LAURIOU <arnaud.lauriou@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.
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
participants (3)
-
Alan Buxey -
Alan DeKok -
Arnaud LAURIOU