Proxy FreeRADIUS Monitoring from LB F5

[CALMELS, Thierry (SOGETI REGIONS SAS)]

I am trying to give you more details

The perl module has been enabled in '/etc/raddb/sites-available/default' as below

authenticate {
       
        Auth-Type Perl {
                perl
        }

authorize {
…
        files
        perl
        if (ok || updated) {
            update control {
            Auth-Type := Perl
            }
        }

The custom script perl is invoked since '/etc/raddb/mods-enabled/perl'
perl {
        …
        filename = ${modconfdir}/${.:instance}/radius_proxy.pl
…



>>This might not work if you're already using the "users" file to do other things.  But since you're not really describing what you're doing, I can't really help much more than that
I don't use the "users" file for anything else.
As you see the 'files' module was configured before 'perl'. But unfortunately this configuration (and your proposal) seems not suitable:(

KR
Thierry

-----Message d'origine-----
De : Freeradius-Users [mailto:freeradius-users-bounces+thierry.calmels.external=airbus.com at lists.freeradius.org] De la part de Alan DeKok
Envoyé : lundi 10 décembre 2018 16:36
À : FreeRadius users mailing list
Objet : Re: Proxy FreeRADIUS Monitoring from LB F5

On Dec 10, 2018, at 10:25 AM, CALMELS, Thierry (SOGETI REGIONS SAS) <thierry.calmels.external at airbus.com> wrote:
> 
> At my knowledge (I was not present at the beginning of project) the built-in proxy logic was not used, because it was not possible to trigger custom code and we are not able to manage realms regarding the constraints (NAS and RADIUS Solution migration).

  I'm not sure what that means, but OK...

> The proxy handles a script perl which only forward requests to the RADIUS A and if the reply is a REJECT, next send back the request to the RADIUS B.

  So you're not using the built-in proxy functionality.  Instead, you're using a Perl module that does the proxying.

  While this can work, I suspect it will have limited performance.

  We've re-engineered the "master" branch in github to support this functionality in a standard way.  It's not ready for an official release yet, but it does work.

> If you configure the proxy to reply to the F5 for local users, it should work.
> => How is possible to do it? 

  You didn't really describe what you *are* doing, or include any debug output.  So I'll have to guess.  Having *specific* information in your email helps us to give *specific* answers.  In contrast, vague questions result in vague answers.

  The issue is that you're *always* running the Perl script.  If you read the documentation and examples, you will see how to *conditionally* run modules.  Reading the debug output also helps.

  The solution should then be fairly straightforward.  You can edit the "authorize" section:

authorize {
	...
	files
	if (control:Auth-Type == "Accept") {
		perl
	}
	...
}

  i.e. run the "files" module. If it doesn't set "Auth-Type Accept", then run the perl module.

  This might not work if you're already using the "users" file to do other things.  But since you're not really describing what you're doing, I can't really help much more than that.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.