Hello Traiano - For testing purposes I would suggest using a Client clause in the configuration file so you know exactly what is happening.
For your ClientListSQL I'm not sure about using boolean for the field - I would suggest text instead. regards Hugh On 19 May 2012, at 19:47, Traiano Welcome wrote: > Hi Hugh > > Thanks for your response! > > I don't use the Client clause (I'm using the Handler clause to match > NAS-Identifiers), but I see one can use this in the ClientListSQL clause as > I've done below: > > --- > <ClientListSQL> > DBSource dbi:Pg:dbname=<hidden>;host=localhost > DBUsername <redacted> > DBAuth <obscured> > GetClientQuery select nas_ip,secret,ignoreacctsignature,dupinterval > from naslist > </ClientListSQL> > --- > > ... with a corresponding modification from my "naslist" table as follows: > > --- > Table "public.naslist" > > Column | Type | Modifiers > ---------------------+---------+-------------- > nas_ip | inet | not null > secret | text | not null > ignoreacctsignature | boolean | default true > dupinterval | integer | default 2 > hostname | text | > description | text | > --- > > Example: > > -- > nas_ip | secret | ignoreacctsignature | dupinterval > ----------------+-----------+---------------------+------------- > loa.dba.lan.cer | <redacted> | t | 2 > -- > > > However I'm still seeing the "WARNING: Bad authenticator in request from ..." > messages after restarting radius several times. How can I debug this further > ? > > I see the "IgnoreAcctSignature" is not supported in the Handler statement. > > Traiano > > > > ________________________________________ > From: Hugh Irvine [[email protected]] > Sent: Saturday, May 19, 2012 6:45 AM > To: Traiano Welcome > Cc: [email protected] > Subject: Re: [RADIATOR] (no subject) > > Hello Traiano - > > You can try setting "IgnoreAcctSignature" in the client clause in the Centos > Radiator configuration. > > See section 5.7.3 in the Radiator 4.9 reference manual ("doc/ref.pdf"). > > regards > > Hugh > > > On 19 May 2012, at 10:15, Traiano Welcome wrote: > >> Hi List >> >> I have a a 'cluster' of 5 Radiator radius servers behind a FreeBSD server >> running Radiator in load balancing configuration. The radius servers behind >> the load balancer do authentication and accounting, 4 of them are freebsd >> running in vmware VMs and the fifth is a CentOS physical host. While I see >> the FreeBSD radius auth/acct servers are handling requests correctly, >> logging accounting to a postgresql database, I am seeing all the accounting >> requests proxied via the load-balancer to the CentOS host fail with the >> following error in the logs: >> >> --- >> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from >> lo.ad.bal.ancer (na.s.100.20) >> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from >> lo.ad.bal.ancer (na.s.100.20) >> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from >> lo.ad.bal.ancer (na.s.0.100) >> Sat May 19 00:50:52 2012: WARNING: Bad authenticator in request from >> lo.ad.bal.ancer (na.s.0.100) >> --- >> >> No accounting packets are being logged to the postgresql database on the >> CentOS host, as a consequence (?) >> >> Normally I would expect this to be due to a mismatch in secrets between the >> NAS (here being the Radiator load balancer?) and the auth'ing/accounting >> radiator server, however the secret configured on the freebsd server is >> identical to that on the CentOS host and the radiator load balancer, and the >> FreeBSD radius server is auth'ing and accounting successfully. >> >> Running tcpdump on each system, I can see the following: >> >> - The FreeBSD load-balancer is sending accounting requests to the CentOS >> load balancer, but is seeing no responses in return >> - The CentOS auth/acct server is seeing requests from the load-balancer is >> not sending accounting response packets back to the load balancer >> - The FreeBSD auth/acct server is happily receiving accounting requests and >> sending responses from the load-balancer >> >> So free flow of radius packets between the load-balancer and the CentOS >> radiator server is unlikely to be the issues ... After, all, no responses >> are being sent out by the CentOS host in the first place. >> >> The details of the load balancer and the two radius accounting/auth servers >> behind it are as follows: >> >> 1) FreeBSD Load Balancer server (Radiator Configured as a load balancer) >> >> - FreeBSD 8.2-RELEASE-p6 #0 >> - PERL (v5.12.4) built for amd64-freebsd >> - p5-Digest-MD5-2.51 >> >> 2) FreeBSD Radiator server handling RADIUS packets from the Load Balancer >> (Radiator configured to auth from and account to a local postgresql database) >> >> - FreeBSD 8.2-RELEASE-p4 #2 >> - PERL (v5.12.4) built for amd64-freebsd-thread-multi >> - postgres (PostgreSQL) 8.4.10 >> - p5-Digest-MD5-2.51 >> >> 3) CentOS Radiator Server handling RADIUS packets from the Load Balancer >> (Radiator configured to auth from and account to a local postgresql database) >> >> - CentOS release 6.2 (Final), 2.6.32-220.el6.x86_64 #1 SMP >> - v5.10.1 (*) built for x86_64-linux-thread-multi >> - (PostgreSQL) 8.4.10 >> - Digest::MD5 (2.51) >> - perl-Net-SSLeay-1.35-9.el6.x86_64 >> - perl-Digest-HMAC-1.01-22.el6.noarch >> - perl-DBI-1.609-4.el6.x86_64 >> - perl-DBD-Pg-2.15.1-3.el6.x86_64 >> >> Attached are the radiator configurations for each of the above servers: >> >> 1. My FreeBSD Load balancer's Radiator configuration: >> 2. The Radiator configuration on a working freebsd server: >> 3. The Radiator configuration on the CentOS server: >> >> I've tried the following tests to confirm if this isn't a software/library >> issue: >> >> - reinstalled postgresql, Radiator and the associated PERL libraries a >> number of times, testing different combinations of package versions - no luck >> - tried CPAN perl libraries instead of the centos yum perl modules >> - installed radiator from source and using the rpm package >> - tried radiator 4.8 and 4.9 >> - Postgresl 8.4 and 9.2 from source and rpm >> - Confirmed database connectivity between Radiator and Postgresql >> - Upping the radiator Trace level to 5 doesn't reveal any actual details of >> possible cause of failure other than a dump of the radius accounting-request >> packet (that I can recognise anyway :p) >> >> I'd be grateful if someone could point out a likely cause of the CentOS >> Radiator servers non-response to accounting-requests, or suggest some >> additional detailed debugging techniques I could use? >> >> Let me know if I should send some packet traces in addition to the above! >> >> Many Thanks in advance! >> Traiano >> >> >> >> <freebsd-auth-acct-host-radiusd.cfg><freebsd-load-balancer-radiator.cfg><centos-host-radiusd.cfg>_______________________________________________ >> radiator mailing list >> [email protected] >> http://www.open.com.au/mailman/listinfo/radiator > > > -- > > Hugh Irvine > [email protected] > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER etc. > Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. > -- Hugh Irvine [email protected] Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
