Hi Christian
On 2012/02/07 5:41 PM, "Christian Kratzer" <ck-li...@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.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
