03-19-2023 09:17 PM
Hi there,
My device is CBS350-24FP-4G.
My topology:
VLAN 101 Application 172.30.101.0/24
VLAN 102 Staffs 172.30.102/24
VLAN 103 Bastion 172.30.103.0/24
I'm trying to create an extended ACL to allow a specific IP in VLAN 103 able to SSH to all IP in VLAN 101, others deny.
You can see on my attached image
But the ACL didn't work, when I chose "Default Action" to "Deny Any", my machine with IP 172.30.103.99 in VLAN 103 couldn't SSH to machine in VLAN 101. On other hand, "Permit Any" allows all VLAN to SSH to machine in VLAN 101.
Please help me to figure out what's wrong with my configuration.
Thank you!
Solved! Go to Solution.
03-20-2023 07:53 AM
I feel your pain. On those switches, the direction of service ACLs is always IN. Here’s what the manual says.
“When an ACL is bound to an interface, its ACE rules are applied to packets arriving at that interface.”
Note that those packets arrive from the VLAN you bind the ACL to so the source IP address in ACEs needs to be from the subnet of that VLAN. Therefore, your permit rule with source IP address of 172.30.103.99 should not be bound to the interface of VLAN101 (Subnet 172.30.101.0/24).
It is unfortunate that CISCO with their CBS series of switches follows the path of other small business switch manufactures providing too limited ACL rule set. I usually find workarounds to those limitation, but the end result is not pretty and is difficult to maintain. Since I’m also a server admin for my network, sometimes I just patch a hole using server firewalls.
03-20-2023 01:08 AM
Hello
@tunxt99 wrote:
I'm trying to create an extended ACL to allow a specific IP in VLAN 103 able to SSH to all IP in VLAN 101,
Try the following acl:
ip access-list extended VL103-SSH_Host
permit tcp host 172.30.103.99 any eq 22
deny tcp 172.30.102.0 0.0.0.255 any eq 22
deny tcp 172.30.103.0 0.0.0.255 any eq 22
permit ip any any
int vlan 101
ip access-group VL103-SSH_Host OUT
03-20-2023 02:25 AM - edited 03-20-2023 02:26 AM
Hello Paul,
Thank you for your response. My switch doesn't has command as you shown but I believe I did the same thing as yours. It's still not working as my expected.
03-20-2023 02:59 AM
Hello
looks like the service-acl is in the wrong direction relating to the access-list it is calling, try service-acl output if not change the acl to read the other away around
ip access-list extended VL103-SSH_Host
permit tcp any host 172.30.103.99 eq 22
deny tcp any host 172.30.102.0 0.0.0.255 eq 22
deny tcp any 172.30.103.0 0.0.0.255 eq 22
FYI -
SVI acl logic
IN = traffic originating from within the vlan
OUT = traffic originating outside the vlan
03-20-2023 03:03 AM
Hello Paul,
ACLs that apply to VLAN don't have option OUTPUT as you mentioned, only apply for PORT. Please help me. Thank you.
03-20-2023 07:53 AM
I feel your pain. On those switches, the direction of service ACLs is always IN. Here’s what the manual says.
“When an ACL is bound to an interface, its ACE rules are applied to packets arriving at that interface.”
Note that those packets arrive from the VLAN you bind the ACL to so the source IP address in ACEs needs to be from the subnet of that VLAN. Therefore, your permit rule with source IP address of 172.30.103.99 should not be bound to the interface of VLAN101 (Subnet 172.30.101.0/24).
It is unfortunate that CISCO with their CBS series of switches follows the path of other small business switch manufactures providing too limited ACL rule set. I usually find workarounds to those limitation, but the end result is not pretty and is difficult to maintain. Since I’m also a server admin for my network, sometimes I just patch a hole using server firewalls.
03-20-2023 07:37 PM
Hi Kris K,
Thank you so much for your sharing.
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