Johan Meiring wrote:
This works very well, but has a few irritating (not showstopping) side effects.
1) Sometimes we have more than one Nas behind the same natted connection. This means that they all have to have the same shared secret.
2) Also it happens that a different Nas ends up behind a previous Nas's IP (dynamically assigned broadband IP) and then the shared secret is again rejected.
Yup. That's a limitation of RADIUS.
Within a corporate/large telco's network, the Nas's (802.11x switches or Dslams) are generally behind fixed IPs, but for the hotspot world any Nas source IP goes.
Is it not a maybe a good idea to start considering a different "key" to identify the Nas by.
Use SSH, or SSL. Create an SSH or OpenVPN connection between the NAS and the server. That avoids most of the problems.
In clients.conf (or for dynamic clients) a paramter ("nas-key") that could be Src-IP or Nas-Id. i.e. you can choose the "key" that identifies a spesific Nas/client and therefore the shared secret.
Does it sound like a bad idea?
Yes. It means that it's even easier to spoof the packets.
How difficult would such a change in Freeradius be? (I've not read the source code yet, just throwing an idea out there).
It might not be hard... but it won't go into the main release.
Opinions?
Lots.
PS: I realise that tunneling the radius traffic is a different solution to the same problem, but in our case not always easy to implement. (The only extra "layer" I would love to see is RadSec.)
In progress. But that requires upgrading the NASes, too. That's much harder than upgrading FreeRADIUS. Alan DeKok.