Freeradius and What's Up Gold Question
Hi everyone: I'm going to try to explain this as best I can. I'm using Freeradius 1.0.5 on a Linux Redhat 9 server. I have a network monitoring program on another computer called What's Up Gold. It is made by a company called Ipswitch. There is a setting in the WUG program that lets you monitor a radius server. This is how Ipswitch explains how it works: "What we specified for a test is an INVALID test for the userid TEST as it not encoded using the secret key. Then what we expect back is a response telling us the userid doesn't exist. The main key for making it work on Radius servers is to ensure the requesting workstation has permissions to send Radius requests. This seems to be the most common error in implementation by users. You will have to include the Monitor station (that is, the computer running WUG) in the /etc./raddb/clients file on the Radius server." I completely understand what it is saying and I have done this. Now that I have given you some background on how this works, here is my actual situation and question: I keep getting false positives on my WUG telling me that freeradius is down even though it's not. This does not happen everytime WUG sends a request to the radius. It happens at random. When I search in the radius logs it shows that the request is being sent to freeradius from WUG and the user TEST is indeed being rejected just like it's suppose to. The request is sent to the radius every 20 minutes and it makes it there every time. Now, the way I see it, it can be one of two things... The first... I have my WUG set at 5 seconds as a time out. Could freeradius, at times, be taking more than 5 seconds to respond to a sent request? if this is the case, I figure it would take my customers a few times to dial up and get authenticated at times, which is not a good thing since I work for an ISP. We haven't had any customers calling tech support about this, but still we can't rule it out just yet. The second... does freeradius lock out users after a certain amount of bad requests and if so, is there a configuration change that I can make to avoid this? I have looked all over for an answer to this question and I haven't found it, so I thought I'd post it here with the hope that someone would know. I'm sorry about the huge post. I just wanted to give enough information for the person/people that may help me with this. Thank you and I look forward to any response. By the way, I just wanted to say thanks to everyone that has helped me in the past, especially Mr. DeKok who has had much patience with me. I love your freeradius program. It's the best radius server I have used yet. Thank you for giving it to us for free and for all of your support because I do realize that you don't need to give any support if you didn't want to. You are much appreciated. Linda Pagillo Director of Technical Services N2 The Net, LLC lpagillo@n2thenet.com 931-372-9179
"Linda Pagillo" <linda@n2thenet.com> wrote:
This is how Ipswitch explains how it works:
"What we specified for a test is an INVALID test for the userid TEST as it not encoded using the secret key. Then what we expect back is a response telling us the userid doesn't exist.
This isn't how RADIUS works. A "reject" is not the same as "user doesn't exist". RADIUS has "reject", not "user doesn't exist".
You will have to include the Monitor station (that is, the computer running WUG) in the /etc./raddb/clients file on the Radius server."
And the shared secret.
Now, the way I see it, it can be one of two things... The first... I have my WUG set at 5 seconds as a time out. Could freeradius, at times, be taking more than 5 seconds to respond to a sent request?
Sure, but it should be rare. AND the WUG should re-transmit the packet, as is normally done by RADIUS clients.
The second... does freeradius lock out users after a certain amount of bad requests
No. Alan DeKok.
Thank you once again Mr.DeKok. I have already added the secret to my clients.conf entry. I also already checked into adding the shared secret to WUG and there is no way to do this, so i'm told. Is there another way around this problem? Perhaps i have my clients.conf entry incorrect. Here is what i have: client xx.xxx.xxx.xx { secret = mysecrethere shortname = shortnamehere } It is different for the entries i have for my NAS. Here is an example of of those: client xx.xxx.xxx.xxx { secret = mysecrethere shortname = shortnamehere nastype = nastypehere login = loginhere password = passwordhere } Am I missing something? Thanks again. ----- Original Message ----- From: "Alan DeKok" <aland@ox.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, October 20, 2005 3:45 PM Subject: Re: Freeradius and What's Up Gold Question
"Linda Pagillo" <linda@n2thenet.com> wrote:
This is how Ipswitch explains how it works:
"What we specified for a test is an INVALID test for the userid TEST as it not encoded using the secret key. Then what we expect back is a response telling us the userid doesn't exist.
This isn't how RADIUS works. A "reject" is not the same as "user doesn't exist". RADIUS has "reject", not "user doesn't exist".
You will have to include the Monitor station (that is, the computer running WUG) in the /etc./raddb/clients file on the Radius server."
And the shared secret.
Now, the way I see it, it can be one of two things... The first... I have my WUG set at 5 seconds as a time out. Could freeradius, at times, be taking more than 5 seconds to respond to a sent request?
Sure, but it should be rare. AND the WUG should re-transmit the packet, as is normally done by RADIUS clients.
The second... does freeradius lock out users after a certain amount of bad requests
No.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ---
If you can't change the shared secret in WUG then change the secret in your clients.conf to match what is in WUG. Or better yet, abandon WUG and it's windows platform and use www.intermapper.com It is a MUCH better product and works just fine with freeradius, I'm doing so here. It also runs on linux. Duane Cox ----- Original Message ----- From: "Linda Pagillo" <linda@n2thenet.com> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, October 20, 2005 5:08 PM Subject: Re: Freeradius and What's Up Gold Question
Thank you once again Mr.DeKok. I have already added the secret to my clients.conf entry. I also already checked into adding the shared secret to WUG and there is no way to do this, so i'm told. Is there another way around this problem? Perhaps i have my clients.conf entry incorrect. Here is what i have:
client xx.xxx.xxx.xx { secret = mysecrethere shortname = shortnamehere }
It is different for the entries i have for my NAS. Here is an example of of those:
client xx.xxx.xxx.xxx { secret = mysecrethere shortname = shortnamehere nastype = nastypehere login = loginhere password = passwordhere }
Am I missing something? Thanks again.
----- Original Message ----- From: "Alan DeKok" <aland@ox.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, October 20, 2005 3:45 PM Subject: Re: Freeradius and What's Up Gold Question
"Linda Pagillo" <linda@n2thenet.com> wrote:
This is how Ipswitch explains how it works:
"What we specified for a test is an INVALID test for the userid TEST as it not encoded using the secret key. Then what we expect back is a response telling us the userid doesn't exist.
This isn't how RADIUS works. A "reject" is not the same as "user doesn't exist". RADIUS has "reject", not "user doesn't exist".
You will have to include the Monitor station (that is, the computer running WUG) in the /etc./raddb/clients file on the Radius server."
And the shared secret.
Now, the way I see it, it can be one of two things... The first... I have my WUG set at 5 seconds as a time out. Could freeradius, at times, be taking more than 5 seconds to respond to a sent request?
Sure, but it should be rare. AND the WUG should re-transmit the packet, as is normally done by RADIUS clients.
The second... does freeradius lock out users after a certain amount of bad requests
No.
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
If you can't change the shared secret in WUG then change the secret in your clients.conf to match what is in WUG. Or better yet, abandon WUG and it's windows platform and use www.intermapper.com It is a MUCH better product and works just fine with freeradius, I'm doing so here. It also runs on linux. Duane Cox ----- Original Message ----- From: "Linda Pagillo" <linda@n2thenet.com> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, October 20, 2005 5:08 PM Subject: Re: Freeradius and What's Up Gold Question
Thank you once again Mr.DeKok. I have already added the secret to my clients.conf entry. I also already checked into adding the shared secret to WUG and there is no way to do this, so i'm told. Is there another way around this problem? Perhaps i have my clients.conf entry incorrect. Here is what i have:
client xx.xxx.xxx.xx { secret = mysecrethere shortname = shortnamehere }
It is different for the entries i have for my NAS. Here is an example of of those:
client xx.xxx.xxx.xxx { secret = mysecrethere shortname = shortnamehere nastype = nastypehere login = loginhere password = passwordhere }
Am I missing something? Thanks again.
----- Original Message ----- From: "Alan DeKok" <aland@ox.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, October 20, 2005 3:45 PM Subject: Re: Freeradius and What's Up Gold Question
"Linda Pagillo" <linda@n2thenet.com> wrote:
This is how Ipswitch explains how it works:
"What we specified for a test is an INVALID test for the userid TEST as it not encoded using the secret key. Then what we expect back is a response telling us the userid doesn't exist.
This isn't how RADIUS works. A "reject" is not the same as "user doesn't exist". RADIUS has "reject", not "user doesn't exist".
You will have to include the Monitor station (that is, the computer running WUG) in the /etc./raddb/clients file on the Radius server."
And the shared secret.
Now, the way I see it, it can be one of two things... The first... I have my WUG set at 5 seconds as a time out. Could freeradius, at times, be taking more than 5 seconds to respond to a sent request?
Sure, but it should be rare. AND the WUG should re-transmit the packet, as is normally done by RADIUS clients.
The second... does freeradius lock out users after a certain amount of bad requests
No.
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
participants (3)
-
Alan DeKok -
Duane Cox -
Linda Pagillo