Depending on your hardware, you might want to try radsecproxy. It does currently have a 16 character password limit though Johan Meiring wrote:
Hi all,
The radius spec currently identifies a Nas (client) by the Nas's IP address (Packet-Src-Ip-Addres?). That is how radius works.
We have a bunch of hotspots out in the field which could be behind any kind of internet connection. Broadband/Dynamic IP, natted, etc.
Because we have no idea where a spesific Nas's traffic might come from we've implemented dynamic-clients. Using rlm_raw we use the Nas-Identifier to lookup the shared secret in a database, and the client gets dynamically created. (Thanks Alan for the help with this one!!)
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.
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.
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?
How difficult would such a change in Freeradius be? (I've not read the source code yet, just throwing an idea out there).
Opinions?
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.)