Hi Alan/others, I wonder whether there is any use for Freeradius-Proxied-To attribute with freeradius 2.0. In freeradius 1.X the attribute was used to stop proxy for relayed packets. Now when I'm relaying some accounting packets to my freeradius server using radrelay binary from 1.1.6 and there is a packet which has already "Freeradius-Proxied-To" attribute set then freeradius 2.0(cvs head) just ignores it and tries to proxy the packet to remote home server. Would it be possible that 2.0 also honors the Freeradius-Proxied-To attribute as in 1.X? I've also observed following related issue regarding the "default_fallback" option of "proxy server {}" in proxy.conf: * I've set default_fallback = yes * home server for realm A was not reachable ==> when sending the packet with realm A(with Freeradius-Proxied-To set to IP of home_server for realm A) to radius then: 1) radius was trying to proxy the packet to home_server(ignoring Freeradius-Proxied-To attribute) 2) radius did not fall back to LOCAL realm 3) radius did not send accounting response back to client(radrelay) - probably consequence of 2??? Final consequence is that radrelay re-sends the packet which was not acknowledged by accounting response and it keeps re-sending forever...(radrelay can't continue in processing detail file) What I'm trying to achieve actually is freeradius 2.0 + radrelay(using binary from 1.1.6) and above is the "show stopper":( Any advise? Here is related debug: ... home_server srv { ipaddr = <PROXY_IP> IP address [<PROXY_IP>] port = 1812 type = "auth+acct" secret = "Atekfuv9" response_window = 30 max_outstanding = 65536 zombie_period = 40 status_check = "none" ping_check = "none" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 num_pings_to_alive = 3 revive_interval = 300 status_check_timeout = 4 } server_pool failover { type = failover home_server = srv } server_pool failover { type = failover home_server = srv } realm A { pool = failover } ... Proxying request 0 to realm A, home server <PROXY_IP> port 1813 ... Going to the next request Thread 1 waiting to be assigned a request Waking up in 29 seconds... Received conflicting packet from client <RADRELAY_CLIENT_IP> port 33413 - ID: 0 due to unfinished request 0. Giving up on old request. ... Proxying request 1 to realm A, home server <PROXY_IP> port 1813 ... Proxying request 2 to realm A, home server <PROXY_IP> port 1813 Going to the next request Thread 3 waiting to be assigned a request Waking up in 23 seconds... Received conflicting packet from client <RADRELAY_CLIENT_IP> port 33413 - ID: 0 due to unfinished request 2. Giving up on old request. ... Rejecting request 0 due to lack of any response from home server <PROXY_IP> port 1813 WARNING: Unresponsive child (id 0) for request 0, in module <server-core> component <server-core> WARNING: Marking home server <PROXY_IP> port 1813 as zombie (it looks like it is dead). Thread 1 got semaphore Thread 1 waiting to be assigned a request Received conflicting packet from client <RADRELAY_CLIENT_IP> port 33413 - ID: 0 due to unfinished request 9. Giving up on old request. ... Rejecting request 1 due to lack of any response from home server <PROXY_IP> port 1813 WARNING: Unresponsive child (id 0) for request 1, in module <server-core> component <server-core> Thread 3 got semaphore Thread 3 waiting to be assigned a request Received conflicting packet from client <RADRELAY_CLIENT_IP> port 33413 - ID: 0 due to unfinished request 10. Giving up on old request. ... ERROR: Failed to find live home server for realm A ... Rejecting request 438 due to lack of any response from home server <PROXY_IP> port 1813 FAILURE: Marking home server <PROXY_IP> port 1813 as dead. WARNING: Unresponsive child (id 0) for request 438, in module <server-core> component <server-core> ... ERROR: Failed to find live home server for realm A Finished request 449 state 6 ... Milan Holub holub (at) thenet (dot) ch -------------------------------------- TheNet-Internet Services AG, im Bernertechnopark, Morgenstr. 129 CH-3018, Bern, Switzerland 031 998 4333, Fax 031 998 4330 http://www.thenet.ch http://wlan.thenet.ch --------------------------------------
Milan Holub wrote:
I wonder whether there is any use for Freeradius-Proxied-To attribute with freeradius 2.0.
It should be there for backwards compatibility, but there are likely better ways of achieving the same result.
Now when I'm relaying some accounting packets to my freeradius server using radrelay binary from 1.1.6 and there is a packet which has already "Freeradius-Proxied-To" attribute set then freeradius 2.0(cvs head) just ignores it and tries to proxy the packet to remote home server.
See src/modules/rlm_realm/rlm_realm.c That code needs to be fixed.
Would it be possible that 2.0 also honors the Freeradius-Proxied-To attribute as in 1.X?
That *is* the idea.
I've also observed following related issue regarding the "default_fallback" option of "proxy server {}" in proxy.conf:
That should probably be removed. There will be other, better, ways of acheiving the same result in 2.0. See my recent message to freeradius-devel.
What I'm trying to achieve actually is freeradius 2.0 + radrelay(using binary from 1.1.6) and above is the "show stopper":(
Any advise?
The radrelay functionality in 2.0 doesn't yet work properly. This was acknowledged in the announcement. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi Alan&others, On Mon, May 21, 2007 at 04:57:51PM +0200, Alan Dekok wrote:
Milan Holub wrote:
I wonder whether there is any use for Freeradius-Proxied-To attribute with freeradius 2.0.
It should be there for backwards compatibility, but there are likely better ways of achieving the same result.
Now when I'm relaying some accounting packets to my freeradius server using radrelay binary from 1.1.6 and there is a packet which has already "Freeradius-Proxied-To" attribute set then freeradius 2.0(cvs head) just ignores it and tries to proxy the packet to remote home server.
See src/modules/rlm_realm/rlm_realm.c That code needs to be fixed.
Would it be possible that 2.0 also honors the Freeradius-Proxied-To attribute as in 1.X?
That *is* the idea.
==> my humble attempt to add the backwards compatibility for Freeradius-Proxied-To attribute: Index: src/modules/rlm_realm/rlm_realm.c =================================================================== RCS file: /source/radiusd/src/modules/rlm_realm/rlm_realm.c,v retrieving revision 1.66 diff -u -r1.66 rlm_realm.c --- src/modules/rlm_realm/rlm_realm.c 20 Apr 2007 14:31:30 -0000 1.66 +++ src/modules/rlm_realm/rlm_realm.c 25 May 2007 12:48:08 -0000 @@ -64,6 +64,7 @@ char *ptr; VALUE_PAIR *vp; REALM *realm; + lrad_ipaddr_t my_ipaddr; struct realm_config_t *inst = instance; @@ -241,12 +242,18 @@ */ vp = pairfind(request->packet->vps, PW_FREERADIUS_PROXIED_TO); if (vp) { -#if 0 /* * FIXME: HOME SERVER * * What the heck is this code doing, and why? */ + my_ipaddr.af = AF_INET; + my_ipaddr.ipaddr.ip4addr = vp->data.ipaddr; + if (home_server_find(&my_ipaddr, request->packet->dst_port)) { + DEBUG2(" rlm_realm: Request not proxied due to Freeradius-Proxied-To"); + return 0; + } +#if 0 if (request->packet->code == PW_AUTHENTICATION_REQUEST && vp->vp_ipaddr == realm->home_auth->ipaddr.ipaddr.ip4addr.s_addr) { ==> I works for me well(incomming accounting/authorization packet containing Freeradius-Proxied-To is no more sent to IP present as a value of the attribute); this might not work for home servers which listen on non-standard ports(due to dst_port passed in to home_server_find function) ==> the patch might be useful for setups where you have some home_servers already FR 2.0 but but some of them still FR 1.X ==> could you comment, Alan? Milan Holub holub (at) thenet (dot) ch -------------------------------------- TheNet-Internet Services AG, im Bernertechnopark, Morgenstr. 129 CH-3018, Bern, Switzerland 031 998 4333, Fax 031 998 4330 http://www.thenet.ch http://wlan.thenet.ch --------------------------------------
Milan Holub wrote:
==> my humble attempt to add the backwards compatibility for Freeradius-Proxied-To attribute:
In 2.0.0, the "detail" file reader looks for Packet-Src-IP-Address && Packet-Dst-IP-Address. The "detail" module needs to write these, too. Then, the "realm" module needs to be updated to suppress proxying when: request->packet->src_ipaddr == request->home->ipaddr && request->packet->src_port == request->home->port This makes the FreeRADIUS-Proxied-To attribute (mostly) redundant. It will work easily for 2 servers. For more than 2, the configuration should be set up as: 1 -> 2 1 -> 3 2 -> 1 3 -> 1 Requests from '2' will reach '3' through '1', and there's no loop. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Milan Holub wrote: ...
==> I works for me well(incomming accounting/authorization packet containing Freeradius-Proxied-To is no more sent to IP present as a value of the attribute); this might not work for home servers which listen on non-standard ports(due to dst_port passed in to home_server_find function)
Yes. And it's not
==> the patch might be useful for setups where you have some home_servers already FR 2.0 but but some of them still FR 1.X
I've committed a related patch, which handles servers with non-standard ports. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi Alan&others, On Mon, May 21, 2007 at 04:57:51PM +0200, Alan Dekok wrote:
What I'm trying to achieve actually is freeradius 2.0 + radrelay(using binary from 1.1.6) and above is the "show stopper":(
Any advise?
The radrelay functionality in 2.0 doesn't yet work properly. This was acknowledged in the announcement.
==> finally I came to the workaround where all accounting requests comming from certain IP(server where radrelay is running on detail file) are explicitly set to be proxied to realm LOCAL ==> this is ensured by following acct_users entry: DEFAULT Packet-Src-IP-Address == "<relay_host_ip>", Proxy-To-Realm := LOCAL Firstly I wanted to put the entry into preproxy_users where it did not work properly: I could see that the realm was set correctly to "LOCAL" but at the same time there was an attempt to send the packet to remote home_server: Proxying request 0 to realm LOCAL, home server <FOREIGN_HOMESERVER_IP> port 1813 Is this a bug with "preproxy_users" or it's just a feature? Milan Holub holub (at) thenet (dot) ch -------------------------------------- TheNet-Internet Services AG, im Bernertechnopark, Morgenstr. 129 CH-3018, Bern, Switzerland 031 998 4333, Fax 031 998 4330 http://www.thenet.ch http://wlan.thenet.ch --------------------------------------
Milan Holub wrote:
Firstly I wanted to put the entry into preproxy_users where it did not work properly: I could see that the realm was set correctly to "LOCAL" but at the same time there was an attempt to send the packet to remote home_server: Proxying request 0 to realm LOCAL, home server <FOREIGN_HOMESERVER_IP> port 1813
preproxy_users cannot currently cancel proxying. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (2)
-
Alan Dekok -
Milan Holub