Link Search Menu Expand Document

Access Lists Template

Use this page to create, modify, delete, and rename Access Control Lists (ACLs).

img

An ACL is a reusable MATCH criteria for filtering flows.

NOTE: All selected match criteria options are ANDed to form the final match specification. For example, if you select Application Group and Application, both specifications are used to determine how the policy is applied. Review the summary of your match criteria at the bottom of this dialog.

Click More Options and More User Profile Options to display more match criteria selections. The More User Profile Options displays match criteria for identity-based traffic monitoring (User MAC, User Name, User Device, User Group, and User Vlan). For more information on these options, see Aruba SD-WAN Identity-Based Traffic Management User Guide.

It is associated with an action, permit or deny. You can use the same ACL as the MATCH condition in more than one policy: Route, QoS, Optimization, or NAT.

  • An ACL consists of one or more ordered access control rules.

  • An ACL only becomes active when it is used in a policy.

  • Deny prevents further processing of the flow by that ACL, specifically. The appliance continues to the next entry in the policy.

  • Permit allows the matching traffic flow to proceed on to the policy entry’s associated SET actions. The default is permit.

  • When creating ACL rules, list deny statements first, and prioritize less restrictive rules ahead of more restrictive rules.

Priority

  • For ACL rules, you can set the priority to a value within the range 1 to 65535. When adding a rule, the priority is incremented by ten from the previous rule. You can change the priority, but this default behavior helps ensure that you can insert new rules without having to change subsequent priorities.

Match Criteria

  • To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

Source or Destination

  • An IP address can specify a subnet - for example: 10.10.10.0/24.

  • To allow any IP address, use 0.0.0.0/0.

  • Ports are available only for the protocols tcp, udp, and tcp/udp.

  • To allow any port, use 0.

Wildcard-based Prefix Matching Rules

  • Even when using a range or a wildcard, the IPv4 address must be specified in the 4-octet format, separated by the dot notation. For example, A.B.C.D.

  • Range is specified using a single dash. For example, 128-129.

  • Wildcard is specified as an asterisk (*).

  • Range and Wildcard can both be used in the same address, but an octet can only contain one or the other. For example, 10.136-137.*.64-95.

  • A wildcard can only be used to define an entire octet. For example, 10.13*.*.64-95 is not supported. Use 10.130-139.*.64-95 to specify this range.

  • The same rules apply to IPv6 addressing.

  • CIDR notation and (Range or Wildcard) are mutually exclusive in the same address. For example, 192.168.0.1-127/24 is not supported. Use either 192.168.0.0/24 or 192.168.0.1-127.

  • These prefix-matching rules apply to the following policies only: Route, QoS, Optimization, NAT, Security, and ACLs.


Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to HPE Aruba Networking EULA.

Open Source Code:

Hewlett Packard Enterprise Company
Attn: General Counsel
WW Corporate Headquarters
1701 E Mossy Oaks Rd Spring, TX 77389
United States of America