Block traffic between two vlans on a Cat3560C + Internet Access

[John Peterson]

Hi,

I have a Cisco C3560CG which is running C3560c405ex-UNIVERSALK9-M), Version 12.2(55)EX2.

The switch has vlan 1 and vlan 50 configured, vlan 50 should have access to a limited number of host in vlan 1.

The following acl has been applied on the inbound to vlan 50:

10 permit tcp 10.16.30.0 0.0.0.255 host 192.168.15.243 eq 137 138 139 445

20 permit udp 10.16.30.0 0.0.0.255 host 192.168.15.243 eq netbios-ns netbios-dgm netbios-ss 445

25 permit icmp 10.16.30.0 0.0.0.255 host 192.168.1.243

26 permit ip 10.16.30.0 0.0.0.255 host 10.16.30.254

30 permit ip 10.16.30.0 0.0.0.255 host 192.168.15.254

40 deny ip 10.16.30.0 0.0.0.255 192.168.15.0 0.0.0.255

50 permit udp any any eq bootps

60 permit udp any any eq bootpc

70 permit udp 10.16.30.0 0.0.0.255 any eq domain

80 permit tcp 10.16.30.0 0.0.0.255 any eq domain

90 permit tcp 10.16.30.0 0.0.0.255 any eq www

95 permit tcp 10.16.30.0 0.0.0.255 any eq 443

100 permit icmp 10.16.30.0 0.0.0.255 any

I sure the above would work, but for some reason some of the packet counter are not incrementing but the traffic is being blocked. But I would like to see the counter increament.

Also I have that I may beed to use VACL wouls this be the case?

Thanks

[John Peterson]

Hi Peter,

Thank you.

Following on this topic, Edison Ortiz mentioned that the acl counter will not increment, therefore will the packets always be filtered by the acl, even tho counter do not increase? Is this always/only the case with L3 switches or can it also incur in routers?

John.

[Peter Paluch]

Hi John,

Edison is spot on (he's always spot on!). If traffic filtering is performed using hardware acceleration (usually performed using a TCAM memory), as is common on Catalyst switches, the counters on ACL entries will not be increased but the filtering will still occur normally. To my best knowledge, all recent Catalyst switches, starting from 2950 and going up through 2960, 3550, 3560, 3750 up to 6500, perform traffic filtering in hardware and therefore, you should not expect the counters to increase. On these platforms, the only case when the counters really increase is the situation when the hardware acceleration was not used, and the filtering was performed by IOS software itself, consuming CPU resources.

On Cisco routers, the behavior is usually different, as routers do not use hardware acceleration for ACL functions (except for high-end routers such as 7600 and up). On routers, you can therefore expect the ACL counters to always increase.

One more comment - you have considered using the log option in your ACL entries on the switch. I strongly discourage you from doing that. The log keyword may actually have no effect, as the hardware-based filtering is performed without any involvement of the IOS and CPU (and logging packets is their job), or in worse case, it may actually force the ACL to be processed in software. Depending on the amount of traffic filtered by that ACL, it could overload your CPU, leading to all sorts of ill behavior (STP failures, inability to access the switch remotely, various other CPU-processed protocols and mechanisms failing, ...)

Best regards,

Peter

[John Peterson]

Hi Peter,

Thank you.

I used the log keyword more for reassurance that the acl is filtering packets, I guess I could do tests before hand but this proves difficult in an live environment.

From reading other posts I was informed that log would force the switch to use the software therefore incrementing the counters. This is something which I was only looking to use in the first instance and then remove. Strange thing is that some of the acl from the above have the counters incremented and other don't. Why would some acl be processed by software and others by hardware?

It this just a bug in the IOS?

[Peter Paluch]

Hi John,

According to the following document about Cat3560:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swacl.html#wp1725217

Because routing is done in hardware and logging is done in software, if a large number of packets match a permit or deny ACE containing a log keyword, the software might not be able to match the hardware processing rate, and not all packets will be logged.

I assume the same goes for incrementing the counters.

Best regards,

Peter

[John Peterson]

Hi,

From one of the above post you mentation that an accless-list always has an explict deny in the end. Today I tested a connection from a remote laptop which is connected to the L3 switch. I have a application which uses the internet on a port which I have not mention in the access list. But still this application is able to access the internet, the strange thing is when I add a deny ip any any at the end of the acl the application stops working??

Is there something which I'm missing?

Thank you.

[John Peterson]

Any advise would be much appreciated.

[Peter Paluch]

Hi John,

Can you please post the current complete configuration of your switch and precisely specify the following:

1. into which port of the switch is the laptop connected?
2. what are the exact addressing details of the traffic that was surprisingly permitted (i.e. source and destination IP address, transport protocol, source/destination port)?

I apologize for answering lately - I did not notice an additional question in this thread. I am sorry.

Best regards,

Peter

[John Peterson]

Hi Peter,

Thank you very much for reply, really apperciate it.

Sorry for the late reply.

The laptop is plugged in into vlan 15. From the access-list I should not be able to connected to the internet when using remote desktop or similar to logmein application.

Also when I add deny ip any any the application stop work, meaning the explicit deny is not functioning correctly.

Please find config attached.

Thank you.

[John Peterson]

Hi Peter,

I was wondering if you have an chance to look at the above?

Thanks

J.

[Peter Paluch]

Hello John,

I apologize - I missed the fact that you have responded. My sincere apologies.

From the access-list I should not be able to connected to the internet when using remote desktop

Why not? Your ACL contains the following entries:

  permit udp 10.16.30.0 0.0.0.255 any eq domain log

  permit tcp 10.16.30.0 0.0.0.255 any eq domain log

  permit tcp 10.16.30.0 0.0.0.255 any eq www log  

  permit tcp 10.16.30.0 0.0.0.255 any eq 443 log  

They exactly permit access to DNS, HTTP and HTTPS service for any station in the 10.16.30.0/24 network (VLAN15).

What do you exactly mean when you say "when using remote desktop"?

Also when I add deny ip any any the application stop work, meaning the explicit deny is not functioning correctly.

Interesting. This would depend on the placement of the deny ip any any entry... Are you sure you have added this entry at the end of the ACL and not at the beginning?

Nevertheless, I see you are still having the log keyword attached to each and every ACL entry. Please remove it. There may be an ill interaction with this keyword - I would like to continue debugging this issue with a configuration that is 100% supported.

Thank you - and once more, please apologize my late answer.

Best regards,

Peter

[John Peterson]

Hi Peter,

No need to apologize, any amount of your time is highly appreciated by me, therefore thank you.

I'm under the impression that the remote desktop 3rd party application used a part other than what I've defined.

I'm going to do a wireshark and examine the ports used.

Your comment on the log keyword, is this something which is not supported? Would this cause the packet to miss the acl or would it just slow the process down. I've placed this keyword so I could see the packets going through the acl. I understand the implication of the CPU using the lo keyword, but were not aware of any other.

From this thread I would like to ask a question which relates to the acl and its placement. As I've placed the acl in the inside direction of the vlan 15. If I were to connect anothor switch on a truck link, would I need to move the acl to the other switch ( as this is where the pc would connect to the switch) orcan I leave it in place were it currently is. The way I understand is, its the phyical entry of the switch and it does not matter if its a truck or access, would this be correct?

thanks

J

[Peter Paluch]

Hello John,

I'm under the impression that the remote desktop 3rd party application used a part other than what I've defined. 
I'm going to do a wireshark and examine the ports used.

I am not entirely getting you here. From where are you accessing the remote desktop, and where exactly does the remote desktop run? Does the machine accessed via remote desktop reside in the VLAN 15? I have troubles understanding where is the remote desktop client located, and where does the remote desktop server (i.e. the machine that you remotely access and from which you access the internet) reside.

Your comment on the log keyword, is this something which is not supported?

Let's just say that the log keyword is not supposed to be used in ACLs on multilayer switches. How exactly that turns out is always a matter of particular implementation and no one outside Cisco can tell you what will exactly happen. I want to be sure we are running a configuration that is not claimed to have any unrecommended or unsupported components.

As I've placed the acl in the inside direction of the vlan 15. If I were  to connect anothor switch on a truck link, would I need to move the acl  to the other switch ( as this is where the pc would connect to the  switch) orcan I leave it in place were it currently is. The way I  understand is, its the phyical entry of the switch and it does not  matter if its a truck or access, would this be correct?

The interface Vlan 15 onto which you have placed your ACL is the focal point of all traffic that is carried from VLAN15 into other VLANs and vice versa (if the switch performs inter-VLAN routing). Intra-VLAN communication on trunks is not controlled by the ACL placed on interface VLAN. So your question actually asks about something different than you think it is asking

Best regards,

Peter