On Feb 16, 2021, at 6:23 AM, Pablo Nogueira <pnogueira@gmail.com> wrote:
I'm trying to implement dynamic access lists for 802.1X authenticated users. To do so, I'm using attribute NAS-Filter-Rule, as defined in RFC 4849 and FreeRADIUS Version 3.0.21 as the RADIUS server.
To do so, I've modified users file with the following entry user1 Cleartext-Password := "pass1" Service-Type = Framed-User, Nas-filter-Rule = "permit in tcp from any to 10.2.3.4/24", Nas-filter-Rule += 0x00, Nas-filter-Rule += "permit in ip from 192.168.101.5/32 to 192.168.101.1", Nas-filter-Rule += 0x00, Nas-filter-Rule += "deny in ip from any to any", Nas-filter-Rule += 0x00
That really won't do what you want. The "+=" operator adds multiple attributes of the same name. It doesn't concatenate strings for the same attribute. See "man unlang". Further, adding "0x00" to a "string" attribute doesn't add a zero byte. It appends the literal string "0x00".
I've been able to make it work as I think it should adding the following line to my dictionary # override NAS-Filter-Rule to convey NUL character between rules ATTRIBUTE NAS-Filter-Rule 92 octets
That still doesn't quite do what the RFC says. That change sends *multiple* NAS-Filter-Rule attributes, some with string values, and some with a 0x00 byte. It doesn't follow the RFC guidelines of packing all of the strings together. If it works... it's OK for now. But it's not really the correct approach.
My question is, is there any other way to force freeradius to send the entry rules as strings with NUL terminated character? Should I report this as an issue (bug) to freeradius developers so that they change the dictionary.rfc4849 entry?
The developers read this list. Don't worry about that. Changing the data type sort of works. But it means that when the server is receiving proxied Access-Accept packets, it won't print out the NAS-Filter-Rule correctly. For now, your changes work for you. We'll see if we can get some fixes into the next release. Alan DeKok.