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

Traiano Welcome Traiano.Welcome at mtnbusiness.co.za
Tue Feb 7 09:13:02 CST 2012


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?

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



More information about the radiator mailing list