Re: proxy problems with 2.0.5

[Alan DeKok]

Pshem Kowalczyk wrote:
> For some reason the module returns noop ;-( I tried the following:

  Which is not what I suggested.  Why?

> I guess the easiest way to fix this is to use unlang to update the
> reply packet based on information from either control or request
> attributes.

  That's what unlang is for.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: proxy problems with 2.0.5

[Pshem Kowalczyk]

Hi,

For some reason the module returns noop ;-( I tried the following:

I created new 'files' instance:
files post_proxy_files {

usersfile = ${confdir}/post-proxy-users
acctusersfile = ${confdir}/post-proxy-users
auth_usersfile = ${confdir}/post-proxy-users
postproxy_usersfile = ${confdir}/post-proxy-users
postauth_usersfile = ${confdir}/post-proxy-users
}

(yes it's an overkill, I just tried to figure out which file is the
one to be read during that phase)

The post-proxy-users has the following syntax:
DEFAULT NAS-IP-Address == '10.119.255.244'
Cisco-AVpair += "ip:dns-servers=x.y.129.67 x.y.129.68",
Framed-Pool += "wc-1",
Huawei-Primary-DNS += "x.y.129.67",
Huawei-Secondary-DNS += "x.y.129.68"

(which is the same as the 'auth' section, without the Proxy-To-Realm statement).

and the post-proxy section:
post-proxy {
post_proxy_files
$INCLUDE post-proxy.conf
attr_filter.post-proxy
#   reply_log
}

During the debug I get the following:

Going to the next request
rad_recv: Access-Accept packet from host 127.0.0.1 port 1815, id=175, length=57
IHUG-Speed-Down = "64"
IHUG-Speed-Up = "64"
Framed-Protocol = PPP
Service-Type = Framed-User
Proxy-State = 0x323339
+- entering group post-proxy
++[post_proxy_files] returns noop

Which suggests that the module didn't find anything worth dwelling on.

So I made a small experiment - replaced the entry in the users file with:
DEFAULT Framed-Protocol == PPP
Cisco-AVpair += "ip:dns-servers=x.y.129.67 x.y.129.68",
Framed-Pool += "ihug-wc-1",
Huawei-Primary-DNS += "x.y.129.67",
Huawei-Secondary-DNS += "x.y.129.68"

(to match the reply from the home server) and I got exactly what I wanted:

+- entering group post-proxy
postproxy_users: Matched entry DEFAULT at line 4
++[post_proxy_files] returns ok

and it returned the whole answer.

Reading rlm_files.c I found the following:

static int file_postproxy(void *instance, REQUEST *request)
{
struct file_instance *inst = instance;

return file_common(inst, request, "postproxy_users",
   inst->postproxy_users,
   request->proxy_reply->vps, &request->reply->vps);
}

does that mean that in fact looks for the match only in the
'proxy-reply' packet?

I guess the easiest way to fix this is to use unlang to update the
reply packet based on information from either control or request
attributes.

kind regards
Pshem
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: proxy problems with 2.0.5

[Alan DeKok]

  Ah  You're relying on the "authorize" section being run after the
proxy reply is received.

  Don't do that.

  That feature was removed before 2.0, and seems to have accidentally
been enabled again.  It was removed in 2.0.5 because it's wrong.  The
"post-proxy" section is meant to process proxy replies.  Use it, not the
"authorize" section.

  If you need to run some *specific* module in the post-proxy section,
you can migrate your configuration by doing:

post-proxy {
...
files.authorize
sql.authorize
...
}

  Which will run the "authorize" sections of the "files" and "sql" modules.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: proxy problems with 2.0.5

[Alan DeKok]

Pshem Kowalczyk wrote:
> I upgraded our test server from 2.0.4 to 2.0.5 today and proxy setup
> we use stopped working.

  What does debugging mode say in 2.0.4, and in 2.0.5?

> Should that continue to work?

  Well, yes.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html