Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

This may be the case now, but pretty sure we went down this road YEARS ago and 
even with BindAddress, packets were still being sourced from the main IP 
address. In the mailing list archives this argument may exist. I vaguely 
remember being told by Hugh that it was not possible in Perl at the time to 
choose the source address to respond from.

Again, not arguing that now; just saying what we ran into in the past.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 29, 2016, at 6:17 AM, Heikki Vatiainen  wrote:
> 
> When BindAddress is configured, a socket is created and bound for each 
> address defined by BindAddress. In this case the source address of a 
> reply is the specific non-wildcard address the socket was bound to.
> 
> In short: BindAddress can be useful on multi homed hosts. However, if IP 
> addresses are added and removed dynamically, this can cause problems 
> because the addresses are now part of the Radiator configuration too.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

In my experience this is not the case. It will LISTEN on those addresses for 
sure. But it’s return packets are always sourced from the primary IP address of 
the outgoing interface. DSR will work, but the clients will receive a response 
from an IP address that is not of the configure RADIUS server. This may (but 
should not) work for various clients. This may of changed, in recent years. 
YMMV.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 29, 2016, at 5:19 AM, Hartmaier Alexander 
>  wrote:
> 
> When you configure the VIP as loopback on every radiator server and bind
> radiator to this ip the reply packets should be sent from it.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Heikki Vatiainen]

On 27.07.2016 21:32, Robert Blayzor wrote:

> The problem with this I think is that Radiator responds with a source
> address of where the packet leaves. (at least that’s been my
> experience).

Yes, this happens by default when BindAddress is not configured.

The default is to bind the RADIUS listen ports with the wildcard address 
0.0.0.0. When the replies are sent, they are from the socket that 
received the request. When the socket has been bound with the wildcard 
address, kernel will pick a source address for the reply.

When BindAddress is configured, a socket is created and bound for each 
address defined by BindAddress. In this case the source address of a 
reply is the specific non-wildcard address the socket was bound to.

In short: BindAddress can be useful on multi homed hosts. However, if IP 
addresses are added and removed dynamically, this can cause problems 
because the addresses are now part of the Radiator configuration too.

> Most clients will probably ignore the response as it’s
> coming from a different address.

Yes, they will probably log the replies as unknown messages or something 
similar.

> With Radiator being Perl, I don’t think you can force Radiator to
> answer from a specific source address on the server.

With wildcard bind address things can get complicated. There are socket 
functions that allow querying the address the request was sent to, but 
these are OS specific and may require additional modules for accessing, 
for example sendmsg() and other functions.

The easiest way to handle problems with reply addresses on multi homed 
hosts is to use BindAddress, if possible.

Thanks,
Heikki

-- 
Heikki Vatiainen
Open System Consultants

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Hartmaier Alexander]

As a general network design we try to stay away from multihomed servers
as much as possible as the server admins lack networking/routing
know-how which leads to failing connectivity all the time.

Direct server return has its own share of problems which is why we don't
use it anymore but this is protocol dependent and might work for radius
which is udp.

When you configure the VIP as loopback on every radiator server and bind
radiator to this ip the reply packets should be sent from it.

Best regards, Alex


On 2016-07-28 00:48, xcorpse wrote:
> On 27/07/16 19:32, Robert Blayzor wrote:
>> DSR load balancing assumes the real servers know about the load balanced VIP 
>> and is generally configured on a loopback.
>>
>> The problem with this I think is that Radiator responds with a source 
>> address of where the packet leaves. (at least that’s been my experience). 
>> Most clients will probably ignore the response as it’s coming from a 
>> different address.
>>
>> With Radiator being Perl, I don’t think you can force Radiator to answer 
>> from a specific source address on the server.
> i've used radiator with dsr for some fairly large radius installs, works
> fine as long as you set it up correctly. the loopback alias or firewall
> packet mangling rules will make sure that the return packets are not
> ignored ...
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[xcorpse]

On 27/07/16 19:32, Robert Blayzor wrote:
> DSR load balancing assumes the real servers know about the load balanced VIP 
> and is generally configured on a loopback.
>
> The problem with this I think is that Radiator responds with a source address 
> of where the packet leaves. (at least that’s been my experience). Most 
> clients will probably ignore the response as it’s coming from a different 
> address.
>
> With Radiator being Perl, I don’t think you can force Radiator to answer from 
> a specific source address on the server.

i've used radiator with dsr for some fairly large radius installs, works 
fine as long as you set it up correctly. the loopback alias or firewall 
packet mangling rules will make sure that the return packets are not 
ignored ...

-- 
no name ... no slogan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Robert Blayzor]

DSR load balancing assumes the real servers know about the load balanced VIP 
and is generally configured on a loopback.

The problem with this I think is that Radiator responds with a source address 
of where the packet leaves. (at least that’s been my experience). Most clients 
will probably ignore the response as it’s coming from a different address.

With Radiator being Perl, I don’t think you can force Radiator to answer from a 
specific source address on the server.


NAT will work via the F5, you just have to make sure that the response traffic 
goes back out to the load balancer it came in on.

--
Robert
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu




> On Jul 27, 2016, at 1:38 PM, shaun gibson  wrote:
> 
> i've used direct server return for radius and it seemed to work well :
> 
> http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
> https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
> 
> using the f5 for inbound and outbound traffic nat will also work, just
> depends what your requirements are ...

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[Barry Ard]

Thanks Shaun. This is good reading.

Barry

On Wed, Jul 27, 2016 at 11:38 AM, shaun gibson  wrote:

> On 27/07/2016 18:14, Barry Ard wrote:
>
> > We are running into some challenges configuring a new environment for
> > Eduroam.
> >
> > Recently we have moved away from 2 servers running multiple radiator
> > processes to a multiple VMs behind an F5 load balancer. This has been
> > working well for our wireless infrastructure but has been posing
> > challenges as we are trying to include our Eduroam config.
> >
> > The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a
> > private address facing the F5, eth1 is a public address and is the
> > default gateway.
> >
> > I have created a test enviroment with an external radius server to
> > simulate Eduroam.
> > Initially proxied requests would transit the VMs default gateway which
> > I think is undesriable so I created a static route for the external
> > radius server to force it out the load balancer facing interface. Now
> > proxied requests have a private address which of course will not work.
> >
> > I think the desirable scenario would be for proxied requests to exit
> > through the F5 and be NAT’d to source from the F5 external address. My
> > colleague who admins the load balancer is hesitant to NAT externally
> > using an address that is currently listening on a service. He thinks
> > this is getting too complicated.
> >
> > I am sure others are using a load balancer in this scenario so please
> > tell me what you are doing.
> >
> i've used direct server return for radius and it seemed to work well :
>
>
> http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
>
> https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
>
> using the f5 for inbound and outbound traffic nat will also work, just
> depends what your requirements are ...
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>



-- 

Barry Ard   barry@ualberta.ca
IST
University of Alberta
Edmonton, Alberta   Canada
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator and Load Balancer

[shaun gibson]

On 27/07/2016 18:14, Barry Ard wrote:

> We are running into some challenges configuring a new environment for
> Eduroam. 
>
> Recently we have moved away from 2 servers running multiple radiator
> processes to a multiple VMs behind an F5 load balancer. This has been
> working well for our wireless infrastructure but has been posing
> challenges as we are trying to include our Eduroam config. 
>
> The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a
> private address facing the F5, eth1 is a public address and is the
> default gateway.
>
> I have created a test enviroment with an external radius server to
> simulate Eduroam.
> Initially proxied requests would transit the VMs default gateway which
> I think is undesriable so I created a static route for the external
> radius server to force it out the load balancer facing interface. Now
> proxied requests have a private address which of course will not work.
>
> I think the desirable scenario would be for proxied requests to exit
> through the F5 and be NAT’d to source from the F5 external address. My
> colleague who admins the load balancer is hesitant to NAT externally
> using an address that is currently listening on a service. He thinks
> this is getting too complicated.
>
> I am sure others are using a load balancer in this scenario so please
> tell me what you are doing.
>
i've used direct server return for radius and it seemed to work well :

http://blog.haproxy.com/2011/07/29/layer-4-load-balancing-direct-server-return-mode/
https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return

using the f5 for inbound and outbound traffic nat will also work, just
depends what your requirements are ...



signature.asc
Description: OpenPGP digital signature
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radiator and Load Balancer

[Barry Ard]

We are running into some challenges configuring a new environment for
Eduroam.

Recently we have moved away from 2 servers running multiple radiator
processes to a multiple VMs behind an F5 load balancer. This has been
working well for our wireless infrastructure but has been posing challenges
as we are trying to include our Eduroam config.

The F5 is NATing to the VMs. The VMs have 2 interfaces: eth0 is a private
address facing the F5, eth1 is a public address and is the default gateway.

I have created a test enviroment with an external radius server to simulate
Eduroam.
Initially proxied requests would transit the VMs default gateway which I
think is undesriable so I created a static route for the external radius
server to force it out the load balancer facing interface. Now proxied
requests have a private address which of course will not work.

I think the desirable scenario would be for proxied requests to exit
through the F5 and be NAT’d to source from the F5 external address. My
colleague who admins the load balancer is hesitant to NAT externally using
an address that is currently listening on a service. He thinks this is
getting too complicated.

I am sure others are using a load balancer in this scenario so please tell
me what you are doing.

Thanks,
Barry


-- 

Barry Ard   barry@ualberta.ca
IST
University of Alberta
Edmonton, Alberta   Canada
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator