[RADIATOR] Multi-homed, Virtual IP and source IP

[Hugh Irvine]

Hello Thomas -

I'm not sure I understand your question?

The load balancers that I have worked with rewrite the reply to the VIP address, so the problem you describe doesn't occur.

Perhaps I am not understanding the problem?

regards

Hugh


On 25 May 2010, at 13:06, Thomas Guthmann wrote:

> Hey guys,
> 
> *Disclaimer*
> - It's a long email :)
> - I know, it's a common issue but I'd like to have some clarifications 
> and also to summarize for everybody the dilemma and possible solutions :)
> 
> *Issue*
> If you have Radiator behind a load balancer, you have Virtual IPs (VIP) 
> mounted on the Radiator hosts. As a result they will receive 
> Access-Requests for these VIPs. However Radiator won't reply with the 
> VIP used to receive the Access-Request but with its real IP (RIP aka 
> your main server IP).
> This generates 2 side effects :
> - the client will generally drop the reply because it's coming from an 
> unknown host. Indeed the client asked the VIP and expects a reply from 
> this source address and not from something else.
> - possible asymmetric routing (that's not a biggie)
> 
> *Questions*
> - Are there any Radiator design limitations to not be able to reply with 
> a VIP ?
> - Can you give me some hints to implement this feature in a homemade 
> authentication module (so far we use get_user and then return 
> $main::ACCEPT in handle_request)
> - is LocalAddress and getSock the way to go (cf: AuthRADIUS.pm) ?
> 
> *Possible workarounds*
> - Launch a radiator daemon per VIP with BindAddress [1]
> - Use dedicated routes [2]
> - Use iptables to S/DNAT everything to a VIP
> 
> None of these solutions are great IMHO. Because all of them imply more 
> work and create other problems. How to maintain many different 
> configurations or how to maintain all the routes/iptables rules when you 
> add/remove a VIP ? How to monitor so many process where you could only 
> monitor one. I agree workarounds exist, so it's better than nothing but 
> still it's just too bad that this feature doesn't exist for any kind of 
> authentication (though LocalAddress exists for AuthRADIUS to proxy 
> requests). I'm sure it would simplify a lot everybody's radiator farms 
> IF this is possible.
> 
> Anyway, except that Radiator is awesome, it's flexible and powerful. 
> Thanks for that and thanks for reading so far :)
> 
> Cheers,
> Thomas
> 
> PS: The wiki is broken : internal server error.
> 
> [1] : http://www.open.com.au/pipermail/radiator/2009-March/015444.html
> [2] : http://www.mail-archive.com/radiator@open.com.au/msg10956.html
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.