Hi, On 06.04.2017 15:07, Michael Schwartzkopff wrote:
But the DFN thinks there are stil some issues with FreeRADIUS 3 so that is why they advertise to use radsecproxy.
They did not tell me yet what the issues were, but as far as I understood they wanted to have a dynamic home server resolution based on realms in eduroam.
at least there seem to be interoperability issues between FR3 (3.0.12) and DFN's radsecproxy (1.6.8, I think). When trying to upgrade my old FR2 servers with FR3, I came cross this: - Proxy relationships are all configured old-style, i.e. with fixes shared secret and DNS CNAMEs (or even IP addresses) - When my traveling users want to use eduroam, all is fine with FR2 on my side. - When I replace it with my new FR3 VM (leaving outside view of CNAME/IP identical), my traveling users are unable to authenticate if and only if my FR3 server talking to DFN's radsecproxy is to terminate the request itself. If there is at least one Proxy step involved on my side, things are fine again. Debugging showed that for every client, the first Access-Request arrives and ist answered by Access-Challenge. The Access-Challenge is then discarded by the radsecproxy, for unknown reasons. Of course, this is not actual reason to recommend a radsecproxy at the boundary of every realm. But putting it in enables you to sort of kill two birds with one stone: You (and they) get the radsec benefits, and the weird issues described above are magically gone. For now, I simply put in the proxy step to get FR2 out of business. As soon as I have converted this to radsec, I will try and see if I can get some more information on that. Cheers, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg