Comware

Β View Only
last person joined: 4 days ago 

Expand all | Collapse all

Multiple ACL

This thread has been viewed 41 times
  • 1.  Multiple ACL

    Posted Jun 17, 2022 09:29 AM
    Need to apply 2 separate ACL to VLAN interface

    I get this odd message:

    [HPE5900-SR1]int Vlan-interface 160
    [HPE5900-SR1-Vlan-interface160]packet-filter 3333 inbound
    Failed to apply ACL 3333 to the inbound direction of interface Vlan-interface160 on slot 1, 2, 3, 4.
    
    [HPE5900-SR1-Vlan-interface160]dis thi
    #
    interface Vlan-interface160
     ip address 10.10.160.254 255.255.255.0
     packet-filter filter route
     packet-filter 3160 inbound
     packet-filter 3333 inbound
     dhcp select relay
     dhcp relay information enable
     dhcp relay server-address 10.10.9.1
     dhcp relay server-address 10.10.9.25
    #
    return
    


    I do NOT want to have content of ACL 3333 inside ACL 3160
    It would make it unmanageable

    I can see that it indeed did not apply (even it shows in config)

    Seb




    ------------------------------
    spgsitsupport
    ------------------------------


  • 2.  RE: Multiple ACL

    EMPLOYEE
    Posted Jun 17, 2022 09:54 AM
    You can't apply multiple different ACLs of the same type to one Vlan-interface in one direction. Here is what the ACL Configuration Guide says - "To the same direction of an interface, you can apply a maximum of four ACLs: one IPv4 ACL, one IPv6 ACL, one Layer 2 ACL, and one user-defined ACL."

    ------------------------------
    Ivan Bondar
    ------------------------------



  • 3.  RE: Multiple ACL

    Posted Jun 20, 2022 05:26 AM
    So what are my options?

    How to be able to re-use the same block of ACL?

    Seb




  • 4.  RE: Multiple ACL

    EMPLOYEE
    Posted Jun 20, 2022 08:55 AM
    Not many. Actually I see only two options how you can achieve this:
     packet-filter 3160 inbound
     packet-filter 3333 inbound​

    1. You can create new ACL containing ACEs (rules) from both ACL 3160 and 3333 and then apply the newly created ACL. But I wouldn't call it "re-using the same block of ACL", it's more like re-using of same block of ACEs...

    2. Another option is to use QoS policy where you use ACL as traffic classifier and then attach the classifier to the behavior with 'filter deny' or 'filter permit' action, but it will require total re-arrangement of all ACLs and there is one major caveat in Comware when you use ACL in traffic classifier - when an ACL is used by a QoS policy for traffic classification, the action (permit or deny) in the ACL is ignored, and the actions in the associated traffic behavior are performed.

    It is totally different from what many people got used in other Network OSes. For example, you decide to drop incoming DNS traffic, but allow everything else. A 'normal' ACL that can be used as with the 'packet-filter' command on an interface will be like this:

    acl number 3333
     rule 10 deny udp destination-port eq 53
     rule 100 permit ip
    


    However, if you decide to configure something similar with QoS:

    acl number 3333
     rule 10 permit udp destination-port eq 53
     rule 100 deny ip any
    #
    traffic classifier DNS
     if-match acl 3333
    #
    traffic behavior BLOCK
     filtery deny
    #
    qos policy BLOCK_DNS
     classifier DNS behavior BLOCK
    #
    interface Vlan-interface160
     qos apply policy BLOCK_DNS inbound
    

    this will block all the traffic, because 'deny' in the rule 100 wont' be considered as 'skip, don't match', but will be ignored and the 'ip any' will be mapped to the behavior 'BLOCK' with 'filter deny' action , e.g. all the IP traffic will be dropped. In Comware you don't won't to match any traffic in a QoS classifier, just don't mention it. Don't try to exclude it with 'deny' clause, it won't work.

    So, if you understand all the limitations and specifics of this approach, you can create ACLs for QoS and then re-use these ACLs in different classifiers, re-use classifiers, use several classifier-behavior pairs in one QoS policy etc. For example, if we still insist on the previous scenario were we want to block all incoming DNS requests and allow the rest of the traffic, then this should work correctly:

    acl number 3333
     rule 10 permit udp destination-port eq 53
    #
    acl number 3999
     rule 10 permit ip any
    #
    traffic classifier DNS
     if-match acl 3333
    #
    traffic classifier ANY
     if-match acl 3999
    #
    traffic behavior BLOCK
     filtery deny
    #
    traffic behavior ALLOW
     filter permit
    #
    qos policy BLOCK_DNS_ALLOW_ANY
     classifier DNS behavior BLOCK
     classifier ANY behavior ALLOW
    #
    interface Vlan-interface160
     qos apply policy BLOCK_DNS_ALLOW_ANY inbound
    

    It won't be a problem to re-user classifiers 'DNS' and 'ANY', as well as both behaviors as parts of new QoS policy. Also you can re-user ACLs 3333 and 3999 in other classifiers. No restrictions on that. Just keep in mind that a QoS policy can be applied to multiple interfaces, but only one QoS policy can be applied in one direction (inbound or outbound) of an interface.





    ------------------------------
    Ivan Bondar
    ------------------------------



  • 5.  RE: Multiple ACL

    Posted Jun 20, 2022 10:25 AM
    It looks even more complicated then multiple copy/past ACLs

    And all this to simply block access to switch SSL/SSH site running on each & every configured IP (basically on every VLAN gateway interface)
    Just because Comware does not have an option to bind it to a specified IP (and nothing else)
    So I block access from every VLAN (one that does not have already different ACL applied - because none is needed, has only this ACL 3333 applied:)

    acl number 3333
    descritpion Webserver SSH access
     rule 33 deny tcp destination 10.10.21.254 0 destination-port eq 443
     rule 34 deny tcp destination 10.0.1.17 0 destination-port eq 443
     rule 35 deny tcp destination 10.10.20.254 0 destination-port eq 443
     rule 36 deny tcp destination 10.10.9.254 0 destination-port eq 443
     rule 37 deny tcp destination 10.10.23.254 0 destination-port eq 443
     rule 38 deny tcp destination 10.10.25.254 0 destination-port eq 443
     rule 39 deny tcp destination 10.10.26.254 0 destination-port eq 443
     rule 40 deny tcp destination 10.10.27.254 0 destination-port eq 443
     rule 41 deny tcp destination 10.10.28.254 0 destination-port eq 443
     rule 42 deny tcp destination 10.10.29.14 0 destination-port eq 443
     rule 43 deny tcp destination 10.10.30.254 0 destination-port eq 443
     rule 44 deny tcp destination 10.10.50.254 0 destination-port eq 443
     rule 45 deny tcp destination 10.10.51.254 0 destination-port eq 443
     rule 46 deny tcp destination 10.10.88.254 0 destination-port eq 443
     rule 47 deny tcp destination 10.10.101.254 0 destination-port eq 443
     rule 48 deny tcp destination 10.10.111.254 0 destination-port eq 443
     rule 49 deny tcp destination 10.10.123.254 0 destination-port eq 443
     rule 50 deny tcp destination 10.10.135.254 0 destination-port eq 443
     rule 51 deny tcp destination 10.10.143.254 0 destination-port eq 443
     rule 52 deny tcp destination 10.10.159.254 0 destination-port eq 443
     rule 53 deny tcp destination 10.10.160.254 0 destination-port eq 443
     rule 54 deny tcp destination 192.168.88.254 0 destination-port eq 443
    
     rule 55 deny tcp destination 10.10.21.254 0 destination-port eq 22
     rule 56 deny tcp destination 10.0.1.17 0 destination-port eq 22
     rule 57 deny tcp destination 10.10.20.254 0 destination-port eq 22
     rule 58 deny tcp destination 10.10.9.254 0 destination-port eq 22
     rule 59 deny tcp destination 10.10.23.254 0 destination-port eq 22
     rule 60 deny tcp destination 10.10.25.254 0 destination-port eq 22
     rule 61 deny tcp destination 10.10.26.254 0 destination-port eq 22
     rule 62 deny tcp destination 10.10.27.254 0 destination-port eq 22
     rule 63 deny tcp destination 10.10.28.254 0 destination-port eq 22
     rule 64 deny tcp destination 10.10.29.14 0 destination-port eq 22
     rule 65 deny tcp destination 10.10.30.254 0 destination-port eq 22
     rule 66 deny tcp destination 10.10.50.254 0 destination-port eq 22
     rule 67 deny tcp destination 10.10.51.254 0 destination-port eq 22
     rule 68 deny tcp destination 10.10.88.254 0 destination-port eq 22
     rule 69 deny tcp destination 10.10.101.254 0 destination-port eq 22
     rule 70 deny tcp destination 10.10.111.254 0 destination-port eq 22
     rule 71 deny tcp destination 10.10.123.254 0 destination-port eq 22
     rule 72 deny tcp destination 10.10.135.254 0 destination-port eq 22
     rule 73 deny tcp destination 10.10.143.254 0 destination-port eq 22
     rule 74 deny tcp destination 10.10.159.254 0 destination-port eq 22
     rule 75 deny tcp destination 10.10.160.254 0 destination-port eq 22
     rule 76 deny tcp destination 192.168.88.254 0 destination-port eq 22
     
     rule 77 deny tcp destination 172.25.3.254 0 destination-port eq 443
     rule 78 deny tcp destination 172.25.3.254 0 destination-port eq 22
    ​

    ------------------------------
    spgsitsupport
    ------------------------------


  • 6.  RE: Multiple ACL

    EMPLOYEE
    Posted Jun 20, 2022 11:59 AM
    Networking IS complicated. This is the way. πŸ˜„ In sake of discussion - could you demonstrate me a working configuration with many ACLs applied in 'inbound' direction on any competitive platform - Cisco, Arista, Juniper, Extreme etc? πŸ˜‰

    Ok, jokes aside, let's get back to your primary target - if just to restrict SSH and WEB access to the switch itself is what you want, there is absolutely no need to use interface-level ACLs. Instead just apply appropriate ACL on the management plane directly:

    system-view
    #
    ssh server acl {advanced-acl-number | basic-acl-number | mac-acl-number}

    For example, if you want to restrict SSH access to be possible just from one management station with IP address 1.1.1.1, then following configuration will work:

    system-view 
    #
    acl number 2001 
     rule permit source 1.1.1.1 0 
    #
    ssh server acl 2001

    Same for HTTP/S server (which is unsupported on this model, btw):

    system-view
    #
    ip http acl {advanced-acl-number | basic-acl-number | mac-acl-number}
    ip https acl {advanced-acl-number | basic-acl-number | mac-acl-number}


    As simple as that. And no need to apply ACL on every L3 interface.



    ------------------------------
    Ivan Bondar
    ------------------------------



  • 7.  RE: Multiple ACL

    Posted Jun 21, 2022 04:55 AM
    Well, I do not want to apply restriction to a single workstation.

    I want to apply restriction on WHICH IP the unit replies to https/ssh requests

    And anyway, I already have ACL in place for all the VLANs that need to be restricted/isolated, so this approach would also mean adding to existing (and not re-using the block)


    ------------------------------
    spgsitsupport
    ------------------------------



  • 8.  RE: Multiple ACL

    EMPLOYEE
    Posted Jun 21, 2022 05:33 AM
    Then why not using an advanced ACL where source is 'any', destination IP is that only IP were the switch accepts SSH/HTTP-S traffic and the destination TCP ports are 22 and 443?

    For example, if IP address of that only management switch interface were SSH and HTTPS should be accepted is 1.1.1.1, then this config should do it:

    acl number 3333
    descritpion Webserver SSH access
     rule 10 permit tcp destination 1.1.1.1 0 destination-port eq 443
     rule 20 permit tcp destination 1.1.1.1 0 destination-port eq 22
    #
    ssh server acl 3333
    ip https acl 3333
    
    ​


    ------------------------------
    Ivan Bondar
    ------------------------------



  • 9.  RE: Multiple ACL

    Posted Jun 21, 2022 06:01 AM
    Does not work on this switch/Comware version:

    [HPE5900-SR1]ip http acl ?
    INTEGER<2000-2999> ACL number

    Now I remember why I done it the way I have...

    ------------------------------
    spgsitsupport
    ------------------------------



  • 10.  RE: Multiple ACL

    EMPLOYEE
    Posted Jun 21, 2022 06:09 AM
    As I mentioned before, Web GUI is not really supported on 5900 model line. I know it works to some extent, but it is extremely limited and not very useful. And can contain bugs that will never be fixed. Also, 'ip http enable' and 'ip https enable' are not even listed by the official command reference guide, at least not by the latest 243x one. That is probably why that 'ip https acl' command being a deprecated one has not been improved to accept advanced ACLs. But 'ssh server acl' must support advanced ACLs.

    ------------------------------
    Ivan Bondar
    ------------------------------



  • 11.  RE: Multiple ACL

    Posted Jun 21, 2022 06:34 AM
    So I either do NOT run web server at all (which I do find handy sometimes) or restrict it as I currently do

    Hardly ideal either way

    In the end I have redone the per-VLAN ACLs to block access to switch https (only the ones that might have not been blocked by other rules existing already)

    So I am within the limit of one ACL per (VLAN) interface


    ------------------------------
    spgsitsupport
    ------------------------------