RADIUS configuration based on source IP

[Arran Cudbard-Bell]

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 at freeradius.org

RADIUS - Half the complexity of Diameter