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

[Christian Kratzer]

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.

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.

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.

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.

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