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.