Re-transmits arriving via a different proxy / EAP duplicate detection

alan buxey A.L.M.Buxey at
Tue Oct 9 20:17:10 CEST 2012


> As I iterate through our logging config, I'm gaining increasing
> visibility of all kinds of peculiar stuff. This one I spotted today
> - we are seeing remote RADIUS servers (eduroam visited sites)
> sending retransmits via different intermediate proxies.

I've seen this a couple of times int he past - and recently too. the recent
one was fixed by ensuring that the RADIUS server was listening only
on a particular IPv6 address - by default it was binding to all available
interfaces...and having 2 NICs, it has 2 IPv4 addresses and 2 IPv6 addresses...
the IPv4 had been bound to just eth1 as reuqired...but the IPv6 hadnt....
thus, whilst the request was arriving at eth1, responses were going out via eth0

> First, the FreeRADIUS duplicate detect / retransmit logic doesn't
> apply because the source IP, shared secret, Proxy-State and
> Message-Authenticator are all different, even though all other
> attributes are identical. This is correct behaviour AFAICT from the
> RFCs.

correct.....and the EAP session gets really broken 

> We're also generating a lot of logging and noise, though that's an
> internal problem.

thats a side effect of more 802.!x action - and one we too are dealing with locally
(locally, a campus site deals with far more traffic than other systems that
I deal with....the difference is that you have direct control over your NAS kit
and local infrastructure and can fix things..). we've already gone through several
iterations of optimising PGSQL, indexing, clearing and having 1st-line access
what they need etc.  doing dot1x/mab/webauth on switches just adds to the noise/mix.
...and the hundreds of misconfigured devices... certificate errors...TLS issues, wifi
causing problems with failed EAP etc. 


More information about the Freeradius-Users mailing list