Re: RADIUS response from incorrect interface
"John Gruber" <[EMAIL PROTECTED]> wrote: > Is that prophesy or cynicism?Not that you're wrong... we'd ask for > that. It's a strong opinion. Writing one RADIUS server is hard enough. Writing a RADIUS server with multiple personalities is even harder. If people want to return different attributes based on the NAS, then they can do that now. But allowing two *completely* different configurations inside of the RADIUS server makes misconfiguration and security leaks *much* more likely. For similar reasons, I'm opposed to adding a PHP module to the server. PHP is nice, but it has an *atrocious* security record. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RADIUS response from incorrect interface
Is that prophesy or cynicism?Not that you're wrong... we'd ask for that. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alan DeKok Sent: Monday, February 10, 2003 3:35 AM To: [EMAIL PROTECTED] Subject: Re: RADIUS response from incorrect interface Jason Haar <[EMAIL PROTECTED]> wrote: > On Sat, Feb 08, 2003 at 01:47:28PM +, Miquel van Smoorenburg wrote: > >[...stuff on how complex it is to bind to >1 interface deleted] > > Why not just run two instances of radiusd - one on each address? They can > point to the same auth system - just the logfiles have to be different... I can understand people wanting the *same* radius server to listen on 2 interfaces, and respond correctly from those interfaces. Running one server which listens on 2 interfaces is a reasonable solution. If that's implemented, then I'll bet the next request will be for the ability to run one server, which does different things, based on which interface received the request. The response to that will be 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
Re: RADIUS response from incorrect interface
Jason Haar <[EMAIL PROTECTED]> wrote: > On Sat, Feb 08, 2003 at 01:47:28PM +, Miquel van Smoorenburg wrote: > >[...stuff on how complex it is to bind to >1 interface deleted] > > Why not just run two instances of radiusd - one on each address? They can > point to the same auth system - just the logfiles have to be different... I can understand people wanting the *same* radius server to listen on 2 interfaces, and respond correctly from those interfaces. Running one server which listens on 2 interfaces is a reasonable solution. If that's implemented, then I'll bet the next request will be for the ability to run one server, which does different things, based on which interface received the request. The response to that will be NO. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
On Sat, Feb 08, 2003 at 01:47:28PM +, Miquel van Smoorenburg wrote: >[...stuff on how complex it is to bind to >1 interface deleted] Why not just run two instances of radiusd - one on each address? They can point to the same auth system - just the logfiles have to be different... -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
In article <[EMAIL PROTECTED]>, Alan DeKok <[EMAIL PROTECTED]> wrote: >"John Gruber" <[EMAIL PROTECTED]> wrote: >> But bind on * should work too.. and the reply should come from the address >> for the interface the request was sent to. It just doesn't, and I did not >> have the time at the time to see why in the code. > > It only works if you call bind() immediately upon receiving a >packet. That's expensive, and causes the server to do a *lot* of >work. You mean immediately before sending a reply. But that creates a race condition, since you can then not receive packets from other interfaces anymore. Unless you use a seperate send and receive socket. However then you need to lock around the bind() / sendto() calls, to prevent race conditions between threads. It's not worth it. It's also impossible for another reason: you cannot know on which interface a certain UDP packet was received. recvfrom() only records the clients IP address, not the address of the interface the packet was received on. With Linux, you can use recvmsg() / sendmsg() with IP_PKTINFO in the ancillary data to get / set the local address, but that is not portable (though *BSD appears to have something similar). > A better solution is to explicitely list the addresses the server >listens on, which is much less expensive, but requires a bit more >code. And just open one socket for each address/port to listen on. Yes, that is the easiest solution by far. Mike. -- Anyone who is capable of getting themselves made President should on no account be allowed to do the job -- Douglas Adams. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
"John Gruber" <[EMAIL PROTECTED]> wrote: > But bind on * should work too.. and the reply should come from the address > for the interface the request was sent to. It just doesn't, and I did not > have the time at the time to see why in the code. It only works if you call bind() immediately upon receiving a packet. That's expensive, and causes the server to do a *lot* of work. A better solution is to explicitely list the addresses the server listens on, which is much less expensive, but requires a bit more code. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RADIUS response from incorrect interface
I had the same problem earlier this year. I have failover virtual addresses on n-servers. In my failover scripts I start the radiusd process. The radiusd process only runs on the current production server at any given time. I stopped trying to have radiusd bound to * in the config. It just doesn't work - or at least does not guarantee that you get your reply back from the interface you expect. All my radius processes work with AUTH and ACCT tables on replicated databases anyway. My radiusd are cheap frontend processors to back end systems. With the cost of sparc5s on ebay these days.. it has not been hard to find cheap reliable hardware that you can use for both load balancing and redundancy yourself. But bind on * should work too.. and the reply should come from the address for the interface the request was sent to. It just doesn't, and I did not have the time at the time to see why in the code. I just smiled and restarted the radiusd process in the failover scripts. John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Jenner Sent: Friday, February 07, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: RE: RADIUS response from incorrect interface Hi all. Thanks for so many replies so quickly. I totally take on board the comments about UDP responses on the same IP not being trivial and probably not being worth it to implement. However its worth pointing out for the record why its useful here. The situation here is that the RADIUS requests come from load-balanced upstream telco proxies who require two IPs for the RADIUS servers for both resilience and load-balancing. Normally these would be serviced by two physical servers with two real IPs but, when one server is not available, the other can take over by taking the IP as a virtual interface. There are a lot of arguments about whether this is a sensible thing to do etc. however this is what I am trying to implement (and it works for UDP DNS requests with ISC bind). Thanks for all the help on this - I think for now I'll look for a solution outside of the RADIUS software (translation on firewalls etc. most likely) as this appears the correct place to do this kind of thing, Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <>
RE: RADIUS response from incorrect interface
So (and I'm reading in between the lines here), it seems as if you already have two servers, A and B, configured using some sort of clustering so that if A fails, B picks up A's address virtually, and vice-versa. If so, then I think you're making the problem harder than it is. Typically, most software that does RADIUS will accept a primary and a backup, and is within the client's control which server they decide to talk to. (i.e. you might be making a problem when in fact none really exists!) I would pose that question to your telco; chances are it will automatically fail over to the backup if the primary is unavailable. Additionally, most layer 7 load balancers also have a provision for determining if the end node is not available and automatically routing traffic to the other available node(s). I would also query your telco on this possibility. (In other words, the way I see it, you shouldn't need to any of this virtual IP jazz, because it should already be accounted for in the radius clients themselves!) Vincent Giovannone Network Infrastructure Group Information Services Division Rush - Presbyterian St. Luke's Medical Center "So for the IT Manager Role, you want someone who's absolute crap, looks reasonable on paper, and won't cause too much trouble. ... Well I don't have any MCSEs on my books at the moment, but I could call around."-- Simon Travaglia "Paul Jenner" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 02/07/2003 10:33 AM Please respond to freeradius-users To: <[EMAIL PROTECTED]> cc: Subject:RE: RADIUS response from incorrect interface Hi all. Thanks for so many replies so quickly. I totally take on board the comments about UDP responses on the same IP not being trivial and probably not being worth it to implement. However its worth pointing out for the record why its useful here. The situation here is that the RADIUS requests come from load-balanced upstream telco proxies who require two IPs for the RADIUS servers for both resilience and load-balancing. Normally these would be serviced by two physical servers with two real IPs but, when one server is not available, the other can take over by taking the IP as a virtual interface. There are a lot of arguments about whether this is a sensible thing to do etc. however this is what I am trying to implement (and it works for UDP DNS requests with ISC bind). Thanks for all the help on this - I think for now I'll look for a solution outside of the RADIUS software (translation on firewalls etc. most likely) as this appears the correct place to do this kind of thing, Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RADIUS response from incorrect interface
Hi all. Thanks for so many replies so quickly. I totally take on board the comments about UDP responses on the same IP not being trivial and probably not being worth it to implement. However its worth pointing out for the record why its useful here. The situation here is that the RADIUS requests come from load-balanced upstream telco proxies who require two IPs for the RADIUS servers for both resilience and load-balancing. Normally these would be serviced by two physical servers with two real IPs but, when one server is not available, the other can take over by taking the IP as a virtual interface. There are a lot of arguments about whether this is a sensible thing to do etc. however this is what I am trying to implement (and it works for UDP DNS requests with ISC bind). Thanks for all the help on this - I think for now I'll look for a solution outside of the RADIUS software (translation on firewalls etc. most likely) as this appears the correct place to do this kind of thing, Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
Dear Paul Jenner, It's not a bug. In case of UDP, if you bind service to all interfaces and there are 2 interfaces on the same network there is no guarantee reply packet will be sent from interface incoming packet was sent to. Because replay packet will always be sent from interface according to routing table (if there are 2 records for same network with same metrics first one will be chosen). It's expected behavior. Program need some code to specially change binding interface in order to process request as you expect it to do. In case of FreeRADIUS it's not trivial, because interface is shared between multiple threads and changing interface binding may affect another threads. So, best solution for you is to review your network configuration. --Friday, February 7, 2003, 7:00:29 PM, you wrote to [EMAIL PROTECTED]: PJ> Hi. PJ> I am seeing an issue with freeradius 0.8.1 on Red Hat 8.0 where RADIUS PJ> responses are coming out of a different virtual interface to the PJ> interface they are made to. I couldn't see anything in the doc so PJ> hopefully someone on this list can help. PJ> In more detail: PJ> * my RADIUS server has a real interface on IP X.X.X.X and a virtual PJ> interface on IP Y.Y.Y.Y PJ> * both interfaces are on the same subnet PJ> * the software is freeradius 0.8.1 compiled on Red Hat 8.0 PJ> * it is configured with "bind_address = *" to listen on both interfaces PJ> * when RADIUS requests are made to IP X.X.X.X, the responses come back PJ> from IP X.X.X.X PJ> * however when requests are made to IP Y.Y.Y.Y, the responses still come PJ> back from IP X.X.X.X PJ> * hence they are dropped by firewall as unestablished outgoing PJ> connections PJ> * UDP responses on virtual interfaces do work with this kernel as ISC PJ> bind is able to respond to DNS UDP requests on the same IP as the PJ> connection is made to PJ> Am I doing something wrong in the config or is this a bug? PJ> Thanks for any help on this, PJ> Paul PJ> Paul Jenner PJ> ioko365 Ltd. PJ> T: +44 (0)1904 438000 x353 PJ> M: +44 (0)7979 598170 PJ> E: [EMAIL PROTECTED] PJ> W: http://www.ioko365.com/ PJ> - PJ> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- ~/ZARAZA Åñëè äàæå âû ïîëó÷èòå êàêîå-íèáóäü ïèñüìî, âû âñå ðàâíî íå ñóìååòå åãî ïðî÷èòàòü. (Òâåí) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RADIUS response from incorrect interface
Hi Simon. > -Original Message- > From: Simon White [mailto:[EMAIL PROTECTED]] > > Do you need it to listen on both interfaces? Sorry should have explained. Yep - I need it to respond on both IPs - the real interface and the virtual. > What does your routing table look like? Pretty simple stuff - just local network and gateway. I can provide if you wish. However all other communication works as expected (ICMP, TCP, UDP through at least bind). Its just RADIUS responses that are coming back of the wrong interface. > Is the NAS on the same subnet too? Nope. Its actually RADIUS proxy servers provided by a telco. The responses are routed back to the NAS correctly, they just come from the wrong interface. Thanks for the help here, Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
07-Feb-03 at 16:00, Paul Jenner ([EMAIL PROTECTED]) wrote : > Hi. > > I am seeing an issue with freeradius 0.8.1 on Red Hat 8.0 where RADIUS > responses are coming out of a different virtual interface to the > interface they are made to. I couldn't see anything in the doc so > hopefully someone on this list can help. > * it is configured with "bind_address = *" to listen on both interfaces Do you need it to listen on both interfaces? What does your routing table look like? Is the NAS on the same subnet too? -- [Simon White. vim/mutt. [EMAIL PROTECTED] Folding@home no log script yet...] /"\ASCII Ribbon Campaign \ /Respect for open standards X No HTML/RTF in email / \No M$ Word docs in email - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: RADIUS response from incorrect interface
"Paul Jenner" <[EMAIL PROTECTED]> wrote: > I am seeing an issue with freeradius 0.8.1 on Red Hat 8.0 where RADIUS > responses are coming out of a different virtual interface to the > interface they are made to. I couldn't see anything in the doc so > hopefully someone on this list can help. Read 'radiusd.conf', and look for "IP address" Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html