A permit or deny policy for IPv4 traffic you want to filter can be based on source address alone, or on source address plus other factors.
Use a standard ACL when you need to permit or deny IPv4 traffic based on source address only. Standard ACLs are also useful when you need to quickly control a performance problem by limiting IPv4 traffic from a subnet, group of devices, or a single device. This can block all IPv4 traffic from the configured source, but does not hamper IPv4 traffic from other sources within the network.
A standard ACL uses an alphanumeric ID string or a numeric ID of 1 through 99. Specify a single host, a finite group of hosts, or any host.
Use an extended ACL when simple IPv4 source address restrictions do not provide the sufficient traffic selection criteria needed on an interface. Extended ACLs allow use of the following criteria:
-
source and destination IPv4 address combinations
-
IPv4 protocol options
Extended, named ACLs also offer an option to permit or deny IPv4 connections using TCP for applications such as Telnet, http, ftp, and others.
ACL filtering is applied to IPv4 traffic as follows:
|
On a VLAN configured with a VACL, inbound IP traffic, regardless of whether it is switched or routed. On a multinetted VLAN, this includes inbound IPv4 traffic from any subnet. |
|
|
On a port having an ACL assigned by a RADIUS server to filter an authenticated client's traffic, filters inbound IPv4 and IPv6 traffic from that client For information on RADIUS-assigned ACLs, see RADIUS Services Support on HP Switches. |
VACLs filter any IPv4 traffic entering the switch on a VLAN configured with the "VLAN" ACL option.
Syntax:
For example, in VACL filter application to IPv4 traffic entering the switch, you would assign a VACL to VLAN 2 to filter all inbound switched or routed IPv4 traffic received from clients on the 10.28.20.0 network. In this instance, routed traffic received on VLAN 2 from VLANs 1 or 3 would not be filtered by the VACL on VLAN 2.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: The switch allows one VACL assignment configured per VLAN. This is in addition to any other ACL applications assigned to the VLAN or to ports in the VLAN. |
|
|
An IPv4 static port ACL filters any IPv4 traffic inbound on the designated port, regardless of whether the traffic is switched or routed.
|
|
|
|
|
NOTE: IPv6 support is available for RADIUS-assigned port ACLs configured to filter inbound IPv4 and IPv6 traffic from an authenticated client. Also, the implicit deny in RADIUS-assigned ACLs applies to both IPv4 and IPv6 traffic inbound from the client. For information on enabling RADIUS-assigned ACLs, see RADIUS Services Support on HP Switches. |
|
|
Dynamic (RADIUS-assigned) port ACLs are configured on RADIUS servers and can be configured to filter IPv4 and IPv6 traffic inbound from clients authenticated by such servers.
User-Based 802.1X access control allows up to 32 individually authenticated clients on a given port. Port-Based access control does not set a client limit, and requires only one authenticated client to open a given port; it is recommended for applications where only one client at a time can connect to the port.
-
If you configure 802.1X user-based security on a port and the RADIUS response includes a RADIUS-assigned ACL for at least one authenticated client, then the RADIUS response for all other clients authenticated on the port must also include a RADIUS-assigned ACL. Inbound IP traffic on the port from a client that authenticates without receiving a RADIUS-assigned ACL will be dropped and the client will be de-authenticated.
-
Using 802.1X port-based security on a port where the RADIUS response to a client authenticating includes a RADIUS-assigned ACL, different results can occur, depending on whether any additional clients attempt to use the port and whether these other clients initiate an authentication attempt. This option is recommended for applications where only one client at a time can connect to the port, and not recommended for instances where multiple clients may access the same port at the same time. For more information, see 802.1X port-based access control.
-
An ACL configured on a RADIUS server to filter IPv4 traffic will also deny inbound IPv6 traffic from an authenticated client unless the ACL includes ACEs that permit the desired IPv6 traffic. The reverse is true for a dynamic ACL configured on RADIUS server to filter IPv6 traffic. (ACLs are based on the MAC address of the authenticating client.) See RADIUS Services Support on HP Switches.
-
To support authentication of IPv6 clients:
-
The VLAN to which the port belongs must be configured with an IPv6 address.
-
Connection to an IPv6-capable RADIUS server must be supported.
-
For 802.1X or MAC authentication methods, clients can authenticate regardless of their IP version (IPv4 or IPv6).
-
For the Web authentication method, clients must authenticate using IPv4. However, this does not prevent the client from using adual stack, or the port receiving a RADIUS-assigned ACL configured with ACEs to filter IPv6 traffic.
-
The RADIUS server must support IPv4 and have an IPv4 address. (RADIUS clients can be dual stack, IPv6 only, or IPv4 only.)
-
802.1X rules for client access apply to both IPv6 and IPv4 clients for RADIUS-assigned ACLs. See 802.1X user-based and port-based applications.
-
The switch allows multiple ACL applications on an interface (subject to internal resource availability). This means that a port belonging to a given VLAN "X" can simultaneously be subject to all of the following:
Per-interface multiple ACL assignments
On a given interface where multiple ACLs apply to the same traffic, a packet having a match with a deny ACE in any applicable ACL on the interface (including an implicit deny any) will be dropped.
For example, suppose the following is true:
-
Port A10 belongs to VLAN 100.
-
A static port ACL is configured on port A10.
-
A VACL is configured on VLAN 100.
An inbound, switched packet entering on port A10, with a destination on port A12, will be screened by the static port ACL and the VACL, regardless of a match with any permit or deny action. A match with a deny action (including an implicit deny) in either ACL will cause the switch to drop the packet. (If the packet has a match with explicit deny ACEs in multiple ACLs and the log option is included in these ACEs, then a separate log event will occur for each match.)
Connection-rate filtering can be configured along with one or more other ACL applications on the same interface. In this case, a connection-rate match for a filter action is carried out according to the configured policy, regardless of whether any other ACLs on the interface have a match for a deny action. Also, if a connection-rate filter permits (ignore action) a packet, it can still be denied by another ACL on the interface.
-
All ACEs in an ACL configured on the switch are automatically sequenced (numbered). For an existing ACL, entering an ACE without specifying a sequence number automatically places the ACE at the end of the list. Specifying a sequence number inserts the ACE into the list at the specified sequential location.
-
A source or destination IPv4 address and amask, together, can define a single host, a range of hosts, or all hosts.
-
Every ACL populated with one or more explicit ACEs includes an Implicit Deny as the last entry in the list. The switch applies this action to any packets that do not match other criteria in the ACL. For standard ACLs, the Implicit Deny is
deny any. For extended ACLs, it isdeny ip any any. -
In any ACL, you can apply an ACL log function to ACEs that have an explicit "deny" action. The logging occurs when there is a match on a "deny" ACE. The switch sends ACL logging output to Syslog, if configured, and, optionally, to a console session.
You can create ACLs for the switch configuration using either the CLI or a text editor. The text-editor method is recommended when you plan to create or modify an ACL that has more entries than you can easily enter or edit using the CLI alone.
-
Identify the ACL action to apply. As part of this step, determine the best points at which to apply specific ACL controls. For example, you can improve network performance by filtering unwanted IPv4 traffic at the edge of the network instead of in the core. Also, on the switch itself, you can improve performance by filtering unwanted IPv4 traffic where it is inbound to the switch instead of outbound.
Traffic source ACL application IPv4 or IPv6 traffic from a specific, authenticated client RADIUS-assigned ACL for inbound IP traffic from an authenticated client on a port[a] IPv4 traffic entering the switch on a specific port static port ACL (static-port assigned) for any inbound IPv4 traffic on a port from any source switched or routed IPv4 traffic entering the switch on a specific VLAN VACL (VLAN ACL) [a] For more on this option, see RADIUS Services Support on HP Switches, and also the documentation for your RADIUS server.
-
Identify the traffic types to filter.
(IPv4 only, unless the ACL is a RADIUS-assigned ACL, which supports IPv4 and IPv6 filtering.)
-
The SA and/or the DA of traffic you want to permit or deny. This can be a single host, a group of hosts, a subnet, or all hosts.
-
Any TCP traffic (only) for a specific TCP port or range of ports, including optional control of connection traffic based on whether the initial request should be allowed
-
All ICMP traffic or ICMP traffic of a specific type and code
-
Any of the above with specificprecedence and/or ToS settings
-
-
Design the ACLs for the control points (interfaces) selected. When using explicit "deny" ACEs, optionally use the VACL logging feature for notification that the switch is denying unwanted packets.
-
Assign the ACLs to the interfaces you want to filter, using the ACL application (static port ACL) appropriate for each assignment.