Proxy-State in a CoA proxied request
Hi All. I have tried filtering out Proxy-State attribute for proxied CoA in pre.proxy section but it does not seem to work for me. Debug mentions the following which makes me think it is not using the DEFAULT section of attrs.pre-proxy: [attr_filter.pre-proxy] expand: %{Realm} -> ++[attr_filter.pre-proxy] returns noop (more debug in context below) Have you got this filtering to work Frédéric? If so, can you show me relevant parts of your config that shows how to make it work? Does anyone have any advice on how I can fix my config to be able to filter out (or not add) Proxy-State attribute for proxied CoA? I have included relevant parts of my config and debug below. Regards, Anthony !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! FreeRADIUS Version 2.1.12 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! contents of sites-enabled/coa: listen { type = coa ipaddr = * port = 1700 server = coa } server coa { recv-coa { if ("%{NAS-IP-Address}" == "10.0.72.14") { update control { Home-Server-Pool := bng01-coa-pool } } if ("%{NAS-IP-Address}" == "10.0.72.15") { update control { Home-Server-Pool := bng02-coa-pool } } ok } send-coa { ok } pre-proxy { attr_filter.pre-proxy pre_proxy_log } } contents of attrs.pre-proxy: DEFAULT User-Name =* ANY, Acct-Session-Id =* ANY, NAS-IP-Address =* ANY, Cisco-AVPair =* ANY partial contents of modules/attr_filter: attr_filter attr_filter.pre-proxy { attrsfile = ${confdir}/attrs.pre-proxy relaxed = no } !!!!!!!!!!!!!!!!! example radsniff: # radsniff -p 1700 -x Device: [eth0] PCAP filter: [udp port 1700 or 1701] RADIUS secret: [testing123] CoA-Request Id 239 10.0.91.203:49184 -> 10.0.91.204:1700 (1 packets) +0.000 User-Name = "test@testdomain.com" Acct-Session-Id = "00000016" Cisco-AVPair = "ip:sub-qos-policy-out=UNSHAPE" NAS-IP-Address = 10.0.72.14 CoA-Request Id 243 10.0.91.204:1814 -> 10.0.72.14:1700 (2 packets) +0.000 User-Name = "test@testdomain.com" Acct-Session-Id = "00000016" Cisco-AVPair = "ip:sub-qos-policy-out=UNSHAPE" NAS-IP-Address = 10.0.72.14 Proxy-State = 0x323339 CoA-NAK Id 243 10.0.72.14:1700 -> 10.0.91.204:1814 (3 packets) +0.001 Reply-Message = "Unsupported Attribute" Error-Cause = Unsupported-Attribute CoA-NAK Id 239 10.0.91.204:1700 -> 10.0.91.203:49184 (4 packets) +0.001 Reply-Message = "Unsupported Attribute" Error-Cause = Unsupported-Attribute !!!!!!!!!!!!!! example debug: Ready to process requests. rad_recv: CoA-Request packet from host 10.0.91.203 port 50769, id=33, length=101 User-Name = "test@testdomain.com" Acct-Session-Id = "00000016" Cisco-AVPair = "ip:sub-qos-policy-out=UNSHAPE" NAS-IP-Address = 10.0.72.14 server coa { # Executing section recv-coa from file /etc/freeradius/sites-enabled/coa +- entering group recv-coa {...} ++? if ("%{NAS-IP-Address}" == "10.0.72.14") expand: %{NAS-IP-Address} -> 10.0.72.14 ? Evaluating ("%{NAS-IP-Address}" == "10.0.72.14") -> TRUE ++? if ("%{NAS-IP-Address}" == "10.0.72.14") -> TRUE ++- entering if ("%{NAS-IP-Address}" == "10.0.72.14") {...} +++[control] returns noop ++- if ("%{NAS-IP-Address}" == "10.0.72.14") returns noop ++? if ("%{NAS-IP-Address}" == "10.0.72.15") expand: %{NAS-IP-Address} -> 10.0.72.14 ? Evaluating ("%{NAS-IP-Address}" == "10.0.72.15") -> FALSE ++? if ("%{NAS-IP-Address}" == "10.0.72.15") -> FALSE ++[ok] returns ok } # server coa # Executing section pre-proxy from file /etc/freeradius/sites-enabled/coa +- entering group pre-proxy {...} [attr_filter.pre-proxy] expand: %{Realm} -> ++[attr_filter.pre-proxy] returns noop [pre_proxy_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d -> /var/log/freeradius/radacct/10.0.91.203/pre-proxy-detail-20120601 [pre_proxy_log] /var/log/freeradius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d expands to /var/log/freeradius/radacct/10.0.91.203/pre-proxy-detail-20120601 [pre_proxy_log] expand: %t -> Fri Jun 1 07:58:56 2012 ++[pre_proxy_log] returns ok Sending CoA-Request of id 162 to 10.0.72.14 port 1700 User-Name = "test@testdomain.com" Acct-Session-Id = "00000016" Cisco-AVPair = "ip:sub-qos-policy-out=UNSHAPE" NAS-IP-Address = 10.0.72.14 Proxy-State = 0x3333 Proxying request 0 to home server 10.0.72.14 port 1700 Sending CoA-Request of id 162 to 10.0.72.14 port 1700 User-Name = "test@testdomain.com" Acct-Session-Id = "00000016" Cisco-AVPair = "ip:sub-qos-policy-out=UNSHAPE" NAS-IP-Address = 10.0.72.14 Proxy-State = 0x3333 Going to the next request Waking up in 0.9 seconds. rad_recv: CoA-NAK packet from host 10.0.72.14 port 1700, id=162, length=49 Reply-Message = "Unsupported Attribute" Error-Cause = Unsupported-Attribute WARNING: Empty post-proxy section. Using default return values. server coa { # Executing section send-coa from file /etc/freeradius/sites-enabled/coa +- entering group send-coa {...} ++[ok] returns ok } # server coa Sending CoA-NAK of id 33 to 10.0.91.203 port 50769 Reply-Message = "Unsupported Attribute" Error-Cause = Unsupported-Attribute Finished request 0.
fab junkmail wrote:
I have tried filtering out Proxy-State attribute for proxied CoA in pre.proxy section but it does not seem to work for me. Debug mentions the following which makes me think it is not using the DEFAULT section of attrs.pre-proxy:
You can't filter out Proxy-State. It's added automatically.
Does anyone have any advice on how I can fix my config to be able to filter out (or not add) Proxy-State attribute for proxied CoA? I have included relevant parts of my config and debug below.
Edit the source code. See src/main/event.c, around line 2200. The real answer is to call the NAS vendor, and tell them their product violates RFC 3576. It's been out for nearly a decade, so there is NO EXCUSE. If they give you trouble, email me off-list. I'll call the people they report to. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
fab junkmail wrote:
I have tried filtering out Proxy-State attribute for proxied CoA in pre.proxy section but it does not seem to work for me. Debug mentions the following which makes me think it is not using the DEFAULT section of attrs.pre-proxy:
You can't filter out Proxy-State. It's added automatically.
Does anyone have any advice on how I can fix my config to be able to filter out (or not add) Proxy-State attribute for proxied CoA? I have included relevant parts of my config and debug below.
Edit the source code. See src/main/event.c, around line 2200.
Huh? The following works for us: server coa { .. pre-proxy { update proxy-request { Proxy-State !* 0 } } }
The real answer is to call the NAS vendor, and tell them their product violates RFC 3576. It's been out for nearly a decade, so there is NO EXCUSE.
Well, that is on my todo-list for some rainy day. But I must admit that it's easier to work around the problem than trying to break through the support barrier...
If they give you trouble, email me off-list. I'll call the people they report to.
The thing is, you cannot exactly claim a bug like that is affecting your network in any way, so it's not going to get a high priority. Ever. And I don't think the vendors are afraid of being named as RFC violators either. So the only way I think you're going to get this fixed is if you happen to run into a developer and mention it during the conversation. Bjørn
Bjørn Mork wrote:
Huh? The following works for us:
Hmm... OK. I learn something every day. :)
Well, that is on my todo-list for some rainy day. But I must admit that it's easier to work around the problem than trying to break through the support barrier...
Yeah. The benefit I have is ~15 years doing RADIUS. I end up knowing everyone from everywhere.
The thing is, you cannot exactly claim a bug like that is affecting your network in any way, so it's not going to get a high priority. Ever. And I don't think the vendors are afraid of being named as RFC violators either.
They don't care publicly. But privately, it's a bit different.
So the only way I think you're going to get this fixed is if you happen to run into a developer and mention it during the conversation.
Or run into their boss, and get it prioritized. I've pinged my contacts. We'll see what happens. Alan DeKok.
Hi Alan and Bjørn, Thank you very much for your information and help. I have implemented Bjørn's solution and it works. Regarding the NAS vendor I will forward on Alan's comments to our network engineers to see if they will follow up with the NAS vendor. As it stands, this now works for us. Thanks again. Anthony
participants (3)
-
Alan DeKok -
Bjørn Mork -
fab junkmail