Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can't seem to get Vlan ACLs to work properly. I want to be able to get to servers on the 10.100.x.x network as well as the 10.200.x.x network when I'm connected through the VPN. But, I want to prevent the 10.100.x.x network from seeing 10.200.x.x

Currently, I have 2 Vlans:

interface Vlan111
 description "vlan 111" 
 ip address

interface Vlan222
 description "vlan 222"
 ip address
 ip access-group vlan222_acl in
 ip access-group vlan222_acl out

And I have 2 servers connected to each VLAN:

!--- the below port is connected to a windows machine with static ip address and gateway
interface FastEthernet0/4                            
 description server 1
 switchport access vlan 111
 switchport mode access

!--- the below port is connected to a windows machine with static ip address and gateway
interface FastEthernet0/5                            
 description server 2
 switchport access vlan 222
 switchport mode access

The problem is when I configure vlan222_acl.

Here is what I enter:

ip access-list extended vlan222_acl
 deny icmp

But here is what gets applied to the running config:

ip access-list extended vlan222_acl
 deny icmp
!--- the above line is not what I actually entered in the terminal, for some reason 
!--- the source and dest ip addresses are getting replaced with zeros

Because of the above line, everyone now is unable to ping the server at When I remove the line, ie no deny icmp then I can ping it again.

How can I restrict only 10.100.x.x from being able to ping 10.200.x.x?

Many thanks in advance for the help! G

share|improve this question

you need to reverse your netmasks...i.e., instead of use


ip access-list standard external_traffic

Additionally, you do understand that you need a router between VLAN'd subnets, right? (not trying to sound snotty, I'm just not sure of your experience level)

edit: Is there a reason you're using /24 subnets for address assignment, but /16's for your ACL?

My suggestion would be to toss out the ACL on 222, and put restrictions on the 111 subnet, since that's what you're actually wanting to restrict anyway.

ip access-list extended block-icmp
deny icmp
permit ip any any
interface vlan 111
 ip access-group block-icmp in
share|improve this answer
Thanks very much for your reply. I tried the following: deny icmp which seemed to effectively block the host from getting to, but it also ended up blocking everyone else from getting to it (same as my initial problem). I.E: I also tried pinging from a host on a different network (192.168.x.x), and before adding the above command, I was able to ping and get to 10.200.x.x, but after adding it, I'm no longer able to. – G Chuk Mar 15 '11 at 21:17
In all access-lists you need an allow rule at the end of the list if you want to access anything. By default a Cisco ACL is implicit deny. @Greeblesnort: The Cisco 3550 is layer 3 capable and can route between VLANs. – HampusLi Mar 16 '11 at 9:18
Unfortunately, this doesn't work either: what ends up happening is everyone gets blocked when I apply the deny rule, then everyone gets access again once I apply the permit any any command :S – G Chuk Mar 24 '11 at 20:29
@HampusLi - I should have known that, as I've got a 3550 floating around somewhere in my datacenter, even though it's only doing L2. – Greeblesnort Apr 11 '11 at 20:31

You have applied the ACL to VLAN 222 for both incoming and outgoing traffic and the ACLs are not stateful. This means that they won't allow return traffic by their own, you will have to add an implicit rule for that. So, in this case, you're blocking the return traffic.

One solution would be to add another rule for the return traffic on the same ACL but what I think would be best, is to have two different ACLs for incoming and outgoing traffic, if you really need them.

You can also try to use reflexive ACLs which is a good way to allow return traffic. Check here for more details:

Here are some additional tips that may help t-shooting.

  • show access-list NAME/NUMBER shows the number of hits for each rule show you can see which rules are matching and denying or allowing packets. This wouldn't help much in your case since you have the same ACL on both directions and you wouldn't know where it matched.

  • If you add log at the end of each rule (i.e. deny icmp log) the switch will log each match which the you can revies with show logging This is CPU intensive though so try not to leave it on for long, just for t-shooting.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.