Yep, it’s another post about the redirect ACL. If you’ve worked with Cisco ISE for a while, you know the classic redirect ACL we’ve all configured.
ip access-list extended <Redirect ACL Name> permit tcp any any eq 80 permit tcp any any eq 443 deny ip any any
The thought behind it was simple: When a client tries to connect to any website, redirect them to the ISE portal. The problem with this approach is that modern browsers do not like their HTTPS session being redirected. There is a very good reason behind that. Redirecting HTTPS traffic pushes the client to a different website with a certificate that doesn’t match the original URL the browser tried to establish a connection to. The browser is warning you about a potential man-in-the-middle attack.
I have talked with ISE admins that say “Oh, I tell the guest/user to just click through because it’s an expected error.” Stop it! No, no, no, no, no. That is a horrible, no good, terrible idea. You are training your users to accept man-in-the-middle attacks! What is to stop them from just clicking through when browsing the Internet at home because “Well, the site must be having an issue”?
A better idea for redirecting guests or posturing is to only redirect HTTP requests. Most devices (Windows, OSX, etc.) have hotspot portal detection built in. The OS sends an HTTP request to a predefined URL, checks the response, and will prompt the user to log into a portal if one is detected. Because every hotspot check is via HTTP, you can easily use a redirect ACL like this:
ip access-list extended <Redirect ACL Name> # Redirect all HTTP requests permit tcp any any eq 80 # Ignore all other traffic deny ip any any
If you are not using the client provisioning portal for posturing because you have a software management system to deploy AnyConnect and its modules (which I highly recommend), you can use a redirect ACL that uses the IP address of the default gateway and enroll.cisco.com. Using my trusty example of a 192.168.x.y network where the default gateway is always 192.168.x.1:
ip access-list extended <Posture ACL Name> # Redirect HTTP requests sent to the default gateway permit tcp any 192.168.0.1 0.0.255.0 eq 80 # Redirect HTTP requests sent to enroll.cisco.com permit tcp any host 72.163.1.80 eq 80 deny ip any any
That’s it. Keep it clean, simple, and no more HTTPS errors! As always, be sure to apply a dACL or port ACL to define what traffic should be allowed (at least allow it to the ISE PSN!) and what traffic should be denied.
Note: After seeing some replies about this article on social media, I need to make it clear that this certificate warning has nothing to do with trusting the portal SSL certificate itself as long as the portal has a valid certificate. The warning the clients will receive is due to the browser wanting to hit a secure site (ie https://www.google.com) but being presented with the NAD SSL certificate and the redirection URL. The browser does not appreciate having a secure connection hijacked. There is no certificate error on the ISE portal page itself because the SSL certificate assigned to the portal matches the portal URL.
Nice article Brad – thanks for sharing.
Question – because of this:
“The OS sends an HTTP request to a predefined URL, checks the response, ”
…do we need to allow public DNS resolution prior to final authorization policy being applied (if we don’t redirect https) or should the ISE/NAD http redirection suffice? I’ve seen varying success by clients and never ran it down precisely so this is why I ask.
You shouldn’t have to use public DNS. I have utilized a dACL to allow access for DHCP, internal DNS server (because the client has to resolve the ISE node), and the ISE portal (typically the default 8443 port) with a lot of success. Wireless with AireOS is a little different because of the way the ACL works but typically wireless clients hit the captive portal check (HTTP) before they launch a browser and try a secure site (HTTPS).
Clearly users adopt what their IT organization tells them to do, so accept SSL webpages with warnings is teaching them the wrong way…an SSL certificate probably represents 0.001% of their budget.
Thanks a lot for all the information you published here.
I have a problem, I was wondering if you could help me.
I have vpn conncetion through ASA, also, I integrated ISE with ASA, the redorect URL can be created and pushed to asa by ISE ,but, the end user can not open the client
provisioning portal.
Why does it happen?