Internal vs external proxy server
Hi guys, Can someone please point me in right direction of why reply attributes gets deleted from internal proxy reply ? If I use: DEFAULT Proxy-To-Realm := "dialup" realm dialup { virtual_server = dialup } server dialup { authorize { dialup_sql_auth pap } authenticate { Auth-Type PAP { pap } } post-auth { update reply { &Alc-Subsc-ID-Str := "DIALUP-%{%{Stripped-User-Name}:-%{User-Name}}" } } } default server gets reply from dialup server but ignore any reply attributes and returns empty Accept. I can copy attribute from proxy-reply in post-proxy and see it in radclient accept. update reply { &Alc-Subsc-ID-Str := &proxy-reply:Alc-Subsc-ID-Str } But if i use same config but change dialup from internal to external proxy it works and I can see all return attributes: server dialup { listen { type = auth ipaddr = 127.0.0.1 port = 1645 } ... } realm dialup { authhost=127.0.0.1:1645 secret=xxx } Thanks, Artis
On Aug 19, 2019, at 1:41 PM, Artis Caune <artis.caune@gmail.com> wrote:
Can someone please point me in right direction of why reply attributes gets deleted from internal proxy reply ?
They don't get deleted, they just don't get copied across.
If I use:
DEFAULT Proxy-To-Realm := "dialup"
realm dialup { virtual_server = dialup } server dialup { authorize { dialup_sql_auth pap } authenticate { Auth-Type PAP { pap } } post-auth { update reply { &Alc-Subsc-ID-Str := "DIALUP-%{%{Stripped-User-Name}:-%{User-Name}}" }
add: update { &outer.reply += &reply } And it will copy the reply over to the parent. We're not going to "fix" this in v3, unfortunately. People rely on the existing behaviour, and we can't really change that. Alan DeKok.
On Wed, 21 Aug 2019 at 06:25, Alan DeKok <aland@deployingradius.com> wrote:
add:
update { &outer.reply += &reply }
And it will copy the reply over to the parent.
Did not work when added to dialup server post-auth but it worked in parent. Internal servers don't print attributes in -X so I used "%{debug_attr:reply:}" I can see all attributes when dialup replies to parent (radproxy) radproxy is virtual server as well btw: server { listen { ... virtual_server = radproxy } } In radproxy server I could see all attributes with "%{debug_attr:proxy-reply:}" within post-proxy and post-auth. So I added this to radproxy post-auth and it worked: post-auth { update { &reply += &proxy-reply } } Does it looks good ? Feels like cleaner solution than listening virtual servers on localhost. I'm moving multiple radius servers (radiator, freeradius 1.1 and freeradius 2.2) to v3. Yes v1.1, don't ask!
We're not going to "fix" this in v3, unfortunately. People rely on the existing behaviour, and we can't really change that.
Sounds good, looking forward to v4
On Aug 20, 2019, at 5:53 PM, Artis Caune <artis.caune@gmail.com> wrote:
On Wed, 21 Aug 2019 at 06:25, Alan DeKok <aland@deployingradius.com> wrote: Did not work when added to dialup server post-auth but it worked in parent. Internal servers don't print attributes in -X so I used "%{debug_attr:reply:}" I can see all attributes when dialup replies to parent (radproxy)
Sure, that's good.
radproxy is virtual server as well btw: server { listen { ... virtual_server = radproxy } }
In radproxy server I could see all attributes with "%{debug_attr:proxy-reply:}" within post-proxy and post-auth.
Yes.
So I added this to radproxy post-auth and it worked: post-auth { update { &reply += &proxy-reply } }
Does it looks good ? Feels like cleaner solution than listening virtual servers on localhost.
Yes, that's good.
I'm moving multiple radius servers (radiator, freeradius 1.1 and freeradius 2.2) to v3. Yes v1.1, don't ask!
Wow. But it's a testament to the stability of the server. I've seen people running 7-8 year-old versions, because "it works". Alan DeKok.
participants (2)
-
Alan DeKok -
Artis Caune