Proxy FreeRADIUS Monitoring from LB F5

classic Classic list List threaded Threaded
15 messages Options
| Threaded
Open this post in threaded view
|

Proxy FreeRADIUS Monitoring from LB F5

CALMELS, Thierry (SOGETI REGIONS SAS)
Hello freeradius support team,

We have an infrastucture using freeRadius 3 (freeradius-3.0.13-8) on RHEL7.5.

The infrastructure implements in front a layer “PROXY RADIUS” (not based on proxy.conf usage – thus we are using a custom proxy logic).
The infrastructure works as expected.

The architecture is as follow:

Client NAS --> LB BigIP F5 --> Proxy FreeRADIUS --> LB BigIP F5 --> BackEnd FreeRADIUS

However we want to improve monitoring made by F5 in front of the layer proxy Radius.
For that, we have configured a Radius profile on the F5, based on username/password declared in the /etc/raddb/users files.

healthcheckVIP   Auth-Type:=Accept, User-Password=="my_password "

Unfortunately, this configuration works only if the healthcheckVIP account is declared on the BackEnd FreeRADIUS!
The account declared on Proxy is not taken in account.
I didn’t find any solution/setting to block the radius request at layer proxy when the account is found and credentials confirmed.

Thank a lot for your support

Thierry
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[cid:image003.png@01D304A6.07AEE120]

Thierry CALMELS
On behalf of SOGETI France
Subcontractor for ZIOI
AIRBUS OPERATIONS S.A.S.

France – Toulouse – Sogeti – Airbus Zone

Phone: +33 (0)5 67 19 65 55
Mailto: [hidden email]<mailto:[hidden email]>

Join us on the IAM community<https://communities.intra.corp/sites/CAM/Default.aspx>!

P Before printing, think about the environment      --o-o-Ộ-o-o--

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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

image001.png (18K) Download Attachment
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
On Dec 9, 2018, at 2:17 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
> We have an infrastucture using freeRadius 3 (freeradius-3.0.13-8) on RHEL7.5.
>
> The infrastructure implements in front a layer “PROXY RADIUS” (not based on proxy.conf usage – thus we are using a custom proxy logic).
> The infrastructure works as expected.
>
> The architecture is as follow:
>
> Client NAS --> LB BigIP F5 --> Proxy FreeRADIUS --> LB BigIP F5 --> BackEnd FreeRADIUS

  I'm not sure why you need two F5s, but OK.

> However we want to improve monitoring made by F5 in front of the layer proxy Radius.
> For that, we have configured a Radius profile on the F5, based on username/password declared in the /etc/raddb/users files.
>
> healthcheckVIP   Auth-Type:=Accept, User-Password=="my_password "
>
> Unfortunately, this configuration works only if the healthcheckVIP account is declared on the BackEnd FreeRADIUS!

  Only if you configure the proxy to send *all* traffic to the backend.

  If you configure the proxy to reply to the F5 for local users, it should work.  

> The account declared on Proxy is not taken in account.
> I didn’t find any solution/setting to block the radius request at layer proxy when the account is found and credentials confirmed.

  You didn't say how *else* you configured the server.  i.e. how did you configure it to proxy requests?

  You're not using proxy.conf, so what *are* you using?

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: Proxy FreeRADIUS Monitoring from LB F5

CALMELS, Thierry (SOGETI REGIONS SAS)
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).
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.

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

KR
Thierry

-----Message d'origine-----
De : Freeradius-Users [mailto:freeradius-users-bounces+thierry.calmels.external=[hidden email]] De la part de Alan DeKok
Envoyé : dimanche 9 décembre 2018 21:32
À : FreeRadius users mailing list
Objet : Re: Proxy FreeRADIUS Monitoring from LB F5

On Dec 9, 2018, at 2:17 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
> We have an infrastucture using freeRadius 3 (freeradius-3.0.13-8) on RHEL7.5.
>
> The infrastructure implements in front a layer “PROXY RADIUS” (not based on proxy.conf usage – thus we are using a custom proxy logic).
> The infrastructure works as expected.
>
> The architecture is as follow:
>
> Client NAS --> LB BigIP F5 --> Proxy FreeRADIUS --> LB BigIP F5 --> BackEnd FreeRADIUS

  I'm not sure why you need two F5s, but OK.

> However we want to improve monitoring made by F5 in front of the layer proxy Radius.
> For that, we have configured a Radius profile on the F5, based on username/password declared in the /etc/raddb/users files.
>
> healthcheckVIP   Auth-Type:=Accept, User-Password=="my_password "
>
> Unfortunately, this configuration works only if the healthcheckVIP account is declared on the BackEnd FreeRADIUS!

  Only if you configure the proxy to send *all* traffic to the backend.

  If you configure the proxy to reply to the F5 for local users, it should work.  

> The account declared on Proxy is not taken in account.
> I didn’t find any solution/setting to block the radius request at layer proxy when the account is found and credentials confirmed.

  You didn't say how *else* you configured the server.  i.e. how did you configure it to proxy requests?

  You're not using proxy.conf, so what *are* you using?

  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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
On Dec 10, 2018, at 10:25 AM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> 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
| Threaded
Open this post in threaded view
|

RE: 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=[hidden email]] 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) <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
On Dec 10, 2018, at 4:11 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
>
> I am trying to give you more details

  That's good.

> The perl module has been enabled in '/etc/raddb/sites-available/default' as below
>
> authenticate {
>
>        Auth-Type Perl {
>                perl
>        }

  OK...

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

  Which forces the server to use "Auth-Type perl" if the "perl" module returns "ok || updated"

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

  That's fine.

>
>
>
>>> 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:(

  The configuration you posted here is *not* what I proposed that you use.

  Please go back and read my message again.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: Proxy FreeRADIUS Monitoring from LB F5

CALMELS, Thierry (SOGETI REGIONS SAS)
Hello Alan


>The configuration you posted here is *not* what I proposed that you use.
>Please go back and read my message again.

I reviewed your answer and I updated as you advise but without success.

The configuration which is working is the below one with the conditional on User-Name.
I don't find it very sexy!

files
if (&User-Name != 'healthcheckVIP') {
        perl
        if (ok || updated) {
            update control {
                Auth-Type := Perl
            }
        }
}

================
I tried to make something like that, but I got the error saying the Auth-Type is not defined.

files
If (notfound) {
                Perl
....
}


Thank a lot for your support


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

On Dec 10, 2018, at 4:11 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
>
> I am trying to give you more details

  That's good.

> The perl module has been enabled in '/etc/raddb/sites-available/default' as below
>
> authenticate {
>
>        Auth-Type Perl {
>                perl
>        }

  OK...

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

  Which forces the server to use "Auth-Type perl" if the "perl" module returns "ok || updated"

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

  That's fine.

>
>
>
>>> 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:(

  The configuration you posted here is *not* what I proposed that you use.

  Please go back and read my message again.

  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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
On Dec 16, 2018, at 2:32 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:

>> The configuration you posted here is *not* what I proposed that you use.
>> Please go back and read my message again.
>
> I reviewed your answer and I updated as you advise but without success.
>
> The configuration which is working is the below one with the conditional on User-Name.
> I don't find it very sexy!
>
> files
> if (&User-Name != 'healthcheckVIP') {

  OK, I really dislike this whole process of giving tiny bits of information.  It wastes everyone's time.

  This is the *first* time you mentioned that there's a "healthcheckVIP" user name.  If you had said that at the START of the conversation, I would have been able to give you better advice.

  If you want good answers, ask good questions.  Your questions are vague, and generally don't include relevant information.

>        perl

  What does this do?  You haven't said.

>        if (ok || updated) {
>            update control {
>                Auth-Type := Perl
>            }
>        }
> }
>
> ================
> I tried to make something like that, but I got the error saying the Auth-Type is not defined.

  <sigh>  If only there was some kind of debug output which you could post to the list, so that *experts* could read it and give you useful advice.

  You're trying to solve the problem without describing it in any detail.  That isn't good.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: Proxy FreeRADIUS Monitoring from LB F5

CALMELS, Thierry (SOGETI REGIONS SAS)
Happy new year Alan,

As new resolution, I decided to re-contact you about the same topic^^
Below, the old thread.

>This is the *first* time you mentioned that there's a "healthcheckVIP" user name.  If you had said that at the START of the conversation, I would have been able to give you better advice.
Not really - this username was mentioned in my first mail. This username (+password+PSK) are configured on LB F5 in front of the RADIUS PROXY.

>If only there was some kind of debug output which you could post to the list, so that *experts* could read it and give you useful advice
Below a trace involving the local user "healthcheckVIP".

Reminder: the aim is to validate that the condition on &User-Name is acceptable or not. The functional test made by the LB is OK but the implementation on RADIUS side can be improved....
Without this condition, I don't understand why although the user was find in files repository, we chain to the perl module...  

Thu Jan  3 15:05:12 2019 : Debug: (2) Received Access-Request Id 152 from 11.126.112.186:38553 to 11.126.109.241:1812 length 95
Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Name = "healthcheckVIP"
Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Password = "xxxxxxxxxx"
Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-IP-Address = 11.147.11.193
Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-Identifier = "m880gbigip1-val.fr.eu.airbus.corp"
Thu Jan  3 15:05:12 2019 : Debug: (2) session-state: No State attribute
Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section authorize from file /etc/raddb/sites-enabled/default
Thu Jan  3 15:05:12 2019 : Debug: (2)   authorize {
Thu Jan  3 15:05:12 2019 : Debug: (2)     policy filter_username {
Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name) {
Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  -> TRUE
Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  {
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /) {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /)  -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/ ) {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/ )  -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ ) {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ )  -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/))  {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/))   -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)  {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)   -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)  {
Thu Jan  3 15:05:12 2019 : Debug: No matches
Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)   -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)       } # if (&User-Name)  = notfound
Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy filter_username = notfound
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling preprocess (rlm_preprocess)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from preprocess (rlm_preprocess)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [preprocess] = ok
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling chap (rlm_chap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from chap (rlm_chap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [chap] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling mschap (rlm_mschap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from mschap (rlm_mschap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [mschap] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling digest (rlm_digest)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from digest (rlm_digest)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [digest] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling suffix (rlm_realm)
Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: Checking for suffix after "@"
Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No '@' in User-Name = "healthcheckVIP", looking up realm NULL
Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No such realm "NULL"
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from suffix (rlm_realm)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [suffix] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling eap (rlm_eap)
Thu Jan  3 15:05:12 2019 : Debug: (2) eap: No EAP-Message, not doing EAP
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from eap (rlm_eap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [eap] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling files (rlm_files)
Thu Jan  3 15:05:12 2019 : Warning: Found User-Password == "..."
Thu Jan  3 15:05:12 2019 : Warning: Are you sure you don't mean Cleartext-Password?
Thu Jan  3 15:05:12 2019 : Warning: See "man rlm_pap" for more information
Thu Jan  3 15:05:12 2019 : Debug: (2) files: users: Matched entry healthcheckVIP at line 91
Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: FROM 0 TO 0 MAX 0
Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: TO in 0 out 0
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from files (rlm_files)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [files] = ok
Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name != 'healthcheckVIP' && &User-Name != 'monitoringUser') {
Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name != 'healthcheckVIP' && &User-Name != 'monitoringUser')  -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling expiration (rlm_expiration)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from expiration (rlm_expiration)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [expiration] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling logintime (rlm_logintime)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from logintime (rlm_logintime)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [logintime] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling pap (rlm_pap)
Thu Jan  3 15:05:12 2019 : WARNING: (2) pap: Auth-Type already set.  Not setting to PAP
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned from pap (rlm_pap)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [pap] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)   } # authorize = ok
Thu Jan  3 15:05:12 2019 : Debug: (2) Found Auth-Type = Accept
Thu Jan  3 15:05:12 2019 : Debug: (2) Auth-Type = Accept, accepting the user
Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section post-auth from file /etc/raddb/sites-enabled/default
Thu Jan  3 15:05:12 2019 : Debug: (2)   post-auth {
Thu Jan  3 15:05:12 2019 : Debug: (2)     update {
Thu Jan  3 15:05:12 2019 : Debug: (2)       No attributes updated
Thu Jan  3 15:05:12 2019 : Debug: (2)     } # update = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: calling exec (rlm_exec)
Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: returned from exec (rlm_exec)
Thu Jan  3 15:05:12 2019 : Debug: (2)     [exec] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     policy remove_reply_message_if_eap {
Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message && &reply:Reply-Message) {
Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
Thu Jan  3 15:05:12 2019 : Debug: (2)       else {
Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]: calling noop (rlm_always)
Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]: returned from noop (rlm_always)
Thu Jan  3 15:05:12 2019 : Debug: (2)         [noop] = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)       } # else = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy remove_reply_message_if_eap = noop
Thu Jan  3 15:05:12 2019 : Debug: (2)   } # post-auth = noop
Thu Jan  3 15:05:12 2019 : Auth: (2) Login OK: [healthcheckVIP] (from client radius-proxy-v port 0)
Thu Jan  3 15:05:12 2019 : Debug: (2) Sent Access-Accept Id 152 from 11.126.109.241:1812 to 11.126.112.186:38553 length 0
Thu Jan  3 15:05:12 2019 : Debug: (2) Finished request


>        perl
>  What does this do?  You haven't said.
This custom script is *ONLY* used as pass-throughs to forward the requests to the server RADIUS 1 and if the reply is REJECT then the request is sent in failover to server RADIUS 2.  

Thx for your patience

-----Message d'origine-----
De : Freeradius-Users [mailto:freeradius-users-bounces+thierry.calmels.external=[hidden email]] De la part de Alan DeKok
Envoyé : lundi 17 décembre 2018 14:20
À : FreeRadius users mailing list
Objet : Re: Proxy FreeRADIUS Monitoring from LB F5

On Dec 16, 2018, at 2:32 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:

>> The configuration you posted here is *not* what I proposed that you use.
>> Please go back and read my message again.
>
> I reviewed your answer and I updated as you advise but without success.
>
> The configuration which is working is the below one with the conditional on User-Name.
> I don't find it very sexy!
>
> files
> if (&User-Name != 'healthcheckVIP') {

  OK, I really dislike this whole process of giving tiny bits of information.  It wastes everyone's time.

  This is the *first* time you mentioned that there's a "healthcheckVIP" user name.  If you had said that at the START of the conversation, I would have been able to give you better advice.

  If you want good answers, ask good questions.  Your questions are vague, and generally don't include relevant information.

>        perl

  What does this do?  You haven't said.

>        if (ok || updated) {
>            update control {
>                Auth-Type := Perl
>            }
>        }
> }
>
> ================
> I tried to make something like that, but I got the error saying the Auth-Type is not defined.

  <sigh>  If only there was some kind of debug output which you could post to the list, so that *experts* could read it and give you useful advice.

  You're trying to solve the problem without describing it in any detail.  That isn't good.

  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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan Buxey
hi,

found in user file because "files: users: Matched entry healthcheckVIP at
line 91" . - whats in line 91 of your users file?

I would adjust the check.... how often is this health check running? Your
check should be reversed, I think, such that if its
the monitoring user-name then you do X, else do Y.   but another thing -
the monitor user will have specific other attributes
that the normal traffic wont have - the NAS-IP-Address or such..you also
want that in as a check item for your logic - be specific
as possible for your health check... would be even better if you could
direct that to its own virtual server but maybe thats too much to ask for.

alan

On Thu, 3 Jan 2019 at 14:50, CALMELS, Thierry (SOGETI REGIONS SAS) <
[hidden email]> wrote:

> Happy new year Alan,
>
> As new resolution, I decided to re-contact you about the same topic^^
> Below, the old thread.
>
> >This is the *first* time you mentioned that there's a "healthcheckVIP"
> user name.  If you had said that at the START of the conversation, I would
> have been able to give you better advice.
> Not really - this username was mentioned in my first mail. This username
> (+password+PSK) are configured on LB F5 in front of the RADIUS PROXY.
>
> >If only there was some kind of debug output which you could post to the
> list, so that *experts* could read it and give you useful advice
> Below a trace involving the local user "healthcheckVIP".
>
> Reminder: the aim is to validate that the condition on &User-Name is
> acceptable or not. The functional test made by the LB is OK but the
> implementation on RADIUS side can be improved....
> Without this condition, I don't understand why although the user was find
> in files repository, we chain to the perl module...
>
> Thu Jan  3 15:05:12 2019 : Debug: (2) Received Access-Request Id 152 from
> 11.126.112.186:38553 to 11.126.109.241:1812 length 95
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Name = "healthcheckVIP"
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Password = "xxxxxxxxxx"
> Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-IP-Address = 11.147.11.193
> Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-Identifier =
> "m880gbigip1-val.fr.eu.airbus.corp"
> Thu Jan  3 15:05:12 2019 : Debug: (2) session-state: No State attribute
> Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section authorize from
> file /etc/raddb/sites-enabled/default
> Thu Jan  3 15:05:12 2019 : Debug: (2)   authorize {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     policy filter_username {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name) {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  -> TRUE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  {
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /)  ->
> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> ) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> )  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ ) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ )
> -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> (&User-Name !~ /@(.+)\.(.+)$/))  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> (&User-Name !~ /@(.+)\.(.+)$/))   -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)
>  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)
>  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       } # if (&User-Name)  = notfound
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy filter_username =
> notfound
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> preprocess (rlm_preprocess)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from preprocess (rlm_preprocess)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [preprocess] = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> chap (rlm_chap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from chap (rlm_chap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [chap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> mschap (rlm_mschap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from mschap (rlm_mschap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [mschap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> digest (rlm_digest)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from digest (rlm_digest)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [digest] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> suffix (rlm_realm)
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: Checking for suffix after "@"
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No '@' in User-Name =
> "healthcheckVIP", looking up realm NULL
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No such realm "NULL"
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from suffix (rlm_realm)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [suffix] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> eap (rlm_eap)
> Thu Jan  3 15:05:12 2019 : Debug: (2) eap: No EAP-Message, not doing EAP
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from eap (rlm_eap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [eap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> files (rlm_files)
> Thu Jan  3 15:05:12 2019 : Warning: Found User-Password == "..."
> Thu Jan  3 15:05:12 2019 : Warning: Are you sure you don't mean
> Cleartext-Password?
> Thu Jan  3 15:05:12 2019 : Warning: See "man rlm_pap" for more information
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: users: Matched entry
> healthcheckVIP at line 91
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: FROM 0 TO 0 MAX 0
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: TO in 0 out 0
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from files (rlm_files)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [files] = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> 'healthcheckVIP' && &User-Name != 'monitoringUser') {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> 'healthcheckVIP' && &User-Name != 'monitoringUser')  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> expiration (rlm_expiration)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from expiration (rlm_expiration)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [expiration] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> logintime (rlm_logintime)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from logintime (rlm_logintime)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [logintime] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> pap (rlm_pap)
> Thu Jan  3 15:05:12 2019 : WARNING: (2) pap: Auth-Type already set.  Not
> setting to PAP
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from pap (rlm_pap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [pap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)   } # authorize = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2) Found Auth-Type = Accept
> Thu Jan  3 15:05:12 2019 : Debug: (2) Auth-Type = Accept, accepting the
> user
> Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section post-auth from
> file /etc/raddb/sites-enabled/default
> Thu Jan  3 15:05:12 2019 : Debug: (2)   post-auth {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     update {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       No attributes updated
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # update = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: calling
> exec (rlm_exec)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: returned
> from exec (rlm_exec)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [exec] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     policy
> remove_reply_message_if_eap {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> &reply:Reply-Message) {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> &reply:Reply-Message)  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       else {
> Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> calling noop (rlm_always)
> Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> returned from noop (rlm_always)
> Thu Jan  3 15:05:12 2019 : Debug: (2)         [noop] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)       } # else = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy
> remove_reply_message_if_eap = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)   } # post-auth = noop
> Thu Jan  3 15:05:12 2019 : Auth: (2) Login OK: [healthcheckVIP] (from
> client radius-proxy-v port 0)
> Thu Jan  3 15:05:12 2019 : Debug: (2) Sent Access-Accept Id 152 from
> 11.126.109.241:1812 to 11.126.112.186:38553 length 0
> Thu Jan  3 15:05:12 2019 : Debug: (2) Finished request
>
>
> >        perl
> >  What does this do?  You haven't said.
> This custom script is *ONLY* used as pass-throughs to forward the requests
> to the server RADIUS 1 and if the reply is REJECT then the request is sent
> in failover to server RADIUS 2.
>
> Thx for your patience
>
> -----Message d'origine-----
> De : Freeradius-Users [mailto:
> freeradius-users-bounces+thierry.calmels.external=
> [hidden email]] De la part de Alan DeKok
> Envoyé : lundi 17 décembre 2018 14:20
> À : FreeRadius users mailing list
> Objet : Re: Proxy FreeRADIUS Monitoring from LB F5
>
> On Dec 16, 2018, at 2:32 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <
> [hidden email]> wrote:
> >> The configuration you posted here is *not* what I proposed that you use.
> >> Please go back and read my message again.
> >
> > I reviewed your answer and I updated as you advise but without success.
> >
> > The configuration which is working is the below one with the conditional
> on User-Name.
> > I don't find it very sexy!
> >
> > files
> > if (&User-Name != 'healthcheckVIP') {
>
>   OK, I really dislike this whole process of giving tiny bits of
> information.  It wastes everyone's time.
>
>   This is the *first* time you mentioned that there's a "healthcheckVIP"
> user name.  If you had said that at the START of the conversation, I would
> have been able to give you better advice.
>
>   If you want good answers, ask good questions.  Your questions are vague,
> and generally don't include relevant information.
>
> >        perl
>
>   What does this do?  You haven't said.
>
> >        if (ok || updated) {
> >            update control {
> >                Auth-Type := Perl
> >            }
> >        }
> > }
> >
> > ================
> > I tried to make something like that, but I got the error saying the
> Auth-Type is not defined.
>
>   <sigh>  If only there was some kind of debug output which you could post
> to the list, so that *experts* could read it and give you useful advice.
>
>   You're trying to solve the problem without describing it in any detail.
> That isn't good.
>
>   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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
In reply to this post by CALMELS, Thierry (SOGETI REGIONS SAS)
On Jan 3, 2019, at 9:50 AM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
>> This is the *first* time you mentioned that there's a "healthcheckVIP" user name.  If you had said that at the START of the conversation, I would have been able to give you better advice.
> Not really - this username was mentioned in my first mail. This username (+password+PSK) are configured on LB F5 in front of the RADIUS PROXY.

  I went back and looked before I had sent that message.  I didn't see it

>> If only there was some kind of debug output which you could post to the list, so that *experts* could read it and give you useful advice
> Below a trace involving the local user "healthcheckVIP".
>
> Reminder: the aim is to validate that the condition on &User-Name is acceptable or not. The functional test made by the LB is OK but the implementation on RADIUS side can be improved....
> Without this condition, I don't understand why although the user was find in files repository, we chain to the perl module...  

  The problem is we're playing a game of "twenty questions" here.  You're giving little bits of information in each message.  You're not *fully* describing what you want.

  When you make it hard for me to help you, I'm inclined to just give up.  Such as this:

> Thu Jan  3 15:05:12 2019 : Debug: (2) Received Access-Request Id 152 from 11.126.112.186:38553 to 11.126.109.241:1812 length 95
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Name = "healthcheckVIP"
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Password = "xxxxxxxxxx"

  Really?  *ALL* of the documentation says to post "radiusd -X".  Not "-XXXxxxxxxx".

  When it's clear you're not following the documentation *and* are making it hard for me to help you, that's frustrating.  Why do this?

  You're in the classic problem of trying all kinds of different solutions, when you don't have a clear description of the problem.  Write down a clear description of the problem, and the solution should be pretty simple:

* When the server gets an Access-Request from the F5 IP
  AND the Access-Request contains User-Name == "healthcheckVIP"
  AND the User-Password is XXX
  THEN return Access-Accept containing .... attributes.

  You can write that down almost exactly like that in "unlang", with a few simple "if" statements, and an "update" section.  It really is that simple.

  Stop trying to understand whatever complex solution you've come up with.  It's clearly not working.  In large part because you don't have a clear description of the problem, *and* because you're not clear on how the server works.

  It really is that simple:  IF A && B && C then D.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: Proxy FreeRADIUS Monitoring from LB F5

CALMELS, Thierry (SOGETI REGIONS SAS)
In reply to this post by Alan Buxey
Hi,

The line 91 contains the user declaration (healthcheckVIP).
The healtcheck is done every 10s.
I reversed the check and I think it's better.
About other specific attribute, you suggest to use the NAS-IP-Address for example in place of User-Name ?..
About the usage of virtual server, I saw that the VS do NOT have to be set up with the "sites-available" and "sites-enabled" directories meaning the configuration must be moved to radiusd.conf. Not easy to do that for the time being without validating again the entire configuration.

Kr
Thierry

-----Message d'origine-----
De : Freeradius-Users [mailto:freeradius-users-bounces+thierry.calmels.external=[hidden email]] De la part de Alan Buxey
Envoyé : jeudi 3 janvier 2019 15:59
À : FreeRadius users mailing list
Objet : Re: Proxy FreeRADIUS Monitoring from LB F5

hi,

found in user file because "files: users: Matched entry healthcheckVIP at
line 91" . - whats in line 91 of your users file?

I would adjust the check.... how often is this health check running? Your
check should be reversed, I think, such that if its
the monitoring user-name then you do X, else do Y.   but another thing -
the monitor user will have specific other attributes
that the normal traffic wont have - the NAS-IP-Address or such..you also
want that in as a check item for your logic - be specific
as possible for your health check... would be even better if you could
direct that to its own virtual server but maybe thats too much to ask for.

alan

On Thu, 3 Jan 2019 at 14:50, CALMELS, Thierry (SOGETI REGIONS SAS) <
[hidden email]> wrote:

> Happy new year Alan,
>
> As new resolution, I decided to re-contact you about the same topic^^
> Below, the old thread.
>
> >This is the *first* time you mentioned that there's a "healthcheckVIP"
> user name.  If you had said that at the START of the conversation, I would
> have been able to give you better advice.
> Not really - this username was mentioned in my first mail. This username
> (+password+PSK) are configured on LB F5 in front of the RADIUS PROXY.
>
> >If only there was some kind of debug output which you could post to the
> list, so that *experts* could read it and give you useful advice
> Below a trace involving the local user "healthcheckVIP".
>
> Reminder: the aim is to validate that the condition on &User-Name is
> acceptable or not. The functional test made by the LB is OK but the
> implementation on RADIUS side can be improved....
> Without this condition, I don't understand why although the user was find
> in files repository, we chain to the perl module...
>
> Thu Jan  3 15:05:12 2019 : Debug: (2) Received Access-Request Id 152 from
> 11.126.112.186:38553 to 11.126.109.241:1812 length 95
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Name = "healthcheckVIP"
> Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Password = "xxxxxxxxxx"
> Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-IP-Address = 11.147.11.193
> Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-Identifier =
> "m880gbigip1-val.fr.eu.airbus.corp"
> Thu Jan  3 15:05:12 2019 : Debug: (2) session-state: No State attribute
> Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section authorize from
> file /etc/raddb/sites-enabled/default
> Thu Jan  3 15:05:12 2019 : Debug: (2)   authorize {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     policy filter_username {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name) {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  -> TRUE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  {
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /)  ->
> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> ) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> )  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ ) {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ )
> -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> (&User-Name !~ /@(.+)\.(.+)$/))  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> (&User-Name !~ /@(.+)\.(.+)$/))   -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)
>  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)  {
> Thu Jan  3 15:05:12 2019 : Debug: No matches
> Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)
>  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       } # if (&User-Name)  = notfound
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy filter_username =
> notfound
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> preprocess (rlm_preprocess)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from preprocess (rlm_preprocess)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [preprocess] = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> chap (rlm_chap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from chap (rlm_chap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [chap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> mschap (rlm_mschap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from mschap (rlm_mschap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [mschap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> digest (rlm_digest)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from digest (rlm_digest)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [digest] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> suffix (rlm_realm)
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: Checking for suffix after "@"
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No '@' in User-Name =
> "healthcheckVIP", looking up realm NULL
> Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No such realm "NULL"
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from suffix (rlm_realm)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [suffix] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> eap (rlm_eap)
> Thu Jan  3 15:05:12 2019 : Debug: (2) eap: No EAP-Message, not doing EAP
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from eap (rlm_eap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [eap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> files (rlm_files)
> Thu Jan  3 15:05:12 2019 : Warning: Found User-Password == "..."
> Thu Jan  3 15:05:12 2019 : Warning: Are you sure you don't mean
> Cleartext-Password?
> Thu Jan  3 15:05:12 2019 : Warning: See "man rlm_pap" for more information
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: users: Matched entry
> healthcheckVIP at line 91
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: FROM 0 TO 0 MAX 0
> Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: TO in 0 out 0
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from files (rlm_files)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [files] = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> 'healthcheckVIP' && &User-Name != 'monitoringUser') {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> 'healthcheckVIP' && &User-Name != 'monitoringUser')  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> expiration (rlm_expiration)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from expiration (rlm_expiration)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [expiration] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> logintime (rlm_logintime)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from logintime (rlm_logintime)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [logintime] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> pap (rlm_pap)
> Thu Jan  3 15:05:12 2019 : WARNING: (2) pap: Auth-Type already set.  Not
> setting to PAP
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> from pap (rlm_pap)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [pap] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)   } # authorize = ok
> Thu Jan  3 15:05:12 2019 : Debug: (2) Found Auth-Type = Accept
> Thu Jan  3 15:05:12 2019 : Debug: (2) Auth-Type = Accept, accepting the
> user
> Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section post-auth from
> file /etc/raddb/sites-enabled/default
> Thu Jan  3 15:05:12 2019 : Debug: (2)   post-auth {
> Thu Jan  3 15:05:12 2019 : Debug: (2)     update {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       No attributes updated
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # update = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: calling
> exec (rlm_exec)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: returned
> from exec (rlm_exec)
> Thu Jan  3 15:05:12 2019 : Debug: (2)     [exec] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     policy
> remove_reply_message_if_eap {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> &reply:Reply-Message) {
> Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> &reply:Reply-Message)  -> FALSE
> Thu Jan  3 15:05:12 2019 : Debug: (2)       else {
> Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> calling noop (rlm_always)
> Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> returned from noop (rlm_always)
> Thu Jan  3 15:05:12 2019 : Debug: (2)         [noop] = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)       } # else = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy
> remove_reply_message_if_eap = noop
> Thu Jan  3 15:05:12 2019 : Debug: (2)   } # post-auth = noop
> Thu Jan  3 15:05:12 2019 : Auth: (2) Login OK: [healthcheckVIP] (from
> client radius-proxy-v port 0)
> Thu Jan  3 15:05:12 2019 : Debug: (2) Sent Access-Accept Id 152 from
> 11.126.109.241:1812 to 11.126.112.186:38553 length 0
> Thu Jan  3 15:05:12 2019 : Debug: (2) Finished request
>
>
> >        perl
> >  What does this do?  You haven't said.
> This custom script is *ONLY* used as pass-throughs to forward the requests
> to the server RADIUS 1 and if the reply is REJECT then the request is sent
> in failover to server RADIUS 2.
>
> Thx for your patience
>
> -----Message d'origine-----
> De : Freeradius-Users [mailto:
> freeradius-users-bounces+thierry.calmels.external=
> [hidden email]] De la part de Alan DeKok
> Envoyé : lundi 17 décembre 2018 14:20
> À : FreeRadius users mailing list
> Objet : Re: Proxy FreeRADIUS Monitoring from LB F5
>
> On Dec 16, 2018, at 2:32 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <
> [hidden email]> wrote:
> >> The configuration you posted here is *not* what I proposed that you use.
> >> Please go back and read my message again.
> >
> > I reviewed your answer and I updated as you advise but without success.
> >
> > The configuration which is working is the below one with the conditional
> on User-Name.
> > I don't find it very sexy!
> >
> > files
> > if (&User-Name != 'healthcheckVIP') {
>
>   OK, I really dislike this whole process of giving tiny bits of
> information.  It wastes everyone's time.
>
>   This is the *first* time you mentioned that there's a "healthcheckVIP"
> user name.  If you had said that at the START of the conversation, I would
> have been able to give you better advice.
>
>   If you want good answers, ask good questions.  Your questions are vague,
> and generally don't include relevant information.
>
> >        perl
>
>   What does this do?  You haven't said.
>
> >        if (ok || updated) {
> >            update control {
> >                Auth-Type := Perl
> >            }
> >        }
> > }
> >
> > ================
> > I tried to make something like that, but I got the error saying the
> Auth-Type is not defined.
>
>   <sigh>  If only there was some kind of debug output which you could post
> to the list, so that *experts* could read it and give you useful advice.
>
>   You're trying to solve the problem without describing it in any detail.
> That isn't good.
>
>   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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan DeKok-2
On Jan 7, 2019, at 12:06 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <[hidden email]> wrote:
>
> The line 91 contains the user declaration (healthcheckVIP).
> The healtcheck is done every 10s.
> I reversed the check and I think it's better.

  i.e. made a random change without understanding it.

  Thats' bot a recommended approach.

> About other specific attribute, you suggest to use the NAS-IP-Address for example in place of User-Name ?..
> About the usage of virtual server, I saw that the VS do NOT have to be set up with the "sites-available" and "sites-enabled" directories

  Yes.

> meaning the configuration must be moved to radiusd.conf.

  Why?

> Not easy to do that for the time being without validating again the entire configuration.

  It's that hard to cut & paste files?

  You have (again) some massive unspoken assumptions behind your message.  We can't read your mind.  We don't know *why* you're doing things.  You're not explaining yourself.

  This is why people get mad at me.  I ask them to explain *clearly* what they're doing, and they refuse.  Then, they get upset when I point out I can't help them without a clear explanation.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Mark J. Bobak
Hi all,

I mostly just lurk here, as my FreeRadius implementation is gong strong,
with no issues.

But, it seems like a good time to mention this:
http://www.catb.org/esr/faqs/smart-questions.html

-Mark

On Mon, Jan 7, 2019 at 12:12 PM Alan DeKok <[hidden email]>
wrote:

> On Jan 7, 2019, at 12:06 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <
> [hidden email]> wrote:
> >
> > The line 91 contains the user declaration (healthcheckVIP).
> > The healtcheck is done every 10s.
> > I reversed the check and I think it's better.
>
>   i.e. made a random change without understanding it.
>
>   Thats' bot a recommended approach.
>
> > About other specific attribute, you suggest to use the NAS-IP-Address
> for example in place of User-Name ?..
> > About the usage of virtual server, I saw that the VS do NOT have to be
> set up with the "sites-available" and "sites-enabled" directories
>
>   Yes.
>
> > meaning the configuration must be moved to radiusd.conf.
>
>   Why?
>
> > Not easy to do that for the time being without validating again the
> entire configuration.
>
>   It's that hard to cut & paste files?
>
>   You have (again) some massive unspoken assumptions behind your message.
> We can't read your mind.  We don't know *why* you're doing things.  You're
> not explaining yourself.
>
>   This is why people get mad at me.  I ask them to explain *clearly* what
> they're doing, and they refuse.  Then, they get upset when I point out I
> can't help them without a clear explanation.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Proxy FreeRADIUS Monitoring from LB F5

Alan Buxey
In reply to this post by CALMELS, Thierry (SOGETI REGIONS SAS)
hi,

you dont need an entry in the users file if you are doing manual Accept etc
via unlang

I wasnt suggesting using another attribute instead of User-Name, was
suggesting using another attribute *as well as* User-Name for your policy.

regarding VS. no. dont remove....add extra ones,,,,eg one on a specific
port that the LB could use, for example.

alan

On Mon, 7 Jan 2019 at 17:06, CALMELS, Thierry (SOGETI REGIONS SAS) <
[hidden email]> wrote:

> Hi,
>
> The line 91 contains the user declaration (healthcheckVIP).
> The healtcheck is done every 10s.
> I reversed the check and I think it's better.
> About other specific attribute, you suggest to use the NAS-IP-Address for
> example in place of User-Name ?..
> About the usage of virtual server, I saw that the VS do NOT have to be set
> up with the "sites-available" and "sites-enabled" directories meaning the
> configuration must be moved to radiusd.conf. Not easy to do that for the
> time being without validating again the entire configuration.
>
> Kr
> Thierry
>
> -----Message d'origine-----
> De : Freeradius-Users [mailto:
> freeradius-users-bounces+thierry.calmels.external=
> [hidden email]] De la part de Alan Buxey
> Envoyé : jeudi 3 janvier 2019 15:59
> À : FreeRadius users mailing list
> Objet : Re: Proxy FreeRADIUS Monitoring from LB F5
>
> hi,
>
> found in user file because "files: users: Matched entry healthcheckVIP at
> line 91" . - whats in line 91 of your users file?
>
> I would adjust the check.... how often is this health check running? Your
> check should be reversed, I think, such that if its
> the monitoring user-name then you do X, else do Y.   but another thing -
> the monitor user will have specific other attributes
> that the normal traffic wont have - the NAS-IP-Address or such..you also
> want that in as a check item for your logic - be specific
> as possible for your health check... would be even better if you could
> direct that to its own virtual server but maybe thats too much to ask for.
>
> alan
>
> On Thu, 3 Jan 2019 at 14:50, CALMELS, Thierry (SOGETI REGIONS SAS) <
> [hidden email]> wrote:
>
> > Happy new year Alan,
> >
> > As new resolution, I decided to re-contact you about the same topic^^
> > Below, the old thread.
> >
> > >This is the *first* time you mentioned that there's a "healthcheckVIP"
> > user name.  If you had said that at the START of the conversation, I
> would
> > have been able to give you better advice.
> > Not really - this username was mentioned in my first mail. This username
> > (+password+PSK) are configured on LB F5 in front of the RADIUS PROXY.
> >
> > >If only there was some kind of debug output which you could post to the
> > list, so that *experts* could read it and give you useful advice
> > Below a trace involving the local user "healthcheckVIP".
> >
> > Reminder: the aim is to validate that the condition on &User-Name is
> > acceptable or not. The functional test made by the LB is OK but the
> > implementation on RADIUS side can be improved....
> > Without this condition, I don't understand why although the user was find
> > in files repository, we chain to the perl module...
> >
> > Thu Jan  3 15:05:12 2019 : Debug: (2) Received Access-Request Id 152 from
> > 11.126.112.186:38553 to 11.126.109.241:1812 length 95
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Name = "healthcheckVIP"
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   User-Password = "xxxxxxxxxx"
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-IP-Address = 11.147.11.193
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   NAS-Identifier =
> > "m880gbigip1-val.fr.eu.airbus.corp"
> > Thu Jan  3 15:05:12 2019 : Debug: (2) session-state: No State attribute
> > Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section authorize from
> > file /etc/raddb/sites-enabled/default
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   authorize {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     policy filter_username {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name) {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  -> TRUE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&User-Name)  {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /) {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ / /)  ->
> > FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> > ) {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@[^@]*@/
> > )  -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ )
> {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.\./ )
> > -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> > (&User-Name !~ /@(.+)\.(.+)$/))  {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if ((&User-Name =~ /@/) &&
> > (&User-Name !~ /@(.+)\.(.+)$/))   -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)  {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /\.$/)
> >  -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)  {
> > Thu Jan  3 15:05:12 2019 : Debug: No matches
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         if (&User-Name =~ /@\./)
> >  -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       } # if (&User-Name)  =
> notfound
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy filter_username =
> > notfound
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > preprocess (rlm_preprocess)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from preprocess (rlm_preprocess)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [preprocess] = ok
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > chap (rlm_chap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from chap (rlm_chap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [chap] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > mschap (rlm_mschap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from mschap (rlm_mschap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [mschap] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > digest (rlm_digest)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from digest (rlm_digest)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [digest] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > suffix (rlm_realm)
> > Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: Checking for suffix after
> "@"
> > Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No '@' in User-Name =
> > "healthcheckVIP", looking up realm NULL
> > Thu Jan  3 15:05:12 2019 : Debug: (2) suffix: No such realm "NULL"
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from suffix (rlm_realm)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [suffix] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > eap (rlm_eap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2) eap: No EAP-Message, not doing EAP
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from eap (rlm_eap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [eap] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > files (rlm_files)
> > Thu Jan  3 15:05:12 2019 : Warning: Found User-Password == "..."
> > Thu Jan  3 15:05:12 2019 : Warning: Are you sure you don't mean
> > Cleartext-Password?
> > Thu Jan  3 15:05:12 2019 : Warning: See "man rlm_pap" for more
> information
> > Thu Jan  3 15:05:12 2019 : Debug: (2) files: users: Matched entry
> > healthcheckVIP at line 91
> > Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: FROM 0 TO 0 MAX 0
> > Thu Jan  3 15:05:12 2019 : Debug: (2) files: ::: TO in 0 out 0
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from files (rlm_files)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [files] = ok
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> > 'healthcheckVIP' && &User-Name != 'monitoringUser') {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     if (&User-Name !=
> > 'healthcheckVIP' && &User-Name != 'monitoringUser')  -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > expiration (rlm_expiration)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from expiration (rlm_expiration)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [expiration] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > logintime (rlm_logintime)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from logintime (rlm_logintime)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [logintime] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: calling
> > pap (rlm_pap)
> > Thu Jan  3 15:05:12 2019 : WARNING: (2) pap: Auth-Type already set.  Not
> > setting to PAP
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[authorize]: returned
> > from pap (rlm_pap)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [pap] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   } # authorize = ok
> > Thu Jan  3 15:05:12 2019 : Debug: (2) Found Auth-Type = Accept
> > Thu Jan  3 15:05:12 2019 : Debug: (2) Auth-Type = Accept, accepting the
> > user
> > Thu Jan  3 15:05:12 2019 : Debug: (2) # Executing section post-auth from
> > file /etc/raddb/sites-enabled/default
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   post-auth {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     update {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       No attributes updated
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     } # update = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: calling
> > exec (rlm_exec)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     modsingle[post-auth]: returned
> > from exec (rlm_exec)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     [exec] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     policy
> > remove_reply_message_if_eap {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> > &reply:Reply-Message) {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       if (&reply:EAP-Message &&
> > &reply:Reply-Message)  -> FALSE
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       else {
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> > calling noop (rlm_always)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         modsingle[post-auth]:
> > returned from noop (rlm_always)
> > Thu Jan  3 15:05:12 2019 : Debug: (2)         [noop] = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)       } # else = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)     } # policy
> > remove_reply_message_if_eap = noop
> > Thu Jan  3 15:05:12 2019 : Debug: (2)   } # post-auth = noop
> > Thu Jan  3 15:05:12 2019 : Auth: (2) Login OK: [healthcheckVIP] (from
> > client radius-proxy-v port 0)
> > Thu Jan  3 15:05:12 2019 : Debug: (2) Sent Access-Accept Id 152 from
> > 11.126.109.241:1812 to 11.126.112.186:38553 length 0
> > Thu Jan  3 15:05:12 2019 : Debug: (2) Finished request
> >
> >
> > >        perl
> > >  What does this do?  You haven't said.
> > This custom script is *ONLY* used as pass-throughs to forward the
> requests
> > to the server RADIUS 1 and if the reply is REJECT then the request is
> sent
> > in failover to server RADIUS 2.
> >
> > Thx for your patience
> >
> > -----Message d'origine-----
> > De : Freeradius-Users [mailto:
> > freeradius-users-bounces+thierry.calmels.external=
> > [hidden email]] De la part de Alan DeKok
> > Envoyé : lundi 17 décembre 2018 14:20
> > À : FreeRadius users mailing list
> > Objet : Re: Proxy FreeRADIUS Monitoring from LB F5
> >
> > On Dec 16, 2018, at 2:32 PM, CALMELS, Thierry (SOGETI REGIONS SAS) <
> > [hidden email]> wrote:
> > >> The configuration you posted here is *not* what I proposed that you
> use.
> > >> Please go back and read my message again.
> > >
> > > I reviewed your answer and I updated as you advise but without success.
> > >
> > > The configuration which is working is the below one with the
> conditional
> > on User-Name.
> > > I don't find it very sexy!
> > >
> > > files
> > > if (&User-Name != 'healthcheckVIP') {
> >
> >   OK, I really dislike this whole process of giving tiny bits of
> > information.  It wastes everyone's time.
> >
> >   This is the *first* time you mentioned that there's a "healthcheckVIP"
> > user name.  If you had said that at the START of the conversation, I
> would
> > have been able to give you better advice.
> >
> >   If you want good answers, ask good questions.  Your questions are
> vague,
> > and generally don't include relevant information.
> >
> > >        perl
> >
> >   What does this do?  You haven't said.
> >
> > >        if (ok || updated) {
> > >            update control {
> > >                Auth-Type := Perl
> > >            }
> > >        }
> > > }
> > >
> > > ================
> > > I tried to make something like that, but I got the error saying the
> > Auth-Type is not defined.
> >
> >   <sigh>  If only there was some kind of debug output which you could
> post
> > to the list, so that *experts* could read it and give you useful advice.
> >
> >   You're trying to solve the problem without describing it in any detail.
> > That isn't good.
> >
> >   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.
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> -
> 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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html