Wired MAB - Switch is not forwarding the dACL allowed traffic

racp · ‎10-08-2023

I am trying to figure out what is causing this issue. The customer is saying this setup worked before. Hoping someone can help.

The MAB is used as Authentication method on the switch port. The NAC used is ClearPass(not ISE). DHCP is used for profiling a new phone on NAC. IP helper is configured on Distribution switch to forward DHCP discovery packet to NAC.

When a new phone is connected, NAC receive a Radius packet. NAC is unaware of the connected device as profiling with DHCP is not initiated. So NAC provides switch port a Pre-Authentication with redirect URL and dACL.

Even though dACL is allowing DHCP, switch is not forwarding the DHCP discovery. As a result, can’t proceed to profile the device and the phone is not getting an IP from DHCP server.

I don’t know why there is a “implicit deny” in front of ACLs on The “show platform” command.

ACK_L10_9300#show platform software fed switch 2 acl interface 0x22FE6554

INTERFACE: Client MAC 0080.9fda.fe16

Policy Name: implicit_deny:xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8:TEST-CLEARPASS-REDIRECT;

SWITCH : CAT 9300 – IOS-XE Version 17.3.4

!

interface TenGigabitEthernet2/0/43

description TEST-Phone

network-policy 1 <- used to allocate voice vlan to the port

switchport access vlan 115

switchport mode access

device-tracking

authentication host-mode multi-auth

authentication order mab

authentication priority mab

authentication port-control auto

authentication periodic

authentication timer reauthenticate server

mab

spanning-tree portfast

end

ACK_L10_9300#show authentication sessions int te 2/0/43 details

Interface: TenGigabitEthernet2/0/43

IIF-ID: 0x22FE6554

MAC Address: 0080.9fda.fe16

IPv6 Address: Unknown

IPv4 Address: Unknown

User-Name: 00809fdafe16

Status: Authorized

Domain: DATA

Oper host mode: multi-auth

Oper control dir: both

Session timeout: N/A

Common Session ID: 0101A8C0000017B81097542C

Acct Session ID: 0x000017af

Handle: 0x67000721

Current Policy: POLICY_Te2/0/43

Local Policies:

Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Security Policy: Should Secure

Server Policies:

URL Redirect: https://clearpass.TEST.net.au/guest/TEST_Logon.php?mac=00:80:9f:da:fe:16

URL Redirect ACL: TEST-CLEARPASS-REDIRECT

ACS ACL: xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8

Method status list:

Method State

mab Authc Success

ACK_L10_9300#show access-l TEST-CLEARPASS-REDIRECT

Extended IP access list TEST-CLEARPASS-REDIRECT

<- Tried deny bootps entry on this ACL. But it didn’t help.

40 permit tcp any any eq www

50 permit tcp any any eq 443

Extended IP access list xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8

1 permit udp any any eq bootps

2 permit udp any any eq bootpc

3 permit udp any any eq domain

ahollifield · ‎10-09-2023

Why are you using "redirect ACL for this? I get it's just a name but are you using captive portal on ClearPass? What does the dACL configuration on ClearPass look like?

racp · ‎10-09-2023

Redirect ACL "TEST-CLEARPASS-REDIRECT" is defined on switch. The URL redirect the users to Clearpass portal, login page.

Extended IP access list TEST-CLEARPASS-REDIRECT

40 permit tcp any any eq www

50 permit tcp any any eq 443

Allow traffic dACL "xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8" is defined on Clearpass.

Extended IP access list xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8

1 permit udp any any eq bootps

2 permit udp any any eq bootpc

3 permit udp any any eq domain

MHM Cisco World · ‎10-09-2023

Hi'

Show access list' do yoh see dacl push from Server to SW?

If not

Add access list under port with same name' and make it empty and check again.

racp · ‎10-10-2023

Hi

Yes, the dACL is sent by the server. The redirect ACL “url-redirect-acl” is define on switch and called by the server.

Below are the Radius attributes sent from the server to switch for ACLs.

Radius:Cisco:Cisco-AVPair = url-redirect-acl=TEST-CLEARPASS-REDIRECT

Radius:Cisco:Cisco-IP-Downloadable-ACL = 0x2341435341434c232d49502........................

MHM Cisco World · ‎10-10-2023

What is SW platform you have?

ammahend · ‎10-10-2023

To prove this theory why don’t you remove initial ACL pushed with redirect url and see if you get an IP ?

-hope this helps-

racp · ‎10-10-2023

I don't understand what will be proven by disabling dACL sent by Server. I can't change it at the moment as the policy is used by operational devices.

The command "show platform" output show the ACLs are applied on the port.

For testing "authentication open" was applied on port. Then can see the Authentication "Pre-Authentication level" received from the Server, Phone get and IP from DHCP, Server perform "profiling" with DHCP discovery packet and identify the device as a phone. A COA is received on the switch with Auth for "Voice" with port allow-all(packet) status.

ACK_L10_9300#show platform software fed switch 2 acl info acl-grp-cgid 10512
########################################################
######### ##################
######## Printing CG Entries #################
######### ##################
########################################################
===================================
ACL CG (acl-grp/10512): implicit_deny:xACSACLx-IP-DACL_CISCO_REDIRECT-3010-8:TEST-CLEARPASS-REDIRECT; type: IPv4
Total Ref count 1
---------------------------------
1 CGACL
---------------------------------
region reg_id: 1
subregion: 0 jumpto reg_idx 0 subr_idx 1

GCE#:40 #flds: 4 l4:Y matchall:N deny:N
Result: 0x03000000
ipv4_src: value = 0x00000000, mask = 0x00000000
ipv4_dst: value = 0x00000000, mask = 0x00000000
ip_prot: start = 6, end = 6
l4_dst: start = 80, end = 80
GCE#:50 #flds: 4 l4:Y matchall:N deny:N
Result: 0x03000000
ipv4_src: value = 0x00000000, mask = 0x00000000
ipv4_dst: value = 0x00000000, mask = 0x00000000
ip_prot: start = 6, end = 6
l4_dst: start = 443, end = 443
subregion: 1 jumpto reg_idx 0 subr_idx 2
GCE#:1 #flds: 4 l4:Y matchall:N deny:N
Result: 0x04000000
ipv4_src: value = 0x00000000, mask = 0x00000000
ipv4_dst: value = 0x00000000, mask = 0x00000000
ip_prot: start = 17, end = 17
l4_dst: start = 67, end = 67
GCE#:2 #flds: 4 l4:Y matchall:N deny:N
Result: 0x04000000
ipv4_src: value = 0x00000000, mask = 0x00000000
ipv4_dst: value = 0x00000000, mask = 0x00000000
ip_prot: start = 17, end = 17
l4_dst: start = 68, end = 68 <--------------------------------- dhcp allowd

racp · ‎10-10-2023

The switch platform and IOS version

SWITCH : CAT 9300 – IOS-XE Version 17.3.4

MHM Cisco World · ‎10-11-2023

You mention that it was work before.

Can you check tcam utilize. It can that tcam have no any more room for this additional dacl.

racp · ‎10-11-2023

The customer said it used to work before. The problem is affecting more than one switch. The tcam usage is low. below is the tcam for ACLs

ACK_L10_9300#show platform hardware fed switch active fwd-asic resource tcam utilization | inc ACL
QOS ACL TCAM IO 5120 93 1.82% 30 42 0 21
Security ACL TCAM IO 5120 203 3.96% 46 112 0 45
Netflow ACL TCAM I 256 6 2.34% 2 2 0 2
PBR ACL TCAM I 1024 22 2.15% 16 6 0 0
Netflow ACL TCAM O 768 6 0.78% 2 2 0 2
Flow SPAN ACL TCAM IO 1024 13 1.27% 3 6 0 4
QOS ACL TCAM IO 5120 89 1.74% 29 40 0 20
Security ACL TCAM IO 5120 202 3.95% 45 112 0 45
Netflow ACL TCAM I 256 6 2.34% 2 2 0 2
PBR ACL TCAM I 1024 22 2.15% 16 6 0 0
Netflow ACL TCAM O 768 6 0.78% 2 2 0 2
Flow SPAN ACL TCAM IO 1024 13 1.27% 3 6 0 4