OK, I know a lot of techies read this. My google skills must be lacking because I can't find this and it seems like it should exist.
When handling a PPP session the LNS will do a RADIUS request to a RADIUS server. It can answer with IP details to terminate the PPP. It can instead provide a set of tunnel endpoints and passwords to allow L2TP relay to another LNS...
What I want is a way to respond by RADIUS providing a list of RADIUS servers to go and try. This secondary RADIUS would get tunnel endpoints.
What I cannot find is the RADIUS access accept attributes to tell an LNS to go do another RADIUS check. If anyone knows this, do post or email me.
In the absence of an RFC for this I was planning to define another Tunnel-Type value for RADIUS. This would allow the preference ordered and grouped list of up to 32 RADIUS servers using the tagged Tunnel-Server-Endpoint, and Tunnel-Password, just like an L2TP situation but RADIUS. Technically RADIUS is not a "tunnel" type, but it seems to fit well. Indeed one could see a case for sending some RADIUS endpoints plus some L2TP endpoints all in the same reply where the L2TP endpoints are the last resort if RADIUS is not responding.
So, if anyone has any clues as to an RFC for this, that would be great :-)
Subscribe to:
Post Comments (Atom)
Breaking my heart
One of the things I suffer from is tachycardia. My first memory of this was in secondary school, when I got a flat tyre cycling to school an...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
I don't think what you're after exists, not least because this would require some means to set up the shared secrets between the original RADIUS client and the subsequently announced servers.
ReplyDeleteIs there any reason you can't proxy the RADIUS yourself to those extra servers? It's not that hard.
Various reasons to prefer this way, and not a problem to send the shared secret as tagged Tunnel-Password to the LNS.
ReplyDeleteBut I think you are right, I think people usually proxy the RADIUS to RADIUS rather than telling LNS to do it.
However, if you know how to make freeradius proxy it, and filter the response to only be tunnel data, then we could do that instead. This is mainly being done to make it easier for people doing the RADIUS initially using freeradius.
I would have thought that you'd internally proxy the packets that need to be proxied to the other RADIUS server via a different virtual radius server that has the correct attribute filter set. Choosing the right packets etc should be doable with a bit of unlang code if you can't do it by realm or other easily identifiable attributes.
ReplyDelete(I've not been using freeradius long, so this may not be the best way of doing it, but don't think it should be too hard.)
I don't know any way to do this other than the RADIUS server proxying the request to another server.
ReplyDelete