Wired Intelligent Edge

 View Only

  • 1.  Vlan Acl's

    Posted Jul 14, 2022 11:20 PM
    Looking to add some acl's to our switches. We have 2930's and just need an example to get started. Did some Googling and looking through discussions, but this group has helped me along the way with Aruba switches and thought I could get an example from the group. I have a couple vlan's. I figure Acl's will pretty much be the same, with a few changes. If I have for example, Vlan 5, 10.0.5.0/23. I don't want anything to be able to get to the systems on that vlan(computers, printers, etc.), except for our servers on vlan 10, 172.16.20.0/24(DHCP,DNS,AD, etc..). Each user also has an IP phone on an untagged vlan 12. There are some users that have their computer running through the ip phone, not on a separate drop. I want to do the same basic setup for all of our vlan's. Also, the acl's would be created on the core switches correct? Thank you in advance for your help.


  • 2.  RE: Vlan Acl's

    Posted Jul 15, 2022 04:23 AM
    Edited by DP-7f7ca3 Jul 15, 2022 05:32 AM
    Hi mg14,

    Yes ACL needs to ne deployed on the Routing Switch which owns the SVIs (Gateways) of involved VLANs. Supposing you're dealing with three VLANs (say VLAN id x, id y and id z tied to, respectively, Network Segment x, y and z with, respectively, SVI IP address x, y and z) then you should (it's not essential) build three ACLs, one for each VLAN, each ACL should be applied in the incoming direction as seen from the SVI (so each ACL would deal with incoming traffic leaving the VLAN - source - with any other possible destination, internally connected or not, as possible target).

    At least this is the way I build mines and I found building them quite simple once understood the flow direction's concept and following this approach.

    So - in my opinion - when you write "If I have for example, VLAN 5, 10.0.5.0/23. I don't want anything to be able to get to the systems on that VLAN (computers, printers, etc.), except for our servers on VLAN 10, 172.16.20.0/24(DHCP,DNS,AD, etc..)." you have to translate it into this sentence like: "Systems belonging to VLAN 5 shouldn't be able to communicate with anything outside VLAN 5 - including any external network like the Internet, I add (isn't it?) - they can only communicate with - starting communication to or responding to incoming messages coming from - VLAN 10 systems like DHCP Server, DNS Server...and so on." and the approach resolving this requirement will the one that help you to build the ACL protecting the VLAN 5 (or any other VLANs).

    Repeat & Rinse for VLAN 10 (and any other involved VLAN you want to protect) always remembering you should build your ACL skeleton seeing traffic incoming to the SVI of the particular VLAN you're building the ACL to.

    This just to start with.


  • 3.  RE: Vlan Acl's
    Best Answer

    Posted Jul 18, 2022 05:05 AM
    Just to close this loop...

    Try to configure an ACL called, say, "VLAN-5" (so it's pretty recognizable that that ACL is tied to the VLAN 5 and it should be applied to that specific VLAN only):

    ip access-list extended VLAN-5

    once inside the ACL "VLAN-5" context you can add/edit/delete necessary ACEs as per your requirements (YMMV).

    In your case you want that hosts belonging to VLAN 5 network segment 10.0.5.0 /23 will be able to communicate with all systems hosted into VLAN 10 network segment 172.16.20.0 /24 but, concurrently, you don't want that the formers be able to communicate with other locally connected network segments of your LAN (say VLAN 100, 200, 300, 400 or whatever else you have...) and you want instead that they are able to communicate with any other non-locally connected network (Internet, as example, via the Next Hop Gateway defined into your Default Route on the Core switch).

    Given that you should setup these ACEs (as example):

    ip access-list extended VLAN-5
10 remark "Permit VLAN 5 net to VLAN 10 172.16.20.0 /24 net (Internal Servers)"
10 permit ip 10.0.5.0 0.0.1.255 172.16.20 0.0.0.255
20 remark "Deny VLAN 5 net to VLAN 100 net"
20 deny ip 10.0.5.0 0.0.1.255 <VLAN-100-Net-Address> <VLAN-100-Net-Wildcard> log
30 remark "Deny VLAN 5 net to VLAN 200 net"
30 deny ip 10.0.5.0 0.0.1.255 <VLAN-200-Net-Address> <VLAN-200-Net-Wildcard> log
40 remark "Deny VLAN 5 net to VLAN 300 net"
40 deny ip 10.0.5.0 0.0.1.255 <VLAN-300-Net-Address> <VLAN-300-Net-Wildcard> log
50 remark "Deny VLAN 5 net to VLAN 400 net"
50 deny ip 10.0.5.0 0.0.1.255 <VLAN-400-Net-Address> <VLAN-400-Net-Wildcard> log
100 remark "Permit any/any before the final implicit Deny any/any"
100 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit

    Then you need to apply this ACL into the incoming direction on the VLAN 5 context with the command executed into the VLAN 5 context: 

    ip access-group "VLAN-5" in

    I generally add these two ACEs at very beginning to permit (from/to) ICMP ping in any case (be cautious because the fact an ICMP ping between hosts belonging to different networks works, doesn't necessarily mean that you have an ACE properly set to permit IP traffic between ICMP ping tested hosts).

     
    1 remark "Permit VLAN 5 net ICMP echo-reply to any destination"
1 permit icmp 10.0.5.0 0 0.0.1.255 0.0.0.0 255.255.255.255 0
2 remark "Permit VLAN 5 net ICMP echo to any destination"
2 permit icmp 10.0.5.0 0 0.0.1.255 0.0.0.0 255.255.255.255 8


    Once your ACL is ready (saved), you can resequence its ACEs' ids with the command:

    ip access-list resequence VLAN-5 100 10

    where the first value (100) is the desired first ACE's starting id and the second value (10) is the step's size between ACEs.

    Finally, remember always to save (write memory) and to check ACEs statistics with this command (example for your VLAN 5):

    show statistics aclv4 VLAN-5 vlan 5 in


    Original Message


Related Content