802.1x DACL, Per-User ACL, Filter-ID, and Device Tracking Behavior

Transcription

1 802.1x DACL, Per-User ACL, Filter-ID, and Device Tracking Behavior Document ID: Contributed by Michal Garcarz, Piotr Kupisiewicz, and Roman Machulik, Cisco TAC Engineers. Nov 24, 2015 Contents Introduction Device Tracking Theory Device Tracking Configuration Device Tracking Tests Debugs From Version , IP Device Tracking Updated by DHCP Snooping Probe and ARP Snooping IP Device Tracking for Version Hidden Command IP Device Tracking for Version Static IP Example IP Device Tracking for Version 15.x IP Device Tracking for Cisco IOS-XE IP Device Tracking with 802.1x and DACL for Version IP Device Tracking with 802.1x and DACL for Version 15.x Specific ACL Entry Control-Direction IP Device Tracking with 802.1x and Per-User ACL for Version 15.x Difference when Compared to the DACL IP Device Tracking with 802.1x and Filter-ID ACL for Version 15.x IP Device Tracking - Defaults and Best Practices Interface ACL Rewrite for Version 15.x Default ACL Used for 802.1x Open Mode When the Interface ACL is Mandatory DACL on 4500/6500 MAC Address Status for 802.1x Troubleshoot Related Information Introduction This document describes how the IP device tracking feature works, which includes what the triggers are to add and remove a host. Also, the impact of device tracking on the 802.1x Downloadable Access Control List (DACL) is explained. The behavior changes between versions and platforms. The second part of the document focuses on the Access Control List (ACL) returned by the Authentication, Authorization, and Accounting (AAA) server and applied to the 802.1x session. A comparison between the DACL, Per-User ACL and Filter-ID ACL is presented. Also, some caveats in regards to the ACL rewrite and default ACL are discussed.

2 Device Tracking Theory Device tracking adds an entry when: it learns the new entry via DHCP snooping. it learns the new entry via an Address Resolution Protocol (ARP) request (reads the sender MAC address and the sender IP address from the ARP packet). That functionality is sometimes called ARP inspection, but it is not the same as Dynamic ARP Inspection (DAI). That feature is enabled by default and cannot be disabled. It is also called ARP snooping, but debugs will not show it after "debug arp snooping" is enabled. ARP snooping is enabled by default and cannot be disabled or controlled. Device tracking removes an entry when there is no response for an ARP request (sending probe for each host in the device tracking table, by default every 30 seconds). Device Tracking Configuration ip dhcp excluded-address ip dhcp pool POOL network ! ip dhcp snooping vlan 1 ip dhcp snooping ip device tracking! interface Vlan1 ip address ip route ! interface FastEthernet0/1 description PC Device Tracking Tests BSNS # show ip dhcp binding IP address Client-ID/ Lease expiration Type Hardware address e.a1 Mar :31 AM Automatic BSNS # show ip device tracking all IP Device Tracking = Enabled IP Address MAC Address Interface STATE ea1 FastEthernet0/1 ACTIVE Debugs From Version , IP Device Tracking Updated by DHCP Snooping DHCP snooping populates the binding table: BSNS # show debugging DHCP Snooping packet debugging is on DHCP Snooping event debugging is on DHCP server packet debugging is on. DHCP server event debugging is on. track: IP device-tracking redundancy events debugging is on

3 IP device-tracking cache entry Creation debugging is on IP device-tracking cache entry Destroy debugging is on IP device-tracking cache events debugging is on 02:30:57: DHCP_SNOOPING: checking expired snoop binding entries 02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/1 for pak. Was Vl1 02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Vl1 for pak. Was Fa0/1 02:31:12: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/1 for pak. Was Vl1 02:31:12: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/1) 02:31:12: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Fa0/1, MAC da: 001f.27e6.cfc0, MAC sa: ea1, IP da: , IP sa: , DHCP ciaddr: , DHCP yiaddr: , DHCP siaddr: , DHCP giaddr: , DHCP chaddr: ea1 02:31:12: DHCP_SNOOPING: add relay information option. 02:31:12: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format 02:31:12: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format 02:31:12: DHCP_SNOOPING: binary dump of relay info option, length: 20 data: 0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0x3 0x2 0x8 0x0 0x6 0x0 0x1F 0x27 0xE6 0xCF 0x80 02:31:12: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: 001F.27E6.CFC0, packet is flooded to ingress VLAN: (1) 02:31:12: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1. 02:31:12: DHCPD: DHCPREQUEST received from client e.a1. 02:31:12: DHCPD: Sending DHCPACK to client e.a1 ( ). 02:31:12: DHCPD: unicasting BOOTREPLY to client ea1 ( ). 02:31:12: DHCP_SNOOPING: received new DHCP packet from input interface (Vlan1) 02:31:12: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Vl1, MAC da: ea1, MAC sa: 001f.27e6.cfc0, IP da: , IP sa: , DHCP ciaddr: , DHCP yiaddr: , DHCP siaddr: , DHCP giaddr: , DHCP chaddr: ea1 02:31:12: DHCP_SNOOPING: add binding on port FastEthernet0/1. 02:31:12: DHCP_SNOOPING: added entry to table (index 189) 02:31:12: DHCP_SNOOPING: dump binding entry: Mac=00:50:56:99:4E:A1 Ip= Lease=86400 ld Type=dhcp-snooping Vlan=1 If=FastEthernet0/1 After the DHCP binding is added to the database, it triggers the notification for device tracking: 02:31:12: sw_host_track-ev:host_track_notification: Add event for host ea1, on interface FastEthernet0/1 02:31:12: sw_host_track-ev:async Add event for host ea1, on interface FastEthernet0/1 02:31:12: sw_host_track-ev:msg = 2 02:31:12: DHCP_SNOOPING_SW no entry found for ea FastEthernet0/1 02:31:12: DHCP_SNOOPING_SW host tracking not found for update add dynamic ( , , ea1) vlan 1 02:31:12: DHCP_SNOOPING: direct forward dhcp reply to output port: FastEthernet0/1. 02:31:12: sw_host_track-ev:add event: ea1, , FastEthernet0/1 02:31:12: sw_host_track-obj_create: ea1( ) Cache entry created 02:31:12: sw_host_track-ev:activating host ea1, on interface FastEthernet0/1 02:31:12: sw_host_track-ev: ea1 Starting cache timer: 30 seconds ARP probes are sent by default every 30 seconds: 02:41:12: sw_host_track-ev: ea1 Stopping cache timer 02:41:12: sw_host_track-ev: ea1: Send Host probe (0) 02:41:12: sw_host_track-ev: ea1 Starting cache timer: 30 seconds 02:41:42: sw_host_track-ev: ea1 Stopping cache timer 02:41:42: sw_host_track-ev: ea1: Send Host probe (1) 02:41:42: sw_host_track-ev: ea1 Starting cache timer: 30 seconds 02:42:12: sw_host_track-ev: ea1 Stopping cache timer 02:42:12: sw_host_track-ev: ea1: Send Host probe (2) 02:42:12: sw_host_track-ev: ea1 Starting cache timer: 30 seconds 02:42:42: sw_host_track-ev: ea1 Stopping cache timer 02:42:42: sw_host_track-obj_destroy: ea1( ): Cache entry deleted 02:42:42: sw_host_track-ev: ea1 Stopping cache timer

4 After the entry is removed from the device tracking table, the corresponding DHCP binding entry is still there: BSNS #show ip device tracking all IP Device Tracking = Enabled IP Address MAC Address Interface STATE BSNS #show ip dhcp binding IP address Client-ID/ Lease expiration Type Hardware address e.a1 Mar :06 AM Automatic There is the issue when you have an ARP response, but the device tracking entry is removed anyway. That bug appears to be in Version and has not appeared in Version or 15.x software. Also there are some differences when handling with the L2 port (access-port) and L3 port (no switchport). Probe and ARP Snooping Device tracking with the ARP snooping feature: BSNS #show debugging ARP: ARP packet debugging is on Arp Snoop: Arp Snooping debugging is on 03:43:36: sw_host_track-ev: ea1 Stopping cache timer 03:43:36: sw_host_track-ev: ea1: Send Host probe (0) 03:43:36: IP ARP: sent req src f.27e6.cf83, dst ea1 FastEthernet0/1 03:43:36: sw_host_track-ev: ea1 Starting cache timer: 30 seconds 03:43:36: IP ARP: rcvd rep src ea1, dst Vlan1 IP Device Tracking for Version Hidden Command For Version 12.2 there might be a need to use a hidden command in order to activate it: BSNS #show ip device tracking all IP Device Tracking = Enabled IP Device Tracking Probe Count = 2 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE ea1 55 FastEthernet0/1 ACTIVE Total number interfaces enabled: 1 Enabled interfaces: Fa0/1 BSNS #ip device tracking interface fa0/48 BSNS #show ip device tracking all IP Device Tracking = Enabled

5 IP Device Tracking Probe Count = 2 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE c d 1006 FastEthernet0/48 ACTIVE a.dada.dada 1006 FastEthernet0/48 ACTIVE acf2.c5ed FastEthernet0/48 ACTIVE ea1 55 FastEthernet0/1 ACTIVE c ca FastEthernet0/48 ACTIVE FastEthernet0/48 ACTIVE Total number interfaces enabled: 2 Enabled interfaces: Fa0/1, Fa0/48 IP Device Tracking for Version Static IP Example In this example, the PC has been configured with a static IP address. Debugs show that after you get an ARP response (MSG=2), the device tracking entry is updated. 01:03:16: sw_host_track-ev: ea1 Stopping cache timer 01:03:16: sw_host_track-ev: ea1: Send Host probe (0) 01:03:16: sw_host_track-ev: ea1 Starting cache timer: 30 seconds 01:03:16: sw_host_track-ev:host_track_notification: Add event for host ea1, on interface FastEthernet0/1, vlan 1 01:03:16: sw_host_track-ev:async Add event for host ea1, on interface FastEthernet0/1 01:03:16: sw_host_track-ev:msg = 2 01:03:16: sw_host_track-ev:add event: ea1, , FastEthernet0/1 01:03:16: sw_host_track-ev: ea1: Cache entry refreshed 01:03:16: sw_host_track-ev:activating host ea1, on interface FastEthernet0/1 01:03:16: sw_host_track-ev: ea1 Starting cache timer: 30 seconds So every ARP request from the PC updates the device tracking table (the sender MAC address and sender IP address from the ARP packet). IP Device Tracking for Version 15.x It is important to remember that some of the features such as DACL for 802.1x are not supported in the LAN Lite version (beware - Cisco Feature Navigator does not always show the correct information). The hidden command from Version 12.2 can be executed, but will have no effect. In the Software Version 15.x, IP device tracking (IPDT) by default is only enabled for the interfaces which have 802.1x enabled: bsns #show ip device tracking all IP Device Tracking = Enabled IP Device Tracking Probe Count = 3 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE GigabitEthernet1/0/1 ACTIVE c.29d GigabitEthernet1/0/1 ACTIVE Total number interfaces enabled: 2 Enabled interfaces: Gi1/0/1, Gi1/0/2

6 bsns #show run int g1/0/3 Building configuration... Current configuration : 38 bytes! interface GigabitEthernet1/0/3 bsns (config)#int g1/0/3 bsns (config-if)#switchport mode access bsns (config-if)#authentication port-control auto bsns (config-if)#do show ip device tracking all IP Device Tracking = Enabled IP Device Tracking Probe Count = 3 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE GigabitEthernet1/0/1 ACTIVE c.29d GigabitEthernet1/0/1 ACTIVE Total number interfaces enabled: 3 Enabled interfaces: Gi1/0/1, Gi1/0/2, Gi1/0/3 After removal of 802.1x configuration from the port, IPDT will also be removed from that port. The port status might be "DOWN", so it is necessary to have "switchport mode access" and "authenticaion port-control auto" in order to have IP device tracking activated on that port. The maximum interface device limit is set to 10: bsns (config-if)#ip device tracking maximum? <1-10> Maximum devices IP Device Tracking for Cisco IOS-XE Again, the behavior on Cisco IOS-XE 3.3 has changed when compared to Cisco IOS Version 15.x. The hidden command from Version 12.2 is obsolete, but now this error will be returned: # no ip device tracking int g1/0/48 % Command accepted but obsolete, unreleased or unsupported; see documentation. In Cisco IOS-XE, device tracking is activated for all the interfaces (even the ones which do not have 802.1x configured): #show ip device tracking all Global IP Device Tracking for clients = Enabled Global IP Device Tracking Probe Count = 3 Global IP Device Tracking Probe Interval = 30 Global IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface Probe-Timeout State Source c.29bd.3cfa 1 GigabitEthernet1/0/ dca.e4a7 1 GigabitEthernet1/0/ a0ff GigabitEthernet1/0/ c0.9f GigabitEthernet1/0/ GigabitEthernet1/0/48 30

7 cf 20 GigabitEthernet1/0/ d48c.b52f.4a1e 99 GigabitEthernet1/0/12 30 IN c.296e.8dbc 1 GigabitEthernet1/0/ d 1 GigabitEthernet1/0/ da20.8c00 1 GigabitEthernet1/0/ c20.560e.1b64 1 GigabitEthernet1/0/ c.29e9.db25 1 GigabitEthernet1/0/ f15f.f7ca 1 GigabitEthernet1/0/ c bc 1 GigabitEthernet1/0/ d029.74cf 1 GigabitEthernet1/0/ c.58de GigabitEthernet1/0/ f62a.c4a3 1 GigabitEthernet1/0/ bee 1 GigabitEthernet1/0/ c5.e8b7 1 GigabitEthernet1/0/ fa13.9a40 1 GigabitEthernet1/0/ bf4 1 GigabitEthernet1/0/ c.2957.c7ad 1 GigabitEthernet1/0/48 30 Total number interfaces enabled: 57 Enabled interfaces: Gi1/0/1, Gi1/0/2, Gi1/0/3, Gi1/0/4, Gi1/0/5, Gi1/0/6, Gi1/0/7, Gi1/0/8, Gi1/0/9, Gi1/0/10, Gi1/0/11, Gi1/0/12, Gi1/0/13, Gi1/0/14, Gi1/0/15, Gi1/0/16, Gi1/0/17, Gi1/0/18, Gi1/0/19, Gi1/0/20, Gi1/0/21, Gi1/0/22, Gi1/0/23, Gi1/0/24, Gi1/0/25, Gi1/0/26, Gi1/0/27, Gi1/0/28, Gi1/0/29, Gi1/0/30, Gi1/0/31, Gi1/0/32, Gi1/0/33, Gi1/0/34, Gi1/0/35, Gi1/0/36, Gi1/0/37, Gi1/0/38, Gi1/0/39, Gi1/0/40, Gi1/0/41, Gi1/0/42, Gi1/0/43, Gi1/0/44, Gi1/0/45, Gi1/0/46, Gi1/0/47, Gi1/0/48, Gi1/1/1, Gi1/1/2, Gi1/1/3, Gi1/1/4, Te1/1/1, Te1/1/2, Te1/1/3, Te1/1/ #$ #sh run int g1/0/48 Building configuration... Current configuration : 39 bytes! interface GigabitEthernet1/0/48 end (config-if)#ip device tracking maximum? < > Maximum devices (0 means disabled) Also, there are no limits for maximum entries per port (0 means disabled).

8 IP Device Tracking with 802.1x and DACL for Version If 802.1x is configured with DACL, the device tracking entry is used in order to fill the IP address of device. This example shows device tracking working for a statically configured IP: BSNS #show ip device tracking all IP Device Tracking = Enabled IP Device Tracking Probe Count = 2 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE ea1 2 FastEthernet0/1 ACTIVE Total number interfaces enabled: 1 Enabled interfaces: Fa0/1 This is an 802.1x session built with "permit icmp any any" DACL: BSNS # sh authentication sessions interface fa0/1 Interface: FastEthernet0/1 MAC Address: ea1 IP Address: User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: single-host Oper control dir: both Authorized By: Authentication Server Vlan Policy: 2 ACS ACL: xacsaclx-ip-dacl-516c2694 Session timeout: N/A Idle timeout: N/A Common Session ID: 0A3042A C5 Acct Session ID: 0x D Handle: 0x Runnable methods list: Method State dot1x Authc Success BSNS #show epm session summary EPM Session Information Total sessions seen so far : 1 Total active sessions : 1 Interface IP Address MAC Address Audit Session Id: FastEthernet0/ ea1 0A3042A C5 This shows an applied ACL: BSNS #show ip access-lists Extended IP access list Auth-Default-ACL 10 permit udp any range bootps any range bootpc permit udp any any range bootps deny ip any any (8 matches) Extended IP access list xacsaclx-ip-dacl-516c2694 (per-user)

9 10 permit icmp any any (6 matches) Also, the ACL on the fa0/1 interface is the same: BSNS #show ip access-lists interface fa0/1 permit icmp any any Even though the default is dot1x ACL: BSNS #show ip interface fa0/1 FastEthernet0/1 is up, line protocol is up Inbound access list is Auth-Default-ACL It might be expected for the ACL to use "any" as That works like this for auth proxy, but for 802.1x DACL src "any" is not changed to the detected IP of the PC. For auth proxy, one original ACL from the ACS is cached and shown with the show ip access-list command and a specific (Per-User with specific IP) ACL is applied on the interface with the show ip access-list interface fa0/1 command. However, auth-proxy does not use device IP tracking. What if the IP address is not detected correctly? After device tracking is disabled: BSNS #show authentication sessions interface fa0/1 Interface: FastEthernet0/1 MAC Address: ea1 IP Address: Unknown User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: single-host Oper control dir: both Authorized By: Authentication Server Vlan Policy: 2 ACS ACL: xacsaclx-ip-dacl-516c2694 Session timeout: N/A Idle timeout: N/A Common Session ID: 0A3042A C775 Acct Session ID: 0x Handle: 0xB Runnable methods list: Method State dot1x Authc Success So no IP address is attached then, but the DACL is still applied: BSNS #show ip access-lists Extended IP access list Auth-Default-ACL 10 permit udp any range bootps any range bootpc permit udp any any range bootps deny ip any any (4 matches) Extended IP access list xacsaclx-ip-dacl-516c2694 (per-user) 10 permit icmp any any In this scenario, device tracking for 802.1x is not required. The only difference is that knowing the IP address of the client upfront can be used for a RADIUS access-request. After attribute 8 is attached: radius-server attribute 8 include-in-access-req

10 It will exist in Access-Request and on ACS it will be possible to create more granular authorization rules: 00:17:44: RADIUS( ): Send Access-Request to :1645 id 1645/27, len :17:44: RADIUS: authenticator F CE C1 85 E8 E8 - CB 5B C 07 CE CA 00:17:44: RADIUS: User-Name [1] 7 "cisco" 00:17:44: RADIUS: Service-Type [6] 6 Framed [2] 00:17:44: RADIUS: Framed-IP-Address [8] Keep in mind that TrustSec also needs IP device tracking for IP to SGT bindings. IP Device Tracking with 802.1x and DACL for Version 15.x What is the difference between Version 15.x and Version in DACL? In software Version15.x, it works the same as for auth-proxy. The generic ACL can be seen when the show ip access-list command is entered (cached response from AAA), but after the show ip access-list interface fa0/1 command, the src "any" is replaced by the source IP address of the host (known via IP device tracking). This is the example for a phone and PC on one port (g1/0/1), software Version SE2 on 3750X: bsns #sh authentication sessions interface g1/0/1 Interface: GigabitEthernet1/0/1 MAC Address: IP Address: User-Name: Status: Authz Success Domain: VOICE Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 100 ACS ACL: xacsaclx-ip-permit_all_traffic-51134bb2 Session timeout: N/A Idle timeout: N/A Common Session ID: C0A B680D23 Acct Session ID: 0x B Handle: 0x Runnable methods list: Method State dot1x Failed over mab Authc Success Interface: GigabitEthernet1/0/1 MAC Address: ea1 IP Address: User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 20 ACS ACL: xacsaclx-ip-permit_all_traffic-51134bb2 Session timeout: N/A Idle timeout: N/A Common Session ID: C0A BD336EC4D6 Acct Session ID: 0x000002F9 Handle: 0xF80001BE

11 Runnable methods list: Method State dot1x Authc Success mab Not run The phone is authenticated via MAC Authentication Bypass (MAB), while the PC uses dot1x. Both the phone and PC use the same ACL: bsns #show ip access-lists xacsaclx-ip-permit_all_traffic-51134bb2 Extended IP access list xacsaclx-ip-permit_all_traffic-51134bb2 (per-user) 10 permit ip any any However, when verified on the interface level the source has been replaced by the IP address of the device. IP device tracking triggers that change and it can occur at any time (much later than the authentication session and download of the ACL): bsns #show ip access-lists interface g1/0/1 permit ip host any (5 matches) permit ip host any Both MAC addresses should be marked as static: bsns #sh mac address-table interface g1/0/1 Mac Address Table Vlan Mac Address Type Ports ea1 STATIC Gi1/0/ STATIC Gi1/0/1 Specific ACL Entry When is the source "any" in the DACL replaced with the host IP address? Only when there are at least two sessions on the same port (two supplicants). There is no need to replace the source "any" when there is only one session. The problems might appear when there are multiple sessions, and for not all of them IP device tracking knows the IP address of the host. In that scenario it will still be "any" for some entries. That behavior is different on some platforms. For example, on the 2960X with Version 15.0(2)EX the ACL will always be specific even when there is just one authentication session per port. However, for the 3560X and 3750X Version 15.0(2)SE, you need to have at least two sessions to make that ACL specific. Control-Direction By default, the control-direction is type both: bsns (config)#int g1/0/1 bsns (config-if)#authentication control-direction? both Control traffic in BOTH directions in Control inbound traffic only bsns (config-if)#authentication control-direction both That means that before the supplicant is authenticated, traffic cannot be sent to or from the port. For "in" mode, the traffic could have been sent from port to supplicant, but not from supplicant to the port (could be

12 useful for the WAKE on LAN feature). Still, the switch applies the ACL just on the "in" direction. It does not matter which mode is used. bsns #sh ip access-lists interface g1/0/1 out bsns #sh ip access-lists interface g1/0/1 in permit ip host any permit ip host any That basically means that after authentication the ACL is applied for traffic to the port (in direction) and all traffic is permitted from the port (out direction). IP Device Tracking with 802.1x and Per-User ACL for Version 15.x It is also possible to use a Per-User ACL which is passed in cisco-av-pair "ip:inacl" and "ip:outacl". This example configuration is similar to a previous configuration, but this time the phone uses DACL and the PC uses Per-User ACL. The ISE profile for the PC is: The phone still has the DACL applied: bsns #show authentication sessions interface g1/0/1 Interface: GigabitEthernet1/0/1 MAC Address: IP Address: User-Name: Status: Authz Success Domain: VOICE Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 100 ACS ACL: xacsaclx-ip-permit_all_traffic-51134bb2 Session timeout: N/A Idle timeout: N/A Common Session ID: C0A D8 Acct Session ID: 0x000006D2 Handle: 0x Runnable methods list: Method State dot1x Failed over mab Authc Success bsns #sh ip access-lists xacsaclx-ip-permit_all_traffic-51134bb2 Extended IP access list xacsaclx-ip-permit_all_traffic-51134bb2 (per-user) 10 permit ip any any However, the PC on the same port uses the Per-User ACL:

13 Interface: GigabitEthernet1/0/1 MAC Address: ea1 IP Address: User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 20 Per-User ACL: permit icmp any any log Session timeout: N/A Idle timeout: N/A Common Session ID: C0A B Acct Session ID: 0x000006D1 Handle: 0x9D In order to verify how that is merged on the gig1/0/1 port: bsns #show ip access-lists interface g1/0/1 permit icmp host any log permit ip host any The first entry has been taken from the Per-User ACL (notice the log keyword) and the second entry is taken from the DACL. Both of them are rewritten by IP device tracking for the specific IP address. Per-User ACL could be verified with the debug epm all command: Apr 12 02:30:13.489: EPM_SESS_EVENT:IP Per-User ACE: permit icmp any any log received Apr 12 02:30:13.489: EPM_SESS_EVENT:Recieved string GigabitEthernet1/0/1#IP#7844C6C Apr 12 02:30:13.489: EPM_SESS_EVENT:Add ACE [permit icmp any any log] to ACL [GigabitEthernet1/0/1#IP#7844C6C] Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [ip access-list extended GigabitEthernet1/0/1#IP#7844C6C] command through parse_cmd. Result= 0 Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [permit icmp any any log] command through parse_cmd. Result= 0 Apr 12 02:30:13.497: EPM_SESS_EVENT:Executed [end] command through parse_cmd. Result= 0 Apr 12 02:30:13.497: EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL) application on the interface GigabitEthernet1/0/1 And also via the show ip access-lists command: bsns #show ip access-lists Extended IP access list GigabitEthernet1/0/1#IP#7844C6C (per-user) 10 permit icmp any any log What about the ip:outacl attribute? It is completely omitted in Version 15.x. The attribute has been received, but the switch does not apply/process that attribute. Difference when Compared to the DACL As noted in Cisco bug ID CSCut25702, the Per-User ACL behaves differently than DACL. DACL with just one entry ("permit ip any any") and one supplicant connected to a port can work correctly without IP device tracking enabled. The "any" argument will not be substituted and all traffic will be permitted. However, for the Per-User ACL it is mandatory to have IP device tracking enabled. If it is disabled and has just the "permit ip any any" entry and one supplicant, then all traffic will be blocked.

14 IP Device Tracking with 802.1x and Filter-ID ACL for Version 15.x Also, the IETF attribute filter-id [11] can be used. The AAA server returns the ACL name, which should be defined locally on the switch. The ISE profile could look like this: Note that you need to specifiy the direction (in or out). For that it is necessary to add the attribute manually: Then the debug shows: debug epm all Apr 12 23:41:05.170: EPM_SESS_EVENT:Filter-Id : Filter-ACL received Apr 12 23:41:05.170: EPM_SESS_EVENT:Notifying PD regarding Policy (NAMED ACL) application on the interface GigabitEthernet1/0/1 That ACL will be also shown for the authenticated session: bsns #show authentication sessions interface g1/0/1 Interface: GigabitEthernet1/0/1 MAC Address: ea1 IP Address: User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 20 Filter-Id: Filter-ACL Session timeout: N/A Idle timeout: N/A Common Session ID: C0A E47B77481 Acct Session ID: 0x Handle: 0x5E00059F Runnable methods list:

15 Method State dot1x Authc Success mab Not run And, as the ACL is binded to the interface: bsns #show ip access-lists interface g1/0/1 permit icmp host any log permit tcp host any log Note that this ACL can be merged with other types of ACLs on the same interface. For example, having on the same switch port another supplicant which gets DACL from ISE: "permit ip any any" you could see: bsns #show ip access-lists interface g1/0/1 permit icmp host any log permit tcp host any log permit ip host any Note that the IP device tracking rewrites the source IP for each source (supplicant). What about the "out" filter list? Again (as Per-User ACL), it will not be used by the switch. IP Device Tracking - Defaults and Best Practices For releases earlier than 15.2(1)E, before any feature can use IPDT it needs to be enabled globally first with this CLI command: (config)#ip device tracking For releases 15.2(1)E and later, the ip device tracking command is not needed any more. IPDT is enabled only if a feature that relies on it enables it. If no feature enables IPDT, IPDT is disabled. The "no ip device tracking" command has no effect. The specific feature has the control to enable/disable IPDT. When you enable IPDT, you have to remember about the "Duplicate IP Address" issue on. See Troubleshoot "Duplicate IP Address " Error Messages for more information. It is recommended to disable IPDT on a trunk port: (config-if)# no ip device tracking On the later Cisco IOS, it is a different command: (config-if)# ip device tracking maximum 0 It is recommended to enable IPDT on the access port and delay ARP probes in order to avoid the "Duplicate IP Address" issue: (config-if)# ip device tracking probe delay 10 Interface ACL Rewrite for Version 15.x For the interface ACL, it works before authentication: interface GigabitEthernet1/0/2 description windows7 switchport mode access ip access-group test1 in

16 authentication order mab dot1x authentication port-control auto mab dot1x pae authenticator end bsns #show ip access-lists test1 Extended IP access list test1 10 permit tcp any any log-input However, after authentication succeeds it is rewritten (override) by the ACL returned from the AAA server (it does not matter if it is DACL, ip:inacl, or filterid). That ACL (test1) can block the traffic (which would normally be permitted on open mode), but after authentication does not matter anymore. Even when no ACL is returned from the AAA server, the interface ACL is overwritten and full access is provided. That is a bit misleading since Ternary Content Addressable Memory (TCAM) indicates that the ACL is still binded on the interface level. Here is an example from Version on 3750X: bsns #show platform acl portlabels interface g1/0/2 Port based ACL: (asic 1) Input Label: 5 Op Select Index: 255 Interface(s): Gi1/0/2 Access Group: test1, 4 VMRs Ip Portal: 0 VMRs IP Source Guard: 0 VMRs LPIP: 0 VMRs AUTH: 0 VMRs C3PLACL: 0 VMRs MAC Access Group: (none), 0 VMRs That information is valid only for the interface level, not for the session level. Some more information (presents a compounded ACL) can be deduced from: bsns #show ip access-lists interface g1/0/2 permit ip host any Extended IP access list test1 10 permit icmp host host The first entry is created as "permit ip any any" DACL is returned for successful authentication (and "any" is replaced by an entry from the device tracking table). The second entry is the result of the interface ACL and is applied for all new authentications (before authorization). Unfortunately, (again platform dependent) both ACLs are concatenated. That happens on Version on 3750X. That means that for authorized session, both of them are applied. First the DACL and second the interface ACL. That is why when you add explicit "deny ip any any", the DACL will not take into consideration the interface ACL. Usually there is no explicit deny in the DACL and then the interface ACL is applied after that. The behavior for Version on 3750X is the same, but the sh ip access-list interface command does not show the interface ACL anymore (but it will still be concatenated with the interface ACL unless explicit deny in the DACL exists). Default ACL Used for 802.1x There are two types of default ACLs:

17 auth-default-acl-open - used for open mode auth-default-acl - used for closed access Both auth-default-acl and auth-default-acl-open are used when the port is in the unauthorized state. By default, closed access is used. That means that before authentication all traffic is dropped except the one permitted by the auth-default-acl. This way DHCP traffic is permitted before successful authorization. The IP address is allocated and the downloaded DACL can be correctly applied. That ACL is created automatically and cannot be found in the configuration. bsns #sh run i Auth-Default bsns #sh ip access-lists Auth-Default-ACL Extended IP access list Auth-Default-ACL 10 permit udp any range bootps any range bootpc (22 matches) 20 permit udp any any range bootps (12 matches) 30 deny ip any any It is created dynamically for the first authentication (between authentication and authorization phase) and removed after the last session is removed. Auth-Default-ACL permits only DHCP traffic. After authentication succeeds and the new DACL is downloaded, it is applied to that session.when the mode is changed to open auth-default-acl-open appears and it is used and works in exactly the same way as Auth-Default-ACL: bsns (config)#int g1/0/2 bsns (config-if)#authentication open bsns #show ip access-lists Extended IP access list Auth-Default-ACL-OPEN 10 permit ip any any Both ACLs can be customized, but they will never be seen in the configuration. bsns (config)#ip access-list extended Auth-Default-ACL bsns (config-ext-nacl)#permit udp any any bsns #sh ip access-lists Extended IP access list Auth-Default-ACL 10 permit udp any range bootps any range bootpc (22 matches) 20 permit udp any any range bootps (16 matches) 30 deny ip any any 40 permit udp any any bsns #sh run i Auth-Def bsns # Open Mode The previous section described the behavior for ACLs (which includes the one used by default for open mode). The behavior for open mode is: it allows for all traffic (as per default auth-default-acl-open) when the session is in an unauthorized state. the session is in an unauthorized state during authentication/authorization (good for Encryption Appliance Model E (PXE) boot scenarios) or after that process fails (good for scenarios called "low impact mode"). when the session moves to the authorized state for multiple platforms, ACLs are concatenated and the first DACL is used, then the interface ACL.

18 for multi-auth or multi-domain there might be multiple sessions at the same time in different states (then the different ACL type will apply for each session). When the Interface ACL is Mandatory For multiple 6500/4500 platforms, the interface ACL is mandatory in order to apply the DACL correctly. Here is an example with 4500 sup SG6, no interface ACL: brisk#show run int g2/3! interface GigabitEthernet2/3 switchport mode access switchport voice vlan 10 authentication host-mode multi-auth authentication open authentication order mab dot1x authentication priority dot1x mab authentication port-control auto mab Then after the host is authenticated, the DACL is downloaded. It will not be applied and authorization fails. *Apr 25 04:38:05.239: RADIUS: Received from id 1645/ :1645, Access-Accept, len 209 *Apr 25 04:38:05.239: RADIUS: authenticator 35 8E 59 E4 D5 CF 8F 9A - EE 1C FC 5A 9F B2 *Apr 25 04:38:05.239: RADIUS: User-Name [1] 41 "#ACSACL#-IP-PERMIT_ALL_TRAFFIC-51ef7db1" *Apr 25 04:38:05.239: RADIUS: State [24] 40 *Apr 25 04:38:05.239: RADIUS: F 6E 3A [ReauthSession:0a] *Apr 25 04:38:05.239: RADIUS: [30424a000EF50F53] *Apr 25 04:38:05.239: RADIUS: [ 5A6693] *Apr 25 04:38:05.239: RADIUS: Class [25] 54 *Apr 25 04:38:05.239: RADIUS: A [CACS:0a30424a000] *Apr 25 04:38:05.239: RADIUS: A [EF50F535A6693:is] *Apr 25 04:38:05.239: RADIUS: F F [e2/ /128] *Apr 25 04:38:05.239: RADIUS: [ 6553] *Apr 25 04:38:05.239: RADIUS: Message-Authenticato[80] 18 *Apr 25 04:38:05.239: RADIUS: AF 47 E F A 61 5C C5 8B ED F5 [ G e/y9ra\] *Apr 25 04:38:05.239: RADIUS: Vendor, Cisco [26] 36 *Apr 25 04:38:05.239: RADIUS: Cisco AVpair [1] 30 "ip:inacl#1=permit ip any any" *Apr 25 04:38:05.239: RADIUS( ): Received from id 1645/19 *Apr 25 04:38:05.247: EPM_SESS_ERR:Failed to apply ACL to interface *Apr 25 04:38:05.247: EPM_API:In function epm_send_message_to_client *Apr 25 04:38:05.247: EPM_SESS_EVENT:Sending response message to process AUTH POLICY Framework *Apr 25 04:38:05.247: EPM_SESS_EVENT:Returning feature config *Apr 25 04:38:05.247: EPM_API:In function epm_acl_feature_free *Apr 25 04:38:05.247: EPM_API:In function epm_policy_aaa_response *Apr 25 04:38:05.247: EPM_FSM_EVENT:Event epm_ip_wait_event state changed from policy-apply to ip-wait *Apr 25 04:38:05.247: EPM_API:In function epm_session_action_ip_wait *Apr 25 04:38:05.247: EPM_API:In function epm_send_ipwait_message_to_client *Apr 25 04:38:05.247: EPM_SESS_ERR:NULL feature list for client ctx 1B2694B0 for type DOT1X

19 *Apr 25 04:38:05.247: %AUTHMGR-5-FAIL: Authorization failed for client ( ) on Interface Gi2/3 AuditSessionID 0A C050 brisk#show authentication sessions Interface MAC Address Method Domain Status Session ID Gi2/ mab VOICE Authz Failed 0A C050 After the interface ACL is added: brisk#show ip access-lists all Extended IP access list all 10 permit ip any any (63 matches) brisk#sh run int g2/3! interface GigabitEthernet2/3 switchport mode access switchport voice vlan 10 ip access-group all in authentication host-mode multi-auth authentication open authentication order mab dot1x authentication priority dot1x mab authentication port-control auto mab The authentication and authorization will succeed and the DACL will be applied correctly: brisk#show authentication sessions Interface MAC Address Method Domain Status Session ID Gi2/ mab VOICE Authz Success 0A A2CE4 The behavior is not dependent on "authentication open". In order to accept the DACL, you need the interface ACL for both open/closed mode. DACL on 4500/6500 On the 4500/6500, the DACL is applied with acl_snoop DACLs. An example with 4500 sup SG6 (phone + PC) is shown here. There is a separate ACL for voice (10) and data (100) VLAN: brisk#show ip access-lists Extended IP access list acl_snoop_gi2/3_10 10 permit ip host any 20 deny ip any any Extended IP access list acl_snoop_gi2/3_ permit ip host any 20 deny ip any any ACLs are specific because IPDT has the correct entries: brisk#show ip device tracking all IP Device Tracking = Enabled IP Device Tracking Probe Count = 3 IP Device Tracking Probe Interval = 30 IP Device Tracking Probe Delay Interval = IP Address MAC Address Vlan Interface STATE GigabitEthernet2/3 ACTIVE

20 c.29d GigabitEthernet2/3 ACTIVE Authenticated sessions confirm the addresses: brisk#show authentication sessions int g2/3 Interface: GigabitEthernet2/3 MAC Address: 000c.29d IP Address: User-Name: 00-0C-29-D Status: Authz Success Domain: VOICE Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: N/A Session timeout: N/A Idle timeout: N/A Common Session ID: 0A E0C Acct Session ID: 0x Handle: 0x Runnable methods list: Method State mab Authc Success dot1x Not run Interface: GigabitEthernet2/3 MAC Address: IP Address: User-Name: Status: Authz Success Domain: DATA Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: N/A Session timeout: N/A Idle timeout: N/A Common Session ID: 0A E031D1DB8 Acct Session ID: 0x Handle: 0x4A00002E Runnable methods list: Method State mab Authc Success dot1x Not run At this stage both the PC and the phone responds to ICMP echo, but the interface ACL presents only: brisk#show ip access-lists interface g2/3 permit ip host any Why? Because the DACL has been pushed only for the phone ( ). For the PC, the interface ACL with open mode is used: interface GigabitEthernet2/3 ip access-group all in authentication open brisk#show ip access-lists all Extended IP access list all 10 permit ip any any (73 matches)

21 In summary, acl_snoop will be created for both the PC and the phone, but the DACL is returned just for the phone. That is why that ACL is seen as binded to the interface. MAC Address Status for 802.1x When 802.1x authentication starts, the MAC address is still seen as DYNAMIC but action for that packet is DROP: bsns #show authentication sessions Interface MAC Address Method Domain Status Session ID Gi1/0/ dot1x UNKNOWN Running C0A F4DCE bsns #show mac address-table interface g1/0/1 Mac Address Table Vlan Mac Address Type Ports DYNAMIC Drop Total Mac Addresses for this criterion: 1 After successful authentication the MAC address becomes static and the port number is provided: bsns #show authentication sessions Interface MAC Address Method Domain Status Session ID Gi1/0/ mab VOICE Authz Success C0A F4DCE bsns #show mac address-table interface g1/0/1 Mac Address Table Vlan Mac Address Type Ports STATIC Gi1/0/1 That is true for all mab/dot1x session for both domains (VOICE/DATA). Troubleshoot Remember to read the 802.1x configuration guide for your specific software version and platform. If you open a TAC case, provide the output from these commands: show tech show authentication session interface <xx> detail show mac address-table interface <xx> It is also good to collect a SPAN port packet capture and these debugs: debug radius verbose debug epm all debug authentication all debug dot1x all debug authentication feature <yy> all debug aaa authentication

22 debug aaa authorization Related Information 802.1X Authentication Services Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3850 Switches) Catalyst 3750-X and Catalyst 3560-X Switch Software Configuration Guide, Cisco IOS Release 15.2(1)E Catalyst 3750-X and 3560-X Software Configuration Guide, Release 15.0(1)SE Catalyst 3560 Software Configuration Guide, Release 12.2(52)SE Technical Support & Documentation - Cisco Systems Updated: Nov 24, 2015 Document ID: