Hello list, I run a very simple architecture for broadband access with 2 routers, 2 radius proxies and 2 radius home servers. On the side of this architecture I run a homemade script that sends PoD directly to the two routers and everything works fine. I would like to change the direct access to the routers and have all my radius messages go through the 2 proxies, including the PoD. I have upgraded in 2.1.12 because of a bug in CoA proxyfication and now the PoD are handled correctly, sent to the routers through the proxy ! But there is a problem : the two cisco routers don't support the Proxy-State attribute and send me a very clear message : fgabut@savon:~$ cat toto | radclient -x a.b.c.d:3799 disconnect toto1234 Sending Disconnect-Request of id 138 to a.b.c.d port 3799 NAS-IP-Address = x.x.x.x User-Name = "xxx@nautile.nc" rad_recv: Disconnect-NAK packet from host a.b.c.d port 3799, id=138, length=47 Reply-Message = "No Matching Session" Error-Cause = Invalid-Request The debug message I have on the router is : Apr 28 23:42:29.980: POD: a.b.c.d Unsupported attribute type 33 for component Apr 28 23:42:29.980: POD: a.b.c.d user xxx@nautile.nc 0.0.0.0 sessid 0x0 key 0x0 DROPPED Apr 28 23:42:29.980: POD: Added Reply Message: No Matching Session Apr 28 23:42:29.980: POD: Added NACK Error Cause: Invalid Request Apr 28 23:42:29.980: POD: Sending NAK from port 1700 to a.b.c.d/1814 I can't find any option to not use the attribute 33 (Proxy-State) in the process of matching the session on the router. So I guess the only solution left is to filter the Proxy-State directly on the exit of the radius proxy. The RFC3576 states that : When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. So I was wondering if there were any option to disable the add of the attribute Proxy-State when the radius server proxyfies a CoA request ? I think that the usual attr filter method won't fit there. Thanks in advance, Best regards, -- Frederic Gabut-Deloraine Network Engineer NEO TELECOMS - AS8218 21 rue La Boetie 75008 Paris Tel : +33 1.49.97.07.47 Mob : +33 6.15.07.10.30 skype : fgabutdeloraine
Frédéric Gabut-Deloraine wrote:
But there is a problem : the two cisco routers don't support the Proxy-State attribute and send me a very clear message :
The router shouldn't support Proxy-State. They don't need to. But they shouldn't *drop* the packet when they receive a Proxy-State attribute.
fgabut@savon:~$ cat toto | radclient -x a.b.c.d:3799 disconnect toto1234 Sending Disconnect-Request of id 138 to a.b.c.d port 3799 NAS-IP-Address = x.x.x.x User-Name = "xxx@nautile.nc" rad_recv: Disconnect-NAK packet from host a.b.c.d port 3799, id=138, length=47 Reply-Message = "No Matching Session" Error-Cause = Invalid-Request
And there's no Proxy-State attribute there, or *ANY OTHER* session information. What is this command supposed to test?
I can't find any option to not use the attribute 33 (Proxy-State) in the process of matching the session on the router. So I guess the only solution left is to filter the Proxy-State directly on the exit of the radius proxy.
See the "attr_filter" module.
The RFC3576 states that :
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one.
That has been replaced by RFC 5176. Which has similar text.
So I was wondering if there were any option to disable the add of the attribute Proxy-State when the radius server proxyfies a CoA request ? I think that the usual attr filter method won't fit there.
No. But you can delete it before the packet is sent. See "attr_filter". My $0.02 is to file a bug with Cisco, and tell them that their software is broken. RFC 5176 Section 3.1 says that the NAS is supposed to echo back Proxy-State from the request to the reply. Discarding the packet means that this is impossible. The Cisco NAS is violating the RFCs. Alan DeKok.
Le 29 avr. 2012 à 09:05, Alan DeKok a écrit :
Frédéric Gabut-Deloraine wrote:
But there is a problem : the two cisco routers don't support the Proxy-State attribute and send me a very clear message :
The router shouldn't support Proxy-State. They don't need to.
But they shouldn't *drop* the packet when they receive a Proxy-State attribute.
They don't drop the packet but consider the request as an "Invalid-Request" and return a Disconnect-NAK as shown below :
fgabut@savon:~$ cat toto | radclient -x a.b.c.d:3799 disconnect toto1234 Sending Disconnect-Request of id 138 to a.b.c.d port 3799 NAS-IP-Address = x.x.x.x User-Name = "xxx@nautile.nc" rad_recv: Disconnect-NAK packet from host a.b.c.d port 3799, id=138, length=47 Reply-Message = "No Matching Session" Error-Cause = Invalid-Request
And there's no Proxy-State attribute there, or *ANY OTHER* session information. What is this command supposed to test?
That was supposed to show the "Invalid-Request" answer from the router.
I can't find any option to not use the attribute 33 (Proxy-State) in the process of matching the session on the router. So I guess the only solution left is to filter the Proxy-State directly on the exit of the radius proxy.
See the "attr_filter" module.
The RFC3576 states that :
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one.
That has been replaced by RFC 5176. Which has similar text.
So I was wondering if there were any option to disable the add of the attribute Proxy-State when the radius server proxyfies a CoA request ? I think that the usual attr filter method won't fit there.
No. But you can delete it before the packet is sent. See "attr_filter".
Ok, I thought that attr_filter wouldn't help me because I thought that Proxy-State was added just before going on the wire. I have tried briefly and gave up. I'll try again.
My $0.02 is to file a bug with Cisco, and tell them that their software is broken. RFC 5176 Section 3.1 says that the NAS is supposed to echo back Proxy-State from the request to the reply. Discarding the packet means that this is impossible.
The Cisco NAS is violating the RFCs.
I totally agree, however it's often easier to fix the origin of the bug than the bug itself with network vendors ;-). -- Frederic Gabut-Deloraine Network Engineer NEO TELECOMS - AS8218 21 rue La Boetie 75008 Paris Tel : +33 1.49.97.07.47 Mob : +33 6.15.07.10.30 skype : fgabutdeloraine
Frédéric Gabut-Deloraine wrote:
Ok, I thought that attr_filter wouldn't help me because I thought that Proxy-State was added just before going on the wire. I have tried briefly and gave up. I'll try again.
The Proxy-State is added before the "pre-proxy" section is run. See src/main/event.c, line 2200. So you can filter it out via "attr_filter".
I totally agree, however it's often easier to fix the origin of the bug than the bug itself with network vendors ;-).
My policy is that we WILL NOT butcher FreeRADIUS in order to work around third-party violations of the RFCs. The vendors MUST fix their equipment. This policy has worked surprisingly well over the past decade. FreeRADIUS has become the "de facto" standard for RADIUS implementations. Alan DeKok.
participants (2)
-
Alan DeKok -
Frédéric Gabut-Deloraine