[RADIATOR] Proxying RADIUS Accounting Packets to Third Party Vendor: Not all Attributes proxied

[Traiano Welcome]

Hi Christian


On 2012/02/07 5:41 PM, "Christian Kratzer" <ck-lists at cksoft.de> wrote:

>Hi,
>
>On Tue, 7 Feb 2012, Traiano Welcome wrote:
>
>> Thanks, Alan! This seems to have worked. I've just had an ida though,
>>for
>> "mirroring" radius accounting packets to an upstream radius system,
>>which
>> might be easier than using  radiator  as a proxy, as follows: (On
>> FreeBSD), using packet mirroring functionality (e.g the pf mirroring
>> feature) to make a copy of the incoming radius accounting packets and
>> mirror them to an upstream radius server which requires a feed.
>>
>> Would this be an advisable alternative way of sending a radius packet
>>feed
>> to a third party, in this case ? What would be the gotchas?
>
>You would have to decode the packets with the secret they were encoded
>with and reencode them with the secret required by your other radius
>server.



Quite right, but if you used the same secret on the other (final
destination) radius server, I suppose this could be avoided ? Granted
you'll have to keep the secrets I synch across three points in this path
and this would make for a rather ugly setup Š




>
>You would also have to weed to duplicates resulting from resendes to
>your first radius server and you would need to handle resends for
>packets that got dropped and not acked by your destination radius
>server.


Indeed. This is exactly what would make this mechanism un-viable.


>
>All this makes a packet capture solution a whole lot harder than
>just using radius.
>
>Under high request load having a further radius to forward to and having
>to handle resends and acks for that other target might cause issues.


Of course, if you're proxying via radius, you also have additional load
issues to handle anyhow, whereas, from a load perspective mirroring
packets would be less resource intensive.


>
>I would consider spooling the radius requests into a separate file and
>use a script to send the spooled requests to the other radius from a
>separate process. This would isolate any issues you have with forwarding
>from you production setup.


This sounds very much like FreeRADIUS' "radrelay" concept, which
essentially the same thing. Does Radiator come with a standard script that
does this, or would I have to write my own?


>
>Greetings
>Christian Kratzer
>CK Software GmbH
>

>
>>
>> Many Thanks,
>> Traiano
>>
>>
>>
>> On 2012/02/06 6:02 PM, "Alan Buxey" <A.L.M.Buxey at lboro.ac.uk> wrote:
>>
>>> Hi,
>>>
>>>> WARNING: Bad authenticator received in reply to ID 153
>>>
>>> incorrect shared secret or badly munged UDP packets, or packets
>>> received after your local RADIUS server has already decided to forget
>>> about them (timeout)
>>>
>>>> I've confirmed the secret is the same between the proxying radius
>>>> servers
>>>> and the destination radius server, so this doesn't look like the
>>>>issue.
>>>
>>> Secret "whatever the secret is"
>>>
>>>
>>> ..then you never get undone by trailing spaces etc
>>>
>>>>           Vendor Specific Attribute (26), length: 8 (bogus, goes past
>>>> end
>>>> of packet)
>>>>           Vendor Specific Attribute (26), length: 12 (bogus, goes past
>>>> end
>>>> of packet)
>>>
>>> big big packets - larger than the MTU - change the size of your RADIUS
>>> packets
>>> to eg 1280 or so - the default in RADIATOR is big ...too big.  then the
>>> RADIUS
>>> will break the packets up nicely.
>>>
>>> hmm, theres EAPTLS_MaxFragmentSize to deal with EAP - not sure about
>>>what
>>> you tweak
>>> with plain RADIUS accounting packets that are big. maybe change the
>>>host
>>> MTU size?
>>>
>>> alan
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
>-- 
>Christian Kratzer                      CK Software GmbH
>Email:   ck at cksoft.de                  Wildberger Weg 24/2
>Phone:   +49 7032 893 997 - 0          D-71126 Gaeufelden
>Fax:     +49 7032 893 997 - 9          HRB 245288, Amtsgericht Stuttgart
>Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian
>Kratzer