Setting access lists with RADIUS

Chris sent me an interesting challenge a few days ago: he wanted to set inbound access lists on virtual access interfaces with RADIUS but somehow couldn’t get this feature to work.

Uncle Google quickly provided two documents on Cisco.com: an older one (explaining the IETF attributes, vendor-specific attributes and AV-pairs) and the most recent one (with more attributes and less useful information) covering every Cisco IOS software release up to 12.2 (yeah, it looks like the RADIUS attributes haven’t been touched in a long time). According to the documentation, attribute #11 as well as AV-pairs ip:inacl/ip:outacl and lcp:interface-config should work, but the access list did not appear in the interface configuration.

A few e-mails later, we’ve discovered a number of somewhat semi-documented facts:

  • Most changes to interface configuration done with lcp:interface-config AV-pair appear in the show running printout; the access lists don’t (regardless of how you set them). You have to use the show ip interface command to verify the ip access-group configured on the interface.
  • Although the documentation states you can only use a numbered ACL with attribute#11, named ACLs work as well.
  • You have to specify .in or .out suffix in attribute#11, otherwise the same ACL is applied in both directions.
  • You can have multiple instances of attribute#11 in RADIUS reply and the router will simply apply them sequentially, sometimes overwriting the previous settings (for example, you could specify bidirectional ACL in one instance and inbound ACL in the next one).

5 comments:

  1. Thanks, I'm glad to see an article on RADIUS. I was wondering what was wrong with me since there seemed to be a dearth of information on RADIUS for Cisco routers.

    ReplyDelete
  2. Christopher Hunt22 September, 2010 20:07

    Incidentally, if you apply an ACL to a virtual-template, it will _immediately_ trump the one(s) passed down by radius during PPP negotiation. I assume it simply applies them sequentially, as you said.

    So what I did was define an empty ACL, apply it to my radius accounts then wait two weeks to ensure all PPP sessions had that ACL installed. Then I simply added lines to the middle of my ACL.

    Now we can hand down ACLs (and hopefully soon vrf configs) from our CMS (Platypus). Thanks also to rancid for making the addition and maintenance of those ACLs much easier.

    ReplyDelete
  3. you can use this command
    "radius-server attribute 11 default direction in"
    and radius Filter-id attribute
    "showme Cleartext-Password := "1234"
    Service-Type = Framed-User,
    Filter-Id = "100",
    Framed-Protocol = PPP"

    ReplyDelete
  4. "and hopefully soon vrf configs" You can configure like this:
    1. AAA radius group has ip radius soure-interface loopback1 vrf VRF_NAME
    2. loopback1 in vrf VRF_NAME
    3. Virtual template has a string ip vrf forwarding VRF_NAME and ip unnumbered lo1
    4. radius sent framed-ip or other attr.
    You can't configure like that:
    1. AAA radius group
    2. Virtual template without ip unnumbered and ip vrf forwarding VRF_NAME
    3. radius sent ip-unnumbered lo1
    4. radius sent ip-vrf , which removes ip-unnumbered
    As you know, command "ip vrf forwarding VRF_NAME" on interface removes current ip-address. Make sure that the radius server sends the attributes in the correct order.

    ReplyDelete
  5. We use something like the following in our radius for per-user acls.

    test User-Password = "test"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Framed-IP-Address = x.x.x.x,
    cisco-avpair="ip:inacl#1=deny ip any x",
    cisco-avpair="ip:inacl#2=deny ip any x",
    cisco-avpair="ip:inacl#3=deny ip any x",
    cisco-avpair="ip:inacl#4=deny ip any x",
    cisco-avpair="ip:inacl#5=deny ip any x",
    cisco-avpair="ip:inacl#6=permit ip host x any",
    cisco-avpair="ip:inacl#7=deny ip any any"

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.