ISE DACL syntax documentation

[anthonylofreso]

Hello, I'm looking for a deep dive on valid DACL config.

Specifically, what is the 'addrgroup' syntax used for? I can type something like:

permit ip any addrgroup my_addrgroup

in the DACL Content box, and it checks as valid config.

If I just enter "permit ip addrgroup" then click Check Config, the following is displayed:

Line 3 - In "permit ip addrgroup", argument #3 "addrgroup" must be followed by the option(s):

  <address group name> - A string without white spaces; length between 1 and 232 characters"

I guess the question is, if I specify an address group name, from where is that group referenced by the DACL?

[howon]

It is certainly not ISE that group is referenced from. If the goal is to reduce amount of ACE then using object group is not going to help as the limitation will be on the specific switch TCAM rather than the size of dACL. Also, I don't believe object group is supported with dACL even though ISE syntax checker is allowing it.

[anthonylofreso · Accepted solution]

We've been working this in the lab. Seems you are correct. We also found that object-groups, although the syntax exists in the switch, do not work.

We did get to a point where ISE was sending the DACL with the object group. And I could see the object group on the interface authentication session ACL. However it does not work.

So this begs a 2nd question. Let's say I've got a device that's running a small webserver on 443. I want to write a DACL that permits access to this webserver on the private network, but blocks any public IPs.

permit tcp any eq 443 10.x...

permit tcp any eq 443 192.x...

permit tcp any eq 443 172.x...

deny ip any any

^^^^ Is this the least # of ACEs that will achieve the desired outcome?

[howon]

Are you applying this dACL on the user's device or on the server? Or are you implying the web server is running on the endpoint that is being authenticated with 802.1X (Not common to authenticate web server with 802.1X)? The dACL is always applied inbound from the endpoint to the switch. So your example dACL would prevent 802.1X/MAB authenticated device running web server from serving to IP other than in  the private IP space on port 443.

[anthonylofreso]

The web server is running on the endpoint that is being authenticated with (MAB in this case). Small iot devices that have little web servers used for configuration. But in addition to 443, there could be 20 other ports that need to be permitted. So if I want to restrict access to that device to the RFC 1918 space, my DACL quickly becomes significant.

That's why we got excited when we saw addrgroup as valid syntax. Opens up all kinds of possibilities. But alas, I do not believe it's there for the purpose we're thinking.

[howon]

If allowing all open port, why not just use IP instead of TCP/UDP?

Also, I suggest checking out TrustSec (AKA Scalable Group Tag) for this use case as well:

https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/index.html

Lastly, another option is to dVLAN and apply ACL at the SVI.

[anthonylofreso]

Not permitting all open port, best case with dacl for us is IP with TCP/UDP. We're making due, just addrgroup would be nice.

And definitely. TrustSec is endgame (for now), we're just not there yet. Plan to be though.

Have considered this, right now all closet switches are strictly L2, with their GW being on a client VDC off our 7Ks.

[hslai]

Assuming the closet switches are either 2K or 3K, then object-group is not supported. See object group in C3560 & C3750 Switches. - Cisco Support Community.

If you may consider Security Group Firewall using an ASA, then take a look at Securing BYOD with Cisco TrustSec Security Group Firewalling

ISE DACL Syntax Checker is to give a general guidance but it does not do everything. Especially, it's differing among various platforms (e.g. Cisco IOS switches and ASA). Thus, it may give OK, even though the syntax not supported on the target network devices; vice versa. A better verification is to configure a test access-list on the network devices.