07-08-2014 03:53 PM - edited 03-07-2019 07:59 PM
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.
Solved! Go to Solution.
07-08-2014 05:28 PM
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
07-08-2014 05:28 PM
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
07-09-2014 10:16 AM
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.
07-09-2014 10:41 AM
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
07-09-2014 10:51 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide