You have to deny to allow…..what?

ACLs on a switch are pretty straight forward. You want to only allow access to TCP ports 80 and 22 and block everything else?

permit tcp any any eq 80
permit tcp any any eq 22
deny ip any any

Easy to read and understand. Allow access to any server via port 80 and then block everything else. What a lot of my customers get confused on are redirect ACLs on a switch. These URLs are used for wired guest access, wired BYOD, and posture assessment. What causes confusion is how they operate. They don’t work by just allowing or denying traffic across the network. They are actually telling the switch what traffic to redirect to the redirect URL that is assigned to a session based on the authorization profile.

Let’s look at a typical redirect ACL on a switch.

permit tcp any any eq 80
deny ip any any

At first glance, customers think “I don’t want unknown devices full access to the Internet or to any servers on my network via port 80 (www)”. That’s the catch. This isn’t a standard ACL. It’s a redirect ACL. What those lines above do is tell the switch to redirect any traffic on TCP port 80 to the redirect URL that was assigned to the session. The final line is telling the switch to ignore any other traffic (e.g. don’t redirect it).

This is why it is critical to mix in a downloadable ACL (or proper TrustSec settings) to work along with the redirect ACL. Since the redirect ACL is going to let all other traffic pass, the dACL will be used to only allow specific access. A standard dACL I use for customers that are only doing guest access but no posture assessment would be something like this:

permit udp any any eq 53
permit udp any eq bootpc eq bootps
permit tcp any eq 8443
permit tcp any eq 8443
deny ip any any

This dACL does the following:

  1. Allow DNS queries.
  2. Allow DHCP.
  3. Allow access to the 1st ISE PSN on port 8443 (standard guest port).
  4. Allow access to the 2nd ISE PSN on port 8443.
  5. Deny all other traffic.

The dACL will be hit after the local redirect ACL. So when a client hits an auth rule for guest redirection, the full traffic analysis will be:

  1. Traffic checked against the redirect ACL.
    • Redirect any traffic on port 80 to the redirect URL (guest portal on the PSN).
    • Allow all other traffic through.
  2. Traffic checked against the dACL.
    • Allow DNS.
    • Allow DHCP.
    • Allow access to the guest portal on the 1st ISE PSN.
    • Allow access to the guest portal on the 2nd ISE PSN.
    • Deny/drop all other traffic.

Keep in mind that redirect ACLs and dACLs on a switch are applied for inbound traffic (client to network). You don’t have to specifically allow the return traffic as replies (network to client) are already allowed.

Update 2019/08/05: I have removed the line in the redirect ACL to redirect HTTPS (TCP port 443) traffic. That’s no longer recommended as it wasn’t really a good idea anyway. Modern browsers would not trust an HTTPS site redirect and teaching your users to “just click through” is just getting them accustomed to Man-In-the-Middle attacks.

Update 2019/08/31: Another good redirect ACL to use on the switch for posture assessment (not guest access) redirects connections initiated by AnyConnect for detecting the policy node. This is for cases where you use a software management system (ie SCCM) to deploy AnyConnect to your clients instead of relying on the ISE provisioning portal. This ACL redirects traffic destined for the VLAN default gateway and So if your network is 192.168.x.y and the default gateway is 192.168.x.1, your redirect ACL would be as follows:

permit tcp any eq 80
permit tcp any host eq 80
deny ip any any

Be sure to combine this with a dACL or port ACL in order to allow/deny specific traffic while posturing is in process.

Share this post:


    1. The dACL would be like the example I gave above to allow access (permit xxx ….) to services such as DHCP, DNS, remediation servers, etc. I am actually revising this article to remove the “permit tcp any any eq 443” from the redirect ACL because that’s no longer a recommended configuration.

  1. Can you provide evidence that DACLs on switches are stateful? I can’t find any evidence to support this because as far as I can tell it’s just an ACL on the switch. The only hit about it being stateful are from your website as well.

    1. Lynn,

      I apologize. I oversimplified the description because the ACL is applied for inbound (client to network) traffic. I have corrected that line so as to avoid future confusion.

  2. How do you configure a DACL to allow limited internet connectivity? Like only access to office 365 or Outlook?

    1. Unfortunately, at this time, using DNS names in a DACL is not supported. You would have to use IP addresses (or ranges) for that which is obviously not a sustainable method.

      An option to look into is using FQDNs in an ACL on the switch, or WLC, and calling that (eg Filter-ID) in the Authorization Profile to be assigned instead of using a DACL. Support for that feature is software dependent so check release notes for your device to see if it is an option.

Leave a Reply

Your email address will not be published. Required fields are marked *