Proxy FreeRADIUS Monitoring from LB F5

[Alan DeKok]

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.