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
<<attachment: winmail.dat>>
