cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1905
Views
10
Helpful
7
Replies

IOS-XE 16.9 Code Portal Redirect + DACL

paul
Level 10
Level 10

I am seeing an odd issue that I will probably open a TAC case on.  I have the following portal redirect ACL:

 

Extended IP access list PORTAL-REDIRECT
10 permit tcp any host 10.0.0.1 eq www
20 deny ip any any

 

That ACL should only redirect port 80 traffic to 10.0.0.1 and let everything else through.  Then I have a DACL applied:


Extended IP access list xACSACLx-IP-Wired_Default_Access-5df8f97d
1 permit udp any any eq domain
2 permit udp any any eq bootps
3 permit udp any any eq bootpc
4 permit ip any host 10.150.23.62
5 permit ip any host 10.1.90.62
6 permit tcp any host 10.0.0.1 eq www
7 deny ip any 10.0.0.0 0.255.255.255
8 deny ip any 172.16.0.0 0.15.255.255
9 deny ip any 192.168.0.0 0.0.255.255
10 permit ip any any

 

That DACL should block all internal communication except to the ISE nodes, DHCP and DNS.  It allows all other (Internet) traffic.  When the portal redirect and DACL is applied the client can get to everything including internal IPs.  Basically the DACL doesnt do anything.  If I remove the portal redirect the DACL correctly blocks internal traffic. 

 

The correct order of operation is supposed to be redirect ACL evaluation followed by DACL evaluation.  I have done this 100s of times on other IOS versions without an issue.  Has anyone seen this issue on IOS XE or specifically on 16.9 code?

1 Accepted Solution

Accepted Solutions

I did get it working after working with TAC and finding out how the switch process the ACLs.  I still think it is a bug but the work around was simple enough.  My redirect ACL was as follows:

 

Extended IP access list PORTAL-REDIRECT
10 permit tcp any host 10.0.0.1 eq www
20 deny ip any any

 

Because I had an explicit deny ip any any in the redirect ACL the switch basically said "I have a hit on an explicit line in the redirect ACL there is no need to process the DACL.".  That is flawed logic of course but that is how the switch works according to TAC.  Once I removed the explicit deny ip any any statement the DACL was correctly processed.

View solution in original post

7 Replies 7

craig.beck
Level 1
Level 1

With the portal redirect ACL applied can you get to 10.0.0.1 on port 80?

The redirect ACL works as intended. If I go to 10.0.0.1 I get redirected to the portal. The problem is the DACL doesn't block all other internal traffic as it should.



If I remove the redirect ACL the DACL works perfect. I am sure if I modified the redirect ACL to block internal traffic and allow only Internet traffic it would work, but per best practices you shouldn't use the redirect ACL to control traffic. It should only be used to redirect desired traffic. The DACL should be used to control traffic. Redirect ACLs are processed in software where DACLs are done in hardware.


I'm doing some testing with a 9800 IOS-XE based WLC and observed the same behavior.   In my particular case I was able to achieve my desired result by moving everything into the redirect ACL, however, I'd like to understand if this is expected behavior(pre-auth-acl ignored if redirect-acl is applied).  It's a deviation from how it used to behave in the past (redirect ACL evaluated, then pre-auth-acl).

andrewswanson
Level 7
Level 7

Hi

I'm working on a pilot wired CWA deployment with catalyst 3ks running 16.9.4 - I'm new to CWA so I was doing a bit of research into how the various ACLs were applied.

 

When I use the command below to check what ACLs are applied for a given client mac address:

 

show platform software fed switch 1 acl interface | BEGIN <client_MAC-address>

 

It returns the following:

 

Policy Name: LAPTOP_ACL_DEFAULT:xACSACLx-IP-LAPTOP_ISE_ONLY-5e661779:LAPTOP_ACL_REDIRECT:

 

Where:

 

  • LAPTOP_ACL_DEFAULT - the pre-auth PACL applied to the switch interface
  • xACSACLx-IP-LAPTOP_ISE_ONLY-5e661779 - DACL configured on ISE
  • LAPTOP_ACL_REDIRECT - portal redirect ACL

 

The output of this command suggests that the DACL is evaluated before the redirect acl (if I'm reading this correctly)

 

hth
Andy

Madura Malwatte
Level 4
Level 4

Hi @paul did you find any solution to this. Is this expected behaviour? I am running into some issues with 9800 WLC and getting DACL to work after using redirect acl.

I did get it working after working with TAC and finding out how the switch process the ACLs.  I still think it is a bug but the work around was simple enough.  My redirect ACL was as follows:

 

Extended IP access list PORTAL-REDIRECT
10 permit tcp any host 10.0.0.1 eq www
20 deny ip any any

 

Because I had an explicit deny ip any any in the redirect ACL the switch basically said "I have a hit on an explicit line in the redirect ACL there is no need to process the DACL.".  That is flawed logic of course but that is how the switch works according to TAC.  Once I removed the explicit deny ip any any statement the DACL was correctly processed.

Hi Paul, thanks for the reply. This is good to know! I thought this might have been a similar problem to what I am facing on the 9800 wlc but it uses the acl in reverse format (deny to allow and permit to redirect) for the web auth redirect ACL. 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: