Catalyst 2960S ACL issue

[lorenzobexer]

Hi,

i have some problems using ACL and copying a backup from the switch to an scp server.

Firmware version is 15.0(2)SE2, but i have seen the same behaviour on 12.0

This is the configuration of access lists/vty

Standard IP access list ACL_VTY_IN

    5 permit 192.168.0.123 (4 matches)

    40 deny   any log

Standard IP access list ACL_VTY_OUT

    10 permit 192.168.0.123

    20 deny   any log

line vty 0 4

access-class ACL_VTY_IN in

access-class ACL_VTY_OUT out

exec-timeout 15 0

logging synchronous

login authentication xxxxxxxx

length 0

transport input ssh

transport output ssh

Now, when logging into the switch with ssh and trying to backup the configuration (copy running-config scp://user:pw@192.168.0.123/somefile), it seems that the INBOUND ACL is used, as its match counter is increasing.

How can this behaviour be explained? I assumed, the OUT ACL would be used for outgoing connections?

Regards,

Johannes

[Richard Burts]

I think it gets complex and gets subtle. It seems that we have quite different behaviors inbound and outbound. It becomes pretty clear that the access-class in ACL does need to permit the traffic since Johannes tells us that scp does not work if he removes that line from the ACL. And it does seem logical that if the router sees incoming traffic on TCP port 22 that it would evaluate that traffic with the access-class ACL.

The behavior outbound is different. Johannes tells us that scp works but that the line in the ACL outbound does not increment. That indicates that the router is not using the ACL to evaluate that traffic. Then the question becomes whether it is not incrementing because the router does not check traffic that originates from the router or is not incrementing because the router recognizes that it is not traffic originating from vty and therefore does not need to be checked.

It would not be difficult to set up a test of this. Perhaps Johannes can do this or perhaps you can do this. Use a router or switch. Do SSH to some other host (just to demonstrate that SSH does work). Then configure a standard ACL and do not have a permit for that host. Then configure under the vty access-class out. Then try the SSH to that host again. I predict that this time it will fail. Then add a statement to the ACL that does permit this host. Then I predict that SSH will work.

HTH

Rick

[lorenzobexer]

Hi,

sorry, i will be in a meeting all day, but i just made a short test.

The IN ACL counter is clearly incrementing, when i open an SCP session from the Switch to 192.168.0.123 (also tested with SSH, same behaviour)

I have never opened a connection originating from 192.168.0.123 to the switch. This wouldn't even be possible, because there is a firewall in between.

When i remove the IP 192.168.0.123 from the IN ACL, SSH/SCP to this IP does not work anymore.

Also, we have no other ACLs, that could be blocking outgoing L3 traffic.

BR

[Bilal Nawaz]

When you remove the permit statement you have an implicit deny which will deny any traffic attempting to use ssh and come inbound on the vty lines.

You should see the hit counter increment for the deny.

Hope this helps

Sent from Cisco Technical Support iPhone App

[Richard Burts]

Johannes

Am I correct in understanding that what you posted is a stripped down version of the ACLs and that there are other entries in the ACL that you did not show us?

Much of our discussion has focused on the behavior of the outbound ACL used with access-class out. And I believe that much of our explanation of why that is not incrementing is plausible. I believe that there is a simple explanation of why the ACL inbound does increment. SCP uses TCP port 22. So there are incoming packets to the switch on TCP port 22 which is the port for SSH. As the packet comes to the router the router is not aware of whether this is actually an SSH to the router vty or is scp, so it evaluates the packet with the ACL in. Only after the packet is permitted does the router examine the payload and discover that it is a file copy and not an SSH to the vty.

This also explains why scp does not work if you remove that line from the ACL.

HTH

Rick

[mfurnival]

Could this be related to my earlier comment that an ACL will not be applied to traffic originating from  the router but it will be applied to traffic transiting or hitting the router itself? So if you think about your SCP session - it will be sourced from the router and traffic leaving the router during the SCP session will not be affected by the ACL so no hits on the OUT ACL but the return traffic from the SCP server will hit the ACL so you will see increments in the IN ACL?