In BYOD scenarios, the redirect ACL is used to redirect the wireless client to the ISE for either authentication or device registration depending on the BYOD model in place. Understanding the operation of the redirect ACL is critical to understanding what traffic is redirected, and what traffic is actually permitted through.
In summary, for a redirect ACL, a permit statement sends the packet to the CPU for further processing while a deny statement sends the packet to the next feature ACL (VACL or RACL only). If no match is found, packet is then matched against a filter-ID ACL. Further, if no match is found in the filter-ID ACL, an implicit deny will drop the packet and prevent it from being forwarded.
Here is an example using the single SSID BYOD scenario:
Use case: Wireless client needs to be redirected to the device registration portal for provisioning. Before the device is fully provisioned, it should ONLY be allowed to send DHCP, DNS and HTTP traffic to ISE. Additionally, it should be allowed to send telnet traffic to a specific server. Once the client is provisioned, client should be allowed access as per the new policies downloaded from ISE.
The WLAN (sp_data) is setup for PEAP/MSCHAPv2. Once the user associates with the SSID, and enters the username/password for PEAP authentication, ISE authenticates the user against Active Directory or other identity store. Once the user is authenticated successfully, ISE pushes down the authorization policy to the 3850 which includes the redirect URL (pointing to ISE), a redirect ACL (ACL_CWA_REVERSE) and a filter-ID acl (ACL_FILTER). See sample output below:
sp3850-1#sh access-session mac 0024.d79f.9cac detail
Interface: Capwap5
IIF-ID: 0xD5B0400000001E
MAC Address: 0024.d79f.9cac
IPv6 Address: Unknown
IPv4 Address: 12.0.41.15
User-Name: emp1
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0c002804518ab95700000016
Acct Session ID: Unknown
Handle: 0x6A000026
Current Policy: (No Policy)
Server Policies (priority 100)
URL Redirect: https://spear-ise.spear.com:8443/guestportal/gateway?sessionId=0c002804518ab95700000016&action=nsp
URL Redirect ACL: ACL_CWA_REVERSE
Filter-ID: ACL_FILTER
Method status list:
Method State
dot1x Authc Success
On the 3850, a redirect ACL operates as follows:
Permit – any packet that matches a permit statement is punted to the CPU for further processing
Deny – any packet that matches a deny statement is exempted from further processing.
No match – if a packet has no match, the packet is then matched against a filter-ID ACL.
In the above example, the redirect ACL denies DHCP, DNS and packets destined to ISE. Packets that are denied by the redirect ACL, are then matched against the next feature ACL (VACL or RACL). Accordingly, these packets are forwarded out into the appropriate vlan assigned either to the WLAN or the AP Group.
Sample Redirect ACL config:
ip access-list extended ACL_CWA_REVERSE
deny udp any any eq domain
deny udp any any eq bootpc
deny udp any any eq bootps
deny ip any host 10.3.3.60
permit tcp any any eq www
A permit statement is used for outbound HTTP packets. Only these packets are picked up by the CPU for further processing. The permit statement can be as specific as possible to ensure that only certain types of HTTP traffic is picked up for redirection. After redirect takes place, client/user will send HTTP traffic destined to ISE. The deny statement above the permit statement is used to catch this traffic. For this example, the deny statement matches traffic all destined to ISE server. This deny statement can be as specific as possible to match only HTTP traffic to ISE.
NOTE: any packet that matches the permit statement will be send to the CPU for processing. So the permit statement should be selected very carefully. A generic permit statement such as ‘permit tcp any any’ will send ALL TCP packets to the CPU. Only HTTP packets can be redirected, and the 3850 will attempt to forward all other TCP packets. Example: if telnet packets are sent, no redirection can occur on that TCP packet, and the 3850 will attempt to route it according to it’s routing table. If it has a route to that destination (eg: a default route), it will forward the packet out the outgoing VLAN interface.
NOTE: There is no implicit deny as part of the redirect ACL. If no match is found, the packet is then compared again the Filter-ID ACL. If no match is found in the Filter-ID ACL, then an implicit deny is used to drop the packet.
Continuing on the above example, we now need to permit specific TCP traffic. For this, after PEAP authentication, ISE had pushed down the filter-ID ACL as well.
Sample Filter-ID ACL config:
ip access-list extended ACL_FILTER
permit tcp any host 10.3.3.1 eq telnet
Telnet traffic to the specific destination will not match any entry in the redirect ACL. Accordingly, the packet is then matched against the filter-ID ACL which operates as a regular ACL. A permit statement will allow the packet to be forwarded, while a deny will drop the packet. If there is no match in the filter-ID ACL, an implicit deny will drop the packet and prevent it from being sent out.
Once the client is provisioned, the redirect ACL and Filter-ID ACL is removed, and a new policies pushed from ISE are in place. In this case, an access-accept is sent from ISE permitting all traffic from the user. Hence there is no further ACL applied to this client. See sample output below for the client after provisioning is completed:
sp3850-1#sh access-session mac 0024.d79f.9cac de
Interface: Capwap5
IIF-ID: 0xD5B0400000001E
MAC Address: 0024.d79f.9cac
IPv6 Address: Unknown
IPv4 Address: 12.0.41.15
User-Name: emp1
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0c002804518aba4100000017
Acct Session ID: Unknown
Handle: 0x6A000026
Current Policy: (No Policy)
Server Policies (priority 100)
Method status list:
Method State
dot1x Authc Success
