We have one L3 Cisco Switch and two servers on two seperate vlans, ip routing enabled. We want to prevent traffic between these servers with an ACL.
Simplified version of our setup:
interface vlan 10
ip address 192.168.10.1 255.255.255.0
interface vlan 20
ip address 192.168.20.1 255.255.255.0
ip access-group test20 out
ip access-list extended test20
deny ip any any
Hovewer with this ACL applied the traffic is still able to be routed between the vlans. This changes if we change the direction of the ACL to in but we want the traffic to be filtered outbound from the SVI of vlan 20.
The way you have it you should have no traffic flow to anywhere on vlan 20 . that effectively says block all traffic into vlan 20 not just from vlan 10 . so if its still routing I don't know why . Make sure your test ports are where you think they are and are in the correct vlans .
Yeah according to what we could gather from other forum threads it should work but does not.
We even tried to block any outgoing traffic on both SVI interfaces but the traffic was still able to flow. Changed from outgoing to in on one SVI and it the traffic was correctly blocked.
We are so confused right now could it be a bug that does not allow traffic to be filetered on outgoing from SVI?
I wonder if they are doing their testing by pinging from the switch to the server on vlan 20. Ping from the switch would not be affected by the access list because an outbound access list does not filter traffic generated by the switch. If they were testing from the server in vlan 10 I would certainly expect the access list to prevent that traffic. So perhaps we need some clarification from the original poster about how they are testing.
I do agree with Glen that the access list specifying deny any any seems a bit drastic. The original post says that what they want to achieve is to prevent traffic between two servers and this access list will prevent any transit traffic to vlan 20 from anywhere (other than from the switch itself).
The reason we have used "any" for example is to clarify it should affect all kind of traffic. We started with specifiing a lot of acl rules filtering out diffrent kinds of traffic between the servers but since that did not work we went with any traffic to simplify things. We do the testing by sending ping between two servers behind vlan 10 and 20 so no pings from the switch.
It appears the switch acl does not trigger filtering of traffic when its set to outbound but does so when its set to inbound.
Thank you for the additional information. In a test using deny any any does make sense. I am surprised that the testing was from server to server. In that case I would certainly expect the outbound access list to have filtered the traffic. If there is only a single layer 3 switch then it would seem that there is no possibility of an alternate path from server to server, which could have explained the behavior.
There is perhaps the possibility that there is some aspect of the switch configuration which might impact the operation of the access list. Perhaps if you could post a more complete configuration we might find something. And there is certainly the possibility that this is a bug. Is it feasible to try a different version of code on the switch and see if the behavior changes?
Thank you for posting the configuration of the switch. Can you also post the output of the commands show vlan and show arp?
Thank you for the output of the show commands. They do confirm that the VLANs have been created and are active. show arp shows the address for the PC in VLAN 20 but not for the PC in VLAN 10. I am guessing that you have been testing by sending traffic from PC 10 to PC 20. Can you verify that if PC 20 sends something to PC 10 that PC 10 will show up in the output of show arp?
Would you post the output of the commands show ip interface vlan10 and show ip interface vlan 20? Perhaps they might shed some light on this.
And perhaps it is time to ask what kind of switch this is and what version of software it is running.
We had briefly dissconected the client on vlan10. Today we are going to test another IOS from 12.2 to 15.2 more in depth but from our early tests it seems that it can have been a bug in the earlier version of IOS.