Wired Intelligent Edge

 View Only
last person joined: 4 hours ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

3810M switch access lists

This thread has been viewed 3 times
  • 1.  3810M switch access lists

    Posted Jun 23, 2020 02:42 PM

    I'm pretty new to Aruba switching, so I hope someone can help me out with this.

     

    I'm setting up a stack of two 3810M switches to act as a building router on our main campus. There are a couple of rooms in that building that will need to be isolated. We want them to have no access to internal networks but we want them to have Internet access.

     

    I've created the vlans and the access lists. I've applied the access lists and tested the restricted access. Everything works as intended. No problems!

     

    Where I'm struggling is that I also tried to build the access lists using defined "netdestination" entries in the switch.

     

    Example:

     

    netdestination "Internal_Nets"

       network 192.168.0.0 255.255.0.0 position 218

       network 172.16.0.0 255.240.0.0 position 219

       network 10.0.0.0 255.0.0.0 position 220

       exit

     

    This didn't work. I found no way to use a defined netdestination in the extended ACL.

     

    In Cisco, I created object groups then used those groups in creation of the ACL. Is there a similar method in Aruba? Or must we specify every individual network/host in the extended ACL.


    #3810


  • 2.  RE: 3810M switch access lists

    MVP GURU
    Posted Jun 24, 2020 03:08 PM

    Hi! are you so kind to show us the problematic Extended ACL where you tried to use the defined "Internal_Nets" net destination?



  • 3.  RE: 3810M switch access lists

    Posted Jun 24, 2020 04:11 PM

    That's the issue. I couldn't figure out how to incorporate the defined net destination into an extended ACL.

     

    The ACL I ended up using in my 3810 had no defined net destinations and the ACL works as intended.

     

    ip access-list extended "Room_102_ACL"

         10 deny ip xx.xx.xx.0 0.0.0.255 10.0.0.0 0.255.255.255

         20 deny ip xx.xx.xx.0 0.0.0.255 172.16.0.0 255.240.0.0

         30 deny ip xx.xx.xx.0 0.0.0.255 192.168.0.0 255.255.0.0

         40 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

       exit

     

    xx.xx.xx.0 represents the subnet defined for that classroom.

     

    I have to replicate this for multiple classrooms that need to be restricted. Using defined objects in Cisco makes it a little quicker/easier since you can reuse those defined objects in multiple ACLs.

     

    In Cisco, objects were defined as below:

     

    object-group ip address Internal_Nets
    10.0.0.0 255.0.0.0
    172.16.0.0 255.240.0.0
    192.168.0.0 255.255.0.0

     

    Then those objects are referenced in the ACL:

     

    ip access-list extended Restricted_Classroom
    deny ip any addrgroup Internal_Nets
    permit ip any any

     

    Just wondering if Aruba has a similar method/process.

     

     



  • 4.  RE: 3810M switch access lists

    MVP GURU
    Posted Jun 24, 2020 06:08 PM

    The syntax is a little bit different, looking here it would probably be as per your scenario:

     

    ip access-list extended "Room_102_ACL"
    10 deny ip <source-network> 0.0.0.255 alias-dst "Internal_Nets"
    40 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
    exit



  • 5.  RE: 3810M switch access lists

    Posted Jun 25, 2020 11:01 AM

     

    When I tried that, I found that starting the ACE with "deny ip" to block all ip traffic matching the rule prevents the use of the defined netdestination aliases.

     

    It seems that in order to use the aliases, you must define a "netservice" and reference it in the ACE:

    deny alias-src Room_102 alias-dst Internal_Nets alias-srvc <netservice>

     

    Creating the netservice requires use of a specific tcp or udp port or a specific IP protocol number. It doesn't appear possible to block all IP traffic while using defined netdestination aliases for source and/or destination within the ACE.

     

    So it doesn't seem possible to create an ACE like this one:

    deny ip <source-network> 0.0.0.255 alias-dst "Internal_Nets"