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.bu...@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@open.com.au > http://www.open.com.au/mailman/listinfo/radiator > -- Christian Kratzer CK Software GmbH Email: c...@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 _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
