RADIUS configuration based on source IP
I have a variety of Cisco devices that require mutually incompatible values in a certain RADIUS attribute, Cisco-AVPair. The way I have dealt with this in the past is with huntgroups -- I assign our engineer group on huntgroup1 to have Cisco-AVPair set to shell:roles=network-admin, while by default, the engineer group gets shell:priv-lvl=15. So far, so good. Problem is that we have another new kind of Cisco device that achieves engineer read-write with Cisco-AVPair set to shell:roles*admin. I figured that I would just set up another huntgroup, but this device apparently also doesn't set NAS-IP-Address or NAS-Identifier, so the usual huntgroup mechanism doesn't work. My production environment currently uses Cistron. But I'm planning to switch to freeradius. Unfortunately, it looks to me like the same issue applies to freeradius. Help? Is there any way to make a distinction between devices in the config without using huntgroups based on NAS-IP-Address or NAS-Identifier? Thanks! [I sent a very similar message to the cistron mailing list, BTW. I'm looking for a solution for either program.] - Morty
On 30 Aug 2011, at 18:21, Morty wrote:
I have a variety of Cisco devices that require mutually incompatible values in a certain RADIUS attribute, Cisco-AVPair. The way I have dealt with this in the past is with huntgroups -- I assign our engineer group on huntgroup1 to have Cisco-AVPair set to shell:roles=network-admin, while by default, the engineer group gets shell:priv-lvl=15. So far, so good. Problem is that we have another new kind of Cisco device that achieves engineer read-write with Cisco-AVPair set to shell:roles*admin. I figured that I would just set up another huntgroup, but this device apparently also doesn't set NAS-IP-Address or NAS-Identifier, so the usual huntgroup mechanism doesn't work.
Then its not in compliance with RFC 2865 and you should go beat Cisco up about it. An Access-Request SHOULD contain a User-Name attribute. It MUST contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both). How can vendors screw up such basic stuff. Can't you include both AVPs with the += operator? Or does the Cisco device throw a hissy fit?
My production environment currently uses Cistron. But I'm planning to switch to freeradius. Unfortunately, it looks to me like the same issue applies to freeradius.
Help? Is there any way to make a distinction between devices in the config without using huntgroups based on NAS-IP-Address or NAS-Identifier?
If the packets aren't going through a proxy or NAT then you can use Packet-Src-IP-Address instead of NAS-IP-Address.
[I sent a very similar message to the cistron mailing list, BTW. I'm looking for a solution for either program.]
Oh come on the Cistron page hasn't received any love since 06, you know you want to switch :) Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
On Tue, Aug 30, 2011 at 06:43:40PM +0200, Arran Cudbard-Bell wrote:
On 30 Aug 2011, at 18:21, Morty wrote:
but this device apparently also doesn't set NAS-IP-Address or NAS-Identifier, so the usual huntgroup mechanism doesn't work.
Then its not in compliance with RFC 2865 and you should go beat Cisco up about it.
Yup, we've been pursuing that angle in parallel. :) I figured/hoped, though, that someone else had already been through this and that there was a workaround. The Packet-Src-IP-Address you describe below sounds like just the ticket.
Can't you include both AVPs with the += operator? Or does the Cisco device throw a hissy fit?
I had tried sending both. The Cisco devices threw a hissy fit. :) Or more specifically, they ignored whichever attribute was second. Whichever order I put the VSAs in, I wasn't able to get read-write on something.
If the packets aren't going through a proxy or NAT then you can use Packet-Src-IP-Address instead of NAS-IP-Address.
Excellent, thanks! Proxies are not an issue today. They may be an issue in the future, though. It's likely that my proxy will itself by running freeradius. Does Client-IP-Address have the same problem with proxies? If yes, is there a workaround I can use on the proxy itself to populate NAS-IP-Address based on Packet-Src-IP-Address?
Oh come on the Cistron page hasn't received any love since 06, you know you want to switch :)
Oh, I *definitely* want to switch. :) - Morty
Proxies are not an issue today. They may be an issue in the future, though. It's likely that my proxy will itself by running freeradius. Does Client-IP-Address have the same problem with proxies?
Yes.
If yes, is there a workaround I can use on the proxy itself to populate NAS-IP-Address based on Packet-Src-IP-Address?
Sure, just put something like this in authorize {} authorize { update request { NAS-IP-Address = "%{Packet-Src-IP-Address}" } } I *think* Client-IP-Address and Packet-Src-IP-Address are synonyms. You should probably read man unlang if you're just starting with FreeRADIUS 2. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
participants (2)
-
Arran Cudbard-Bell -
Morty