Create a dynamic access control list (dACL) on a Cisco switch

In this topic, you will learn how to create dynamic access lists (dACLs) on Cisco switches to use them in Portnox™ Cloud access control policies.

Warning: We tested this configuration on several models and several versions of Cisco switches but we cannot guarantee that it will cover every Cisco model. Therefore, to get the most accurate and current configuration guidance on dACL configuration, we strongly recommend that you refer to the documentation provided by Cisco on these topics for your particular device model.
  1. Enable IP device tracking.
    ip device tracking

    To use dACLs on a Cisco switch, you must enable IP device tracking. This allows the switch to populate a source IP address (or destination dACL for return traffic) in the dACL. Without IP device tracking enabled, dynamic ACL assignment will not work.

    • For IOS version ≤ 15.0: IP device tracking is disabled by default.
    • For IOS version = 15.1: We could not find information regarding this version. We recommend entering the command to enable IP device tracking as a precaution.
    • For IOS version ≥ 15.2 with dot1x enabled, IP device tracking is enabled by default.
  2. Enter the following AAA commands in config mode. These commands are required for dACL assignment to work.
    radius-server vsa send authentication
    radius-server vsa send accounting
    aaa authorization network default group radius local
  3. Configure the custom dACL in Portnox Cloud.
    • The source IP address must always be set to ANY (when configuring in Portnox Cloud, just leave it empty to set it to ANY). Cisco uses IP device tracking to auto-populate the source address and port in the dACL.
    • The first dACL rules must be set up to allow for DHCP traffic to be exchanged. This can be done by adding both DHCP UDP (68) and BootP UDP (67) ports. DHCP requests initiate on UDP port 67 but are changed by the DHCP server to UDP port 68 when responding. Without both these lines, a DHCP request will not be successful.
    • The last line of the dACL must be a DENY ALL or PERMIT ALL. Most likely this will be a DENY ALL.

    The following is an example dACL restricting an authenticated device to two subnets. The subnets are and

  4. Verify and troubleshoot.

    You can use the following commands to verify that the dACL has been assigned. Critical data is highlighted.

    1. Show interface details.
      show authentications session interface interface_name details

      For example:

      show authentication sessions gigabitEthernet 1/0/10 details 
      Interface:  GigabitEthernet1/0/10
      MAC Address:  3c18.a00c.484c
      IPv6 Address:  Unknown
      IPv4 Address:
      Status:  Authorized
      Domain:  DATA
      Oper host mode:  multi-domain
      Oper control dir:  both
      Session timeout:  N/A
      Restart timeout:  N/A
      Periodic Acct timeout:  N/A
      Session Uptime:  22s
      Common Session ID:  0A02190B000000501E910A42
      Acct Session ID:  Unknown
      Handle:  0xE200001A
      Current Policy:  POLICY_Gi1/0/10
      Local Policies:
      Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
      Server Policies:
      Per-User ACL:  GigabitEthernet1/0/10#v4#7205C4C
      :  permit 17 any eq 68 any
      :  permit 17 any eq 67 any
      :  permit ip any
      :  permit ip any
      :  permit ip any
      :  permit ip any
      :  deny ip any any
      Method status list: 
      Method            State 
      dot1x              Authc Success
    2. Show access list.
      show access list acl_name
      show access list GigabitEthernet1/0/10#v4#7205CF4
      Extended IP access list GigabitEthernet1/0/10#v4#7205CF4 (per-user)
      100 permit udp any any eq bootpc
      101 permit ip any
      102 permit ip any
      103 permit ip any
      104 permit ip any
      105 deny ip any any
  5. Debug the configuration if needed.

    You can use the following tools when debugging dACL assignment:

    • PCAP: Verify that Access-Accept is being delivered to the endpoint.
    • debug radius all: Verify that the dACL is passed to the RADIUS server.
    001567: May  7 13:46:15.269: RADIUS: Received from id 1645/111, Access-Accept, len 407
    001568: May  7 13:46:15.270: RADIUS:  authenticator 22 E2 C9 E9 88 E8 82 58 - F6 09 C9 D1 5F 2C 5A 78
    001569: May  7 13:46:15.270: RADIUS:  Vendor, Microsoft   [26]  58  
    001570: May  7 13:46:15.270: RADIUS:   MS-MPPE-Recv-Key   [17]  52  *
    001571: May  7 13:46:15.270: RADIUS:  Vendor, Microsoft   [26]  58  
    001572: May  7 13:46:15.270: RADIUS:   MS-MPPE-Send-Key   [16]  52  *
    001573: May  7 13:46:15.270: RADIUS:  Vendor, Cisco       [26]  44  
    001574: May  7 13:46:15.270: RADIUS:   Cisco AVpair       [1]   38  "ip:inacl#100=permit 17 any eq 68 any"
    001575: May  7 13:46:15.270: RADIUS:  Vendor, Cisco       [26]  44  
    001576: May  7 13:46:15.270: RADIUS:   Cisco AVpair       [1]   38  "ip:inacl#100=permit 17 any eq 67 any"
    001577: May  7 13:46:15.270: RADIUS:  Vendor, Cisco       [26]  72  
    001578: May  7 13:46:15.270: RADIUS:   Cisco AVpair       [1]   66  "ip:inacl#101=permit ip"
    001579: May  7 13:46:15.270: RADIUS:  Vendor, Cisco       [26]  74  
    001580: May  7 13:46:15.270: RADIUS:   Cisco AVpair       [1]   68  "ip:inacl#102=permit ip"
    001581: May  7 13:46:15.270: RADIUS:  Vendor, Cisco       [26]  36  
    001582: May  7 13:46:15.270: RADIUS:   Cisco AVpair       [1]   30  "ip:inacl#103=deny ip any any"
    001583: May  7 13:46:15.270: RADIUS:  User-Name           [1]   21  ""