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

2012-02-06 Thread Traiano Welcome
Hi List

I've configured my radius servers to send a copy of radius accounting
packets to a receiving radius server at  third party vendor, who will then
process radius accounting packets for billing purposes. I'm doing this
using an "AuthBy RADIUS" clause placed after an "AuthBy SQL" clause:

My configuration  is as follows (Thanks to, Heikki and Hugh!):

-

Identifier Accounting_Packet_Feed
Host 196.181.13.1
Secret  s3cr3t
RetryTimeout 30
AuthPort1812
AcctPort1813
NoForwardAuthentication


-

This is then used in a Handler, right after  as follows (
Identifier Accounting_Packet_Feed):

---


AuthByPolicy ContinueWhileAccept


DBSourcedbi:Pg:dbname=acctrecords;host=localhost
DBUsername  logmonkey
DBAuth  y34hr1ght
AuthSelect
AccountingTable acctrecords
AcctColumnDef nasidentifier,NAS-Identifier
AcctColumnDef timestamp,Timestamp

.
.
.

AuthBy Accounting_Packet_Feed
 .
---

In my AuthBy SQL statement, there are around 200 attributes defined,
however not all of them are being proxy'ed by the "AuthBy RADIUS" module,
especially, we're not seeing all the attributes being exported in the
accounting stop packets proxied to the third party vendor's radius server.

We see a lot of the following type of error in our logs associated with
our destination radius server:

---
.
WARNING: Bad authenticator received in reply to ID 153
.
WARNING: Unknown reply received in AuthRADIUS for request 153 from
196.181.13.1:1813 
.
---

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.


In addition, when I do a verbose tcpdump of packets received from my
proxying radius servers, I notice a lot  of this type of error:


  Vendor Specific Attribute (26), length: 8 (bogus, goes past end
of packet)
  Vendor Specific Attribute (26), length: 12 (bogus, goes past end
of packet)




My questions are as follows:


1. Is there any configuration that  must be applied to the 
module to ensure all the available  radius attributes in the original
accounting packet from the NASes are proxied in their exact state to the
final destination radius server ?
2. Are the  "(bogus, goes past end of packet)" messages anything to be
concerned about ?


Any help would be much appreciated!

Thanks in Advance,
Traiano














___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


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

2012-02-06 Thread Alan Buxey
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