RE: STILL Trying to get tunneling to work- resolved, and a question
Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one? 2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers? -----Original Message----- From: Mike Bernhardt [mailto:bernhardt@bart.gov] Sent: Friday, January 29, 2010 11:36 AM To: 'freeradius-users@lists.freeradius.org' Subject: Re: STILL Trying to get tunneling to work- resolved, and a question I found the major problem that caused my configuration to not work. This was in regards to getting freeradius to proxy EAP/PEAP to IAS servers as standard CHAP. I was using freeradius 2.1.7, and then 2.1.8 as recommended by someone. Neither worked. The solution was to back down to 2.1.4. Is this a bug that was introduced after that, or what? I can email config files to whomever needs them to work on it. So, I now have another question: I have set up 2 IAS servers in a pool. I would like to drastically reduce the timeout before freeradius fails over to the 2nd one. How do I do that? Right now it takes about 30 seconds but I don't see a variable to change that. I also noticed that the status requests, which begin after it has marked a server as bad, do not work. How do I use the user name and [bad] password to check status and bring it back sooner? It only seems to try it once and that's it. Thanks, Mike
Mike Bernhardt wrote:
Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one?
Read raddb/proxy.conf
2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers?
Since that isn't a given... I'm not sure what else to say. Testing for 2.1.8 involved *billions* of packets go through it in prixying && non-proxying setups, with status checks enabled and disabled, with home servers going up && down... Please be more specific than "it doesn't work". Many people are using 2.1.8 in similar setups to yours, and they see that it works. Alan DeKok.
"It doesn't work" referred to the original question I posted with the same subject a few weeks ago. At that time I provided debug output. I tried this configuration with 2.1.7 and 2.1.8 but it "didn't work" in that the request never left freeradius for the downstream server. After I installed 2.1.4, it worked as it should without changing anything else. I will try reinstalling 2.1.8 just for fun and see if it behaves this time. If it doesn't, I'll stick with 2.1.4 and send you my config files. As far as status checks, the authentication pings will work fine. I see now that they only kick in when a server is marked dead. If I can figure out how to shorten the time before it is marked dead I'll be very satisfied with that setup. -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Friday, January 29, 2010 11:12 PM To: FreeRadius users mailing list Subject: Re: STILL Trying to get tunneling to work- resolved, and a question Mike Bernhardt wrote:
Just to clarify my questions: If one of the servers I'm proxying to is dead, is there a way to reduce the number of times freeradius tries before failing over to the next one?
Read raddb/proxy.conf
2. Are there any ways to make this process more efficient, given that status check currently doesn't work with the downstream servers?
Since that isn't a given... I'm not sure what else to say. Testing for 2.1.8 involved *billions* of packets go through it in prixying && non-proxying setups, with status checks enabled and disabled, with home servers going up && down... Please be more specific than "it doesn't work". Many people are using 2.1.8 in similar setups to yours, and they see that it works. Alan DeKok.
Mike Bernhardt wrote:
"It doesn't work" referred to the original question I posted with the same subject a few weeks ago. At that time I provided debug output.
Ah... that's the "failed creating proxy socket" issue. Weird.
I tried this configuration with 2.1.7 and 2.1.8 but it "didn't work" in that the request never left freeradius for the downstream server. After I installed 2.1.4, it worked as it should without changing anything else. I will try reinstalling 2.1.8 just for fun and see if it behaves this time. If it doesn't, I'll stick with 2.1.4 and send you my config files.
OK. If 2.1.8 didn't work 2 weeks ago, re-installing it will likely not help.
As far as status checks, the authentication pings will work fine. I see now that they only kick in when a server is marked dead. If I can figure out how to shorten the time before it is marked dead I'll be very satisfied with that setup.
raddb/proxy.conf. All of the configuration items are documented there. Be aware, though, that 2.1.8 makes these work better than 2.1.4. Alan DeKok.
Alan, A few days ago I sent you a private email to your deployingradius address. I attached a bunch of config files and log output so you could see the issues in my working 2.1.4 vs non-working 2.1.8 installations. I did not scrub the config files since it was a private email. If you want the configs to be public, I'll scrub them and send them again to an appropriate location, but I do not have a place to post them myself. I never got a response to that email, so I wanted to make sure you know I sent it. If it should go elsewhere, let me know.
Mike Bernhardt wrote:
I never got a response to that email, so I wanted to make sure you know I sent it. If it should go elsewhere, let me know.
I received it. I'll take a look and see if I can figure out what's going on. Alan DeKok.
participants (2)
-
Alan DeKok -
Mike Bernhardt