FreeRADIUS + LVS problem
According to my research, FreeRADIUS supposedly does work from behind an LVS load balancer. My current configuration works perfectly outside of the LVS, but once it is put behind the LVS it ceases to work. Connections seem to succeed even behind the LVS, until they get to an access challenge, where I get: rad_recv: Access-Challenge packet from host 192.168.240.111:5058, id=42, length=64 Authentication reply packet code 11 sent to a non- proxy reply port from client WPA_Test:5058 - ID 42 : IGNORED
From what little information I could find on this, it looks like the freeradius thinks these are proxied requests due to ip mangling done by the LVS load balancer (Basically, it's a 1:1 NAT).
Has anyone come across anything like this? Any pointers for work- arounds would definitely be appreciated. P.S. Alan, I would definitely think this (LVS + FreeRADIUS) would be a good topic for your book -- Click for free info on adult education and start making $150k/ year http://tagline.hushmail.com/fc/CAaCXv1S62Uaoe8eWguezq8EENBamjiB/
Sam Schultz wrote:
From what little information I could find on this, it looks like the freeradius thinks these are proxied requests due to ip mangling done by the LVS load balancer (Basically, it's a 1:1 NAT).
Has anyone come across anything like this? Any pointers for work- arounds would definitely be appreciated.
I'd suggest to use LVS in a "direct routing" setup. http://www.linuxvirtualserver.org/VS-DRouting.html -- Nicolas Baradakis
Sam Schultz wrote:
According to my research, FreeRADIUS supposedly does work from behind an LVS load balancer. My current configuration works perfectly outside of the LVS, but once it is put behind the LVS it ceases to work. Connections seem to succeed even behind the LVS, until they get to an access challenge, where I get:
rad_recv: Access-Challenge packet from host 192.168.240.111:5058, id=42, length=64 Authentication reply packet code 11 sent to a non- proxy reply port from client WPA_Test:5058 - ID 42 : IGNORED
Somehow Access-Challenge packets are being sent to the RADIUS server. This could be because some UDP-level routing is incorrect in LVS.
From what little information I could find on this, it looks like the freeradius thinks these are proxied requests due to ip mangling done by the LVS load balancer (Basically, it's a 1:1 NAT).
Even if the LVS load balancer is doing IP mangling, it has no business sending Access-Challenges to a RADIUS server on port 1812. Those challenges are sent FROM the server, and should have been sent back to the NAS. A larger problem with LVS is that if you're doing Access-Challenges, the responses MUST go back to the RADIUS server that sent the challenge. So a UDP-level load balancer that doesn't understand RADIUS may not work.
P.S. Alan, I would definitely think this (LVS + FreeRADIUS) would be a good topic for your book
I plan on having a chapter on that, yes. I've been trying to get Xen installed on a machine, without much luck. (Xen gets part way through booting... stops... and reboots). As for your other message:
I was thinking there may be some way to coerce FR into thinking the load balancer is another radius server sending over proxied requests, or something like that.
The simplest way to do that is (perhaps not surprisingly) to run FreeRADIUS as a proxy, doing RADIUS-aware load balancing. Since that machine won't be doing authentication (DB's are slow), there's no reason it can't handle proxying 5k RADIUS requests/s. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sat 17 Feb 2007 02:44, Alan DeKok wrote:
P.S. Alan, I would definitely think this (LVS + FreeRADIUS) would be a good topic for your book
I plan on having a chapter on that, yes. I've been trying to get Xen installed on a machine, without much luck. (Xen gets part way through booting... stops... and reboots).
If you are not using SUSE Linux Enterprise Server 10 (or openSUSE 10.2) I suggest you try that as Xen support is configured out of the box, officially supported by SUSE and new instances can be easily created from YaST (SUSE's GUI config tool). Basically it should save you a lot of headaches! -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Alan DeKok wrote:
Sam Schultz wrote:
I was thinking there may be some way to coerce FR into thinking the load balancer is another radius server sending over proxied requests, or something like that.
The simplest way to do that is (perhaps not surprisingly) to run FreeRADIUS as a proxy, doing RADIUS-aware load balancing. Since that machine won't be doing authentication (DB's are slow), there's no reason it can't handle proxying 5k RADIUS requests/s.
I agree with Alan: if you want the features of a RADIUS proxy, just setup FreeRADIUS as a proxy. I note alike the LVS servers, you can have several RADIUS proxies in a pool and use Keepalived for failover. Keepalived will monitor the FreeRADIUS proxies. The health check is configured with a "MISC_CHECK" stanza in keepalived.conf. You have to run "radclient" and test whether the server returns Access-Accept, that's all. -- Nicolas Baradakis
Nicolas Baradakis wrote:
Keepalived will monitor the FreeRADIUS proxies. The health check is configured with a "MISC_CHECK" stanza in keepalived.conf. You have to run "radclient" and test whether the server returns Access-Accept, that's all.
This is what Status-Server should be used for. http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-00.txt I have an update I'll be submitting this week. My goal is to have it issued as an RFC in the next 6 months. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Nicolas Baradakis wrote:
Keepalived will monitor the FreeRADIUS proxies. The health check is configured with a "MISC_CHECK" stanza in keepalived.conf. You have to run "radclient" and test whether the server returns Access-Accept, that's all.
This is what Status-Server should be used for.
http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-00.txt
I see one advantage to use Access-Request "pings": I can test both the RADIUS server and the MySQL backend with a single check. A FreeRADIUS proxy uses real users to ping the RADIUS servers, and that's troublesome for the reasons outlined in your draft. Keepalived deals with the problem differently: you can setup a special account to run the monitor checks. Therefore you don't really care whether the statistics of the user keepalived@realm.net are wrong. -- Nicolas Baradakis
Nicolas Baradakis wrote:
I see one advantage to use Access-Request "pings": I can test both the RADIUS server and the MySQL backend with a single check.
Yes.
A FreeRADIUS proxy uses real users to ping the RADIUS servers, and that's troublesome for the reasons outlined in your draft. Keepalived deals with the problem differently: you can setup a special account to run the monitor checks. Therefore you don't really care whether the statistics of the user keepalived@realm.net are wrong.
That's for strictly local testing. I would suggest allowing this only from localhost, or with certain VSA's that will never come in a RADIUS packet. I'll add a paragraph about this situation. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 19 Feb 2007 15:27, Alan DeKok wrote:
Nicolas Baradakis wrote:
I see one advantage to use Access-Request "pings": I can test both the RADIUS server and the MySQL backend with a single check.
Yes.
I see no particular reason why you should not allow a SQL query on a Status packet. We could have a separate sql query just for Status requests which does something like "select version()", "select now()" or "select 1". I think LDAP has something similar as well... On the other hand testing MySQL from another script is not a huge pain... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
I see no particular reason why you should not allow a SQL query on a Status packet. We could have a separate sql query just for Status requests which does something like "select version()", "select now()" or "select 1". I think LDAP has something similar as well...
Yes, but that adds server complexity, etc.
On the other hand testing MySQL from another script is not a huge pain...
Yup. If you want to know if an SQL server is up, there are existing tools to test that. Personally, I would test: a) RADIUS via Status-Server b) SQL via sql client c) "test" user via Access-Request If you just do (c), you have no idea if the problem is the RADIUS server or the SQL server. Not that it matters to a NAS, of course, but it matters to an administrator. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Peter Nixon wrote:
On the other hand testing MySQL from another script is not a huge pain...
Yup. If you want to know if an SQL server is up, there are existing tools to test that. Personally, I would test:
a) RADIUS via Status-Server b) SQL via sql client c) "test" user via Access-Request
If you just do (c), you have no idea if the problem is the RADIUS server or the SQL server. Not that it matters to a NAS, of course, but it matters to an administrator.
That's completely true. I note the discussion started with a question about LVS, not a question about RADIUS supervision in general.
From the LVS server point of view, I think the test (c) is the most useful, because there's no point to send traffic to a node if it fails to authorize a user, whatever the reason is.
The tests (a) and (b) are useful to the administrators, but I don't think they're to be run by the load balancing server. They could be run by general purpose supervision tools like Nagios. -- Nicolas Baradakis
Nicolas Baradakis wrote:
From the LVS server point of view, I think the test (c) is the most useful, because there's no point to send traffic to a node if it fails to authorize a user, whatever the reason is.
Yes.
The tests (a) and (b) are useful to the administrators, but I don't think they're to be run by the load balancing server. They could be run by general purpose supervision tools like Nagios.
Yes. My main objection to using Access-Request is when those packets are sent from *outside* of the local network. Inside of the local network, it's much less of an issue. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 19 Feb 2007 10:22, Alan DeKok wrote:
Nicolas Baradakis wrote:
Keepalived will monitor the FreeRADIUS proxies. The health check is configured with a "MISC_CHECK" stanza in keepalived.conf. You have to run "radclient" and test whether the server returns Access-Accept, that's all.
This is what Status-Server should be used for.
http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-00.tx t
I have an update I'll be submitting this week. My goal is to have it issued as an RFC in the next 6 months.
Nicely written... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (4)
-
Alan DeKok -
Nicolas Baradakis -
Peter Nixon -
Sam Schultz