Alternate proxying methods.
A.Cudbard-Bell at sussex.ac.uk
Tue Apr 10 13:08:19 CEST 2007
> There was an implementation of it in 0.1 or 0.2, but it was removed
> because is caused a great many problems in the server core.
I had a feeling it might be that, it seems it would break with the
rather linear flow of freeradius.
>> I had assumed that it would copy the incoming packet to the realm specified
>> but also continue processing locally. This would really only be of use
>> for accounting packets.
> Yes. The suggestion now is to use "radrelay". It's more work, but it
> does the same thing.
*looks at man page* yes that'd do it !
Ah but this would send all the accounting data out to the jrs proxies,
for which jrs might not look on us
too kindly for . Only a relatively small amount of accounting data would
actually need to go off site...
for users from other institutions using our wireless AP's but
authenticating back at there home institutions.
The advantage of using a 'replicate-to-realm' like feature is that you
can filter the data being replicated, and direct it
to the proper home servers.
I was considering setting up an exec instance pointing to a shell script
which would forward the data via radclient.
> I *think* in 2.0 we can get radrelay to duplicate the functionality of
> Replicate-To-Realm without too much effort, but I'll have to spend some
> more time looking into it.
Yeah that would be cool, then you could synchronize all your accounting
data with multiple off/on-site radius servers.
Especially good for people relying on flat files as opposed to SQL
>> Yes so the actual function is fine, it's just the terminology. A more
>> accurate name might be 'Assign-To-Realm', and then once it's been
>> 'assigned' the internet logic of the realm
>> will decide where it's actually proxied to.
I swear my spell checker hates me.
More information about the Freeradius-Users