Aug
10

In this blog post, we will obtain some good solid Tier 1 level knowledge regarding VLAN Access Control Lists or VACLs. These are often also referred to as VLAN Access Maps or just VLAN Maps; thanks to the syntax that is used in their creation.

When you want to filter traffic that is moving from one VLAN to another, things are real CCNA-like and friendly :-) We use an Access Control List. In fact, we should elaborate on that term a bit now in light of this discussion. We actually use a Router-based Access Control List or RACL.

But what if we want to filter traffic that is flowing within a VLAN? On no, a Router-based Access Control List cannot help us! This is when we turn to the VLAN Access Control List. To help us understand this feature, let us create a topology and a sample scenario. Here is the simple topology:

VACLs

Notice the Fast Ethernet interfaces of R1 and R2 are within the same VLAN (VLAN 10). So, based on the theory we have discussed, we will need a VACL if we want to filter the ability of R1 to communicate with R2. For this experiment, let us use Telnet. Before we begin, let me try Telnetting from R1 to R2. We want to ensure that works before we try and prevent that capability with a VACL.

R1#telnet 10.10.10.2
Trying 10.10.10.2 ... Open

User Access Verification

Password: 

R2>quit

[Connection to 10.10.10.2 closed by foreign host]
R1#

Excellent, there is everything we need in place to test a VACL now. Let us be very specific and create a VACL that denies the ability of R1 to Telnet to R2. Notice, we want to be very specific. Can R1 ping R2 when we are done? Sure! That is, if we configure all of this correctly.

I begin the scenario configuration with an Access Control List that will define the exact traffic we are interested in preventing. Notice I am using a permit Access Control List Entry (ACE) to specify the traffic, but I will end up denying it later on in the VACL structure.

SW2(config)#ip access-list extended ACL_TELNETR1_R2
SW2(config-ext-nacl)#permit tcp host 10.10.10.1 host 10.10.10.2 eq 23

Now that we have configured the identifying access list, it is time to configure the VACL. The first step is to create the VLAN Access Map, and then the second step is to apply it to the appropriate VLAN(s). Notice how these structures are eerily similar to Route Maps. Here is step one:

SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_STOPTELNET
SW2(config-access-map)#action forward
SW2(config-access-map)#exit

Notice that the ACL that matches on the Telnet has an action of DROP, then we match on all other traffic (implicitly), and we forward all of that. Forward is the default action, so I actually did not need the action forward commands, but I added them above to make it more clear for us to learn.

Now for the really easy part of this configuration. In step two, all I need to do is apply this “map” to the appropriate VLAN. That is our VLAN 10:

SW2(config)#vlan filter VACL_STOPTELNET vlan-list 10

Now it is time for verification. In our case it should be very simple to test. R1 should be able to ping R1, but Telnet should fail. First the ping:

R1#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!

That worked as expected. Now, drumroll please, it is time for the Telnet attempt. This is a time in the lab exam where you really hope for a failure:

R1#telnet 10.10.10.2
Trying 10.10.10.2 ...
% Connection timed out; remote host not responding

Superb!

Thank you so much for reading, and please, continue to enjoy your studies!


You can leave a response, or trackback from your own site.

30 Responses to “VLAN Access Control Lists (VACLs) Tier 1”

 
  1. Marcio Costa says:

    Hi, a question that I have about the VACL is action forward just forward the traffic but on switches 3550 and 3560 they donĀ“t have the action of capturing the traffic and redirect to a specific interface as we have on 6500 switches, Am I right ?

  2. Terry Vinson says:

    Thanks,

    That really makes things much clearer! I really appreciate these short subject topics, as do most of us I’m sure. I get as much out of them as any of the higher end video classes. It really demonstrates the value of the blog. It was worth wait. Thanks again!

    Terry

  3. John Spaulding says:

    Just did an advanced version of this last night :) Good to see a write up on it.

  4. Aung San Moe says:

    Hi,

    It is really great post and you really have a great talent to explain things in a simple way and help us to understand clearly. I am really looking forward more posts on this technology.

  5. Dennis says:

    Is it possible to use deny statements in ACLs?

  6. Michael N says:

    Concise and to the point. Very handy tutorial

  7. Omaredu says:

    Good example, easy and clear!

  8. Alexander says:

    Hello,
    Thanks for your post.
    I have some questions:
    as I understand SVI is not required on switches to be configured and VACL can be done on SW1 instead of SW2 with the same final result, do you agree? and also we need L3 switches to configure VACL.
    Thanks again,

    Alex

    • Hi Alexander!

      Yes – these switches in the scenario are in default configurations other than what you see in the topology. No SVI interfaces were created. Also – very good – SW1 could have been chosen as well.

      I never thought about it…but yes, I think you are right. I have never seen this capability on a Layer 2 switch. Notice I did not enable ip routing on these devices, however.

  9. Kiran says:

    Hi,

    Thanks for the post on VACL’s
    A quick question:
    What if R1 & R2 both are connected to SW1, and VACL is configured on SW2?
    Will the VACL work?

  10. Hi Kiran!

    Notice how the logic of what the list does comes from the access-list. So you could rewrite the access list and place the VACL on the other device.

  11. Nick G says:

    Just a heads up

    The following was a boo boo?

    “SW2(config-ext-nacl)#vlan access-map VACL_STOPTELNET”

    The VLAN access-map cannot be done from the config-ext-nacl prompt. At least not on the 3550 (I don’t have a 3560 to verify this second)but was the same on the 2950′s I have so I assume it’s the same on the 3560?

    Here I did it on my 3550 and was a no go:

    CAT1(config-ext-nacl)#vlan access
    CAT1(config-ext-nacl)#vlan ?
    % Unrecognized command
    CAT1(config-ext-nacl)#exit
    CAT1(config)#vlan access-map VACL_STOPTELNET
    CAT1(config-access-map)#

    The only reason I pointed it out as I was following along on my rack and then got the
    “% Unrecognized command” and freaked out thinking my switch wasn’t cool enough. But I was wrong!

    Other than that minor glitch (if I am right that is, hehe) good article was just going through the blueprint and this fit right in, great article!

    -Nick

  12. PrashantS says:

    Hi,

    Its is wonderful blog on vacls and cleared my concepts however, I have a doubt here.
    I have 2 hosts in same vlan on a same 2950 connected to a 3550 and the interface vlan provides L3 to the vlan on 2950.
    Will a VACL [IP or MAC] applied on the 3550 still be of any help.

    -Prashant

  13. Nilesh says:

    Hi,

    This artical is helpful for me.

    Thanks. Keep going

  14. Hahars says:

    Hi,

    I am studying for CCNP switch and currently looking over VACLs. Thanks for the great article.

    I have one question. On my C3550 i created a VACL, to stop icmp traffic from one host to another….but with no success

    here is my configuration….am i missing something here?

    Extended IP access list VACL_test
    10 permit ip host 192.168.1.6 host 192.168.1.7
    30 permit icmp host 192.168.1.7 host 192.168.1.6

    vlan access-map SIKC 1
    action drop
    match ip address VACL_test
    vlan access-map SIKC 2
    action forward
    !
    vlan filter SIKC vlan-list 30

    I am testing the ping from 192.168.1.7 to 192.168.1.6 (its working even with the VACL configured)

  15. Inder Vaid says:

    Hi,

    Amazing explanation, I just though about using this in a scenarios where 2 hosts are in same zone behind a Cisco ASA firewall whereby we cannot stop them from talking with each other but with VACL we can stop them to talk with each other on switch only.

    Thanks
    Inder

  16. mansouri says:

    that was best practise send us more

  17. Malkawi says:

    thanks, i have 1 questions really can’t stop thinkng about them.
    1- can we use just normal Extended Access List, if yes , so what is the advantage of using VACL over normal extended access list.

    2- can we use VACL to deny traffic between two hosts in different VLANs.

    best regards

  18. Bhavesh Kumar says:

    You have done a bit mistake……..

    Have a look on below VACL
    Just changed the map name from SIKC2 to SIKC1
    .
    .

    Extended IP access list VACL_test
    10 permit ip host 192.168.1.6 host 192.168.1.7
    30 permit icmp host 192.168.1.7 host 192.168.1.6

    vlan access-map SIKC 1
    action drop
    match ip address VACL_test
    vlan access-map SIKC 1
    action forward
    !
    vlan filter SIKC vlan-list 30

  19. Sai Lwin Thu says:

    that’s pretty good explanation too.

  20. soubbaya says:

    Good example.Easy to understand..Thanks buddy

  21. john says:

    Hi all,

    i’m facing the folowing issue naimly:
    user with IP 192.168.10.100, should be able to contact any user in the subnet 192.168.10.0/24 as well as telnet connection on 192.168.10.1

    Extended IP access list local-3
    10 permit ip host 192.168.10.100 192.168.10.0 0.0.0.255
    20 permit tcp host 192.168.10.100 192.168.10.0 0.0.0.255 eq telnet.

    after setting the following configuration, user is unable to set up a ping to any host in the vlan as well as no more able to make telnet.

    vlan access-map permit-vlan3 10
    action forward
    match ip address local-3
    vlan access-map permit-vlan3 20
    action drop

    vlan filter permit-vlan3 vlan-list 3

    The purpos is that: user in vlan 3 (192.168.10.0/24) should have access to the network and other not.

    please can you explain me how to realize it?

    thank and regards

    John

  22. smita says:

    for switchport capture .. we need to config on the same VACL configv switch or next switch.??? to get the vlan traffic capture

  23. ChrisFromBelgium says:

    make sure to add “vlan access-map VACL_STOPTELNET” after the drop or it will deny all other traffic:

    vlan access-map VACL_STOPTELNET
    action drop
    match ip address

    This will drop all traffic. Check with “sh vlan access-map”

    Vlan access-map “STOPTELNET” 10
    Match clauses:
    ip address: ACL_TELNETR1_R2
    Action:
    drop

    ==> as you can see, only a drop, nothing after that

    Action forward is indeed the default action, but only if you add an extra line (which will action forward by default):

    vlan access-map VACL_STOPTELNET
    action drop
    match ip address
    vlan access-map VACL_STOPTELNET #make sure to add this line

    this will allow all other traffic:

    sh vlan access-map ==> sequence number 20 was added

    Vlan access-map “STOPTELNET” 10
    Match clauses:
    ip address: ACL_TELNETR1_R2
    Action:
    drop
    Vlan access-map “STOPTELNET” 20
    Match clauses:
    Action:
    forward

    Confused me in the beginning so I thought it would be good to share this remark.

  24. Jegan Nath says:

    Why cant we do below configration in R2

    ip access-list extended 100
    deny tcp 10.10.10.1 0.0.0.0 10.10.10.2 0.0.0.0 eq 23
    permit ip any any

    and apply it in inbound of R2 fa 0/0

  25. Nima says:

    Thanks for the post,
    I’m wondering why do I need the VACL at all! Since in the middle switch, I am still able to use “ip access-group” on interfaces and use ACL. Is that correct?

 

Leave a Reply

Categories

CCIE Bloggers