Catalyst 3850, VLAN access map example (VACL, layer 2)

[corpengineer818]

Hello there:

Trying to get a simple VLAN access map example working (VACL, layer 2).  Want to allow hosts 10.0.0.2 to SSH to 10.0.0.3 (both in vlan 10), but deny all other connectivity from 10.0.0.2 to 10.0.0.3.

access-list test permit tcp host 10.0.0.2 host 10.0.0.3 eq 22

vlan access-map test

   match ip address test

   action forward

vlan filter test vlan-list 10

However, 10.0.0.2 cannot see 10.0.0.3 whatsoever, w/ this VACL enabled (connectivity works w/ VACL disabled).

From what I've read, there is an implicit deny all at the end, if I understand correctly.

I've played with other variations as well, but without any luck.

What am I missing here?

Also, is there a way to debug this using logs or debug statements? Nothing shows up in the logs.

Thank you.

[Peter Paluch · Accepted solution]

Hi,

You have a problem in that your ACL currently allows the SSH traffic from 10.0.0.2 to 10.0.0.3 but the responses are not allowed to flow back from 10.0.0.3 to 10.0.0.2. That is the most probable reason your VACL does not work as expected.

This modification should correct the behavior:

ip access-list extended TestACL
  permit tcp host 10.0.0.2 host 10.0.0.3 eq 22
  permit tcp host 10.0.0.3 eq 22 host 10.0.0.2
  deny ip host 10.0.0.2 host 10.0.0.3
  deny ip host 10.0.0.3 host 10.0.0.2
  permit ip any any
!
vlan access-map TestVACL
  match ip address TestACL
  action forward
!
vlan filter TestVACL vlan-list 10

Here, I've made sure that SSH traffic between 10.0.0.2 as a client and 10.0.0.3 as a server is allowed, any other traffic between these two is denied, and every other communication is allowed. Would you mind testing out this modification?

is there a way to debug this using logs or debug statements? Nothing shows up in the logs.

None that I know of. This filtering is done in hardware, independently from CPU, so the CPU has no insight into what's going on in the TCAM during packet filtering.

Best regards,
Peter

[corpengineer818]

Yes, it does work.  Thank you very much.

So putting the 'eq 22' in the middle refers to the return traffic from the source host.  I had no idea an acl could be configured this way.

This works, and I am appreciative.  Just this seems like a lot of work w/ dozens and dozens of acl's.  I have about 100 hosts and 30 vlans.  Is there a more efficient way to do this?

Would using PACLs be preferable to using VACLs, are there benfits to using one over the other (like debugging capabilities)?

Thank you again.

[Peter Paluch]

Hi,

You are welcome.

So putting the 'eq 22' in the middle refers to the return traffic from the source host.

Quite right. Every entry in an extended ACL consists basically of four parts: action, protocol, source spec, destination spec. By saying host 10.0.0.3 eq 22 host 10.0.0.2 I have said that the source is 10.0.0.3 from port 22 (i.e. the responses from the SSH server), and the destination is 10.0.0.2.

Whether there is a more efficient way of doing this, or using PACLs instead of VACLs - definitely, we need to know more detail about your security requirements. Currently, you haven't explained what you are trying to achieve so we are missing the bigger picture. Until then, it's hard to say.

Best regards,
Peter

[corpengineer818]

We have a Catalyst 3850 Stack, connected to an ASA-X 5545 firewall via 8GB etherchannel.

We have about 100 servers (some connected to the stack w/ bonding or mini-etherchannels), and 30 VLANs.

We have several 10GB connections to servers.

We push large, (up to) TB sized files from VLAN to VLAN (and periodically outbound/inbound), mostly using scp or rsync.

We run mostly SSHd on servers, but also have a few w/ HTTPd, NTPd, and Syslogd & SNMPd for logging/reporting.  Also, some servers run NFSd and SMBd.  We also have a NAS running NFSd and SMBd, connected to the stack via 10GB fiber.

No ip phones, no POE.

Inter-VLAN connectivity/throughput and security are priorities.

Thank you.