Port ACL overrides SGACL

[Antonio Macia]

Hi,

We are moving from traditional DACL to SGACL and we've noticed that the existing static ACL applied to the port that enforces the traffic when the device has not authenticated yet into the network, overrides the SGACL downloaded from ISE. With DACL this does not happen and the DACL has higher priority over the port ACL, but for some reason this is not the case for SGACLs.

Is there a way to make the SGACL more preferable over the PACL?

Regards.

[andrewswanson · Accepted solution]

Hi

When you say you are moving from traditional DACL to SGACL, do you mean that your ISE authz policy is changing from DACL to SGT assignment?

SGTs are assigned by ISE authz policy and SGACLs are downloaded by policy enforcement switches on your network (usually the egress switches of your CTS domain).

To retain your Port ACL and use SGT/SGACL you'd probably have to have an ISE authz policy that assigns an SGT as well as a "permit any" DACL to negate the Port ACL.

hth
Andy

[Greg Gibbs · Accepted solution]

@andrewswanson is correct, but just to add some additional context here...

Switchport ACLs (static or downloadable) enforce traffic at the ingress of the port whereas SGACLs enforce traffic at the egress of the port.

The entire scalability principle of TrustSec is based on the enforcement of SGACLs being done at the egress, closest to the destination. This is the opposite of traditional extended ACLs and this basic tenet of TrustSec should be considered and followed in your design and deployment. If you were to attempt leveraging SGACLs to enforce traffic at the source, like you would traditional ACLs, you will likely run into issues with scalability due to the source having to know every destination IP/SGT binding.

[Antonio Macia]

Thanks @andrewswanson I tested that approach and it works. Thanks as well @Greg Gibbs you right about the egress enforcement.