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[4]: RADIUS response from incorrect interface
Dear Alan DeKok, --Friday, February 7, 2003, 2:13:11 PM, you wrote to [EMAIL PROTECTED]: AD> 3APA3A <[EMAIL PROTECTED]> wrote: >> But it could be nice to change code to bind FreeRADIUS to IP address >> packet was received instead of IP from configuration on sending reply >> packet... AD> That's difficult to do with UDP sockets. We can perform a call to AD> bind() for every request, but that's very expensive. AD> Or, we can update the 'bind_address' functionality to be more like AD> Apache, and to allow a list of addresses. This requires some minor AD> code changes. Yes, it's probably better solution. Additionally, it could be nice to implement more than one port for authentication/accounting/proxying (it could be helpful to satisfy both current RFCs and older standards, for example). -- ~/ZARAZA Âñåãäà áóäåì ðàäû ïîñëóøàòü âàøå ÷èðèêàíüå (Òâåí) - 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: Re[2]: RADIUS response from incorrect interface
3APA3A <[EMAIL PROTECTED]> wrote: > But it could be nice to change code to bind FreeRADIUS to IP address > packet was received instead of IP from configuration on sending reply > packet... That's difficult to do with UDP sockets. We can perform a call to bind() for every request, but that's very expensive. Or, we can update the 'bind_address' functionality to be more like Apache, and to allow a list of addresses. This requires some minor code changes. > On multi-homed hosts with few gateways (for example if some > kind of load balancing is used) it can prevent FreeRADIUS from replying > from wrong IP. Of cause, situation is quite rare. Exactly. People have lived quite well with a single-IP RADIUS server for quite a while. There isn't a huge need for having it listen on multiple IP's. Alan DeKok. - 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[2]: RADIUS response from incorrect interface
Dear Alan DeKok, If he really needs FreeRADIUS to be bound to both interfaces it will not help (I do not see situation it may be useful). But it could be nice to change code to bind FreeRADIUS to IP address packet was received instead of IP from configuration on sending reply packet... On multi-homed hosts with few gateways (for example if some kind of load balancing is used) it can prevent FreeRADIUS from replying from wrong IP. Of cause, situation is quite rare. --Friday, February 7, 2003, 1:58:38 PM, you wrote to [EMAIL PROTECTED]: AD> "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. AD> Read 'radiusd.conf', and look for "IP address" AD> Alan DeKok. AD> - AD> 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
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
RADIUS response from incorrect interface
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. In more detail: * my RADIUS server has a real interface on IP X.X.X.X and a virtual interface on IP Y.Y.Y.Y * both interfaces are on the same subnet * the software is freeradius 0.8.1 compiled on Red Hat 8.0 * it is configured with "bind_address = *" to listen on both interfaces * when RADIUS requests are made to IP X.X.X.X, the responses come back from IP X.X.X.X * however when requests are made to IP Y.Y.Y.Y, the responses still come back from IP X.X.X.X * hence they are dropped by firewall as unestablished outgoing connections * UDP responses on virtual interfaces do work with this kernel as ISC bind is able to respond to DNS UDP requests on the same IP as the connection is made to Am I doing something wrong in the config or is this a bug? Thanks for any help on this, Paul Paul Jenner ioko365 Ltd. T: +44 (0)1904 438000 x353 M: +44 (0)7979 598170 E: [EMAIL PROTECTED] W: http://www.ioko365.com/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
