SG300 ACLs

[josh16903]

Hi all,

Apologies in advance - this is a topic with a lot of related posts.  I have an sg300-20 in L3 mode and am just not seeing what I am missing creating ACLs.  Among others, I was looking at this post: https://community.cisco.com/t5/small-business-switches/sg300-acl-problem/td-p/1917210.

At this point I am not concerned with any other devices - just the switch with 2 hosts attached to respective VLANs.

Firmware: 1.4.10.06 (upgraded from 1.4.2.4).

Setup:

192.168.40.0/24 - VLAN40 (Restricted)  -- Port ge03

192.168.10.0/24 - VLAN10 (Unrestricted) -- Port ge09

For simplicity, I am binding to ports and specifying explicit host ips on each network.

Host 192.168.40.100 -> 192.168.10.100 - DENY

Host 192.168.10.100 -> 192.168.40.100/Anywhere - PERMIT

I understand ACLs apply to ingress packets - traffic INTO the port.  Created ACL:

switch#show access-list
Extended IP access list server-to-lan
deny ip host 192.168.40.100 host 192.168.10.100 ace-priority 20
permit ip any any ace-priority 40

And apply to ge09 (192.168.10.100).

It seems that the default DENY (or PERMIT), only, is honored.  That is, I can ssh between the 2 hosts all day long, ping opposite gw, etc..  If I change to a default DENY - I can't ssh in either direction, ping the gw, etc.

 I have gone through the web ui and the cli thinking perhaps there were some subtle differences.

Any direction is appreciated.

[Seb Rupik]

Hi there,

The ACL you have created should be applied INbound on ge3 not ge9. Or simply swap the host IP arounds and leave it applied to Ge3.

Traffic arriving INbound on Ge9 will always be sourced from 192.168.10.0/24 so will never match your ACL in its current configuration and placement.

cheers,

Seb.

[josh16903]

@Seb Rupik 

Thanks for taking the time to respond.  I am not sure I explained this correctly and I think your suggestion is the reverse?  I did give it a go but it blocked traffic all the same.

Distilling this further:

ge09  -->  ge03 ==  ALLOW

ge03  --> ge09  ==  DENY

Since ACLs are applied INbound I would expect that the DENY rules would be applied to each port where that traffic could end up.  So if ge03 generates the "bad" traffic that could hit any other port, then all ports - less ge03 - would need the ACL to tell them to drop ge03 packets.

ge09  --> ge03 (NO ACL)

ge03  --> ge09 (ACL BLOCKING ge03)

I am staying with physical switch port for consistency/simplicity.

Am I thinking about this correctly?

Thanks

[Deepak Kumar]

HI,

As this is extended ACL so it will check Source and Destination details and it must apply near to the source as much as possible.

switch#show access-list
Extended IP access list server-to-lan
deny ip host 192.168.40.100 host 192.168.10.100 ace-priority 20
permit ip any any ace-priority 40

As per this ACL configuration, it must apply on the port where 40.100 is connected and direction will be IN. 

[Seb Rupik]

Hello again,

To distil your ACL further, it is essentially saying don't let A talk to B, so it needs to be positioned on the switch where it will have an effect. Since source traffic A will be arriving on Ge3 (INbound) destined to B, then it is there that you need to place it.

Remember that when the return traffic arrives INbound on Ge9, the source will be B (now destined to A)

The real issue you are encountering here is the fact that the SG300 is not a stateful firewall, so no what where you place the ACL, reversed or not, it will have the effect of blocking either the initial traffic stream or the return traffic.

Put simply, it is not possible to block the traffic in one direction for a bi-directional traffic stream with stateless ACLs.

cheers,

Seb.

[josh16903]

Hi Seb,

Thanks again.  Apologies if I am coming off obtuse, but if return traffic is being blocked, wouldn't that mean that essentially ANY established connections crossing ACLs would be black and white - PERMIT and DENY - no matter the protocol?  Perhaps I am missing some fundamentals here and considering this too close to firewall rules.

Let me know what you think.  In the meantime, I will review the documentation again.

[Seb Rupik]

This is where the 'established' keyword comes into use on stateless ACLs. In your case you would create an ACL which permits 192.168.40.0 /24 communicating with 192.168.10.0 /24 only is the connection is established. If a host in 192.168.40.0 /24 tries to initiate a connection with 192.168.10.0 /24 it would be denied.

This implementation comes with two problems, first, the established keyword just checks that the ACK bit is set in the TCP header...this can obviously be spoofed. Secondly, this method can only work for TCP connections.

As for the SG300, it does not support the established keyword (I don't have one to test on, but the documentation I have read suggests that this is the case).

To police this traffic properly you really need to move the routing between these subnets onto a firewall.

Hope that makes sense :)

cheers,

Seb.

[Deepak Kumar]

Hi,

This is ACL and there is a very big difference between Firewall and ACL as ACL will block your return traffic until you will not apply "established" at the end of ACL and Cisco SMB switches are not supported to it.