HP
From FreeRADIUS Wiki
Port authentication mechanisms
Web-Based
The switch provides a local captive portal for credential entry. When the user submits their credentials, a hash of the password is then written to the CHAP-Password attribute.
Mac-Based
When the switch receives a ethernet frame from a client which has not yet been authenticated, it copies the value of the ethernet SRC address field into the User-Name attribute of an Access-Request packet. The RADIUS server can then check the User-Name against a list of authorised Mac-Addresses.
Note: A hashed version of the SRC address is also inserted into the CHAP-Password attribute of Access-Request packets.
In normal operation the switch will attempt to authenticate the client every quiet-period (a configurable period measured in seconds). That is, when the client connects and either: The RADIUS server returns an Access-Reject, or the RADIUS server is Unreachable, the switch will retry authentication after quiet-period seconds.
Beware using guest VLANs with mac-based authentication and dynamic VLAN assignment
The quiet-period timer will not fire if an unauth-vid is configured and the client transitions into the 'guest' state. The ASG manual for some products suggests that if the client falls into the 'guest' state because of RADIUS server timeout then they will be re-authenticated, but this was not implemented in software!
Beware using the unauth-vid where switches rely on RADIUS servers for VLAN assignment. A RADIUS server failure or power outage could place all clients into the 'guest' state where they will not be able to recover without manual intervention.
802.1X
The switch port acts as an 802.1X authenticator, encapsulating/de-encapsulating EAP-Messages as required , and forwarding them between the supplicant and RADIUS server.
When a supplicant connects, the switch will send an EAP Identity-Request packet to the suppliant, to prompt an authentication attempt. Alternatively the supplicant can initiate authentication by sending an EAP Start packet to the switch.
As the switch is only acting as a pass-through, any EAP Method may be used, so long as the final EAP-Message is an EAP-Success or EAP-Failure.
Example Packet (Access-Request):
Framed-MTU = 1480
NAS-IP-Address = 192.168.0.1
NAS-Identifier = "hp-e-its-dev8021X-sw1"
User-Name = "user"
Service-Type = Framed-User
Framed-Protocol = PPP
NAS-Port = 2
NAS-Port-Type = Ethernet
NAS-Port-Id = "2"
Called-Station-Id = "00-14-38-fb-94-3e"
Calling-Station-Id = "00-18-8b-1f-ea-c3"
Connect-Info = "CONNECT Ethernet 100Mbps Full duplex"
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "700"
EAP-Message = 0x0201000a0175736572
Message-Authenticator = 0x5128a826dfedf51040215eb6fef398df
Port-Based Mode
Port based mode is used when the 'client-limit' parameter of the 802.1X authenticator is not set.
In port based mode if a single authentication attempt on the port is successful, the port is fully opened and all packets are allowed to ingress.
Note: This mode may not work correctly when used concurrently with another authentication method.
Client-Based Mode
Client based mode is a HP proprietary extension to the 802.1X standard, and is used when a 'client-limit' of 1 or more is configured for the 802.1X authenticator.
In client based mode a filtering table is maintained for each authenticated port. Only devices which have successfully completed 802.1X authentication have their Mac-Addresses added to the filtering table, so only packets from authenticated devices are allowed to ingress into the network. Multiple authentication sessions for different devices may run concurrently, and accounting information will be provided for each individual session.
In earlier firmware, Reply-Messages were encapsulated as EAP-Notification packets.
In firmware (< H.10.74 or equiv) the switch encapsulates the contents of the RADIUS Reply-Message attribute in an EAP-Notification packet, which it sends after the EAP-Success/Failure packet.
Most supplicants deal with this ok (despite it breaking RFC 3579), but it causes WPA_Supplicant to restart authentication. If you're using 802.1X with older firmware, be sure to filter out the Reply-Message attribute in any Access-Accept packets containing an EAP-Message.
ProCurve port authentication special features
Capability advertisements
Switches running K and W code may include one or more instances of the HP-Capability-Advert VSA (Vendor 11, Type 255) in Access-Requests. This attribute defines the capabilities of the NAS, listing all 'special' RADIUS attributes it supports. The format of HP-Capability-Advert values is loosely based around the RFC 2865 attribute encoding format with the length and value fields stripped and a version field added.
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| HP-Capability-Advert | 0+ | Capability advertisement | N/A | Binary encoding of attribute type |
Encoding - Standard attributes
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding - Vendor specific attributes
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dual Authentication
ProCurve switches (>=2600) can run 802.1X authentication concurrently with either Web-Based or Mac-Based authentication on the same port. Though Web-Based and Mac-Based authentication cannot be used together.
When multiple port-access mechanisms are used, 802.1X based authentication always takes priority. That is, if a device has already authenticated via Mac-Based/Web-Based authentication, and then successfully completes 802.1X authentication, any accounting sessions open for Mac/Web based authentication will be closed, and the PVID assignment will reflect the VLAN assigned by the 802.1X authenticator.
If an 802.1X authenticated client sends an EAPOL-Logoff packet, the 802.1X session is terminated and the client will be re-authenticated using Web/Mac based authentication.
Setting the unauth-vid for both 802.1X and Mac/Web authenticators will result in unexpected behavior.
This usually results in the client being assigned the port-access authenticator unauth-vid after completing Mac/Web auth. When you need to configure an unauth-vid with multiple authentication mechanisms, set the unauth-vid for the Mac/Web authenticator, not the 802.1X authenticator.
Note: Setting unath-vid for 802.1X when concurrent 802.1X/MAC authentication is enabled, is now prohibited in software versions >= H.10.79 or equivalent.
Open VLANs
- Unauthorised VLAN - If no port-access authentication mechanisms have managed to successfully authenticate the device, the unauth-vid will be set as the PVID. Although the port will be shown as closed, traffic will be able to flow to/from the connected device on this VLAN. The idea behind this feature is to allow administrators to disseminate resources to connecting users (Installation packages for 802.1X supplicants, instructions etc...), allowing them to configure their computer for the local network and complete authentication successfully.
- Authorised VLAN - If the client successfully completed authentication and no VLAN was specified by the RADIUS server, the auth-vid will be set as the PVID. If no VLAN was specified by the RADIUS server, and no auth-vid was set, the client is assigned to the untagged VLAN configured for the port.
Dynamic VLAN Assignment
When sending an Access-Accept packet the RADIUS server can specify which PVID should be assigned to the client. Most ProCurve switches that support dynamic VLAN assignment use the standard RFC3580 attributes, which allow the assignment of a single untagged VLAN. The latest 'K' series switches however, support RFC4675 and RFC3580 attributes, allowing full control over the tagged and untagged VLANs set on a port.
The recommended approach for configuring both tagged and untagged VLANs, is to configure the untagged ingress/egress VLAN using RFC 3580 attributes, and use RFC 4675 attributes for tagged VLANs.
RFC 3580 (single untagged VLAN) Assignment
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| Tunnel-Type | 1 | Type of tunnel | VLAN | 13 |
| Tunnel-Medium-Type | 1 | Tunnel transport medium | IEEE-802 | 6 |
| Tunnel-Private-Group-ID | 1 | Numeric ingress/egress VLAN ID to be assigned | - | <VLAN_ID> |
If the specified Tunnel-Private-Group-ID matches a VLAN present on the switch, the PVID of the port the client is connected to will be temporarily altered to reflect the assigned PVID. At the end of the session the port will revert back to its static PVID assignment.
On session termination, the ports VLAN membership will revert back to it's statically assigned untagged VLAN. If the specified Tunnel-Private-Group-ID does not much a configured or learned VLAN, authentication will fail.
RFC 4675 (multiple tagged/untagged VLAN) Assignment
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| Egress-VLANID | 1-* | Allow egress traffic for specified VID | - | <tagged/untagged(0x31|0x32)>000<VLAN_ID (as hex)> |
| Egress-VLAN-Name | 1-* | Allow egress traffic for specified VLAN Name | - | <tagged/untagged(1|2)><VLAN Name String> |
| Ingress-Filters | 1 | Drop ingress traffic for VIDs not enabled for egress | Enabled | 1 |
The value of Egress-VLANID is a bit string, the first 8 bits specify whether the VLAN is tagged or untagged and must be either 0x31 (tagged) or 0x32 (untagged). The next 12 bits are padding 0x000, and the final 12 bits are the VLAN ID as an integer value. For example the value to set VLAN 17 as a tagged egress VLAN would be 0x31000011.
Note: It is not possible to specify the ingress untagged VLAN with RFC 4675 attributes, so RFC 3580 attributes must be used instead.
Dynamic CoS (802.1p) Remapping
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| HP-COS | 1 | Assign 802.1p priority to all inbound packets on port | - | <CoS_0><CoS_1><CoS_2><CoS_3><CoS_4><CoS_5><CoS_6><Cos_7> |
The VSA 'HP-COS' or the RFC 4674 attribute 'User-Priority-Table' can be used to write an 802.1p CoS value into the 802.1Q header of all packets received on port-access authenticator enabled port. This attribute should contain the desired CoS priority (as a string) repeated 8 times. The reason for the repetition is that this attribute is meant to form a map to translate different COS priorities in packets egressing on the port. Unfortunately this feature has not yet been implemented in hardware, so whatever value is used for the first (left most) byte is applied for all priorities.
If the packet ingresses into the switch from the client on an untagged VLAN, the priority assigned to CoS_0 will be used.
If the packet then egresses from the switch as a tagged VLAN, the switch will honour the CoS value and forward the packet with the CoS value written into the 802.1Q header.
If the packet egresses from the switch as an untagged VLAN, the switch will honour the CoS value, but forward the packet with no CoS value attached. This is because the CoS value can only be written to the 802.1Q header, which is stripped if the packet is forwarded untagged.
802.1p based QoS is enabled by default on ProCurve switches, and cannot be disabled (except on I & M F/W switches). The eight possible 802.1p priority values are aggregated into four port-based outbound queues, which are applied as the packet egresses from the switch.
| 802.1p Value | Traffic classification (recommended) | Outbound Queue | Queue priority |
|---|---|---|---|
| 1 | Background | 1 | Low |
| 2 | Spare | 1 | Low |
| 0 | Best Effort | 2 | Normal |
| 3 | Excellent Effort | 2 | Normal |
| 4 | Controlled Load | 3 | High |
| 5 | Video | 3 | High |
| 6 | Voice | 4 | Critical |
| 7 | Network Control | 4 | Critical |
Note: On K series the 8 802.1p priorities are not aggregated and map to 8 different queues
Note: HP-COS attribute is honoured by both the WMA by the 802.1X authenticator, although the 'show port-access mac-based' in some branches does not show the override.
Note: There is no way to write a CodePoint value to the DiffServ/ToS field of IPv4 packets using dynamic assignment. HP-COS affects 802.1p priority only.
DHCP-Snooping and WMA/802.1X bridge
This feature is available on all platforms >=2600 series. When DHCP-Snooping and WMA/802.1X are enabled concurrently the IP address of the client learned in by DHCP-Snooping is included in the Framed-IP-Address attribute of all Accounting-Request packets.
In the current implementation this introduces a delay of ~60 seconds between the client being authenticated and the first Accounting Start packet being sent.
Unfortunately there is no method to disable this bridging feature so if reliable accounting times are required it is recommended not to enable DHCP-Snooping.
| Radius Attribute | Times included | Description | Value String | Value |
|---|---|---|---|---|
| Framed-IP-Address | 1 | IP Address learned via DHCP-Snooping | - | <ip_oct1>.<ip_oct2>.<ip_oct3>.<ip_oct4> |
Note: The Acct-Delay-Time attribute included in Accounting-Requests is not properly incremented, so accounting times really will be off by ~60 seconds
GVRP and Dynamic VLAN assignment
In addition to being able to assign statically configured VLANs, GVRP learned VLANs are also available for dynamic assignment.
Default edge port GVRP settings are insecure, and may allow circumvention of network policy.
The default setting for the interface unknown-vlan option is learn, this allows GVRP enabled clients to gain access to additional tagged VLANs once the port is in an open state. This is often undesirable from a security standpoint, so the unknown-vlan option should be set to disable on all port-access authenticated edge ports.
Note: If a GVRP VLAN is no longer advertised to the switch, all clients assigned that VLAN will be forced to re-authenticate.
Enable the use of GVRP learned VLANs with dynamic VLAN assignment
conf aaa port-access gvrp-vlans int <port range> unknown-vlans disable exit
Administrative interface authentication
On most HP Procurve switches there are two levels of authorised access, ‘Operator’ access and ‘Manager’ access.
- Operator access allows the user to view most of the vital stats of the switch (using the show commands), but will not allow them to make any potentially dangerous changes (such as modify the configuration).
- Manager (enabled) access allows the user to perform any supported operation.
When a user attempts to authenticate, the users password is encrypted (using a shared secret between the NAS and RADIUS server) and sent in an access request packet as the User-Password attribute. The username is sent as the User-Name attribute, along with a desired Service-Type. Most ProCurve switches only support PAP for authentication on their management interfaces, though as of K.13.51, PEAP-MSCHAPv2 is supported as an authentication method for management on K branch switches.
Example (PAP Login):
User-Name = "user"
User-Password = "pasphrase"
NAS-IP-Address = 192.168.0.1
NAS-Identifier = "hp-e-its-dev8021X-sw1"
NAS-Port-Type = Virtual
Service-Type = NAS-Prompt-User
Example (PAP Enable):
User-Name = "user"
User-Password = "pasphrase"
NAS-IP-Address = 192.168.0.1
NAS-Identifier = "hp-e-its-dev8021X-sw1"
NAS-Port-Type = Virtual
Service-Type = Administrative-User
Typically the request Service-Type will be NAS-Prompt-User, however if the user either demotes themselves by exiting the administrative session, and tries to escalate themselves to manager; or logs in as an operator and tries to escalate to manager; the switch will send Administrative-User as the requested Service-Type.
The RADIUS server will then authenticate the user and respond with either an Access-Accept or Access-Reject packet. For authentication to succeed, Access-Accept packets must also contain a Service-Type attribute corresponding to the desired privilege level.
| Access Level | Description | Radius Attribute | Times used | Value String | Value |
|---|---|---|---|---|---|
| Operator | The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. | Service-Type | 1 | NAS-Prompt-User | 7 |
| Manager | The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. | Service-Type | 1 | Administrative-User | 6 |
| No Access/Access reject | - | Service-Type | 0 | - | - |
To deny access, either send an Access-Reject, or omit the Service-Type attribute.
ProCurve administrative interface authentication special features
Privilege-Mode
With all newer (>2600) ProCurve switches, the switch can be instructed to respect the Service-Type sent back from the RADIUS server. In older models an administrator would first authenticate to gain access to the switch, and then again when enabling administrative commands.
Note: The privilege-mode feature is not included in the 2500/6108 series.
Enable privilege-mode
conf aaa authentication login privilege-mode exit
Accounting command logging
With all newer (>2600) ProCurve switches, the switch can send all commands executed during a session to a RADIUS server in the form of Accounting-Request (Interim-Update) packets.
The command executed will be written to the HP-Command-String VSA.
Note: The account command logging feature is not included in the 2500/6108 series.
Example:
User-Name = "user" NAS-IP-Address = 192.168.0.1 NAS-Identifier = "hp-e-its-dev8021x-sw1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.0.2" Acct-Status-Type = Interim-Update Acct-Authentic = RADIUS Service-Type = NAS-Prompt-User HP-Command-String = "show system-information" Acct-Delay-Time = 0
Enable command logging
conf aaa accounting commands stop-only radius exit
RFC 3576 Change of Authorisation & Disconnect Message
RFC3576 operation is currently supported on all K and W branch switches. It is considered to be a 'premium' feature, so is unlikely to be backported, or included in lower end switch models.
A RADIUS request with a Code of either 40 (Disconnect Request) or 43 (CoA Request) is sent to UDP port 3799 (default) on the switch. This request must include attributes that identify the NAS, attributes that identify the session, and in the case of CoA, attributes that form the new authorisation profile. RFC 3576 also recommends that an Event-Timestamp attribute be present for replay protection purposes, and that there be a maximum (default) delta of 300 seconds between the NAS time and the Event-Timestamp attribute included in the request.
Note: HP switches will silently discard any CoA or DM requests that do not have a valid Event-Timestamp attribute, this behaviour may be disabled on a server by server basis (see below for example).
Session-identification attributes
All CoA/DM requests must contain at least one set of Session-Identification attributes.
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| User-Name | 1 | User-Name provided in Access-Accept, or used in Authentication | - | <user-name> |
| Acct-session-ID | 1 | Accounting session ID provided in Accounting-Requests | - | <session_id> |
| - | - | - | - | - |
| User-Name | 1 | User-Name provided in Access-Accept, or used in Authentication | - | <user-name> |
| Calling-Station-ID | 1 | Clients Mac-Address (hyphens must be used to delimit octets) | - | <oct1>-<oct2>-<oct3>-<oct4>-<oct5>-<oct6> |
| NAS-Port | 1 | Port on which the client is authenticated (use ifindex on modular switches) | - | <port> |
| - | - | - | - | - |
| User-Name | 1 | User-Name provided in Access-Accept, or used in Authentication | - | <user-name> |
| Calling-Station-ID | 1 | Clients Mac-Address (hyphens must be used to delimit octets) | - | <oct1>-<oct2>-<oct3>-<oct4>-<oct5>-<oct6> |
| NAS-Port-ID | 1 | Port on which the client is authenticated e.g. 1 or A1 (modular) | - | <port> |
If using Mac-Auth the User-Name attribute must match the User-Name provided in the Access-Request.
NAS-Identification attributes
All CoA/DM requests must contain at least one NAS-Identification attribute (NAS-IP-Address appears to be the only one supported so far).
| Radius Attribute | Times used | Description | Value String | Value |
|---|---|---|---|---|
| NAS-IP-Address | 1 | Source IP for RADIUS requests (sent from the switch) | - | <user-name> |
Authorisation attributes
At least one of these attribute/attribute sets must be present in the CoA request else the NAS will return a CoA-NAK (Missing-Attribute). No authorisation attributes may be present in the disconnect message else the NAS will return a DM-NAK (Unsupported-Attribute).
| Radius Attribute(s) | Times used | Description |
|---|---|---|
| Session-Timeout | 1 | Number of seconds between client re-authentication |
| Tunnel-Type=VLAN,Tunnel-Medium-Type,Tunnel-Private-Group-ID=<int> | 1 | PVID assignment/alteration |
| Egress-VLANID | 1+ | Tagged VLAN assignment (octets) |
| Egress-VLAN-Name | 1+ | Tagged VLAN assignment (string) |
| HP-Bandwidth-Max-Ingress | 1 | Percentage of port bandwidth allowed for ingress |
| HP-Bandwidth-Max-Egress | 1 | Percentage of port bandwidth allowed for engress |
| HP-NAS-Filter-Rule | 1+ | ACE (multiple attribtues form ACL) applied to client |
Note: ProCurve switches do not support reauthorization using the "Service-Type = Authorization-Only" AVP
Switch configuration
Add radius-server as CoA originator
conf
radius-server host <coa_originator_ip> key <coa_key>
radius-server host <coa_originator_ip> dyn-authorization
exit
Add dedicated CoA originator
conf
radius-server host <auth_server_ip> key <auth_key>
radius-server host <coa_originator_ip> key <coa_key>
radius-server host <coa_originator_ip> dyn-authorization
aaa server-group radius 'rad_auth' host <auth_server_ip>
aaa authentication port-access eap-radius server-group 'rad_auth'
# repeat for other authentication methods
aaa accounting network start-stop radius 'rad_auth'
# repeat for other accounting methods
exit
Disable Event-Timestamp check
conf
radius-server host <coa_originator_ip> time-window 0
exit
Radclient DM example
echo "NAS-IP-Address = 172.0.0.1,\ User-Name = 'example_user',\ NAS-Port = 1,\ Calling-Station-ID = '00-10-00-10-00-10'\ "| radclient 172.0.0.1:3799 40 testing123 Received response ID 114, code 41, length = 32 Event-Timestamp = "Sep 2 2018 10:26:40 PDT" Acct-Terminate-Cause = Admin-Reset
Radclient CoA example
This changes example_user's PVID to 2 and remaps all incoming 802.1p priorities to 7.
echo "User-Name = 'example_user',\ Acct-Session-ID = '000100006F",\ Tunnel-Type = VLAN,\ Tunnel-Medium-Type = IEEE-802,\ Tunnel-Private-Group-Id = '2',\ HP-COS = '7777777',\ "|radclient 172.0.0.1:3799 43 testing123 Received response ID 193, code 44, length = 26 Event-Timestamp = "Sep 2 2018 10:42:29 PDT"
Configuration - Wired switches
You must have manager access on the target switch and have entered configuration mode to run the following commands.
Most ProCurve wired switches >= 2600 series will support all or a subset of these commands.
Add servers
radius-server host <radius_server_ip1> auth-port 1812 acct-port 1813 radius-server host <radius_server_ip2> auth-port 1812 acct-port 1813
Set Server Parameters
radius-server key <radius_shared_secret>
Set general port-access Parameters
aaa authentication port-access eap-radius aaa port-access gvrp-vlans
Note: Enabling the use of GVRP vlans is optional.
Enable RADIUS Authentication on administrative interfaces
aaa authentication ssh login radius local aaa authentication ssh enable radius local aaa authentication console login radius local aaa authentication console enable radius local aaa authentication login privilege-mode
Enabling 802.1X/MAC dual authentication on selected ports (single client)
aaa port-access authenticator <port range> aaa port-access authenticator <port range> logoff-period 862400 aaa port-access authenticator <port range> quiet-period 30 aaa port-access authenticator <port range> client-limit 1 aaa port-access authenticator active aaa port-access mac-based <port range> aaa port-access mac-based <port range> logoff-period 862400 aaa port-access mac-based <port range> quiet-period 30 # This improves compatibility with devices that use WOL aaa port-access <port range> controlled-direction in
If dual authentication is used with different logoff-period timer values, timer behavior is unpredictable.
In older versions of K series firmware, and all other branches, the logoff-period timer for both 802.1X and WMA was implemented using a single H/W timer. If different values were used for the logoff-period timers in 802.1X and WMA, the timer would reflect the value set by the last authenticator to be initialised. For predictable behavior it is higly recommended that the same value be used for both, if either of the authenticator logoff-period timers are changed from their default of 300 seconds.
Note: The use of port-based 802.1X and WMA concurrently is not recommended, not well supported, and not allowed in recent versions of K branch software. It is recommended to set a 802.1X client limit of 1 or more when using concurrent authentication. This puts the port into client-based 802.1X mode.
Note: The default logoff-period is too low for embedded devices such as printers that may 'sleep' for long periods; if the value is not increased devices that enter a sleep/power-saving mode may become unreachable. It's recommended that devices using Mac-Auth also run a DHCP client, to ensure that they periodically wake up and send packets to the authenticating switch, thus keeping their session alive.
Note: For security reasons it's better to implement dual authentication with 802.1X and Mac-Auth instead of configuring an unauth-vid. This allows the RADIUS server ultimate control over whether data from a device is allowed to ingress onto the network.
Enable Accounting
aaa accounting exec start-stop radius aaa accounting network start-stop radius aaa accounting system start-stop radius aaa accounting update periodic 15
Configuration - WAP 530
You must have manager access on the target ap and have entered configuration mode to run the following commands.
Create WPA/WPA2 TKIP/AES 802.1X Authenticated WLAN
conf radio 1 wlan <wlan_index> ssid <desired_ssid> description "802.1X auth wpa/wpa2 tkip BSSID." security wpa-8021x wpa-allowed wpa-cipher-aes wpa-cipher-tkip wpa2-allowed radius primary key <radius_shared_secret> radius primary ip <radius_server_ip1> radius primary port 1812 radius secondary key <radius_shared_secret> radius secondary ip <radius_server_ip2> radius secondary port 1812 radius-accounting primary key <radius_shared_secret> radius-accounting primary ip <radius_server_ip1> radius-accounting primary port 1813 radius-accounting secondary key <radius_shared_secret> radius-accounting secondary ip <radius_server_ip2> radius-accounting secondary port 1813 enable exit enable exit exit
Known Issues
Always update to the latest version of firmware before attempting to establish 802.1X/WMA authenticated services on HP wired/wireless equipment. Seriously!
H (2626, 2650 and PWR varients) and other parallel HP firmware branches
Issues in F/W Revision H.10.67
- When both Mac-Based and EAP-Based authentication are used, and the Unauth-VID is configured for EAP-Based authentication, and the client fails EAP-Auth,and this is the first time a port is being used, the client will be assigned the Unauth-VID even if Mac-Auth succeeds. The work around is to only configure the Unauth-VID for Mac-Based authentication.
- If a Reply-Message attribute is included in the RADIUS Access-Accept packet, the switch will encapsulate this in an EAP-Notification message, and send it *after* the EAP-Success Message. This causes some supplicants (namely wpa_supplicant) to re-authenticate at regular intervals.
HP 530 Wireless Access points
Issues in F/W Revision 2.10
- Access points may fail to register 'Accounting Response' packets from the RADIUS server, and respond with an ICMP port unreachable message. With multiple access points under heavy load, this has the potential to overwhelm accounting servers and databases. Not Fixed in WA 2.15
- Access points may not respect VLAN assignment when performing MAC based authentication.
- Users may experience crashes and other seemingly random issues when using a config built on F/W 1.* with F/W 2.10. It's probably a good idea to rebuild the configuration manually on an AP running 2.10.