Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users that connect and use a network service. RADIUS is the transport for AAA services. The services can include the user profiles including storing user credentials, user access policies, and user activity statistics which can reside on the same server. Gateway devices that control network access, such as remote access servers, VPN servers, and network switches, can use the RADIUS protocol to communicate with a RADIUS server for:
-
Authentication — verifying user credentials regarding granted access to their networks.
-
Authorization — verifying user access policy on how much and what kind of resources are allowed for an authenticated user.
-
Accounting — keeping statistic information about the user activities for accounting purpose.
The following information provides an overview about RADIUS services supported on a switch, including CoS (802.1p priority), ingress and egress rate-limiting, and ACL client services on a RADIUS server. For information on configuring client authentication capability on the switch, see RADIUS Authentication, Authorization, and Accounting.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: When no |
|
|
RADIUS services supported on the switch
| Service | Application | Standard RADIUS attribute[a] | HP vendor-specific RADIUS attribute (VSA) |
|---|---|---|---|
| Cos (Priority) | per-user | 59 | 40 |
| Ingress Rate-Limiting | per-user | — | 46 |
| Egress Rate-Limiting | per-port2[b] | — | 48 |
| ACLs | |||
| IPv6 and IPv4 ACEs(NAS-Filter-Rule) | per-user | 92 | 61 |
| NAS-Rules-IPv6 (sets IP mode to IPv4-only or IPv4 and IPv6) | per-user | — | 63 |
|
[a] HP recommends using theStandard RADIUS attribute if available. Where both a standard attribute and a VSA are available, the VSA is maintained for backwards compatibility with configurations based on earlier software releases. [b] If multiple clients are authenticated on a port where per-port rules are assigned by a RADIUS server, then the most recently assigned rule is applied to the traffic of all clients authenticated on the port. |
|||
All RADIUS-based services described here can be used without PCM+ or HP PMC IDM (Identity-Driven Management) support, if desired. For information on these services in the HP PCM+ application using the IDM plug-in, see the documentation for these applications on the HP Support web site.
The following information provides general guidelines for configuring RADIUS servers, so that the features listed in CoS and rate-limiting services can be dynamically applied on ports that support authenticated clients.
CoS and rate-limiting services
| Service | Control method and operating notes | ||||||
|---|---|---|---|---|---|---|---|
| 802.1p
Assigns a RADIUS-configured 802.1p priority to the inbound packets received from a specific client authenticated on a switch port.
|
Standard Attribute used in the RADIUS server: 59 (This is the preferred attribute for new or updated configurations.) Vendor-Specific Attribute used in the RADIUS server. (This attribute is maintained for legacy configurations.) HP vendor-specific ID:11 VSA: 40 Setting: User-Priority-Table=xxxxxxxx where: x=desired 802.1p priority Note: This is an eight-digit field. Enter the same x-value for all eight digits. Requires a port-access authentication method (802.1X, Web Auth, or MAC Auth) configured on the client's port on the switch. For more on 802.1p priority levels, see "Quality of Service (QoS)" in the Advanced Traffic Management Guide for your switch. |
||||||
|
Ingress (inbound) rate-limiting per-user Assigns a RADIUS-configured bandwidth limit to the inbound packets received from a specific client authenticated on a port.
|
Vendor-Specific Attribute used in the RADIUS server. HP vendor-specific ID:11 VSA: 46 Setting: HP-Bandwidth-Max-Egress=<bandwidth-in-Kbps> Note: RADIUS-assigned rate-limit bandwidths must be specified in Kbps. (Bandwidth percentage settings are not supported.) Using a VSA on a RADIUS server to specify a per-user rate-limit requires the actual Kbps to which you want to limit ingress (inbound) traffic volume. For example, to limit inbound traffic on a gigabit port to half of the port's bandwidth capacity requires a VSA setting of 500,000 Kbps. Requires a port-access authentication method (802.1X, Web Auth, or MAC Auth) configured on the client's port on the switch. The actual bandwidth available for ingress traffic from an authenticated client can be affected by the total bandwidth available on the client port. See Per-port bandwidth override. |
||||||
|
Egress (outbound) rate-limiting per-port Assigns a RADIUS-configured bandwidth limit to the outbound traffic sent to a switch port. |
Vendor-Specific Attribute used in the RADIUS server. HP vendor-specific ID:11 VSA: 48 (string=HP) Setting: HP-RATE-LIMIT=<bandwidth-in-Kbps> Note: RADIUS-assigned rate-limit bandwidths must be specified in Kbps. (Bandwidth percentage settings are not supported.) Using a VSA on a RADIUS server to specify a per-port rate-limit requires the actual Kbps to which you want to limit outbound traffic volume. For example, to limit outbound traffic on a gigabit port to half of the port's bandwidth capacity requires a VSA setting of 500,000 Kbps. In instances where multiple, authenticated clients are using this feature on the same switch port, only one (per-port) rate limit is applied. In this case, the actual rate used is the rate assigned by the RADIUS server to the most recently authenticated client. This rate remains in effect as long as any authenticated client remains connected on the port. Requires a port-access authentication method (802.1X, Web Auth, or MAC Auth) configured on the client's port on the switch. The actual bandwidth available for egress traffic from an authenti-cated client can be affected by the total bandwidth available on the client port. See Per-port bandwidth override. |
To configure support for the services listed in CoS and rate-limiting services on a specific RADIUS server application, see the documentation provided with the RADIUS application.
Rate limits are applied incrementally on the HP switches, as determined by the RADIUS-applied rate. For any given bandwidth assignment, the switch applies the nearest rate increment that does not exceed the assigned value. The increments are in graduated steps, as described in RADIUS-assigned rate-limit increments.
RADIUS-assigned rate-limit increments
|
RADIUS-assigned bits-per-second rate limit |
Applied rate-limiting increment |
|---|---|
| 1 - 10,999,999 | 100 Kbps |
| 11,000,000 - 100,999,999 | 1 Mbps |
| 101,000,000 - 999,999,999 | 10 Mbps |
| 1,000,000,000 - 10 Gbps | 100 Mbps |
For example, some of the following RADIUS-assigned rates fall between their respective incremental values, resulting in applied rates lower than the RADIUS-assigned rates. However, others match their respective incremental values, resulting in no difference between the RADIUS-assigned rate limits and the applied rate limits.
Assigned and applied rate limits example
| RADIUS-assigned bandwidth (Kbps) | Applied increments | Applied rate limit (Kbps) | Difference/Kbps |
|---|---|---|---|
| 5,250 | 100 Kbps | 5,200 | 50 |
| 50,250 | 1 Mbps | 50,000 | 250 Kbps |
| 51,000 | 1 Mbps | 51,000 | 0 |
| 525,000 | 10 Mbps | 520,000 | 5,000 Kbps |
| 530,000 | 10 Mbps | 530,000 | 0 |
| 1,250,000 | 100 Mbps | 1,200,000 | 50,000 Kbps |
| 1,300,000 | 100 Mbps | 1,300,000 | 0 |
HP recommends that rate-limiting be configured either solely through RADIUS assignments or solely through static CLI configuration on the switch unless the potential for the override described below is specifically desired.
Beginning with software release K.14.01, RADIUS-assigned ingress rate-limits are applied to individual clients instead of to the client's port. But if you use the CLI to configure a per-port ingress rate-limit on the same port where an authenticated client receives a RADIUS-assigned ingress rate-limit, the client's assigned ingress limit can be reduced by the CLI-configured port ingress limit. This occurs if the port reaches its CLI-configured rate-limit maximum before the client reaches its RADIUS-assigned rate-limit maximum, thus denying the client its intended maximum.
The most recent RADIUS-assigned egress rate-limit specifies the maximum egress rate-limit for a port, even if the CLI has also been used to configure an egress rate limit on the port.
| Rate-limit assignment method | Rate-limit actions and restrictions | |
|---|---|---|
| Inbound |
CLI ingress rate-limit per-port
|
Determines the maximum ingress bandwidth available on the port, regardless of any RADIUS-assigned per-client rate-limits dynamically assigned to the same port. |
|
RADIUS ingress rate-limit per-client VSA 46 |
Each client is allowed the inbound bandwidth individually assigned to it by the RADIUS server, up to the port's physical capacity, unless the available bandwidth on the port has been reduced by a CLI-assigned per-port bandwidth limit. | |
| Outbound |
CLI egress rate-limit per-port
|
Determines the maximum egress bandwidth available on the port, unless there is also a RADIUS-assigned per-port rate limit on the port. |
|
RADIUS egress rate-limit per client VSA 48 |
The most recent client to authenticate determines the maximum egress bandwidth on the port for all outbound traffic, regardless of any CLI-assigned per-port outbound rate-limit. | |
For example, suppose the CLI is used to configure a gigabit port to have an ingress rate limit of 500,000 Kbps (50% of available bandwidth), and is receiving 450,000 Kbps of traffic from existing clients. If a RADIUS server then authenticates a new client with an ingress rate-limit of 100,000 Kbps, the maximum ingress rate limit actually available for the new client is 50,000 Kbps as long as the bandwidth usage by the other clients already on the port remains at 450,000 Kbps.
For more on static rate-limiting, see "Rate-Limiting" in the "Port Traffic Controls" in the Management and Configuration Guide for your switch.
A RADIUS-assigned ACL is configured on a RADIUS server and dynamically assigned by the server to filter IP traffic from a specific client after the client is authenticated by the server.
The information in this section describes how to apply RADIUS-assigned ACLs on the switch, and assumes a general understanding of ACL structure and operation. If you need information on ACL filtering criteria, design, and operation, see the following:
RADIUS-assigned ACLs enhance network and switch management access security and traffic control by permitting or denying authenticated client access to specific network resources and to the switch management interface. This includes preventing clients from using TCP or UDP applications, ICMP packet types, and IGMP (IPv4 only) if you do not want their access privileges to include these capabilities.
Beginning with software release K.14.01, the switch supports RADIUS-assigned ACLs for the following traffic applications:
-
Inbound IPv4 traffic only
-
Inbound IPv4 and IPv6 traffic
This feature is designed for use on the network edge to accept RADIUS-assigned ACLs for Layer-3 filtering of IP traffic entering the switch from authenticated clients. A given RADIUS-assigned ACL is identified by a unique user name/password pair or client MAC address, and applies only to IP traffic entering the switch from clients that authenticate with the required, unique credentials. The switch allows multiple RADIUS-assigned ACLs on a given port, up to the maximum number of authenticated clients allowed on the port. Also, a RADIUS-assigned ACL for a given client's traffic can be assigned regardless of whether other ACLs assigned to the same port are statically configured on the switch.
A RADIUS-assigned ACL filters IP traffic entering the switch from the client whose authentication caused the ACL assignment. Filter criteria is based on:
-
Destination address
-
IPv4 or IPv6 traffic type, such as TCP and UDP traffic
Implementing the feature requires:
-
RADIUS authentication using the 802.1X, web-based authentication, or MAC authentication available on the switch to provide client authentication services
-
Configuring one or more ACLs on a RADIUS server instead of the switch, and assigning each ACL to the user name/password pair or MAC address of the clients you want the ACLs to support
Using RADIUS to dynamically apply ACLs to clients on edge ports enables the switch to filter IP traffic coming from outside the network, thus removing unwanted IP traffic as soon as possible and helping to improve system performance. Also, applying RADIUS-assigned ACLs to the network edge is likely to be less complex than configuring static port and VLAN-based ACLs in the network core to filter unwanted IP traffic that could have been filtered at the edge.
|
|
|
|
|
NOTE: A RADIUS-assigned ACL filters inbound IP traffic on a given port from the client whose authentication triggered the ACL assignment to the port. A RADIUS-assigned ACL can be applied regardless of whether IP traffic on the port is already being filtered by other, static ACLs that are already assigned. Simultaneous ACL activity supported per-port lists the supported per-port ACL assignment capacity. ACLs enhance network security by blocking selected IP traffic, and can serve as one aspect of network security. However, because ACLs do not protect from malicious manipulation of data carried in IP packet transmissions, they should not be relied upon for a complete edge security solution. Depending on the ACL configuration in the RADIUS server, the ACLs described in this section filter either IPv4 traffic only or both IPv4 and IPv6 traffic. These ACLs do not filter non-IP traffic such as AppleTalk and IPX. |
|
|
Simultaneous ACL activity supported per-port[1]
| ACL type | Function | IPv4 | IPv6 |
|---|---|---|---|
| VACL | Static ACL assignment to filter inbound IP traffic on a specific VLAN. | 1 | 1 |
| Port ACL | Static ACL assignment to filter inbound IP traffic on a specific port. | 1 | 1 |
| RADIUS-assigned ACL | Dynamic ACL assignment to filter inbound IP traffic from a specific client on a given port. | 1-32[a] | 1-32[a] |
| RACL (IPv4 only) | static ACL assignment to filter routed IPv4 traffic entering or leaving the switch on a specific VLAN | 1 in 1 out | n/a |
| Connection-Rate ACL | Static ACL assignment for virus-throttling on a specific port, see Virus throttling (connection-rate filtering). | 1 | n/a |
|
[a] One per authenticated client, up to a maximum of 32 clients per-port for 802.1X, web-based authenticationentication, and MAC-Authentication methods combined. |
|||
ACLs enhance network security by blocking selected IP traffic, and can serve as one aspect of network security. However, because ACLs do not protect from malicious manipulation of data carried in IP packet transmissions, they should not be relied upon for a complete edge security solution.
Depending on the ACL configuration in the RADIUS server, the ACLs described in this section filter either IPv4 traffic only or both IPv4 and IPv6 traffic. These ACLs do not filter non-IP traffic such as AppleTalk and IPX.
Contrasting dynamic (RADIUS-assigned) and static ACLs highlights several key differences between the static ACLs configurable on switch VLANs and ports, and the dynamic ACLs that can be assigned by a RADIUS server to filter IP traffic from individual clients.
Contrasting dynamic (RADIUS-assigned) and static ACLs
| RADIUS-assigned ACLs | Static port and VLAN ACLs | ||||||
|---|---|---|---|---|---|---|---|
| Configured in client accounts on a RADIUS server. | Configured on switch ports and VLANs. | ||||||
| Designed for use on the edge of the network where filtering of IP traffic entering the switch from individual, authenticated clients is most important and where clients with differing access requirements are likely to use the same port. | Designed for use where the filtering needs focus on static configurations covering:
|
||||||
| Implementation requires client authentication. | Client authentication not a factor. | ||||||
| Identified by the credentials (user name/password pair or the MAC address) of the specific client the ACL is intended to service. | Identified by a number in the range of 1-199 or an alphanumeric name. | ||||||
| Supports dynamic assignment to filter only the IP traffic entering the switch from an authenticated client on the port to which the client is connected. (IPv6 traffic can be switched; IPv4 traffic can be routed or switched. For either IP traffic family, includes traffic having a DA on the switch itself.) | Supports static assignments to filter:
|
||||||
| When the authenticated client session ends, the switch removes the RADIUS-assigned ACL from the client port. | Remains statically assigned to the port or VLAN. | ||||||
|
Allows one RADIUS-assigned ACL per authenticated client on a port. (Each such ACL filters traffic from a different, authenticated client.)
|
Simultaneously supports all of the following static assignments affecting a given port:
|
||||||
| Supports IPv6 ACLs and IPv4 extended ACLs. “IPv6 Access Control Lists (ACLs)” in the IPv6 Configuration Guide for your switch. | Supports IPv6 ACLs and standard, extended, and connection-rate IPv4 ACLs, see Applying connection-rate ACLs. | ||||||
| A given RADIUS-assigned ACL operates on a port to filter only the IP traffic entering the switch from the authenticated client corresponding to that ACL, and does not filter IP traffic inbound from other authenticated clients. (The traffic source is not a configurable setting.) |
An RACL applied to inbound traffic on a VLAN filters routed IPv4 traffic entering the switch through a port on that VLAN, as well as any inbound traffic having a DA on the switch itself. An RACL can be applied to outbound IPv4 traffic on a VLAN to filters routed IPv4 traffic leaving the switch through a port on that VLAN (and includes routed IPv4 traffic generated by the switch itself). A VACL can be applied on a VLAN to filter either IPv4 or IPv6 traffic entering the switch through a port on that VLAN. A static port ACL can be applied on a port to filters either IPv4 or IPv6 traffic entering the switch through that port. |
||||||
| Requires client authentication by a RADIUS server configured to dynamically assign an ACL to a client on a switch port, based on client credentials. | No client authentication requirement. | ||||||
| ACEs allow a counter (cnt) option that causes a counter to increment when there is a packet match. |
Beginning with software release K.14.01, the show statistics command includes options for displaying the packet match count, see Monitoring static ACL performance. Also, ACEs allow a log option that generates a log message whenever there is a packet match with a "deny" ACE. |
A RADIUS-assigned ACL configured on a RADIUS server is identified and invoked by the unique credentials (user name/password pair or a client MAC address) of the specific client the ACL is intended to service. Where the user name/password pair is the selection criteria, the corresponding ACL can also be used for a group of clients that all require the same ACL policy and use the same user name/password pair. Where the client MAC address is the selection criteria, only the client having that MAC address can use the corresponding ACL. When a RADIUS server authenticates a client, it also assigns the ACL configured with that client's credentials to the client's port. The ACL then filters the client's inbound IP traffic and denies (drops) any such traffic that is not explicitly permitted by the ACL.
-
If the filter rule used for a RADIUS-based ACL is one of the options that specifies only IPv4 traffic, then the ACL implicitly denies any inbound IPv6 traffic from the authenticated client.
-
If the filter rule used for a RADIUS-based ACL is the option for specifying both IPv4 and IPv6 traffic, then the ACL filter both IP traffic types according to the ACEs included in the RADIUS-assigned ACL.
When the client session ends, the switch removes the RADIUS-assigned ACL from the client port.
When multiple clients supported by the same RADIUS server use the same credentials, they are all serviced by different instances of the same ACL. (The actual IP traffic inbound from any client on the switch carries a source MAC address unique to that client. The RADIUS-assigned ACL uses this MAC address to identify the traffic to be filtered.)
The switch allows simultaneous use of all supported ACL application types on an interface. Thus, a static ACL assigned to an interface filters authenticated client traffic, regardless of whether a RADIUS-assigned ACL is also filtering the client's traffic. For more information, see Multiple ACLs on an interface.
These steps suggest a process for using RADIUS-assigned ACLs to establish access policies for client IP traffic.
-
Determine the polices you want to enforce for authenticated client traffic inbound on the switch.
-
Plan ACLs to execute traffic policies:
-
Apply ACLs on a per-client basis where individual clients need different traffic policies or where each client must have a different user name/password pair or will authenticate using MAC authentication.
-
Apply ACLs on a client group basis where all clients in a given group can use the same traffic policy and the same user name/password pair.
-
-
Configure the ACLs on a RADIUS server accessible to the intended clients.
-
Configure the switch to use the desired RADIUS server and to support the desired client authentication scheme. Options include 802.1X, web-based authentication, or MAC authentication. (Note that the switch supports the option of simultaneously using 802.1X with either web-based or MAC authentication.)
-
Test client access on the network to ensure that your RADIUS-assigned ACL application is properly enforcing your policies.
For further information common to all IPv4 or IPv6 ACL applications, see the IPv4 Configuration Guide or IPv6 Configuration Guide for your switch.
Packet-filtering in an applied ACL is sequential, from the first ACE in the ACL to the implicit deny any any following the last explicit ACE. This operation is the same regardless of whether the ACL is applied dynamically from a RADIUS server or statically in the switch configuration.
|
|
|
![[CAUTION: ]](images/caution.gif) |
CAUTION: ACLs can enhance network security by blocking selected IP traffic, and can serve as one aspect of maintaining network security. However, because ACLs do not provide user or device authentication, or protection from malicious manipulation of data carried in IP packet transmissions, they should not be relied upon for a complete security solution. |
|
|
|
|
|
|
|
NOTE: If a RADIUS-assigned ACL permits an authenticated client's inbound IP packet, but the client port is also configured with a static port ACL and belongs to a VLAN for which there is an inbound, VLAN-based ACL configured on the switch, then the packet is also filtered by these other ACLs. If there is a match with a deny ACE in any of these ACLs, the switch drops the packet. |
|
|
-
Relating a client to a RADIUS-assigned ACL
A RADIUS-assigned ACL for a particular client must be configured in the RADIUS server under the authentication credentials the server should expect for that client. If the client must authenticate using 802.1X and web-based authentication, the user name/password pair forms the credential set. If authentication is through MAC Authentication, then the client MAC address forms the credential set. See Configuring an ACL in a RADIUS server.
-
Multiple clients using the same user name/password pair
Multiple clients using the same user name/password pair uses duplicate instances of the same ACL.
-
Limits for ACEs in RADIUS-assigned ACLs
The switch supports up to 80 characters in a single ACE. Exceeding this limit causes the related client authentication to fail.
-
Effect of other, statically configured ACLs
Suppose that port B1 belongs to VLAN "Y" and has a RADIUS-assigned ACL to filter inbound traffic from an authenticated client. Port B1 is also configured with IPv4 and IPv6 static port ACLs, and VLAN "Y" is statically configured with IPv4 and IPv6 VACLs.
-
IP traffic entering the switch on port B1 from the client and having a match with a
denyACE configured in any of the ACLs mentioned above is dropped. -
If an inbound RACL was also configured on VLAN "Y", then a
denymatch in the RACL would apply to any inbound, routed IPv4 traffic from the client (and to any inbound, switched traffic having a destination on the switch itself). -
If an outbound RACL was also configured on VLAN "Y", then any outbound, routed IPv4 traffic leaving the switch through the port B1 would be filtered by the outbound RACL.
-
The following information provides general guidelines for configuring a RADIUS server to specify RADIUS-assigned ACLs. It also provides an example configuration for a FreeRADIUS server application. To configure services on a specific RADIUS server application, see the documentation provided with that application.
|
|
|
|
|
NOTE: This application requires a RADIUS server having an IPv4 address. Clients can be dual-stack, IPv4-only or IPv6-only. |
|
|
A RADIUS-assigned ACL configuration in a RADIUS server includes the following elements:
-
Nas-Filter-Rule attributes — standard and vendor-specific
-
ACL configuration, entered in the server, and associated with specific user name/password or MAC address criteria, and comprised of ACEs entered in the server
A RADIUS-assigned ACL includes:
-
One or more explicit
permitanddenyACEs -
An implicit
deny in ip from any to anyACE automatically applied after the last operator-created ACE
Nas-Filter-Rule Attribute Options
| Service | Control method and operating notes | ||||||
|---|---|---|---|---|---|---|---|
|
ACLs Applied to Client Traffic Inbound to the Switch Assigns a RADIUS-configured ACL to filter inbound packets received from a specific client authenticated on a switch port. |
Standard Attribute: 92 Beginning with software release K.14.01, this is the preferred attribute for use in RADIUS-assigned ACLs to configure ACEs to filter IPv4 and IPv6 traffic. Entry for IPv4-Only ACE To Filter Client Traffic: Nas-filter-Rule="<permit or deny ACE> "(Standard Attribute 92)For example: Nas-filter-Rule=permit in tcp from any to any Entries for IPv4/IPv6 ACE To Filter Client Traffic:
For example: HP-Nas-Rules-IPv6=1 Nas-filter-Rule="permit in tcp from any to any"
|
||||||
|
Used with the Nas-filter-Rule attribute described above to provide IPv6 traffic-filtering capability in an ACE. |
HP-Nas-Rules-IPv6: 63 (Vendor-Specific Attribute) When using the standard attribute (92) described above in a RADIUS-assigned ACL to support both IPv4 and IPv6 traffic inbound from an authenticated client, one instance of this VSA must be included in the ACL. Note that this attribute supports either of the following IP modes for Nas-filter-Rule ACEs:
HP vendor-specific ID: 11 VSA: 63 (string=HP-Nas-Rules-IPv6)
2> Nas-filter-Rule "<permit or deny ACE> "
However, if you do not want both the IPv4 and IPv6 traffic of the selected type to go to their respective "any" destinations, then two ACEs with explicit destination addresses are needed. In this case, do one of the following:
For example, if you want to allow the IPv4 Telnet traffic from a client to go to any destination, but you want the IPv6 Telnet traffic from the same client to go only to a specific address or group of addresses, you must distinguish the separate destinations. This is done by using explicit addresses for the "any" destinations. For example: HP-Nas-Rules-IPv6=1 Nas-filter-Rule="deny in tcp from any to 0.0.0.0/0 23" Nas-filter-Rule="deny in tcp from any to fe80::b1 23" The above example sends IPv4 Telnet traffic to its "any" destination, but allows IPv6 Telnet traffic only to fe80::b1 23.To reverse this example, you would configure ACEs such as the following: HP-Nas-Rules-IPv6=1 Nas-filter-Rule="deny in tcp from any to 10.10.10.1 23" Nas-filter-Rule="deny in tcp from any to ::/0 23" In cases where you do not want the selected traffic type for either IPv4 or IPv6 to go to the "any" destination, you must use two ACEs to specify the destination addresses. For example: HP-Nas-Rules-IPv6=1 Nas-filter-Rule="deny in tcp from any to 10.10.10.1 23" Nas-filter-Rule="deny in tcp from any to fe80::23 23" To use the IPv6 VSA while allowing only IPv4 traffic to be filtered, you would use a configuration such as the following: HP-Nas-Rules-IPv6=2 Nas-filter-Rule="permit in tcp from any to any" |
||||||
|
IPv4-only ACLs applied to client traffic inbound to the switch Assigns a RADIUS-configured IPv4 ACL to filter inbound IPv4 packets received from a specific client authenticated on a switch port. |
HP-Nas-Filter-rule (Vendor-Specific Attribute): 61 This attribute is maintained for legacy purposes (for configurations predating software release K.14.01) to support ACEs in RADIUS-assigned ACLs capable of filtering only IPv4 traffic. However, for new or updated configurations (and any configurations supporting IPv6 traffic filtering) HP recommends using the Standard Attribute (92) described earlier in this table instead of the HP-Nas-filter-Rule attribute described here. HP vendor-specific ID: 11 VSA: 61 (string=HP-Nas-Filter-Rule Setting: HP-Nas-filter-Rule="<permit or deny ACE> "
|
The following information describes ACE syntax configuration options in a RADIUS server.
| ACE syntax (standard attribute-92) |
|
| IPv6 VSA for standard attribute |
[ For an example of how to apply this VSA, see Configuring a FreeRADIUS server to filter IPv4 and IPv6 traffic for a client with correct credentials.. |
| ACE syntax (legacy VSA-61) |
This command specifies the standard attribute for filtering inbound IPv4 traffic from an authenticated client. When used without the HP VSA option (below) for filtering inbound IPv6 traffic from the client, drops the IPv6 traffic. See also Nas-Filter-Rule Attribute Options. [ You use the HP VSA in an ACL intended to filter IPv6 traffic. Settings include:
This VSA must be present in an ACL where the Nas-filter-Rule= attribute is intended to filter inbound IPv6 traffic from an authenticated client. See also Nas-Filter-Rule Attribute Options. HP-Nas-filter-Rule= Legacy HP VSA for filtering inbound IPv4 traffic only from an authenticated client. Drops inbound IPv6 traffic from the client. See also Nas-Filter-Rule Attribute Options. Must be used to enclose and identify a complete permit or deny ACE syntax statement. For example: Nas-filter-Rule="deny in tcp from any to 0.0.0.0/0 23"
Specifies whether to forward or drop the identified IP traffic type from the authenticated client. (For information on explicitly permitting or denying all inbound IP traffic from an authenticated client, or for implicitly denying all such IP traffic not already permitted or denied, see Configuration notes.) in Required keyword specifying that the ACL applies only to the traffic inbound from the authenticated client.
Options for specifying the type of traffic to filter. ip Applies the ACE to all IP traffic from the authenticated client. ip-protocol-value This option applies the ACE to the type of IP traffic specified by either a protocol number or by tcp , udp ,icmp,or (for IPv4-only) igmp. The range of protocol numbers is 0-255. (Protocol numbers are defined in RFC 2780. For a complete listing, see "Protocol Registries" on the Web site of the Internet Assigned Numbers Authority at ( www.iana.com). Some examples of protocol numbers include: 1=ICMP 17=UDP 2=IGMP (IPv4 only) 41=IPv6 6=TCP from any Required keywords specifying the (authenticated) client source. (Note that a RADIUS-assigned ACL assigned to a port filters only the inbound traffic having a source MAC address that matches the MAC address of the client whose authentication invoked the ACL assignment.) to Required destination keyword. any
host <ipv4-addr> Specifies a single destination IPv4 address. <ipv4-addr/<mask> Specifies a series of contiguous destination addresses or all destination addresses in a subnet. The host <ipv6-addr> Specifies a single destination IPv6 address. Note: Filtering IPv6 traffic requires the Standard Attribute(Nas-Filter-Rule)with the HP-Nas-Rules-IPv6 VSA set to 1. See Nas-Filter-Rule Attribute Options.<ipv6-addr/<prefix> Specifies a series of contiguous destination addresses or all destination addresses in a subnet. The [ Optional TCP or UDP port specifier. Used when the ACE is intended to filter client TCP or UDP traffic with one or more specific TCP or UDP destination port numbers. You can specify port numbers as individual values and ranges. For example, the following ACE shows two ways to deny any UDP traffic from an authenticated client that has a DA of any address and a UDP destination port of 135, 137-139, or 445: deny in udp from any to any 135, 137-139, 445 deny in 17 from any to any 135, 137-139, 445 [ Optional ICMP type specifier. This can be either a keyword or an ICMP type number. For a listing of numbers and types, see ICMP type numbers and keywords. [ cnt ] Optional counter specifier for a RADIUS-assigned ACE. When used, the counter increments each time there is a "match" with the ACE. This option does not require that you configure the switch for RADIUS accounting. |
This option for ending a RADIUS-assigned ACL permits all of the client's inbound IPv4 and IPv6 traffic not previously permitted or denied.
Nas-filter-Rule += permit in ip from any to any HP-Nas-Rules-IPv6=1
See Nas-Filter-Rule Attribute Options for information on the above attributes.
Any of the following three options for ending a RADIUS-assigned ACL explicitly permit all of the client's inbound IPv4 traffic not previously permitted or denied. These options also deny any of the client's IPv6 traffic not previously permitted or denied.
(Using this attribute to permit IPv4 traffic from the client while denying any IPv6 traffic from the client assumes that
HP-Nas-Rules-IPv6=1does not exist elsewhere in the ACL. See Nas-Filter-Rule Attribute Options for more onHP-Nas-Rules-IPv6.)
Any of the following three options for ending a RADIUS-assigned ACL explicitly deny all of the client's inbound IPv4 and IPv6 traffic not previously permitted or denied.
For any packet being filtered by a RADIUS-assigned ACL, there is always a match. That is, any packet that does not have a match with an explicit permit or deny ACE in the list matches with the implicit deny any any ACE automatically included at the end of the ACL. That is, a RADIUS-assigned ACL includes an implicit deny in ip from any to any ACE at the end of the ACL to deny any IPv4 and IPv6 traffic not previously permitted or denied.
Currently active, RADIUS-based authentication sessions (including HP IDM client sessions) using RADIUS-assigned ACLs share internal switch resources with several other features. The switch provides ample resources for all features. However, if the internal resources do become fully subscribed, new RADIUS-based sessions using RADIUS-assigned ACLs cannot be authenticated until the necessary resources are released from other applications.
-
For information on determining the current resource availability and usage, see “Monitoring Resources" in the Management and Configuration Guide for your switch.
-
For a summary of ACL resource limits, see the topics covering scalability in the latest Management and Configuration Guide for your switch.
See the Event Log Message Reference Guide for information about Event Log messages.
-
An IPv6 ACE has been received on a port and either the
HP-Nas-Rules-IPv6attribute is missing orHP-Nas-Rules-IPv6=2is configured. See Nas-Filter-Rule Attribute Options for more on this attribute.