3.0.18: operator = not behaving as expected after proxying to virtual server
Hello, I have a setup where a proxied-to virtual server sets the attribute Session-Timeout with := and then the calling server sets it subsidiary to a different value with = in post-proxy. The reply_log for both servers shows that the first value is set ok, but the second = operator *adds* the Session-Timeout attribute a second time. This effectively leads to FreeRADIUS sending back a malformed packet because it now contains two Session-Timeout attributes. The reply_log/post_proxy_log contents look like this: Sat Apr 6 12:17:25 2019 Packet-Type = Access-Reject Session-Timeout = 604800 <-- as set with := Timestamp = 1554545845 Sat Apr 6 12:17:25 2019 Packet-Type = Access-Reject Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT" Session-Timeout = 86400 <-- extra addition in post-proxy Idle-Timeout = 7200 Session-Timeout = 604800 <-- should prevail Timestamp = 1554545845 The post-proxy configuration of the caller is: post-proxy { update reply { Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT", Session-Timeout = 86400, Idle-Timeout = 7200 } post_proxy_log } This seems to be a bug: Session timeout is already set, and the = operator should refrain from changing the existing value. And also, it should detect that it is doing something non-RFC compliant by adding it twice. The actual reply as seen by radtest is: Received Access-Reject Id 196 from 127.0.0.1:1812 to 127.0.0.1:49664 length 71 Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT" Session-Timeout = 86400 Idle-Timeout = 7200 Session-Timeout = 604800 (0) -: Expected Access-Accept got Access-Reject So the incorrect attribute list actually made it onto the wire. Greetings, Stefan Winter
On 6/04/2019, at 11:26 PM, stefan.winter@restena.lu wrote:
post-proxy { update reply { Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT", Session-Timeout = 86400, Idle-Timeout = 7200 } post_proxy_log }
I’m not sure if this is the issue - and you haven’t posted debug info so it’s hard to see what’s happening - but I wonder if the trailing commas causes problems - they’re not something you do in unlang.
This seems to be a bug: Session timeout is already set, and the = operator should refrain from changing the existing value. And also, it should detect that it is doing something non-RFC compliant by adding it twice.
I don’t know if it’s FR’s job to determine RFC compliance in terms of how many times and attribute is listed. Often, weird stuff like that is required for poorly implemented NASes. It should allow you to configure it to do weird stuff. -- Nathan Ward
On Apr 6, 2019, at 7:22 AM, Nathan Ward <lists+freeradius@daork.net> wrote:
I don’t know if it’s FR’s job to determine RFC compliance in terms of how many times and attribute is listed.
It's not. We enforce RFC requirements largely for security and formatting. i.e. the attributes should have correctly formatted contents. We absolutely do not enforce the rest of the RFC requirements by default. A good number are wrong and broken. See RFC 5080 for a collection is disgusting breakages in RADIUS. And that didn't catch them all. :(
Often, weird stuff like that is required for poorly implemented NASes. It should allow you to configure it to do weird stuff.
Exactly. And most NASes are written lazily. If they get two attributes where they expect one, they often don't even know. They just look for the first one and use it. Alan DeKok.
On Apr 6, 2019, at 6:26 AM, stefan.winter@restena.lu wrote:
I have a setup where a proxied-to virtual server sets the attribute Session-Timeout with := and then the calling server sets it subsidiary to a different value with = in post-proxy.
The reply_log for both servers shows that the first value is set ok, but the second = operator *adds* the Session-Timeout attribute a second time. ... The post-proxy configuration of the caller is:
post-proxy { update reply { Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT", Session-Timeout = 86400, Idle-Timeout = 7200 } post_proxy_log }
Post-proxy doesn't do what you think it does. It's a way to mangle the *proxied* reply. Not the *actual* reply. When a proxied reply is received, the server runs post-proxy, and then *adds* the proxied reply to the real reply. Operators aren't used for that addition. So what's happening is: - request is proxied - Session-Timeout is added to the proxy reply - back in the main server the original reply is deleted - post-proxy { } section runs - adds session-time out to the reply, using "=". Which works, as the reply is empty - once post-proxy is finished, the proxy reply is appended to the real reply. Which means you have two Session-Timeout attributes. The solution is to do "update proxy-reply" in the post-proxy section. Don't do "update reply" Alan DeKok.
participants (3)
-
Alan DeKok -
Nathan Ward -
stefan.winter＠restena.lu