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

[Traiano Welcome]

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