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 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).


  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.
  2. 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.
  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"
  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.
  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"
Add comment