Source IP address for proxy requests
Hello, I have a cluster of two servers running freeradius (the cluster is monitored by heartbeat). Each of the two members of the cluster has its own IP address (192.168.1.2 and 192.168.1.3) and one of the (the active member) has the IP address in which it runs freeradius (192.168.1.1), so freeradius only listen in this address, not in the owned by the server. Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 968367590 Fax: 968398337
Angel L. Mateo wrote:
Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it?
Why is this a problem? I note RADIUS packets are using UDP, which means they're connectionless. I think you don't want a machine from the cluster send a proxy request, and a different machine get the proxy reply. This wouldn't work. -- Nicolas Baradakis
El lun, 25-09-2006 a las 14:46 +0200, Nicolas Baradakis escribió:
Angel L. Mateo wrote:
Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it?
Why is this a problem?
This is a problem for the next reasons: * I have to configure my firewall to accept radius conections to different addresses, not just the clustered IP. * The radius that receives the request has to define two different clients (to accept my request) and also my clustered radius (to send requests to me). I now it can be solved with configuration but I think this is not a elegant solution to the problem. If I have configured freeradius to listen in just one interface of the server, why it has to use another different interface?
I note RADIUS packets are using UDP, which means they're connectionless. I think you don't want a machine from the cluster send a proxy request, and a different machine get the proxy reply. This wouldn't work.
This is an impossible situation, because I have an active/standby configuration of the cluster. Just one node is running the IP and the server. The other node is just a backup one (in a normal environment). -- Angel L. Mateo <amateo@um.es>
"Angel L. Mateo" <amateo@um.es> wrote:
I note RADIUS packets are using UDP, which means they're connectionless. I think you don't want a machine from the cluster send a proxy request, and a different machine get the proxy reply. This wouldn't work.
This is an impossible situation, because I have an active/standby configuration of the cluster. Just one node is running the IP and the server. The other node is just a backup one (in a normal environment).
It's not impossible. It will happen EVERY TIME the active & standby switch roles. I've built clusters like this before. The clustered IP should be used ONLY for incoming traffic, and replies to that traffic. Any traffic originating from the cluster MUST use the machine-specific IP. This goes for every protocol, not just RADIUS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Angel L. Mateo wrote:
El lun, 25-09-2006 a las 14:46 +0200, Nicolas Baradakis escribió:
Angel L. Mateo wrote:
Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it?
Why is this a problem?
This is a problem for the next reasons:
* I have to configure my firewall to accept radius conections to different addresses, not just the clustered IP.
You could accept a small IP range like 192.168.1.0/30 on the firewall.
* The radius that receives the request has to define two different clients (to accept my request) and also my clustered radius (to send requests to me).
I think a realm server would reply to the same IP which it received the packet from.
I now it can be solved with configuration but I think this is not a elegant solution to the problem. If I have configured freeradius to listen in just one interface of the server, why it has to use another different interface?
That has nothing to do with FreeRADIUS. The source address of an outgoing UDP packet is chosen by the kernel according to the local network configuration. I'd suggest to look at the network routes on the host like suggested in an other reply to your mail.
I note RADIUS packets are using UDP, which means they're connectionless. I think you don't want a machine from the cluster send a proxy request, and a different machine get the proxy reply. This wouldn't work.
This is an impossible situation, because I have an active/standby configuration of the cluster. Just one node is running the IP and the server. The other node is just a backup one (in a normal environment).
I was confused because you didn't mention it was an active/backup setup. However, I note a virtual IP is usually used for incoming traffic, not the requests originated from a node of the cluser. -- Nicolas Baradakis
This is an impossible situation, because I have an active/standby configuration of the cluster. Just one node is running the IP and the server. The other node is just a backup one (in a normal environment).
I was confused because you didn't mention it was an active/backup setup. However, I note a virtual IP is usually used for incoming traffic, not the requests originated from a node of the cluser.
This is probably not the case in a failover config... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Mon 25 Sep 2006 19:05, Nicolas Baradakis wrote:
Angel L. Mateo wrote:
El lun, 25-09-2006 a las 14:46 +0200, Nicolas Baradakis escribió:
Angel L. Mateo wrote:
Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it?
Why is this a problem?
This is a problem for the next reasons:
* I have to configure my firewall to accept radius conections to different addresses, not just the clustered IP.
You could accept a small IP range like 192.168.1.0/30 on the firewall.
* The radius that receives the request has to define two different clients (to accept my request) and also my clustered radius (to send requests to me).
I think a realm server would reply to the same IP which it received the packet from.
I now it can be solved with configuration but I think this is not a elegant solution to the problem. If I have configured freeradius to listen in just one interface of the server, why it has to use another different interface?
That has nothing to do with FreeRADIUS. The source address of an outgoing UDP packet is chosen by the kernel according to the local network configuration.
I had this problem previously with FreeRADIUS where radius had to reply from the inside interface of a multihomed server else the packets would not match the IPSec tunnel ACLs bound to the external interface (A common config) I solved it by telling freeradius to only bind to one IP. Does this config no longer work?? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
El lun, 25-09-2006 a las 22:54 +0300, Peter Nixon escribió:
I had this problem previously with FreeRADIUS where radius had to reply from the inside interface of a multihomed server else the packets would not match the IPSec tunnel ACLs bound to the external interface (A common config) I solved it by telling freeradius to only bind to one IP. Does this config no longer work??
It continues working, but the problem is with connections originated from the radius server, not the answer. Specifically, the problem is with proxy requests sent by the radius server. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 968367590 Fax: 968398337
I've you seen my post or are you just ignoring it ? :) -----Message d'origine----- De : freeradius-users-bounces+s.cantos=neopost.com@lists.freeradius.org [mailto:freeradius-users-bounces+s.cantos=neopost.com@lists.freeradius.org] De la part de Angel L. Mateo Envoyé : mardi 26 septembre 2006 08:34 À : freeradius-users@lists.freeradius.org Objet : Re: Source IP address for proxy requests El lun, 25-09-2006 a las 22:54 +0300, Peter Nixon escribió:
I had this problem previously with FreeRADIUS where radius had to reply
from
the inside interface of a multihomed server else the packets would not match the IPSec tunnel ACLs bound to the external interface (A common config) I solved it by telling freeradius to only bind to one IP. Does this config no longer work??
It continues working, but the problem is with connections originated from the radius server, not the answer. Specifically, the problem is with proxy requests sent by the radius server. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 968367590 Fax: 968398337 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
El mar, 26-09-2006 a las 10:00 +0200, Sebastien Cantos escribió:
I've you seen my post or are you just ignoring it ? :)
I've seen your post. I already know I could reconfigure routes. -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 968367590 Fax: 968398337
Here is the error message I am getting when I am trying to authenticate, -------------------- Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 1 rlm_mschap: Told to do MS-CHAPv2 for apu with NT-Password rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 1 -------------------- Any clues would be appreciated. Apu ------------------------------ Apu Islam ( E Pluribus Unum)
Peter Nixon wrote:
On Mon 25 Sep 2006 19:05, Nicolas Baradakis wrote:
That has nothing to do with FreeRADIUS. The source address of an outgoing UDP packet is chosen by the kernel according to the local network configuration.
I had this problem previously with FreeRADIUS where radius had to reply from the inside interface of a multihomed server else the packets would not match the IPSec tunnel ACLs bound to the external interface (A common config) I solved it by telling freeradius to only bind to one IP. Does this config no longer work??
This example is different from the one we're discussing. FreeRADIUS replies indeed to the NAS from the same address as the request arrived at. However, a proxy request is different, because it's a new outgoing packet. In this case, we don't force the source IP in FreeRADIUS and we shouldn't do so because the NAS and the realm server are possibly on a different network. (it depends on the local network configuration) The network configuration of the host is outside the scope of FreeRADIUS. The correct way to solve the problem is to fix the network routes on the host, so the outgoing requests have the desired source IP. -- Nicolas Baradakis
On Tue 26 Sep 2006 11:55, Nicolas Baradakis wrote:
Peter Nixon wrote:
On Mon 25 Sep 2006 19:05, Nicolas Baradakis wrote:
That has nothing to do with FreeRADIUS. The source address of an outgoing UDP packet is chosen by the kernel according to the local network configuration.
I had this problem previously with FreeRADIUS where radius had to reply from the inside interface of a multihomed server else the packets would not match the IPSec tunnel ACLs bound to the external interface (A common config) I solved it by telling freeradius to only bind to one IP. Does this config no longer work??
This example is different from the one we're discussing. FreeRADIUS replies indeed to the NAS from the same address as the request arrived at.
However, a proxy request is different, because it's a new outgoing packet. In this case, we don't force the source IP in FreeRADIUS and we shouldn't do so because the NAS and the realm server are possibly on a different network. (it depends on the local network configuration)
The network configuration of the host is outside the scope of FreeRADIUS. The correct way to solve the problem is to fix the network routes on the host, so the outgoing requests have the desired source IP.
Yes you are correct. Abviously I didn't read the thread in enough depth. It does bring up the issue that we maybe should have an optional proxy_source_ip config option.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
On Tue 26 Sep 2006 11:55, Nicolas Baradakis wrote:
However, a proxy request is different, because it's a new outgoing packet. In this case, we don't force the source IP in FreeRADIUS and we shouldn't do so because the NAS and the realm server are possibly on a different network. (it depends on the local network configuration)
The network configuration of the host is outside the scope of FreeRADIUS. The correct way to solve the problem is to fix the network routes on the host, so the outgoing requests have the desired source IP.
Yes you are correct. Abviously I didn't read the thread in enough depth. It does bring up the issue that we maybe should have an optional proxy_source_ip config option..
I don't think it's a good idea, because all the realm servers may not be on the same network. IMHO FreeRADIUS doesn't have to cope with the network configuration of the host: it only has to set the destination IP, and the rest is handled by the kernel. -- Nicolas Baradakis
On Tue 26 Sep 2006 16:26, Nicolas Baradakis wrote:
Peter Nixon wrote:
On Tue 26 Sep 2006 11:55, Nicolas Baradakis wrote:
However, a proxy request is different, because it's a new outgoing packet. In this case, we don't force the source IP in FreeRADIUS and we shouldn't do so because the NAS and the realm server are possibly on a different network. (it depends on the local network configuration)
The network configuration of the host is outside the scope of FreeRADIUS. The correct way to solve the problem is to fix the network routes on the host, so the outgoing requests have the desired source IP.
Yes you are correct. Abviously I didn't read the thread in enough depth. It does bring up the issue that we maybe should have an optional proxy_source_ip config option..
I don't think it's a good idea, because all the realm servers may not be on the same network. IMHO FreeRADIUS doesn't have to cope with the network configuration of the host: it only has to set the destination IP, and the rest is handled by the kernel.
It is not a critical option (for me) at present, but it is usefull and it should default to * of course. If someone doesn't have all their realm servers on the same "side" of the server then they should know that. A more flexible option of course would be to have an internal attribute like "Proxy-Source-IP". The it could be specified per request for people who wish to.. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Nicolas Baradakis wrote:
Yes you are correct. Abviously I didn't read the thread in enough depth. It does bring up the issue that we maybe should have an optional proxy_source_ip config option..
All IP protocol servers should offer each type of socket a configurable bind address (or list of such). That is quite aside from the specifics of this issue - that is, it solves other, much much harder to solve problems than just this issue, and is required for absolutely deterministic behaviour.
I don't think it's a good idea, because all the realm servers may not be on the same network. IMHO FreeRADIUS doesn't have to cope with the network configuration of the host: it only has to set the destination IP, and the rest is handled by the kernel.
This is not a convincing argument to my ear. There are legitimate reasons to want to bind to a *specific* IP for sockets sinking and sourcing datagrams (and in fact for stream protocols, though these tend to be less of an issue). Bind, a venerable (if crufty) and EXTREMELY widely deployed datagram protocol client/server, has found this out repeatedly (see transfer-source, query-source, notify-source - those options weren't added for giggles). I'm currently running into a problem with ISC dhcpd related to it's failure to offer IP-specific bind options and offering service to overlapping address space on a single server, which is impossible for the want of this micro-option.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
All IP protocol servers should offer each type of socket a configurable bind address (or list of such). That is quite aside from the specifics of this issue - that is, it solves other, much much harder to solve problems than just this issue, and is required for absolutely deterministic behaviour.
Yes. For 2.0, I wouild like to have a configurable "proxy" section. The difficulty is that it should really be configurable per-home-server. That's a fair amount of work.
There are legitimate reasons to want to bind to a *specific* IP for sockets sinking and sourcing datagrams (and in fact for stream protocols, though these tend to be less of an issue). Bind, a venerable (if crufty) and EXTREMELY widely deployed datagram protocol client/server, has found this out repeatedly (see transfer-source, query-source, notify-source - those options weren't added for giggles).
Yes, I've worked with Bind, and done exactly that. The difference with RADIUS is that there have been relatively few complaints about the current behavior, which means it's a low priority to change it. And changing it means most likely that people will configure proxying on IP X to home server at IP Y... which is not routable from X. The kernel UDP socket code will ensure that no error is returned to the server, meaning that it's impossible to figure out what's going wrong. I really would prefer to have the proxy sockets bind to "*", and to have the kernel do the right thing for sending packets. I'd like to see compelling reasons why this behavior needs to be change before updating the code. (See the comment about about there being few complaints...)
I'm currently running into a problem with ISC dhcpd related to it's failure to offer IP-specific bind options and offering service to overlapping address space on a single server, which is impossible for the want of this micro-option.
That's come up on the ISC list. The answer is to create multiple interfaces, set up routing, and to have multiple servers listening, each on one interface. There has to be a better way... But for dhcpd, the issue isn't the packets it's originating, but which IP's it's listening on. FreeRADIUS already supports listening on multiple IP's, so it's already a step ahead of DHCPD. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue 26 Sep 2006 22:03, Alan DeKok wrote:
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
All IP protocol servers should offer each type of socket a configurable bind address (or list of such). That is quite aside from the specifics of this issue - that is, it solves other, much much harder to solve problems than just this issue, and is required for absolutely deterministic behaviour.
Yes. For 2.0, I wouild like to have a configurable "proxy" section. The difficulty is that it should really be configurable per-home-server. That's a fair amount of work.
Yep That would probably be smarter than my hairbrained "Proxy-Source-IP" suggestion.. *needs more coffee* -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On the active server (the one that have 192.168.1.1) you have to delete the route that route packets through 192.168.1.2 for subnet 192.168.1.1/24 and make sure there's a route through 192.168.1.1 for subnet 192.168.1.1/24. This way, all connexion initiate from this box will have source address 192.168.1.1. When the Ip is switched to 192.168.1.3 you have to do the same route operation, delete the route through 192.168.1.3 for subnet 192.168.1.0/24 and add a route 192.168.1.1 for subnet 192.168.1.1/24. -----Message d'origine----- De : freeradius-users-bounces+s.cantos=neopost.com@lists.freeradius.org [mailto:freeradius-users-bounces+s.cantos=neopost.com@lists.freeradius.org] De la part de Angel L. Mateo Envoyé : lundi 25 septembre 2006 14:01 À : FreeRadius users mailing list Objet : Source IP address for proxy requests Hello, I have a cluster of two servers running freeradius (the cluster is monitored by heartbeat). Each of the two members of the cluster has its own IP address (192.168.1.2 and 192.168.1.3) and one of the (the active member) has the IP address in which it runs freeradius (192.168.1.1), so freeradius only listen in this address, not in the owned by the server. Freeradius is working fine with this configuration, except the proxy module. The problema I have is that proxy requests are originated with the IP address of the member, not the IP of the cluster. And I haven't found any configuration option to configure this. Is there any way to do it? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 968367590 Fax: 968398337 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (7)
-
Alan DeKok -
Angel L. Mateo -
Apu islam -
Nicolas Baradakis -
Peter Nixon -
Phil Mayers -
Sebastien Cantos