HP Unified Wired-WLAN Products Security Configuration Guide

HP Unified Wired-WLAN Products
Security Configuration Guide

HP 830 Unified Wired-WLAN PoE+ Switch Series
HP 850 Unified Wired-WLAN Appliance
HP 870 Unified Wired-WLAN Appliance
HP 11900/10500/7500 20G Unified Wired-WLAN Module
Part number: 5998-6511

Software version:
R3507P26 (HP 830 PoE+ Switch Series)
R2607P26 (HP 850 Appliance)
R2607P26 (HP 870 Appliance)
R2507P27 (HP 11900/10500/7500 20G Module)
Document version: 6W102-20140818
Legal and notice information

Copyright 2014 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP 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. HP shall not be liable for technical or editorial errors or omissions contained herein.
Contents
Security overview 1
Network security threats 1
Network security services 1
Network security technologies 1
Identity authentication 1
Access security 2
Data security 3
Firewall 3
Attack detection and protection 4
Additional security technologies 4
Configuring AAA 6
Overview 6
RADIUS 7
HWTACACS 12
LDAP 14
Domain-based user management 16
Protocols and standards 17
RADIUS attributes 17
FIPS compliance 20
AAA configuration considerations and task list 20
Configuring AAA schemes 22
Configuring local users 22
Configuring RADIUS schemes 27
Configuring HWTACACS schemes 39
Configuring LDAP schemes 45
Configuring AAA methods for ISP domains 49
Creating an ISP domain 50
Configuring ISP domain attributes 51
Configuring authentication methods for an ISP domain 52
Configuring authorization methods for an ISP domain 54
Configuring accounting methods for an ISP domain 56
Tearing down user connections 58
Configuring local EAP authentication 58
Configuration procedure 58
Configuring the local EAP authentication server 58
Configuring a NAS ID-VLAN binding 59
Specifying the device ID 60
Displaying and maintaining AAA 60
AAA configuration examples 60
HWTACACS authentication and authorization for Telnet users 61
Local authentication and HWTACACS authorization for Telnet users 62
LDAP authentication for Telnet users 64
Authentication and authorization for portal users by a RADIUS server 68
Authentication and authorization for 802.1X users by a RADIUS server 74
Local EAP authentication and authorization for 802.1X users 80
RADIUS offload for 802.1X users 82
Level switching authentication for Telnet users by an HWTACACS server 85
Local EAP authentication for 802.1X users by an LDAP server 88
i
Temporary access control of wireless users 90

Troubleshooting AAA 93
Troubleshooting RADIUS 93
Troubleshooting HWTACACS 94
Troubleshooting LDAP 94
802.1X overview 96
802.1X architecture 96
Controlled/uncontrolled port and port authorization status 96
802.1X-related protocols 97
Packet formats 98
EAP over RADIUS 99
Initiating 802.1X authentication 99
802.1X client as the initiator 99
Access device as the initiator 100
802.1X authentication procedures 100
Comparing EAP relay and EAP termination 101
EAP relay 101
EAP termination 103
Configuring 802.1X 105

HP implementation of 802.1X 105
Access control methods 105
802.1X stateful failover 105
Using 802.1X authentication with other features 105
Configuration prerequisites 107
802.1X configuration task list 108
Enabling EAP relay or EAP termination 108
Setting the port authorization state 109
Specifying an access control method 110
Setting the maximum number of concurrent 802.1X users on a port 110
Setting the maximum number of authentication request attempts 111
Setting the 802.1X authentication timeout timers 111
Configuring the online user handshake function 111
Configuration guidelines 112
Configuring the authentication trigger function 112
Specifying a mandatory authentication domain on a port 113
Configuring the quiet timer 114
Enabling the periodic online user re-authentication function 114
Configuring an 802.1X guest VLAN 115
Configuring an Auth-Fail VLAN 116
Specifying supported domain name delimiters 117
Configuring the accounting delay feature 118
Displaying and maintaining 802.1X 118
802.1X with ACL assignment configuration example 119
Network requirements 119
ii

Verifying the configuration 121
Configuring MAC authentication 123

Overview 123
User account policies 123
Authentication approaches 123
MAC authentication timers 124
Using MAC authentication with other features 124
VLAN assignment 124
ACL assignment 124
Guest VLAN 124
MAC-after-portal 125
Configuration task list 125
Basic configuration for MAC authentication 125
Configuring MAC authentication globally 126
Configuring MAC authentication on a port 126
Specifying a MAC authentication domain 127
Configuring a MAC authentication guest VLAN 127
Configuring the MAC-after-portal feature 128
Displaying and maintaining MAC authentication 129
MAC authentication configuration examples 129
Local MAC authentication configuration example 129
RADIUS-based MAC authentication configuration example 132
ACL assignment configuration example 134
Configuring portal authentication 138

Overview 138
Extended portal functions 138
Portal system components 138
Portal system using the local portal server 140
Portal authentication modes 141
Portal support for EAP 142
Layer 3 portal authentication process 142
MAC-based quick portal authentication 146
Portal stateful failover 147
Portal configuration task list 149
Specifying a portal server for Layer 3 portal authentication 150
Configuring the local portal server 151
Customizing authentication pages 151
Configuring the local portal server 154
Enabling Layer 3 portal authentication 155
Controlling access of portal users 156
Configuring a portal-free rule 156
Configuring a portal-forbidden rule 157
Configuring an authentication source subnet 157
Setting the maximum number of online portal users 158
Specifying a portal authentication domain 158
Configuring Layer 3 portal authentication to support Web proxy 159
Configuring RADIUS related attributes 160
Specifying the NAS ID value carried in a RADIUS request 160
Specifying NAS-Port-Type for an interface 160
Specifying the NAS-Port-ID for an interface 161
Specifying a NAS ID profile for an interface 161
iii
Specifying a source IP address for outgoing portal packets 162

Configuring MAC-based quick portal authentication 162
Configuring portal stateful failover 163
Associating an SSID and AP with a portal server and an authentication domain 165
Specifying an autoredirection URL for authenticated portal users 165
Configuring portal detection functions 166
Configuring online Layer 3 portal user detection 166
Configuring the portal server detection function 167
Configuring portal user information synchronization 168
Logging off portal users 169
Enabling forced logoff for user SSID switching 169
Enabling logging for portal packets 169
Specifying the parameters to be carried in the redirection URL 170
Enabling host identity check through DHCP snooping 170
Configuring mandatory webpage pushing 171
Displaying and maintaining portal 171
Portal configuration examples 172
Configuring direct portal authentication 173
Configuring re-DHCP portal authentication 177
Configuring direct portal authentication with extended functions 179
Configuring re-DHCP portal authentication with extended functions 180
Configuring portal stateful failover 183
Configuring portal server detection and portal user information synchronization 191
Configuring direct portal authentication using local portal server 197
Configuring portal stateful failover with local portal servers 199
Configuring MAC-based quick portal authentication 205
Troubleshooting portal 215
Inconsistent keys on the access device and the portal server 215
Incorrect server port number on the access device 215
Configuring port security 216

Overview 216
Port security features 216
Port security modes 216
Support for WLAN 219
Working with guest VLAN and Auth-Fail VLAN 220
Port security stateful failover 220
Enabling port security 221
Setting port security's limit on the number of MAC addresses on a port 221
Setting the port security mode 222
Configuring port security features 223
Configuring NTK 223
Configuring intrusion protection 223
Enabling port security traps 224
Configuring port security for WLAN ports 224
Setting the port security mode of a WLAN port 225
Enabling key negotiation 225
Configuring a PSK 226
Ignoring authorization information from the server 226
Configuring NAS ID profile for port security 226
Configuring port security stateful failover 227
Displaying and maintaining port security 228
Port security configuration examples 228
Configuring the userLoginWithOUI mode 228
iv
Configuring the userLoginSecureExt mode on a WLAN port 233

Configuring an 802.1X guest VLAN for a port security-enabled port 236
Configuring port security with guest VLAN and VLAN assignment 238
Configuring 802.1X stateful failover for port security 242
Troubleshooting port security 247
Cannot change port security mode when a user is online 247
Configuring a user profile 248

Overview 248
User profile configuration task list 248
Creating a user profile 248
Performing configurations in user profile view 249
Enabling a user profile 249
Displaying and maintaining user profile 249
Configuring password control 250

Overview 250
FIPS compliance 252
Password control configuration task list 253
Enabling password control 253
Setting global password control parameters 254
Setting user group password control parameters 255
Setting local user password control parameters 256
Setting super password control parameters 256
Setting a local user password in interactive mode 257
Displaying and maintaining password control 257
Password control configuration example 258
Managing public keys 261

Creating a local asymmetric key pair 262
Displaying or exporting the local host public key 262
Displaying and recording the host public key information 263
Displaying the host public key in a specific format and saving it to a file 263
Exporting the host public key in a specific format to a file 263
Destroying a local asymmetric key pair 264
Specifying the peer public key on the local device 264
Displaying public keys 265
Public key configuration examples 266
Manually specifying the peer public key on the local device 266
Importing a public key from a public key file 268
Configuring PKI 271

Overview 271
PKI terms 271
PKI architecture 272
PKI operation 273
PKI applications 273
PKI configuration task list 273
Configuring a PKI entity 274
Configuring a PKI domain 275
Requesting a certificate 276
Configuring automatic certificate request 276
Manually requesting a certificate 277
Obtaining certificates 278
Verifying PKI certificates 279
v
Verifying certificates with CRL checking 279

Verifying certificates without CRL checking 279
Destroying the local RSA key pair 280
Removing a certificate 280
Configuring a certificate access control policy 280
Displaying and maintaining PKI 281
PKI configuration examples 281
Certificate request from an RSA Keon CA server 282
Certificate request from a Windows 2003 CA server 285
Certificate access control policy configuration example 288
Troubleshooting PKI 290
Failed to obtain the CA certificate 290
Failed to request local certificates 290
Failed to obtain CRLs 291
Configuring SSH 292

Overview 292
How SSH works 292
SSH authentication 293
FIPS compliance 294
Configuring the device as an SSH server 294
SSH server configuration task list 294
Generating local DSA and RSA key pairs 295
Enabling the SSH server function 296
Enabling the SFTP server function 296
Configuring the user interfaces for SSH clients 296
Configuring a client's host public key 297
Configuring an SSH user 298
Setting the SSH management parameters 299
Configuring the device as an Stelnet client 300
Stelnet client configuration task list 300
Specifying a source IP address or source interface for SSH packets 300
Enabling and disabling first-time authentication 301
Establishing a connection to an Stelnet server 302
Configuring the device as an SFTP client 302
SFTP client configuration task list 303
Specifying a source IP address or source interface for SFTP packets 303
Establishing a connection to an SFTP server 303
Working with SFTP directories 304
Working with SFTP files 305
Displaying help information 305
Terminating the connection with the SFTP server 306
Configuring the device as an SCP client 306
SCP client configuration task list 306
Transferring files with an SCP server 307
Displaying and maintaining SSH 307
Stelnet configuration examples 308
Password authentication enabled Stelnet server configuration example 308
Publickey authentication enabled Stelnet server configuration example 312
Password authentication enabled Stelnet client configuration example 317
Publickey authentication enabled Stelnet client configuration example 319
SFTP configuration example 321
SCP configuration example 325
vi

Configuring SSL 327

Overview 327
SSL security mechanism 327
SSL protocol stack 327
Configuring an SSL server policy 328
Configuring an SSL client policy 330
Displaying SSL 331
SSL server policy configuration example 331
Troubleshooting SSL 333
SSL handshake failure 333
Configuring TCP attack protection 334

Overview 334
Enabling the SYN Cookie feature 334
Displaying TCP attack protection 335
Configuring ARP attack protection 336

Overview 336
ARP attack protection configuration task list 336
Configuring unresolvable IP attack protection 337
Configuring ARP source suppression 337
Enabling ARP blackhole routing 337
Displaying and maintaining ARP source suppression 338
Configuration example 338
Configuring ARP packet rate limit 339
Configuring source MAC-based ARP attack detection 339
Displaying and maintaining source MAC-based ARP attack detection 340
Source MAC-based ARP attack detection configuration example 340
Configuring ARP packet source MAC consistency check 342
Configuring ARP active acknowledgement 342
Configuring authorized ARP 342
Authorized ARP configuration example (on a DHCP server) 343
Authorized ARP configuration example (on a DHCP relay agent) 344
Configuring ARP detection 346
Configuring user validity check 346
Configuring ARP packet validity check 347
Configuring ARP restricted forwarding 348
Displaying and maintaining ARP detection 348
User validity check configuration example 348
User validity check and ARP packet validity check configuration example 351
Configuring ARP gateway protection 353
Configuring ARP filtering 355
Configuring IPsec 357

Overview 357
Basic concepts 357
IPsec stateful failover 360
Implementing ACL-based IPsec 361
Configuring an ACL 361
vii
Configuring an IPsec transform set 364

Configuring an IPsec policy 365
Applying an IPsec policy group to an interface 370
Configuring the IPsec anti-replay function 370
Enabling invalid SPI recovery 371
Configuring IPsec stateful failover 371
Displaying and maintaining IPsec 373
IPsec configuration examples 374
Configuration example for IPsec between AC and AP 374
IPsec stateful failover for LWAPP protection configuration example 374
Configuring IKE 384

Overview 384
IKE security mechanism 384
IKE operation 384
IKE functions 385
Relationship between IKE and IPsec 386
Configuration task list for IKE 386
Configuring a name for the local security gateway 387
Configuring an IKE proposal 387
Configuring an IKE peer 388
Setting keepalive timers 391
Setting the NAT keepalive timer 391
Configuring a DPD detector 391
Disabling next payload field checking 392
Displaying and maintaining IKE 392
IKE configuration examples 393
Troubleshooting IKE 393
Proposal mismatch 393
Failing to establish an IPsec tunnel 394
Configuring ALG 395

ALG process 395
Enabling ALG 397
ALG configuration examples 397
FTP ALG configuration example 397
SIP/H.323 ALG configuration example 398
NBT ALG configuration example 399
Configuring firewall 400

Overview 400
ACL based packet filter 400
ASPF 401
Configuring a packet-filter firewall 403
Packet-filter firewall configuration task list 403
Enabling the firewall function 403
Configuring the default filtering action of the firewall 403
Applying an ACL packet-filter firewall to an interface 404
Applying an ACL packet-filter firewall to a user profile 405
Displaying and maintaining a packet-filter firewall 405
Packet-filter firewall configuration example 405
Configuring an ASPF 407
ASPF configuration task list 407
Enabling the firewall function 407
Configuring an ASPF policy 407
viii
Applying an ASPF policy to an interface 408

Applying an ASPF policy to a user profile 408
Configuring port mapping 409
Displaying and maintaining ASPF 409
ASPF configuration example 409
Managing sessions 411

Overview 411
How session management works 411
Session management functions 411
Session management task list 412
Setting session aging time for different protocol states 412
Configuring session aging time for different application layer protocols 413
Enabling checksum verification 413
Specifying persistent sessions 414
Specifying the operating mode for session management 414
Configuring session logging 415
Enabling session logging 415
Setting session logging thresholds 415
Displaying and maintaining session management 416
Configuring Web filtering 417

Overview 417
URL address filtering 417
IP address-supported URL address filtering 417
URL parameter filtering 418
Java blocking 418
ActiveX blocking 419
Configuring Web filtering 419
Configuring URL address filtering 419
Configuring IP address-supported URL address filtering 419
Configuring URL parameter filtering 420
Configuring Java blocking 420
Configuring ActiveX blocking 421
Displaying and maintaining Web filtering 421
Web filtering configuration examples 421
URL address filtering configuration example 422
URL parameter filtering configuration example 423
Java blocking configuration example 425
Troubleshooting Web filtering 426
Failed to add filtering entry or suffix keyword due to upper limit 426
Invalid characters are present in the configured parameter 426
Invalid use of wildcard 427
Invalid blocking suffix 428
ACL configuration failed 428
Unable to access the HTTP server by IP address 428
Configuring user isolation 429

VLAN-based user isolation 429
SSID-based user isolation 430
Configuring VLAN-based user isolation 430
Configuring SSID-based user isolation 431
Displaying and maintaining user isolation 431
User isolation configuration example 431
ix
Configuring source IP address verification 433

Overview 433
Configuring source IP address verification 433
Displaying and maintaining source IP address verification 434
Source IP address verification configuration example 434
Source IPv4 address verification configuration example 435
Source IPv6 address verification configuration example (using DHCPv6 server) 436
Source IPv6 address verification configuration example (using ND) 438
Configuring FIPS 441

Overview 441
FIPS self-tests 441
Power-up self-tests 441
Conditional self-tests 442
Triggering self-tests 442
Configuration considerations 442
Enabling FIPS mode 443
Configuration changes in FIPS mode 443
Displaying and maintaining FIPS 443
FIPS configuration example 443
Verifying the configuration 445
Configuring protocol packet rate limit 446

Enabling protocol packet rate limit 446
Enabling per-protocol bandwidth limit 446
Configuring the threshold for per-protocol bandwidth limit 446
Configuring the threshold for per-flow bandwidth limit 447
Displaying and maintaining protocol packet rate limit 447
Support and other resources 448

Contacting HP 448
Subscription service 448
Related information 448
Documents 448
Websites 448
Conventions 449
Index 451
Security overview
Network security services provide solutions to solve or reduce security threats. Network security threats
are existing or potential threats to data confidentiality, data integrity, and data availability.
Network security threats
Information disclosureInformation is leaked to an unauthorized person or entity.
Data integrity damageData integrity is damaged by unauthorized modification or malicious

destruction.
Denial of serviceMakes information or other network resources unavailable to their intended

users.
Unauthorized usageResources are used by unauthorized persons or in unauthorized ways.
Network security services

A security service is implemented by one or more network security technologies. One technology
involves multiple services. The following are the most important security services:
Identity authenticationIdentifies users and determines if a user is valid. Typical methods include
AAA-based username plus password authentication, and PKI digital certificate-based
authentication.
Access securityPrevents unauthorized access and use of network resources by implementing

AAA-based identity authentication. Access security protocols such as 802.1X, MAC authentication,
and portal authentication work together with AAA to implement user identity authentication.
Data securityEncrypts and decrypts data during data transmission and storage. Typical
encryption mechanisms include symmetric encryption and asymmetric encryption, and their
common applications are IPsec, SSL, and SSH. IPsec secures IP communications. SSL and SSH
protect data transfer based on TCP.
FirewallA highly effective network security model to block unauthorized Internet access to a
protected network. Major firewall implementations are ACL based packet filter, ASPF, and ALG.
Network security technologies

Identity authentication
AAA
AAA provides a uniform framework for implementing network access management. It provides the
following security functions:
AuthenticationIdentifies network users and determines whether the user is valid.
AuthorizationGrants user rights and controls user access to resources and services. For example,
a user who has successfully logged in to the device can be granted read and print permissions to
the files on the device.
AccountingRecords all network service usage information, including the service type, start time,
and traffic. The accounting function provides information for charging and user behavior auditing.
AAA can be implemented through multiple protocols, such as RADIUS, HWTACACS, and LDAP, among
which RADIUS is used most often.
PKI
PKI is an asymmetric key infrastructure to encrypt and decrypt data for securing network services. PKI uses
digital certificates to distribute and employ public keys, and provides network communication and
e-commerce with security services such as user authentication, data confidentiality, and data integrity.
HP's PKI system provides digital certificate management for IPsec and SSL.
Access security
802.1X
802.1X is a port-based network access control protocol for securing wireless LANs (WLANs), and it has
also been widely used on Ethernet networks for access control. 802.1X controls network access by
authenticating the devices connected to 802.1X-enabled LAN ports.
MAC authentication
MAC authentication controls network access by authenticating source MAC addresses on a port. It does
not require client software and users do not need to enter a username and password for network access.
The device initiates a MAC authentication process when it detects an unknown source MAC address on
a MAC authentication enabled port. If the MAC address passes authentication, the user can access
authorized network resources.
Port security
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. It applies to networks that require different authentication methods for different users on
a port, such as a WLAN. Port security prevents unauthorized access to a network by checking the source
MAC address of inbound traffic and prevents access to unauthorized devices by checking the destination
MAC address of outbound traffic.
Portal authentication
Portal authentication, also called "Web authentication," controls user access at the access layer and
other data entrance that needs protection. It does not require client software to authenticate users. Users
only need to enter a username and a password on the webpage for authentication.
With portal authentication, an access device redirects all unauthenticated users to a webpage. All users
can access resources on the webpage without passing portal authentication. However, to access the
Internet, a user must pass portal authentication on the portal authentication page.
Data security
Managing public keys
Public key configuration enables you to manage the local asymmetric key pairs (for example, creating or
destroying a local asymmetric key pair, and displaying or exporting a local host public key), and
configure the peer host public keys on the local device.
IPsec and IKE

IPsec is a security framework for securing IP communications. It is a Layer 3 VPN technology used for
data encryption and data origin authentication.
IKE provides automatic negotiation security parameters for IPsec, simplifying the configuration and
maintenance of IPsec. Security parameters for IKE negotiation include authentication and encryption
algorithms, authentication and encryption keys, IP packet encapsulation modes (tunnel mode and
transport mode), and key lifetime.
SSL
SSL is a security protocol that provides communication security for TCP-based application layer protocols
by using the public key mechanism and digital certificates. SSL is independent of the application layer
protocol, and enables an application layer protocol to use an SSL-based secure connection. A common
application is HTTPSHTTP over SSL or HTTP Secure.
SSH
SSH is a network security protocol that provides secure remote login and file transfer over an insecure
network. Using encryption and authentication, SSH protects devices against attacks such as IP spoofing
and plaintext password interception.
Firewall
ACL based packet-filter
An ACL packet-filter implements IP packet specific filtering.
Before forwarding an IP packet, the device obtains the following header information:
Number of the upper layer protocol carried by the IP layer
Source address
Destination address
Source port number
Destination port number
The device compares the head information against the preset ACL rules and processes (discards or
forwards) the packet based on the comparison result.
ASPF
An ASPF implements status-based packet filtering, and provides the following functions:
Transport layer protocol inspection (generic TCP and UDP inspection)ASPF checks a TCP/UDP
packet's source and destination addresses and port numbers to determine whether to permit the
packet to pass through the firewall into the internal network.
Application layer protocol inspectionASPF checks application layer information for packets, such
as the protocol type and port number, and monitors the application layer protocol status for each
connection. ASPF maintains status information for each connection, and based on status
information, determines whether to permit a packet to pass through the firewall into the internal
network, thus defending the internal network against attacks.
ASPF also supports other security functions, such as port to application mapping, ICMP error message
inspection and first packet inspection for TCP connection.
At the border of a network, an ASPF can work in coordination with a packet-filter firewall to provide the
network with a security policy that is more comprehensive and better satisfies the actual needs.
ALG
ALG processes payload information for application layer packets.
Working with NAT, ALG implements address translation in packet payloads. Working with ASPF, ALG
implements data connection detection and application layer status checking.
Session management
Session management is a common feature designed to implement session-based services such as NAT
and ASPF. Session management tracks the connection status by inspecting the transport layer protocol
(TCP or UDP) information, and regards packet exchanges at transport layer as sessions, performing
unified status maintenance and management of all connections.
In actual applications, session management works together with ASPF to dynamically determine whether
a packet can pass the firewall and enter the internal network according to connection status, thus
preventing intrusion.
The session management function only implements connection status tracking. It does not block potential
attack packets.
Attack detection and protection

ARP attack protection
ARP provides no security mechanism and is vulnerable to network attacks. An attacker can exploit ARP
vulnerabilities to attack network devices. To protect the device against user and gateway spoofing
attacks and flood attacks, HP provides multiple ARP attack protection features. For information about
these features, see "Configuring ARP attack protection."
TCP attack protection

Attackers can attack the device during the process of TCP connection establishment. To prevent such
attacks, the device provides the SYN Cookie feature.
Web filtering
Web filtering can help devices prevent internal users from accessing unauthorized websites and block
Java applets and ActiveX objects from webpages to improve internal network security.
Additional security technologies

The device also provides additional network security technologies to implement a multifunctional and full
range of security protection for users.
User profile
A user profile provides a configuration template to save predefined configurations, such as a CAR policy
or a QoS policy. Different user profiles are applicable to different application scenarios.
The user profile works with PPPoE, 802.1X, MAC authentication, and portal authentication. It is capable
of restricting authenticated users' behaviors. After the authentication server verifies a user, it sends the
device the name of the user profile that is associated with the user.
Password control
Password control is a set of functions for enhancing the local password security. It controls user login
passwords, super passwords, and user login status based on predefined policies. Those policies include
minimum password length, minimum password update interval, password aging, and early notice on
pending password expiration.
Configuring AAA
Overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. It provides the following security functions:
AuthenticationIdentifies users and determines whether a user is valid.
AuthorizationGrants user rights and controls user access to resources and services. For example,
a user who has successfully logged in to the device can be granted read and print permissions to
the files on the device.
AccountingRecords all network service usage information, including service type, start time, and
traffic. It provides information required for accounting and allows for network security surveillance.
AAA typically uses a client/server model, as shown in Figure 1. The client runs on the network access
server (NAS), which is also called the access device. The server maintains user information centrally. In
an AAA network, the NAS is a server for users but a client for AAA servers.
Figure 1 AAA application scenario
Internet
Network
Remote user
NAS
RADIUS server
HWTACACS server
The NAS uses the authentication server to authenticate any user who tries to log in, use network resources,
or access other networks. The NAS transparently transmits authentication, authorization, and accounting
information between the user and the servers. The RADIUS and HWTACACS protocols define how a
NAS and a remote server exchange user information.
The network shown in Figure 1 includes a RADIUS server and an HWTACACS server. You can use
different servers to implement different security functions. For example, you can use the HWTACACS
server for authentication and authorization, and the RADIUS server for accounting.
You can implement any of the security functions provided by AAA as needed. For example, if your
company wants employees to be authenticated before they access specific resources, you would
configure an authentication server. If network usage information is needed, you would also configure an
accounting server.
AAA can be implemented through multiple protocols. The device supports RADIUS, HWTACACS, and
LDAP, and RADIUS is used most often.
6
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that
uses a client/server model. It can protect networks against unauthorized access and is often used in
network environments that require both high security and remote user access.
RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.
RADIUS was originally designed for dial-in user access. RADIUS has been extended to support
additional access methods, including Ethernet and ADSL. RADIUS provides access authentication,
authorization, and accounting services. The accounting function collects and records network resource
usage information.
Client/server model
RADIUS clients run on NASs located throughout the network. NASs pass user information to RADIUS
servers, and reject or accept user access requests depending on the responses from RADIUS servers.
The RADIUS server runs on the computer or workstation at the network center and maintains information
related to user authentication and network access. It receives connection requests, authenticates users,
and returns access control information (for example, rejecting or accepting the user access request) to the
clients.
The RADIUS server typically maintains the following databases: Users, Clients, and Dictionary, as shown
in Figure 2.
Figure 2 RADIUS server databases
RADIUS servers
Users
Clients
Dictionary
UsersStores user information, such as usernames, passwords, applied protocols, and IP

addresses.
ClientsStores information about RADIUS clients, such as shared keys and IP addresses.
DictionaryStores RADIUS protocol attributes and their values.
Security and authentication mechanisms

The RADIUS client and the RADIUS server use a shared key to authenticate RADIUS packets and encrypt
user passwords exchanged between them. For security, this key must be manually configured on the
client and the server.
RADIUS servers support multiple authentication protocols, including PPP PAP and CHAP. A RADIUS
server can also act as the client of another AAA server to provide authentication proxy services.
Basic RADIUS message exchange process

Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server.
Figure 3 Basic RADIUS message exchange process
RADIUS uses the following workflow:

1.
The host initiates a connection request that includes the user's username and password to the
RADIUS client.
2.
The RADIUS client sends an authentication request (Access-Request) to the RADIUS server after it
received the username and password. The user password is encrypted with the MD5 algorithm
and the shared key.
3.
The RADIUS server authenticates the username and password. If the authentication succeeds, the
server returns an Access-Accept message that includes the user's authorization information. If the
authentication fails, the server returns an Access-Reject message.
4.
The RADIUS client permits or denies the user according to the returned authentication result. If the
result permits the user, the RADIUS client sends a start-accounting request (Accounting-Request) to
the RADIUS server.
5.
The RADIUS server returns an acknowledgement (Accounting-Response) and starts accounting.
6.
The user accesses the network resources.
7.
The host requests the RADIUS client to tear down the connection and the RADIUS client sends a
stop-accounting request (Accounting-Request) to the RADIUS server.
8.
The RADIUS server returns an acknowledgement (Accounting-Response) and stops accounting for
the user.
RADIUS packet format

RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS
server and the client, RADIUS uses a timer management mechanism, a retransmission mechanism, and
a backup server mechanism. Figure 4 shows the RADIUS packet format.
Figure 4 RADIUS packet format

0
7
Code
15
31
7
Length
Identifier
Authenticator
Attributes
Descriptions of the fields are as follows:
The Code field (1 byte long) indicates the type of the RADIUS packet.
Table 1 Main values of the Code field
Packet type
Description
Access-Request
From the client to the server. A packet of this type includes user
information for the server to authenticate the user. It must contain the
User-Name attribute and can optionally contain the attributes of
NAS-IP-Address, User-Password, and NAS-Port.
Access-Accept
From the server to the client. If all attribute values included in the
Access-Request are acceptable, the authentication succeeds, and the
server sends an Access-Accept response.
Access-Reject
From the server to the client. If any attribute value included in the
Access-Request is unacceptable, the authentication fails, and the server
sends an Access-Reject response.
Accounting-Request
From the client to the server. A packet of this type includes user
information for the server to start or stop accounting for the user. The
Acct-Status-Type attribute in the packet indicates whether to start or stop
accounting.
Accounting-Response
From the server to the client. The server sends a packet of this type to
notify the client that it has received the Accounting-Request and has
successfully recorded the accounting information.
Code
The Identifier field (1 byte long) is used to match request packets and response packets and to detect
duplicate request packets. Request and response packets of the same type have the same identifier.
The Length field (2 bytes long) indicates the length of the entire packet, including the Code,
Identifier, Length, Authenticator, and Attributes fields. Bytes beyond this length are considered
padding and are ignored by the receiver. If the length of a received packet is less than this length,
the packet is dropped. The value of this field is in the range 20 to 4096.
The Authenticator field (16 bytes long) is used to authenticate responses from the RADIUS server and
to encrypt user passwords. There are two types of authenticators: request authenticator and
response authenticator.
The Attributes field (variable in length) includes the specified authentication, authorization, and
accounting information that defines the configuration details of the request or response. This field
may contain multiple attributes, each with three sub-fields:
9
Type(1 byte long) Type of the attribute. It is in the range of 1 to 255. Commonly used RADIUS
attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. Table 2 shows a list
of the attributes. For more information, see "Commonly used standard RADIUS attributes."
Length(1 byte long) Length of the attribute in bytes, including the Type, Length, and Value
sub-fields.
Value(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and
Length sub-fields.
Table 2 Commonly used RADIUS attributes

No.
Attribute
No.
Attribute
User-Name
45
Acct-Authentic
User-Password
46
Acct-Session-Time
CHAP-Password
47
Acct-Input-Packets
NAS-IP-Address
48
Acct-Output-Packets
NAS-Port
49
Acct-Terminate-Cause
Service-Type
50
Acct-Multi-Session-Id
Framed-Protocol
51
Acct-Link-Count
Framed-IP-Address
52
Acct-Input-Gigawords
Framed-IP-Netmask
53
Acct-Output-Gigawords
10
Framed-Routing
54
(unassigned)
11
Filter-ID
55
Event-Timestamp
12
Framed-MTU
56-59
(unassigned)
13
Framed-Compression
60
CHAP-Challenge
14
Login-IP-Host
61
NAS-Port-Type
15
Login-Service
62
Port-Limit
16
Login-TCP-Port
63
Login-LAT-Port
17
(unassigned)
64
Tunnel-Type
18
Reply-Message
65
Tunnel-Medium-Type
19
Callback-Number
66
Tunnel-Client-Endpoint
20
Callback-ID
67
Tunnel-Server-Endpoint
21
(unassigned)
68
Acct-Tunnel-Connection
22
Framed-Route
69
Tunnel-Password
23
Framed-IPX-Network
70
ARAP-Password
24
State
71
ARAP-Features
25
Class
72
ARAP-Zone-Access
26
Vendor-Specific
73
ARAP-Security
27
Session-Timeout
74
ARAP-Security-Data
28
Idle-Timeout
75
Password-Retry
29
Termination-Action
76
Prompt
10
No.
Attribute
No.
Attribute
30
Called-Station-Id
77
Connect-Info
31
Calling-Station-Id
78
Configuration-Token
32
NAS-Identifier
79
EAP-Message
33
Proxy-State
80
Message-Authenticator
34
Login-LAT-Service
81
Tunnel-Private-Group-id
35
Login-LAT-Node
82
Tunnel-Assignment-id
36
Login-LAT-Group
83
Tunnel-Preference
37
Framed-AppleTalk-Link
84
ARAP-Challenge-Response
38
Framed-AppleTalk-Network
85
Acct-Interim-Interval
39
Framed-AppleTalk-Zone
86
Acct-Tunnel-Packets-Lost
40
Acct-Status-Type
87
NAS-Port-Id
41
Acct-Delay-Time
88
Framed-Pool
42
Acct-Input-Octets
89
(unassigned)
43
Acct-Output-Octets
90
Tunnel-Client-Auth-id
44
Acct-Session-Id
91
Tunnel-Server-Auth-id
Extended RADIUS attributes

Attribute 26 (Vendor-Specific), an attribute defined in RFC 2865, allows a vendor to define extended
attributes to implement functions that the standard RADIUS protocol does not provide.
A vendor can encapsulate multiple sub-attributes as TLVs in attribute 26 to provide extended functions. As
shown in Figure 5, a sub-attribute encapsulated in attribute 26 consists of the following parts:
Vendor-IDID of the vendor. Its most significant byte is 0. The other three bytes contains a code
that is compliant to RFC 1700. The vendor ID of HP is 25506. For more information about the
proprietary RADIUS sub-attributes of HP, see "HP proprietary RADIUS sub-attributes."
Vendor-TypeType of the sub-attribute.
Vendor-LengthLength of the sub-attribute.
Vendor-DataContents of the sub-attribute.
Figure 5 Format of attribute 26
11
HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol
based on TACACS (RFC 1492). HWTACACS is similar to RADIUS, and uses a client/server model for
information exchange between the NAS and the HWTACACS server.
HWTACACS typically provides AAA services for PPP, VPDN, and terminal users. In a typical
HWTACACS scenario, terminal users need to log in to the NAS. Working as the HWTACACS client, the
NAS sends users' usernames and passwords to the HWTACACS sever for authentication. After passing
authentication and obtaining authorized rights, a user logs in to the device and performs operations. The
HWTACACS server records the operations that each user performs.
Differences between HWTACACS and RADIUS

HWTACACS and RADIUS have many features in common, including using a client/server model, using
shared keys for user information security, and providing flexibility and extensibility. Table 3 lists the
primary differences.
Table 3 Primary differences between HWTACACS and RADIUS
HWTACACS
RADIUS
Uses TCP, which provides more reliable network

transmission.
Uses UDP, which provides higher transport efficiency.
Encrypts the entire packet except for the HWTACACS

header.
Encrypts only the user password field in an

authentication packet.
Protocol packets are complicated and authorization is

independent of authentication. Authentication and
authorization can be deployed on different
HWTACACS servers.
Protocol packets are simple and the authorization

process is combined with the authentication process.
Supports authorization of configuration commands.

Access to commands depends on both the user level
and AAA authorization. A user can use only
commands that are at, or lower than, the user level
and authorized by the HWTACACS server.
Does not support authorization of configuration

commands. Access to commands solely depends on
the level of the user. A user can use all the commands
at, or lower than, the user level.
Basic HWTACACS message exchange process

The following example describes how HWTACACS performs user authentication, authorization, and
accounting for a Telnet user.
12
Figure 6 Basic HWTACACS message exchange process for a Telnet user
HWTACACS operates using the following workflow:

1.
A Telnet user sends an access request to the HWTACACS client.
2.
The HWTACACS client sends a start-authentication packet to the HWTACACS server when it
receives the request.
3.
The HWTACACS server sends back an authentication response to request the username.
4.
Upon receiving the response, the HWTACACS client asks the user for the username.
5.
The user enters the username.
6.
After receiving the username from the user, the HWTACACS client sends the server a
continue-authentication packet that includes the username.
7.
The HWTACACS server sends back an authentication response to request the login password.
8.
Upon receipt of the response, the HWTACACS client prompts the user for the login password.
13
9.
The user enters the password.
10. After receiving the login password, the HWTACACS client sends the HWTACACS server a
continue-authentication packet that includes the login password.
11. The HWTACACS server sends back an authentication response to indicate that the user has
passed authentication.
12. The HWTACACS client sends the user authorization request packet to the HWTACACS server.
13. The HWTACACS server sends back the authorization response, indicating that the user is now
authorized.
14. The HWTACACS client pushes its CLI to the user.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indicating that it has received the
start-accounting request.
17. The user logs off.
18. The HWTACACS client sends a stop-accounting request to the HWTACACS server.
19. The HWTACACS server sends back a stop-accounting response, indicating that the
stop-accounting request has been received.
LDAP
Based on TCP/IP, the Lightweight Directory Access Protocol (LDAP) provides standard multi-platform
directory service. LDAP was developed on the basis of the X.500 protocol, and improves the read/write
interactive access, and browse and search functions of X.500. It is suitable for storing data that is not
often changed.
LDAP is typically used to store user information. For example, Microsoft Windows uses Active Directory
Server to store user information and user group information for login authentication and authorization.
LDAP directory service

LDAP uses directories to maintain organization, personnel, and resource information. The directories are
organized in a tree structure and include entries. An entry is a set of attributes with distinguished names
(DNs).
The LDAP directory service is based on a client/server model. All directory information is stored in the
LDAP server. Commonly used LDAP server products include Microsoft Active Directory Server, IBM Tivoli
Directory Server, and Sun ONE Directory Server.
LDAP authentication and authorization

LDAP defines a set of operations to implement functions. LDAP operations for authentication and
authorization are the bind operation and search operation:
Bind operationAllows an LDAP client to establish a connection with the LDAP server, obtain the
access rights to the LDAP server, and check the validity of user information.
Search operationConstructs search conditions and obtains the directory resource information of
the LDAP server.
The basic LDAP authentication process is as follows:

1.
An LDAP client uses the LDAP server administrator DN to bind with the LDAP server, establishes a
connection to the server, and obtains the search rights.
14
2.
The LDAP client, using the username in the authentication information of a user, constructs search
conditions to search for the user in the specified root directory of the server, and obtains a user DN
list.
3.
The LDAP client uses each user DN in the obtained user DN list and the user password to bind with
the LDAP server. If a binding succeeds, the user is legal.
The LDAP authorization process is similar to the LDAP authentication process, except that the client
obtains the authorization information and the user DN list at step 2 in the workflow.
If the authorization information meets the authorization requirements, the authorization process
ends.
If the authorization information does not meet the authorization requirements, the client sends an
administrator bind request to the LDAP server to obtain search right for authorization information
about users on the user DN list.
Basic LDAP message exchange process

The following example illustrates the basic message exchange process during LDAP authentication and
authorization for a Telnet user.
Figure 7 Basic message exchange process for LDAP authentication of a Telnet user
Host
LDAP client
LDAP server
1) The user logs in by Telnet

2) Establish a TCP connection
3) Administrator bind request
4) Bind response
5) User DN search request
6) Search response
7) User DN bind request
8) Bind response
9) Authorization
10) The user logs in successfully
The basic message exchange process during LDAP authentication and authorization is as follows:
1.
A Telnet user initiates a connection request and sends the username and password to the LDAP
client.
2.
After receiving the request, the LDAP client establishes a TCP connection with the LDAP server.
3.
To obtain the search right, the LDAP client uses the administrator DN and password to send an
administrator bind request to the LDAP server.
4.
The LDAP server processes the request. If the bind operation is successful, the LDAP server sends an
acknowledgement to the LDAP client.
15
5.
The LDAP client sends a user DN search request with the username of the Telnet user to the LDAP
server.
6.
After receiving the request, the LDAP server searches for the user DN by the base DN, search
scope, and filtering conditions. If a match is found, the LDAP server sends a response to notify the
LDAP client of the successful search. There may be one or more user DNs found.
7.
The LDAP client uses the obtained user DN and the entered user password as parameters to send
a user DN bind request to the LDAP server, which checks whether the user password is correct.
8.
The LDAP server processes the request, and sends a response to notify the LDAP client of the bind
operation result. If the bind operation fails, the LDAP client uses another obtained user DN as the
parameter to send a user DN bind request to the LDAP server. This process continues until a DN is
bound successfully or all DNs fail to be bound. If all user DNs fail to be bound, the LDAP client
notifies the user of the login failure and denies the access request.
9.
The LDAP client and server exchange authorization messages. If another scheme, for example, an
HWTACACS scheme, is expected for authorization, the LDAP client exchanges authorization
messages with the HWTACACS authorization server instead.
10. After successful authorization, the LDAP client notifies the user of the successful login.
LDAP authentication and authorization restrictions

The device supports LDAP authentication, but it does not support LDAP authorization. To configure a
separate authorization method, use the HWTACACS authorization method. For more information, see
"Configuring HWTACACS schemes."
Domain-based user management

A NAS manages users based on ISP domains. On a NAS, each user belongs to one ISP domain. A NAS
determines the ISP domain for a user by the username entered by the user at login, as shown in Figure
8.
Figure 8 Determining the ISP domain of a user by the username
Authentication, authorization, and accounting of a user depends on the AAA methods configured for the
domain that the user belongs to. If no specific AAA methods are configured for the domain, the default
methods are used. By default, a domain uses local authentication, local authorization, and local
accounting.
AAA allows you to manage users based on their access types:
LAN usersUsers on a LAN who must pass 802.1X or MAC address authentication to access the
network.
16
Login usersUsers who want to log in to the device, including SSH users, Telnet users, Web users,
FTP users, and terminal users.
Portal usersUsers who must pass portal authentication to access the network.
PPP usersUsers who access the network through PPP. Support for PPP users depends on the device
model. For more information, see About the Configuration Guides for HP Unified Wired-WLAN
Products.
In addition, AAA provides the following login services to enhance device security:
Command authorizationEnables the NAS to defer to the authorization server to determine

whether a command entered by a login user is permitted, and allows login users to execute only
authorized commands. For more information about command authorization, see Fundamentals
Configuration Guide.
Command accountingAllows the accounting server to record all commands executed or

successfully authorized on the device. For more information about command accounting, see
Fundamentals Configuration Guide.
Level switching authenticationAllows the authentication server to authenticate users who perform
privilege level switching. When users pass level switching authentication, they can switch their user
privilege levels without logging out and disconnecting current connections. For more information
about user privilege level switching, see Fundamentals Configuration Guide.
You can configure different AAA methods for different types of users in a domain. See "Configuring AAA
methods for ISP domains."
Protocols and standards

The following protocols and standards are related to AAA, RADIUS, HWTACACS, and LDAP:
RFC 2865, Remote Authentication Dial In User Service (RADIUS)
RFC 2866, RADIUS Accounting
RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support
RFC 2868, RADIUS Attributes for Tunnel Protocol Support
RFC 2869, RADIUS Extensions
RFC 1492, An Access Control Protocol, Sometimes Called TACACS
RFC 1777, Lightweight Directory Access Protocol
RFC 2251, Lightweight Directory Access Protocol (v3)
RADIUS attributes
This section provides tables of commonly used standard RADIUS attributes and HP proprietary RADIUS
sub-attributes.
Commonly used standard RADIUS attributes

No.
Attribute
Description
User-Name
Name of the user to be authenticated.
User-Password
User password for PAP authentication, only present in Access-Request

packets when PAP authentication is used.
17
No.
Attribute
Description
CHAP-Password
Digest of the user password for CHAP authentication, only present in

Access-Request packets when CHAP authentication is used.
NAS-IP-Address
IP address for the server to use to identify a client. A client is typically

identified by the IP address of its access interface. This attribute is only
present in Access-Request packets.
NAS-Port
Physical port of the NAS that the user accesses.

Type of service that the user has requested or type of service to be provided:
Service-Type
2802.1X authentication.
10MAC authentication.
Framed-Protocol
Encapsulation protocol for framed access.
Framed-IP-Address
IP address assigned to the user.
11
Filter-ID
Name of the filter list.
12
Framed-MTU
MTU for the data link between the user and NAS. For example, with 802.1X
EAP authentication, NAS uses this attribute to notify the server of the MTU for
EAP packets, so as to avoid oversized EAP packets.
14
Login-IP-Host
IP address of the NAS interface that the user accesses.
15
Login-Service
Type of the service that the user uses for login.
18
Reply-Message
Text to be displayed to the user, which can be used by the server to

communicate information, for example, the reason of the authentication
failure.
26
Vendor-Specific
Vendor specific, proprietary attribute. A packet can contain one or more

proprietary attributes, each of which can contain one or more sub-attributes.
27
Session-Timeout
Maximum service duration for the user before termination of the session.
28
Idle-Timeout
Maximum idle time permitted for the user before termination of the session.
31
Calling-Station-Id
User identification that the NAS sends to the server. For the LAN access
service provided by an HP device, this attribute includes the MAC address of
the user in the format HH-HH-HH-HH-HH-HH.
32
NAS-Identifier
Identification that the NAS uses to identify itself to the RADIUS server.
Type of the Accounting-Request packet. Possible values include:
40
Acct-Status-Type
1Start.
2Stop.
3Interim-Update.
4Reset-Charge.
7Accounting-On. (Defined in the 3rd Generation Partnership Project.)
8Accounting-Off. (Defined in the 3rd Generation Partnership Project.)
9 to 14Reserved for tunnel accounting.
15Reserved for failed.
Authentication method used by the user. Possible values include:

45
Acct-Authentic
1RADIUS.
2Local.
3Remote.
18
No.
Attribute
Description
60
CHAP-Challenge
CHAP challenge generated by the NAS for MD5 calculation during CHAP
authentication.
Type of the physical port of the NAS that is authenticating the user. Possible
values include:
61
NAS-Port-Type
15Ethernet.
16Any type of ADSL.
17Cable (with cable for cable TV).
19WLAN-IEEE 802.11.
201VLAN.
202ATM.
If the port is an ATM or Ethernet one and VLANs are implemented on it, the
value of this attribute is 201.
79
EAP-Message
Used to encapsulate EAP packets to allow RADIUS to support EAP

authentication.
80
Used for authentication and verification of authentication packets to prevent

spoofing Access-Requests. This attribute is present when EAP authentication is
used.
87
NAS-Port-Id
String for describing the port of the NAS that is authenticating the user.
HP proprietary RADIUS sub-attributes

No.
Sub-attribute
Description
Input-Peak-Rate
Peak rate in the direction from the user to the NAS, in bps.
Input-Average-Rate
Average rate in the direction from the user to the NAS, in bps.
Input-Basic-Rate
Basic rate in the direction from the user to the NAS, in bps.
Output-Peak-Rate
Peak rate in the direction from the NAS to the user, in bps.
Output-Average-Rate
Average rate in the direction from the NAS to the user, in bps.
Output-Basic-Rate
Basic rate in the direction from the NAS to the user, in bps.
15
Remanent_Volume
Total remaining available traffic for the connection, in different units for
different server types.
Operation for the session, used for session control. Possible values
include:
20
24
Command
Control_Identifier
1Trigger-Request.
2Terminate-Request.
3SetPolicy.
4Result.
5PortalClear.
Identification for retransmitted packets. For retransmitted packets from the

same session, this attribute must be the same value. For retransmitted
packets from different sessions, this attribute does not have to be the same
value. The client response from a retransmitted packet must also include
this attribute and the value of this attribute must be the same.
For Accounting-Request packets from the start, stop, and interim update
types, the Control-Identifier attribute does not take effect.
19
No.
Sub-attribute
Description
25
Result_Code
Result of the Trigger-Request or SetPolicy operation, zero for success and

any other value for failure.
26
Connect_ID
Index of the user connection.
28
Ftp_Directory
FTP user working directory. When the RADIUS client acts as the FTP server,
this attribute is used to set the FTP directory for an FTP user on the RADIUS
client.
29
Exec_Privilege
EXEC user priority.
59
NAS_Startup_Timestamp
Startup time of the NAS in seconds, which is represented by the time

elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60
Ip_Host_Addr
User IP address and MAC address included in authentication and

accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is
required between the IP address and the MAC address.
61
User_Notify
Information that must be sent from the server to the client transparently.
User_HeartBeat
Hash value assigned after an 802.1X user passes authentication, which is

a 32-byte string. This attribute is stored in the user list on the NAS and
verifies the handshake messages from the 802.1X user. This attribute only
exists in Access-Accept and Accounting-Request packets.
140
User_Group
User groups assigned after the SSL VPN user passes authentication. A user
might belong to more than one user group, which are separated by
semi-colons. This attribute is used to communicate with the SSL VPN
device.
141
Security_Level
Security level assigned after the SSL VPN user passes security
authentication.
201
Input-Interval-Octets
Number of bytes input within a real-time accounting interval.
202
Output-Interval-Octets
Number of bytes output within a real-time accounting interval.
203
Input-Interval-Packets
Number of packets input within an accounting interval in the unit set on the
NAS.
204
Output-Interval-Packets
Number of packets output within an accounting interval in the unit set on

the NAS.
205
Input-Interval-Gigawords
Amount of bytes input within an accounting interval, in units of 4G bytes.
206
Output-Interval-Gigawords
Amount of bytes output within an accounting interval, in units of 4G bytes.
207
Backup-NAS-IP
Backup source IP address for sending RADIUS packets.
255
Product_ID
Product name.
62
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
AAA configuration considerations and task list

To configure AAA on the NAS:
20
1.
Configure the required AAA schemes.

{
2.
Local authenticationConfigure local users and the related attributes, including the usernames
and passwords for the users to be authenticated.
Remote authenticationConfigure the required RADIUS, HWTACACS, and LDAP schemes.
You must configure user attributes on the servers accordingly.
Configure AAA methods for the ISP domain.

{
Authentication methodNo authentication (none), local authentication (local), or remote

authentication (scheme)
Authorization methodNo authorization (none), local authorization (local), or remote
authorization (scheme)
Accounting methodNo accounting (none), local accounting (local), or remote accounting
(scheme)
See Figure 9 for the configuration procedure.

Figure 9 AAA configuration procedure
Table 4 AAA configuration task list

Task
Remarks
Configuring local users
Configuring AAA
schemes
Configuring RADIUS schemes

Configuring HWTACACS schemes
Configuring LDAP schemes
21
Required.
Complete at least
one task.
Task
Configuring AAA
methods for ISP domains
Remarks
Creating an ISP domain
Required.
Configuring ISP domain attributes
Optional.
Configuring authentication methods for an ISP domain
Required.
Configuring authorization methods for an ISP domain
Complete at least
one task.
Configuring accounting methods for an ISP domain

Tearing down user connections
Optional.
Configuring local EAP authentication
Required.
Configuring a NAS ID-VLAN binding
Optional.
Specifying the device ID
Optional.
NOTE:
To use AAA methods to control access of login users, you must configure the authentication-mode
command. For more information, see Fundamentals Configuration Guide.
Configuring AAA schemes

Configuring local users
To implement local AAA, you must create local users and configure user attributes on the device. The
local users and attributes are stored in the local user database on the device. A local user is uniquely
identified by a username. Configurable local user attributes are as follows:
Service type.
Services that the user can use. Local authentication checks the service types of a local user. If none
of the service types is available, the user cannot pass authentication.
Service types include FTP, LAN access, portal, PPP, SSH, Telnet, terminal, and Web. Support for
the PPP service depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.
User state.
Indicates whether or not a local user can request network services. There are two user states: active
and blocked. A user in active state can request network services, but a user in blocked state
cannot.
Maximum number of users using the same local user account.

Indicates how many users can use the same local user account for local authentication.
Validity time and expiration time.

Indicates the validity time and expiration time of a local user account. A user must use a valid local
user account to pass local authentication. For temporary network access needs, you can create a
guest account and specify a validity time and an expiration time for the account.
User group.
22
Each local user belongs to a local user group and has all attributes of the group, such as the
password control attributes and authorization attributes. For more information about local user
group, see "Configuring user group attributes."
Password control attributes.

Password control attributes help control the security of local users' passwords. Password control
attributes include password aging time, minimum password length, and password composition
policy.
You can configure a password control attribute in system view, user group view, or local user view,
and you can make the attribute effective for all local users, all local users in a group, or only the
local user. A password control attribute with a smaller effective range has a higher priority. For
more information about password management and global password configuration, see
"Configuring password control." For more information about password control commands, see
Security Command Reference.
Binding attributes.
Binding attributes control the scope of users, and are checked during local authentication of a user.
If the attributes of a user do not match the binding attributes configured for the local user account,
the user cannot pass authentication. Binding attributes include the ISDN calling number, IP address,
access port, MAC address, and native VLAN.
Authorization attributes.
Authorization attributes indicate the user's rights after it passes local authentication. Authorization
attributes include the ACL, PPP callback number, idle cut function, user level, user role, user profile,
VLAN, and FTP/SFTP work directory. For more information about authorization attributes, see
"Configuring local user attributes."
Every configurable authorization attribute has its definite application environments and purposes.
When you configure authorization attributes for a local user, consider which attributes are needed
and which are not. For example, for PPP users, you do not need to configure the work directory
attribute.
You can configure an authorization attribute in user group view or local user view to make the
attribute effective for all local users in the group or for only the local user. The setting of an
authorization attribute in local user view takes precedence over that in user group view.
Local user configuration task list

Task
Remarks
Configuring local user attributes
Required.
Configuring user group attributes
Optional.
Displaying and maintaining local users and local user groups
Optional.
Configuring local user attributes

Follow these guidelines when you configure local user attributes:
When you use the password-control enable command to globally enable the password control
feature, local user passwords are not displayed. At the same time, you cannot use the password
hash cipher command to configure passwords for local users.
If the user interface authentication mode set by the authentication-mode command in user interface
view is AAA (scheme), command access for the login user depends on the privilege level
authorized to the user. If the user interface authentication mode is password (password) or no
authentication (none), command access for the login user depends on the level configured for the
23
user interface by using the user privilege level command in user interface view. For an SSH user
using public key authentication, command access for the login user depends on the level
configured for the user interface. For more information about user interface authentication mode
and user interface command level, see Fundamentals Configuration Guide.
You can configure the user profile authorization attribute in local user view, user group view, and ISP
domain view. The setting in local user view has the highest priority, and the setting in ISP domain
view has the lowest priority. For more information about user profiles, see "Configuring a user
profile."
If a local user is the only one security log manager in the system, this local user cannot be deleted.
You cannot change or delete the security log manager role of this user unless you specify another
local user as a security log manager.
To configure local user attributes:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Add a local user and enter

local user view.
local-user user-name
By default, a local user named admin

exists.
Optional.
3.
Configure a password for

the local user.
password [ [ hash ] { cipher |

simple } password ]
A local user with no password

configured passes authentication after
providing the valid local username and
attributes. To enhance security,
configure a password for each local
user.
This command is not supported in FIPS
mode. To configure passwords for
local users, use the password control
feature.
By default, no service is authorized to a
local user.
4.
Assign service types for the

local user.
5.
Place the local user to the

active or blocked state.
service-type { ftp | lan-access |

{ ssh | telnet | terminal } * |
portal | ppp | web }
The ftp and telnet keywords are not

supported in FIPS mode.
Support for the ppp keyword depends
on the device model. For more
information, see About the Command
References for HP Unified
Wired-WLAN Products.
Optional.
state { active | block }
By default, a created local user is in

active state and can request network
services.
Optional.
6.
Set the maximum number

of concurrent users of the
local user account.
access-limit max-user-number
By default, there is no limit to the

maximum number of concurrent users
of a local user account.
The limit is effective only for local
accounting, and is not effective for FTP
users.
24
Step
Command
Remarks
Optional.
Set the password aging time:

password-control aging
aging-time
Set the minimum password

7.
Configure password
control attributes for the
local user.
length:
password-control length
length
Configure the password
composition policy:
password-control composition
type-number type-number
[ type-length type-length ]
By default, the local user uses

password control attributes of the user
group to which the local user belongs,
and uses the global setting for any
password control attribute that is not
configured in the user group. The
global settings include a 90-day
password aging time, a minimum
password length of 10 characters, and
at least one password composition
type and at least one character
required for each password
composition type.
In FIPS mode, the value for the
type-number argument must be 4.
8.
Configure binding
attributes for the local user.
bind-attribute { call-number
call-number [ : subcall-number ] |
ip ip-address | location port
slot-number subslot-number
port-number | mac mac-address |
vlan vlan-id } *
Optional.
By default, no binding attribute is
configured for a local user.
Optional.
By default, no authorization attribute is
configured for a local user.
9.
Configure authorization
attributes for the local user.
authorization-attribute { acl
acl-number | callback-number
callback-number | idle-cut minute
| level level | user-profile
profile-name | user-role { guest |
guest-manager | security-audit }
| vlan vlan-id | work-directory
directory-name } *
For PPP users, only acl,

callback-number, idle-cut, and
user-profile are supported.
For LAN and portal users, only acl,
idle-cut, user-profile, and vlan are
supported.
For SSH, terminal, and Web users,
only level is supported.
For FTP users, only level and
work-directory are supported.
For Telnet users, only level and
user-role is supported.
10. Set the validity time of the

local user.
validity-date time
11. Set the expiration time of

the local user.
expiration-date time
12. Assign the local user to a

user group.
group group-name
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
25
By default, a local user belongs to the

default user group system.
Configuring user group attributes

User groups simplify local user configuration and management. A user group includes a group of local
users and has a set of local user attributes. You can configure local user attributes for a user group to
implement centralized user attributes management for the local users in the group. Configurable user
attributes include password control attributes and authorization attributes.
By default, every new local user belongs to the default user group system and has all attributes of the
group. To assign a local user to a different user group, use the group command in local user view.
To configure attributes for a user group:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and enter

user group view.
user-group group-name
N/A
Set the password aging time:
Optional.
password-control aging
aging-time

3.
Configure password control

attributes for the user group.
length:
password-control length length
composition policy:
authorization-attribute { acl
acl-number | callback-number
4.
Configure authorization
attributes for the user group.
callback-number | idle-cut minute

| level level | user-profile
profile-name | vlan vlan-id |
work-directory directory-name } *
By default, the user group uses

global settings, including a 90-day
password aging time, a minimum
password length of 10 characters,
and at least one password
composition type and at least one
character required for each
password composition type.
In FIPS mode, the value for the
type-number argument must be 4.
Optional.
By default, no authorization
attribute is configured for a user
group.
Optional.
5.
Set the guest attribute for the

user group.
group-attribute allow-guest
By default, the guest attribute is not

set for a user group, and guest
users created by a guest manager
through the Web interface cannot
join the group.
Displaying and maintaining local users and local user groups

Task
Command
Remarks
Available in any view.
Display local user

information.
display local-user [ idle-cut { disable | enable } |

service-type { ftp | lan-access | portal | ppp | ssh
| telnet | terminal | web } | state { active |
block } | user-name user-name | vlan vlan-id ] [ |
{ begin | exclude | include } regular-expression ]
Display the user group

configuration.
display user-group [ group-name ] [ | { begin |

exclude | include } regular-expression ]
26
The ftp and telnet keywords

are not supported in FIPS
mode.
Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of
parameters that the device uses to exchange information with the RADIUS servers. For example, there
might be authentication/authorization servers and accounting servers, or primary servers and
secondary servers. The parameters include the IP addresses of the servers, the shared keys, and the
RADIUS server type.
RADIUS scheme configuration task list

Task
Remarks
Creating a RADIUS scheme
Required.
Specifying the RADIUS authentication/authorization servers
Required.
Specifying the RADIUS accounting servers and the relevant parameters
Optional.
Specifying the shared keys for secure RADIUS communication
Optional.
Setting the username format and traffic statistics units
Optional.
Setting the supported RADIUS server type
Optional.
Setting the maximum number of RADIUS request transmission attempts
Optional.
Setting the status of RADIUS servers
Optional.
Specifying the source IP address for outgoing RADIUS packets
Optional.
Specifying a backup source IP address for outgoing RADIUS packets
Optional.
Setting RADIUS timers
Optional.
Configuring RADIUS accounting-on
Optional.
Configuring the IP address of the security policy server
Optional.
Enabling the RADIUS offload feature
Optional.
Configuring interpretation of the RADIUS class attribute as CAR parameters
Optional.
Enabling the trap function for RADIUS
Optional.
Enabling logging of RADIUS packets
Optional.
Enabling the RADIUS client service
Optional.
Displaying and maintaining RADIUS
Optional.
Creating a RADIUS scheme

Before you perform other RADIUS configurations, first create a RADIUS scheme and enter RADIUS
scheme view. A RADIUS scheme can be referenced by multiple ISP domains at the same time.
To create a RADIUS scheme and enter RADIUS scheme view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RADIUS scheme and

enter RADIUS scheme view.
radius scheme
radius-scheme-name
By default, no RADIUS scheme is

created.
27
Specifying the RADIUS authentication/authorization servers

In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS
clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.
You can specify one primary authentication/authorization server and up to 16 secondary
authentication/authorization servers for a RADIUS scheme. When the primary server is not available, a
secondary server is used. If redundancy is not required, specify only the primary server.
A RADIUS authentication/authorization server can function as the primary authentication/authorization
server for one scheme and a secondary authentication/authorization server for another scheme at the
same time.
You can enable the server status detection feature. With the feature, the device periodically sends an
authentication request to check whether or not the target RADIUS authentication/authorization server is
reachable. If the server can be reached, the device sets the status of the server to active. If the server
cannot be reached, the device sets the status of the server to block. This feature promptly notifies
authentication modules of latest server status information.
To specify RADIUS authentication/authorization servers for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
Configure at least one
command.
By default, no
authentication/authorization
server is specified.
Specify the primary RADIUS
3.
Specify RADIUS
servers.
authentication/authorization server:
primary authentication { ip-address
| ipv6 ipv6-address } [ port-number
| key [ cipher | simple ] key | probe
username name [ interval interval ] ]
*
Specify a secondary RADIUS
secondary authentication
{ ip-address | ipv6 ipv6-address }
[ port-number | key [ cipher |
simple ] key | probe username
name [ interval interval ] ] *
In FIPS mode, the shared key

for secure RADIUS
communication must be at
least eight characters that
contain digits, uppercase
letters, lowercase letters, and
special characters, and must
use 3DES for encryption and
decryption.
The IP addresses of the
primary and secondary
servers for a scheme must be
different. Otherwise, the
configuration will fail.
All servers for
and accounting, primary or
secondary, must use IP
addresses of the same IP
version.
28
Specifying the RADIUS accounting servers and the relevant parameters

You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS
scheme. When the primary server is not available, a secondary server is used. When redundancy is not
required, specify only the primary server. A RADIUS accounting server can function as the primary
accounting server for one scheme and a secondary accounting server for another scheme at the same
time.
When the device receives a connection teardown request from a host or a connection teardown
command from an administrator, it sends a stop-accounting request to the accounting server. When the
maximum number of real-time accounting attempts is reached, the device disconnects users who have no
accounting responses. You can enable buffering of non-responded stop-accounting requests to allow the
device to buffer and resend a stop-accounting request until it receives a response. If the number of
stop-accounting attempts reaches the upper limit, the device discards the buffered request.
If you delete an accounting server that is serving users, the device no longer sends real-time accounting
requests or stop-accounting requests for the users to that server, or buffers the stop-accounting requests.
RADIUS does not support accounting for FTP users.
To specify RADIUS accounting servers and set relevant parameters for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
Configure at least one command.
3.
Specify RADIUS accounting

servers.
Specify the primary RADIUS
By default, no accounting server is

specified.
Specify a secondary RADIUS
In FIPS mode, the shared key for

secure RADIUS accounting
communication must be at least
eight characters that contain digits,
uppercase letters, lowercase
letters, and special characters, and
must use 3DES for encryption and
decryption.
accounting server:
primary accounting
{ ip-address | ipv6
ipv6-address } [ port-number |
key [ cipher | simple ] key |
probe username name
[ interval interval ] ] *
accounting server:
secondary accounting
{ ip-address | ipv6
ipv6-address } [ port-number |
key [ cipher | simple ] key |
probe username name
[ interval interval ] ] *
4.
5.
Set the maximum number of

real-time accounting attempts.
retry realtime-accounting
retry-times
Enable buffering of
stop-accounting requests to
which no responses are
received.
stop-accounting-buffer enable
29
The IP addresses of the primary

and secondary accounting servers
must be different from each other.
Otherwise, the configuration fails.
All servers for
authentication/authorization and
accounting, primary or secondary,
must use IP addresses of the same
IP version.
Optional.
The default setting is 5.
Optional.
Enabled by default.
Step
6.
Command
stop-accounting attempts.
Remarks
retry stop-accounting retry-times
Optional.
Specifying the shared keys for secure RADIUS communication

The RADIUS client and RADIUS server use the MD5 algorithm and a shared key pair for packet
authentication and password encryption to secure communication.
A shared key configured in RADIUS scheme view applies to all servers of the specified type (accounting
or authentication) in that scheme, and has a lower priority than those configured for individual RADIUS
servers.
To specify a shared key for secure RADIUS communication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
By default, no shared key is specified.
3.
Specify a shared key for

secure RADIUS
or accounting
communication.
key { accounting |
authentication } [ cipher |
simple ] key
The shared key configured on the device

must be the same as that configured on the
RADIUS server.
In FIPS mode, the shared key must be at least
eight characters that contain digits,
uppercase letters, lowercase letters, and
special characters.

A username is typically in the format userid@isp-name, where isp-name represents the user's ISP domain
name. By default, the ISP domain name is included in a username. However, older RADIUS servers might
not recognize usernames that contain the ISP domain names. In this case, you can configure the device
to remove the domain name from each username to be sent.
The device periodically sends accounting updates to RADIUS accounting servers to report the traffic
statistics of online users. For normal and accurate traffic statistics, make sure that the units for data flows
and data packets on the device are consistent with units on the RADIUS server.
To set the username format and the traffic statistics units for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS
scheme view.
radius scheme
radius-scheme-name
N/A
30
Step
Command
Remarks
Optional.
By default, the ISP domain name is included in
a username.
Set the format for

usernames sent to the
RADIUS servers.
3.
user-name-format
{ keep-original | with-domain |
without-domain }
Do not apply the RADIUS scheme to more than

one ISP domain if you have configured the
user-name-format without-domain command
for that RADIUS scheme. Otherwise, users in
different ISP domains are considered the same
user if they use the same username.
For level switching authentication,
user-name-format keep-original and
user-name-format without-domain commands
all produce the same result to remove ISP
domain names from usernames sent to the
RADIUS server.
Specify the unit for

data flows or packets
sent to the RADIUS
servers.
4.
data-flow-format { data { byte |

giga-byte | kilo-byte |
mega-byte } | packet
{ giga-packet | kilo-packet |
mega-packet | one-packet } }*
Optional.
The default unit is byte for data flows and
one-packet for data packets.
Setting the supported RADIUS server type

The supported RADIUS server type determines the type of the RADIUS protocol that the device uses to
communicate with the RADIUS server:
StandardUses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later.
ExtendedUses the HP proprietary RADIUS protocol.
When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When the
RADIUS server runs third-party RADIUS server software, either RADIUS server type applies.
Changing the RADIUS server type will restore the units for data flows and data packets that are sent to
the RADIUS server to be the defaults.
To set the RADIUS server type:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Set the RADIUS server type.
server-type { extended | standard }
Optional.
The default RADIUS server type
is standard.
Setting the maximum number of RADIUS request transmission attempts

RADIUS uses UDP packets to transfer data. Because UDP communication is not reliable, RADIUS uses a
retransmission mechanism to improve reliability. If a NAS sends a RADIUS request to a RADIUS server
but receives no response before the response timeout timer (defined by the timer response-timeout
command) expires, the NAS retransmits the request. If the number of transmission attempts exceeds the
specified limit but the NAS does not receive a response, it tries to communicate with other RADIUS
31
servers in active state. If no other servers are in active state at the time, the NAS considers the
authentication or accounting attempt a failure. For more information about RADIUS server states, see
"Setting the status of RADIUS servers."
The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server
response timeout period cannot be greater than 75 seconds. For more information about the RADIUS
server response timeout timer, see "Setting RADIUS timers."
To set the maximum number of RADIUS request transmission attempts for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.

RADIUS request transmission
attempts.
retry retry-times
Optional.
Setting the status of RADIUS servers

To control the AAA servers with which the device communicates when the current servers are no longer
available, set the status of RADIUS servers to blocked or active. You can specify one primary RADIUS
server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of
the primary servers. Typically, the device chooses servers based on these rules:
When the primary server is in active state, the device communicates with the primary server.
If the primary server fails, the device changes the server's status to blocked, starts a quiet timer for
the server, and tries to communicate with a secondary server in active state (a secondary server
configured earlier has a higher priority).
If the secondary server is unreachable, the device changes the server's status to blocked, starts a
quiet timer for the server, and continues to check the next secondary server in active state. This
search process continues until the device finds an available secondary server or has checked all
secondary servers in active state.
If the quiet timer of a server expires or an authentication or accounting response is received from
the server, the status of the server automatically changes back to active, but the device does not
check the server again during the authentication or accounting process.
If no server is found reachable during one search process, the device considers the authentication
or accounting attempt a failure.
Once the accounting process of a user starts, the device continues to send the user's real-time
accounting requests and stop-accounting requests to the same accounting server.
If you remove the accounting server, real-time accounting requests and stop-accounting requests for
the user are no longer delivered to the server.
If you remove an authentication or accounting server in use, the communication of the device with
the server will soon time out, and the device will look for a server in active state by checking the
primary server first and then the secondary servers in the order they are configured.
When the primary server and secondary servers are all in blocked state, the device communicates
with the primary server. If the primary server is available, its status changes to active. Otherwise, its
status remains to be blocked.
If one server is in active state and all the others are in blocked state, the device only tries to
communicate with the server in active state, even if the server is unavailable.
32
After receiving an authentication/accounting response from a server, the device changes the status
of the server identified by the source IP address of the response to active if the current status of the
server is blocked.
The device does not change the status of an unreachable authentication or accounting server if the server
quiet timer is set to 0. Instead, the device keeps the server status as active and sends authentication or
accounting packets to another server in active state, so subsequent authentication or accounting packets
can still be sent to that server. For more information about the server quiet timer, see "Setting RADIUS
timers."
By default, the device sets the status of all RADIUS servers to active. In some situations, you might need
to change the status of a server. For example, if a server fails, you can change the status of the server to
blocked to avoid communication attempts to the server.
To set the status of RADIUS servers in a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme

view.
N/A
Set the status of the primary RADIUS

state primary authentication { active | block }
Set the status of the primary RADIUS accounting
By default, all servers in

the RADIUS scheme are
in active state.
Set the status of a secondary RADIUS
The server status set by

the state command
cannot be saved to the
configuration file. After
the device restarts, the
status of each server is
restored to active.
server:
state primary accounting { active | block }
3.
Set the RADIUS server

status.
state secondary authentication [ ip ipv4-address
| ipv6 ipv6-address ] { active | block }
Set the status of a secondary RADIUS accounting

server:
state secondary accounting [ ip ipv4-address |
ipv6 ipv6-address ] { active | block }
4.
(Optional) Display the

states of the servers.
Optional.
display radius scheme
N/A
Specifying the source IP address for outgoing RADIUS packets

The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS
configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a
RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of
any managed NAS. If it is, the server processes the packet. If it is not, the server drops the packet.
The source address of outgoing RADIUS packets is typically the IP address of an egress interface on the
NAS to communicate with the RADIUS server. However, in some situations, you must change the source
IP address.
You can specify a source IP address for outgoing RADIUS packets for a specific RADIUS scheme or all
RADIUS schemes. Before sending a RADIUS packet, the NAS selects a source IP address in the following
order:
1.
The source IP address specified for the RADIUS scheme.
2.
The source IP address specified in system view.

33
3.
The IP address of the outbound interface specified by the route.
To specify a source IP address for all RADIUS schemes:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a source IP address

for outgoing RADIUS packets.
radius nas-ip { ip-address | ipv6

ipv6-address }
By default, the IP address of the

outbound interface is used as the
source IP address.
To specify a source IP address for a specific RADIUS scheme:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
3.

for outgoing RADIUS packets.
nas-ip { ip-address | ipv6

ipv6-address }

source IP address.
Specifying a backup source IP address for outgoing RADIUS packets

Support for this feature depends on the device model. For more information, see About the Configuration
The backup source IP address specified for outgoing RADIUS packets takes effect only when stateful
failover is configured, and it must be the source IP address for outgoing RADIUS packets that is
configured on the standby device.
In a stateful failover scenario, the active device authenticates portal users by interacting with the RADIUS
server, and synchronizes its online portal user information to the standby device through the backup link
established between them. The standby device only receives and processes synchronization messages
from the active device. However, if the active device fails, the RADIUS server cannot send RADIUS
packets to the standby device because it does not have the IP address of the standby device.
To prevent problems, configure the source IP address for outgoing RADIUS packets on each device as the
backup source IP address for outgoing RADIUS packets on the other device. With this configuration, the
active device will send the source IP address for outgoing RADIUS packets configured on the standby
device to the RADIUS server, so that the RADIUS server can send unsolicited RADIUS packets to the
standby device.
You can specify a backup IP address for outgoing RADIUS packets for a specific RADIUS scheme or all
RADIUS schemes. Before sending a RADIUS packet, the NAS selects a backup source IP address in the
following order:
1.
The backup source IP address specified for the RADIUS scheme.
2.
The backup source IP address specified in system view.
If no backup source IP address is specified in the views, the NAS sends no backup source IP address to
the server.
To specify a backup source IP address for all RADIUS schemes:
34
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a backup source IP

address for outgoing RADIUS
packets.
radius nas-backup-ip ip-address
Not specified by default.
To specify a backup source IP address for a RADIUS scheme:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
3.
Specify a backup source IP address for

outgoing RADIUS packets.
nas-backup-ip ip-address
Setting RADIUS timers

The device uses the following types of timers to control communication with a RADIUS server:
Server response timeout timer (response-timeout)Defines the RADIUS request retransmission

interval. After sending a RADIUS request (authentication/authorization or accounting request), the
device starts the server response timeout timer. If the device receives no response from the RADIUS
server before the timer expires, it resends the request.
Server quiet timer (quiet)Defines the duration to keep an unreachable server in blocked state. If
one server is not reachable, the device changes the server's status to blocked, starts this timer for the
server, and tries to communicate with another server in active state. After the server quiet timer
expires, the device changes the status of the server back to active.
Real-time accounting timer (realtime-accounting)Defines the interval for the device to send
real-time accounting packets to the RADIUS accounting server for online users. To implement
real-time accounting, the device must periodically send real-time accounting packets to the
accounting server for online users.
Follow these guidelines when you set RADIUS timers:
For the same type of users, the maximum number of transmission attempts multiplied by the RADIUS
server response timeout period must be less than the client connection timeout time and cannot
exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the
primary/secondary server switchover cannot take place. For example, the product of the two
parameters must be less than 10 seconds for voice users and less than 30 seconds for Telnet users,
because the client connection timeout period for voice users is 10 seconds and that for Telnet users
is 30 seconds.
When you configure the maximum number of RADIUS packet transmission attempts and the
RADIUS server response timeout timer, consider the number of secondary servers. If the
retransmission process takes too long, the client connection in the access module may time out
while the device is trying to find an available server. For more information about the maximum
number of RADIUS packet transmission attempts, see "Setting the maximum number of RADIUS
request transmission attempts."
When a number of secondary servers are configured, the client connections of access modules that
have a short client connection timeout period may still be timed out during initial authentication or
accounting, even if the packet transmission attempt limit and server response timeout period are
configured with small values. In this case, the next authentication or accounting attempt can
35
succeed because the device has set the status of the unreachable servers to blocked and the amount
of time for finding a reachable server has been shortened.
Properly set the server quiet timer. Too short a quiet timer can result in frequent authentication or
accounting failures because the device has to repeatedly attempt to communicate with an
unreachable server that is in active state.
To set RADIUS timers:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
3.
Set the RADIUS server

response timeout timer.
timer response-timeout
seconds
4.
Set the server quiet timer.
timer quiet minutes
5.
Set the real-time accounting

interval.
timer
realtime-accounting
minutes
Optional.
The default RADIUS server response timeout
timer is 3 seconds.
Optional.
The default server quiet timer is 5 minutes.
Optional.
The default real-time accounting interval is 12
minutes.
Configuring RADIUS accounting-on

The accounting-on feature enables the device to send an accounting-on packet to the RADIUS server after
it reboots so the server can log out users who logged in through the device before the reboot. Without this
feature, users who were online before the reboot cannot log in again after the reboot, because the
RADIUS server would consider them to be online already.
If the device receives no response to the accounting-on packet, it re-sends the packet to the RADIUS server
at a particular interval for the specified number of times.
The accounting-on feature must work with the HP IMC network management system.
To configure the accounting-on feature for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme

view.
radius scheme
radius-scheme-name
N/A
3.
Enable accounting-on and

configure parameters.
accounting-on enable
[ interval seconds | send
send-times ] *
Disabled by default.
The default interval is 3 seconds, and the
default number of send-times is 50.
Configuring the IP address of the security policy server

The security policy server is the management and control center for Endpoint Admission Defense (EAD).
The NAS checks the validity of received control packets and accepts only control packets from known
servers. To use a security policy server that is independent of the AAA servers, you must configure the IP
address of the security policy server on the NAS. To implement all EAD functions, configure both the IP
address of the security policy server and the IP address of the IMC Platform on the NAS.
36
To configure the IP address of the security policy server for a scheme:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme

view.
N/A
3.
Specify a security policy

server.
security-policy-server ip-address
No security policy server is

specified by default.
You can specify up to eight security
policy servers for a RADIUS scheme.
Enabling the RADIUS offload feature

RADIUS servers that do not support EAP authentication cannot process EAP packets. To work with these
servers, the device must process EAP packets from EAP clients before forwarding them to the servers. The
RADIUS offload feature enables the device to process EAP packets.
The RADIUS offload feature must work with the local EAP authentication server as follows:
1.
After receiving EAP packets from an EAP client, the local EAP authentication server interacts with
the client, encapsulates the authentication information of the client into the RADIUS MS-CHAPv2
attribute and sends the attribute in a RADIUS authentication request to the RADIUS server.
2.
When a RADIUS server receives the requests, it resolves the authentication information in the
request, performs authentication, and then encapsulates and sends the authentication result in a
RADIUS packet to the local EAP authentication server.
To deploy the RADIUS offload feature, complete the following tasks on the device:
Configure the local EAP authentication server to use PEAP-MSCHAPv2 as the EAP authentication
method. For more information about the configuration, see "Configuring local EAP authentication."
Enable the EAP offload feature for the RADIUS schemes.
To enable the EAP offload feature:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Enable the EAP offload feature.
eap offload method peap-mschapv2
Configuring interpretation of the RADIUS class attribute as CAR parameters

This task is required when the RADIUS server supports assigning CAR parameters through the class
attribute.
According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS
client. However, the RFC does not require the RADIUS client to interpret the attribute and only requires the
RADIUS client to send the attribute to the accounting server on an "as is" basis. When RADIUS servers
use the class attribute to deliver the assigned CAR parameters, the device must interpret the attribute as
the CAR parameters to implement user-based traffic monitoring and controlling.
To configure the device to interpret the RADIUS class attribute as CAR parameters:
37
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
radius scheme
radius-scheme-name
N/A
3.
Interpret the class attribute as

CAR parameters.
attribute 25 car
By default, RADIUS attribute 25 is not

interpreted as CAR parameters.
Enabling the trap function for RADIUS

With the trap function, the NAS sends a trap message when either of the following events occurs:
The status of a RADIUS server changes. If the NAS receives no response to an accounting or
authentication request before the specified maximum number of RADIUS request transmission
attempts is exceeded, it considers the server unreachable, sets the status of the server to block, and
sends a trap message. If the NAS receives a response from a RADIUS server that it considers
unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the
server to active, and sends a trap message.
The ratio of failed transmission attempts to the total authentication request transmission attempts
exceeds a threshold. The threshold ranges from 1% to 100% and defaults to 30%. The threshold
can only be configured through the MIB.
Typically, the failure ratio is small. If a trap message is triggered because the failure ratio is higher than
the threshold, troubleshoot the configuration on and the communication between the NAS and the
RADIUS server.
To enable the trap function for RADIUS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the trap function for

RADIUS.
radius trap { accounting-server-down |

authentication-error-threshold |
authentication-server-down }
Enabling logging of RADIUS packets

You can enable the device to generate logs for RADIUS packets. Make sure the device has sufficient
system resources.
To enable logging of RADIUS packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable logging of RADIUS packets.
radius log packet
Enabling the RADIUS client service

To receive and send RADIUS packets, enable the RADIUS client service on the device. If RADIUS is not
required, disable the RADIUS client service to avoid attacks that exploit RADIUS packets.
To enable the RADIUS client service:
38
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable the RADIUS client

service.
radius client enable
Optional.
Enabled by default.
Displaying and maintaining RADIUS

Task
Command
Remarks
Display the configuration of

RADIUS schemes.
display radius scheme

[ radius-scheme-name ] [ | { begin | exclude
| include } regular-expression ]
Display the RADIUS packet

statistics.
display radius statistics [ | { begin | exclude

Display information about buffered

stop-accounting requests for which
no responses have been received.
display stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range start-time
stop-time | user-name user-name } [ | { begin
| exclude | include } regular-expression ]
Clear RADIUS statistics.
reset radius statistics
Available in user view.
Clear the buffered stop-accounting

requests for which no responses
have been received.
reset stop-accounting-buffer { radius-scheme

radius-scheme-name | session-id session-id |
time-range start-time stop-time | user-name
user-name }
Configuring HWTACACS schemes

You cannot remove the HWTACACS schemes that are in use or change the IP addresses of the
HWTACACS servers that are in use.
HWTACACS configuration task list

Task
Remarks
Creating an HWTACACS scheme
Required.
Specifying the HWTACACS authentication servers
Required.
Specifying the HWTACACS authorization servers
Optional.
Specifying the HWTACACS accounting servers and the relevant parameters
Optional.
Specifying the shared keys for secure HWTACACS communication
Required.
Optional.
Specifying the source IP address for outgoing HWTACACS packets
Optional.
Setting HWTACACS timers
Optional.
Displaying and maintaining HWTACACS
Optional.
39
Creating an HWTACACS scheme

The HWTACACS protocol is configured on a per-scheme basis. Before you perform other HWTACACS
configurations, create an HWTACACS scheme and enter HWTACACS scheme view. You can configure
up to 16 HWTACACS schemes.
You can delete an HWTACACS scheme only when it is not in use.
To create an HWTACACS scheme and enter HWTACACS scheme view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an HWTACACS scheme and

enter HWTACACS scheme view.
hwtacacs scheme
hwtacacs-scheme-name
Not defined by default.
Specifying the HWTACACS authentication servers

You can specify one primary authentication server and one secondary authentication server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. If
redundancy is not required, specify only the primary server.
An HWTACACS server can function as the primary authentication server of one scheme and as the
secondary authentication server of another scheme at the same time. You cannot specify the same IP
address as both the primary and the secondary authentication servers in a scheme.
You can remove an authentication server only when no active TCP connection for sending authentication
packets is using it.
To specify HWTACACS authentication servers for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme

view.
hwtacacs scheme hwtacacs-scheme-name
N/A
Specify the primary HWTACACS

3.
Specify HWTACACS
authentication servers.
authentication server:
primary authentication ip-address
[ port-number ]
Specify a secondary HWTACACS
authentication server:
secondary authentication ip-address
[ port-number ]

command.
No authentication server is
specified by default.
Specifying the HWTACACS authorization servers

You can specify one primary authorization server and one secondary authorization server for an
An HWTACACS server can function as the primary authorization server of one scheme and as the
secondary authorization server of another scheme at the same time. You cannot specify the same IP
address as both the primary and the secondary authorization servers in a scheme.
You can remove an authorization server only when no active TCP connection for sending authorization
40
To specify HWTACACS authorization servers for an HWTACACS scheme:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme hwtacacs-scheme-name
N/A

3.
Specify HWTACACS
authorization servers.
authorization server:
primary authorization ip-address
[ port-number ]

command.
No authorization server
is specified by default.
authorization server:
secondary authorization ip-address
[ port-number ]
Specifying the HWTACACS accounting servers and the relevant parameters

You can specify one primary accounting server and one secondary accounting server for an
When the device receives a connection teardown request from a host or a connection teardown
command from an administrator, it sends a stop-accounting request to the accounting server. You can
enable buffering of non-responded stop-accounting requests to allow the device to buffer and resend a
stop-accounting request until it receives a response or the number of stop-accounting attempts reaches
the configured limit. When the number of stop-accounting attempts reaches the configured limit, the
device discards the packet.
An HWTACACS server can function as the primary accounting server of one scheme and as the
secondary accounting server of another scheme at the same time. You cannot specify the same IP
address as both the primary and the secondary accounting servers in a scheme.
HWTACACS does not support accounting for FTP users.
You can remove an accounting server only when no active TCP connection for sending accounting
To specify HWTACACS accounting servers and set relevant parameters for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme
N/A

3.
Specify HWTACACS
accounting servers.
accounting server:
primary accounting ip-address
[ port-number ]

accounting server:
secondary accounting ip-address
[ port-number ]
41

No accounting server is specified
by default.
Step
4.
5.
Command
Remarks
Enable buffering of
stop-accounting requests to
which no responses are
received.
stop-accounting-buffer enable

stop-accounting attempts.
retry stop-accounting retry-times
Optional.
Enabled by default.
Optional.
Specifying the shared keys for secure HWTACACS communication

The HWTACACS client and HWTACACS server use the MD5 algorithm and a shared key pair for
password encryption.
To specify a shared key for secure HWTACACS communication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme
N/A
By default, no shared key is specified.
3.
Specify a shared key for

secure HWTACACS
authentication, authorization,
or accounting
communication.
key { accounting |
authentication |
authorization } [ cipher |
simple ] key
The shared key configured on the device

must be the same as the shared key
configured on the HWTACACS server.
In FIPS mode, the shared key for secure
HWTACACS communication must be at
least eight characters that contain digits,
uppercase letters, lowercase letters, and
special characters.

A username is typically in the format userid@isp-name, where isp-name represents the user's ISP domain
name. By default, the ISP domain name is included in a username. However, some HWTACACS servers
do not recognize usernames that contain the ISP domain names. In this case, you can configure the
device to remove the domain name from each username to be sent.
The device periodically sends accounting updates to HWTACACS accounting servers to report the traffic
statistics of online users. For normal and accurate traffic statistics, make sure that the units for data flows
and for data packets on the device are consistent with the units configured on the HWTACACS servers.
To set the username format and the traffic statistics units for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme
N/A
42
Step
Command
Remarks
Optional.
By default, the ISP domain name
is included in a username.
3.
4.
Set the format of usernames

sent to the HWTACACS
servers.
user-name-format { keep-original |
with-domain | without-domain }
Specify the unit for data flows

or packets sent to the
HWTACACS servers.
data-flow-format { data { byte |

giga-byte | kilo-byte | mega-byte }
| packet { giga-packet | kilo-packet
| mega-packet | one-packet } }*
If an HWTACACS server does not

support a username that includes
the domain name, configure the
device to remove the domain
name before sending the
username to the server.
For level switching
authentication, user-name-format
keep-original and
user-name-format
without-domain commands make
sure that usernames sent to the
HWTACACS server do not
include ISP domain names.
Optional.
The default unit is byte for data
flows and one-packet for data
packets.
Specifying the source IP address for outgoing HWTACACS packets

The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS
configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. When the
HWTACACS server receives a packet, it checks whether the source IP address of the packet is the IP
address of a managed NAS. If it is, the server processes the packet. If it is not, the server drops the
packet.
To communicate with the HWTACACS server, the source address of outgoing HWTACACS packets is
typically the IP address of an egress interface on the NAS. However, in some situations, you must change
the source IP address.
You can specify the source IP address for outgoing HWTACACS packets for a specific HWTACACS
scheme or all HWTACACS schemes.
Before sending an HWTACACS packet, the NAS selects a source IP address in the following order:
1.
The source IP address specified for the HWTACACS scheme.
2.
The source IP address specified in system view.
3.
The IP address of the outbound interface specified by the route.
To specify a source IP address for all HWTACACS schemes:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

for outgoing HWTACACS
packets.
hwtacacs nas-ip ip-address

source IP address.
To specify a source IP address for a specific HWTACACS scheme:

43
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme
N/A
3.

for outgoing HWTACACS
packets.
nas-ip ip-address

source IP address.
Setting HWTACACS timers

The device uses the following timers to control communication with an HWTACACS server:
Server response timeout timer (response-timeout)Defines the HWTACACS request

retransmission interval. After sending an HWTACACS request (authentication, authorization, or
accounting request), the device starts the server response timeout timer. If the device does not
receive a response from the server before the timer expires, it resends the request.
Primary server quiet timer (quiet)Defines the duration to keep an unreachable primary server in
blocked state. If a primary server is not reachable, the device changes the server's status to blocked,
starts this timer for the server, and tries to communicate with the secondary server if the secondary
server is configured and in active state. After the primary server quiet timer expires, the device
changes the status of the primary server back to active.
To set HWTACACS timers:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

view.
hwtacacs scheme
N/A
3.
Set the HWTACACS server

response timeout timer.
4.
Set the quiet timer for the

primary server.
Optional.
timer response-timeout seconds
The default HWTACACS server

response timeout timer is 5
seconds.
Optional.
timer quiet minutes
The default quiet timer for the

primary server is 5 minutes.
Displaying and maintaining HWTACACS

Task
Command
Remarks
Display the configuration or

statistics of HWTACACS schemes.
display hwtacacs [ hwtacacs-server-name

[ statistics ] ] [ | { begin | exclude |
include } regular-expression ]
Display information about buffered

stop-accounting requests for which
no responses have been received.
display stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
[ | { begin | exclude | include }
regular-expression ]
Clear HWTACACS statistics.
reset hwtacacs statistics { accounting | all |

authentication | authorization }
44
Task
Command
Remarks
Clear buffered stop-accounting

requests that do not get responses.
reset stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name
Configuring LDAP schemes

LDAP configuration task list
Task
Remarks
Creating an LDAP scheme
Required.
Specifying the LDAP authentication server
Required.
Specifying the LDAP authorization server
Optional.
Specifying the LDAP version
Optional.
Specifying the LDAP server type
Optional.
Setting the LDAP server timeout period
Optional.
Configuring administrator attributes
Required.
Configuring LDAP user attributes
Required.
Configuring LDAP group attributes
Optional.
Displaying and maintaining LDAP
Optional.
Creating an LDAP scheme

Before performing other LDAP configurations, you must create an LDAP scheme and enter LDAP scheme
view. You can configure up to 16 LDAP schemes. An LDAP scheme can be referenced by multiple ISP
domains, and can be deleted only when it is not referenced.
To create an LDAP scheme and enter LDAP scheme view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an LDAP scheme and

enter LDAP scheme view.
ldap scheme
ldap-scheme-name
By default, no LDAP scheme is present.
Specifying the LDAP authentication server

Changing the IP address and port number of the LDAP authentication server only affects LDAP
authentication processes that occur after your change.
To specify the LDAP authentication server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter LDAP scheme view.
ldap scheme ldap-scheme-name
N/A
3.
Specify the LDAP

authentication server.
authentication-server ip-address
[ port-number ]
45
Specifying the LDAP authorization server

Changing the IP address and port number of the LDAP authorization server only affects LDAP
authorization processes that occur after your change.
To specify the LDAP authorization server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the LDAP

authorization server.
authorization-server ip-address
[ port-number ]
Specifying the LDAP version

The device supports LDAPv2 and LDAPv3. A Microsoft LDAP server supports only LDAPv3.
To specify the LDAP version:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the LDAP version.
protocol-version { v2 | v3 }
Optional.
LDAPv3 is used by default.
Specifying the LDAP server type

The device supports LDAP servers by IBM, Microsoft, and Sun.
To specify the type of the LDAP server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the LDAP server

type.
server-type { ibm | microsoft |

sun }
Optional.
The default LDAP server type is microsoft.
Setting the LDAP server timeout period

If the device sends a bind or search request to an LDAP server but does not receive a response from the
server within the LDAP server timeout period, the device considers that the authentication or authorization
request has timed out and tries the backup authentication or authorization method, if any. If no backup
method is configured, the device considers the authentication or authorization attempt as a failure.
To set the LDAP server timeout period:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
46
Step
Command
Set the LDAP server timeout
period.
3.
Remarks
Optional.
server-timeout time-interval
The default LDAP server timeout

period is 10 seconds.
Configuring administrator attributes

To configure the administrator DN and password for binding with the LDAP server during LDAP
authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the administrator DN.
login-dn dn-string
4.
Configure the administrator

password.
login-password [ cipher | simple ]

password
The administrator DN specified on

the device must be consistent with
the administrator DN specified on
the LDAP server.
Configuring LDAP user attributes

To authenticate a user, an LDAP client must establish a connection to the LDAP server, obtain the user DN,
and use the user DN and the user's password to bind with the LDAP server. According to the LDAP DN
search mechanism, an LDAP client sends search requests to the server based on the search policy
determined by the LDAP user attributes of the LDAP client.
The LDAP user attributes include:
Search base DN
Search scope
User group attribute
Username attribute
Username format
User object class
If the user group attribute is configured on the LDAP server, the user group attribute setting on the device
must match the setting on the LDAP server.
A user DN search starting from the root directory might take a long time if the LDAP server has many
levels of directories. To improve search efficiency, you can change the start point by specifying the search
base DN.
If the usernames configured on the LDAP server do not contain domain names, configure the device to
remove domain names from the usernames to be sent to the LDAP server. Otherwise, configure the device
to send usernames containing domain names to the LDAP server.
The Microsoft LDAP server defines a default user group attribute named memberOf. If the Microsoft LDAP
server is used, the device obtains the user group by searching for the user DN.
47
The IBM LDAP server and Sun LDAP server have no default user group attribute, and you can configure
a user group attribute by modifying the schema file on the LDAP server. If the IBM server or Sun server is
used and there is no user-defined user group attribute, the device figures out the user group by checking
each user group to see whether it contains the user DN. For more information about user group attribute
configuration, see "Configuring LDAP group attributes."
To configure LDAP user attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the user search

base DN.
user-parameters search-base-dn
base-dn
4.
Specify the user search

scope.
user-parameters search-scope
{ all-level | single-level }
Optional.
The default user search scope is
all-level.
Optional.
5.
Specify the required user

group attribute.
user-parameters user-group-attribute
attribute-name
6.
Specify the username

attribute.
user-parameters user-name-attribute
{ name-attribute | cn | uid }
7.
Specify the username

format.
user-parameters user-name-format
{ with-domain | without-domain }
By default, no user group attribute

is specified, and the default user
group attribute defined on the
LDAP server is used.
Optional.
The default username attribute is
cn.
Optional.
The default username format is
without-domain.
Optional.
8.
Specify the user object

class.
user-parameters user-object-class
object-class-name
By default, no user object class is

specified, and the default user
object class on the LDAP server is
used. The default user object class
varies by device.
Configuring LDAP group attributes

User authorization is implemented by searching user groups and obtaining authorization information.
For a user group search, specify the search method and criteria (LDAP group attributes). Specifying
group attributes is necessary for IBM and Sun LDAP servers. Because the user object class of Microsoft
LDAP server contains user group attributes, specifying group attributes is unnecessary for Microsoft LDAP
server. Configurable LDAP group attributes are as follows:
Group name attribute
Group object class
Member name attribute
Search base DN
Search scope
48
Typically, the group object class and member name attribute take the default values defined by the server
manufacturers. If no default values are specified or you want to customize them, you can use commands
to configure the values.
A user group search starting from the root directory might take a long time if the LDAP server has many
levels of directories. To improve search efficiency, you can change the start point by specifying the search
base DN. Support for the group object class default and member name attribute default depends on the
LDAP server manufacturers. IBM and Sun support the default group object class and member name
attribute, but Microsoft does not have these defaults.
To configure LDAP group attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Specify the search base

DN for group search.
group-parameters search-base-dn
base-dn
4.
Specify the search scope

for group search.
group-parameters search-scope
{ all-level | single-level }
5.
Specify a user-defined
group object class for
group search.
group-parameters group-object-class
object-class-name
Optional.
Specify the member name

attribute for group search.
group-parameters
member-name-attribute
attribute-name
Optional.
Specify the group name

attribute for group search.
group-parameters
group-name-attribute
{ name-attribute | cn | uid }
Optional.
6.
7.
Optional.
The default search scope for group
search is all-level.
The default group name attribute

for group search is cn.
Displaying and maintaining LDAP

Task
Command
Remarks
Display the configuration of LDAP

schemes.
display ldap scheme [ scheme-name ] [ |

{ begin | exclude | include }
Configuring AAA methods for ISP domains

By default, the device uses local (default) AAA methods for users in an ISP domain. To use other AAA
methods for them, configure the device to reference existing AAA schemes for the ISP domain. For
information about configuring AAA schemes, see "Configuring RADIUS schemes," "Configuring
HWTACACS schemes," and "Configuring LDAP schemes."
To use local authentication for users in an ISP domain, first configure local user accounts on the device
(see "Configuring local user attributes").
49
Creating an ISP domain

In a networking scenario with multiple ISPs, the device can connect users from different ISPs. Different ISP
users can have different user attributes (such as username and password structures), different service
types, and different rights. To manage these ISP users, you need to create ISP domains and then
configure AAA methods and domain attributes for each ISP domain.
The device can accommodate up to 16 ISP domains, including the system-defined ISP domain system.
You can specify one ISP domain as the default domain.
On the device, each user belongs to an ISP domain. If a user provides no ISP domain name at login, the
device considers the user belongs to the default ISP domain.
The device chooses an authentication domain for each user in the following order:
The authentication domain specified for the access module
The ISP domain in the username
The default ISP domain of the device
The ISP domain specified for users with unknown domain names
If all the domains are unavailable, user authentication will fail.

NOTE:
Support for the authentication domain configuration depends on the access module. You can specify an
authentication domain for 802.1X, portal, or MAC address authentication.
To create an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an ISP domain and

enter ISP domain view.
domain isp-name
N/A
3.
Return to system view.
quit
N/A
Optional.
By default, the default ISP domain is the
system-defined ISP domain system.
4.
Specify the default ISP

domain.
domain default enable

isp-name
5.
Specify an ISP domain for

users with unknown domain
names.
domain if-unknown
isp-name
To delete the ISP domain that is

functioning as the default ISP domain,
you must change it to a non-default ISP
domain by using the undo domain
default enable command.
Optional.
By default, no ISP domain is specified for
users with unknown domain names.
To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default
ISP domain by using the undo domain default enable command.
50
Configuring ISP domain attributes

In an ISP domain, you can configure the following attributes:
Domain statusBy placing the ISP domain to the active or blocked state, you allow or deny
network service requests from users in the domain.
Maximum number of online usersThe device controls the number of online users in a domain to
ensure reliable system performance and services.
Idle cutEnables the device to check the traffic of each online user in the domain at the idle timeout
interval, and to log out any user in the domain whose traffic during the idle timeout period is less
than the specified minimum traffic.
Self-service server locationAllows users to access the self-service server to manage their own
accounts and passwords. A self-service RADIUS server running on IMC is required for the
self-service server location function to work.
IP address pool for allocating addresses to PPP usersThe device assigns IP addresses from the
pool to PPP users in the domain.
Default authorization user profileIf a user passes authentication but is not authorized with a user
profile, the device authorizes the default user profile of the ISP domain to the user and restricts the
user's behavior based on the profile. For more information about user profiles, see "Configuring a
user profile."
An ISP domain attribute applies to all users in the domain.

To configure ISP domain attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
3.
Place the ISP domain to the

active or blocked state.
state { active | block }
By default, an ISP domain is in active

state, and users in the domain can
request network services.
4.
Specify the maximum

number of online users in the
ISP domain.
access-limit enable
max-user-number
Optional.
Optional.
No limit is specified by default.

Optional.
5.
6.
Configure the idle cut

function.
idle-cut enable minute [ flow ]
Enable the self-service server

location function and specify
the URL of the self-service
server.
self-service-url enable url-string
This command is effective only for

LAN, portal, and PPP users.
In a portal stateful failover scenario,
set the idle cut interval to be greater
than 5 minutes to make sure data of
online users can be backed up.
51
Optional.
Step
Command
Remarks
Define an IP address pool

for allocating addresses to
PPP users.
ip pool pool-number
low-ip-address [ high-ip-address ]
8.
Specify the default

authorization user profile.
authorization-attribute
user-profile profile-name
9.
Set the device to include the

idle cut time in the user
online time to be uploaded
to the server.
7.
Optional.
By default, no IP address pool is
configured for PPP users.
Optional.
By default, an ISP domain has no
default authorization user profile.
Optional.
session-time include-idle-time
By default, the user online time

uploaded to the server excludes the
idle cut time.
Configuring authentication methods for an ISP domain

In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to
the interactive authentication process of username/password/user information during an access or
service request. The authentication process does not send authorization information to a supplicant or
trigger any accounting.
AAA supports the following authentication methods:
No authentication (none)The method trusts all users and does not perform authentication. For
security purposes, do not use the method.
Local authentication (local)Authentication is performed by the NAS, which is configured with the
user information, including the usernames, passwords, and attributes. Local authentication provides
high speed and low cost benefits, but the amount of information that can be stored is limited by the
size of the storage space.
Remote authentication (scheme)The NAS works with a RADIUS, HWTACACS, or LDAP server to
authenticate users. Remote authentication provides centralized information management, high
capacity, high reliability, and support for centralized authentication service for multiple NASs. You
can configure local or no authentication as the backup method, which will be used when the remote
server is not available. The no authentication method can only be configured for LAN users as the
backup method of remote authentication.
You can configure AAA authentication to work alone without authorization and accounting.
By default, an ISP domain uses the local authentication method.
Configuration prerequisites
Before configuring authentication methods, complete the following tasks:
For RADIUS, HWTACACS, or LDAP authentication, configure the RADIUS, HWTACACS, or LDAP
scheme to be referenced first. Local and none authentication methods do not require a scheme.
Determine the access type or service type to be configured. With AAA, you can configure an
authentication method for each access type and service type to limit the authentication protocols
that users can use for access.
Determine whether to configure the default authentication method for all access types or service
types.
52
Configuration guidelines
When configuring authentication methods, follow these guidelines:
If you configure an authentication method that references a RADIUS scheme and an authorization
method that does not reference a RADIUS scheme, AAA accepts only the authentication result from
the RADIUS server. The Access-Accept message from the RADIUS server also includes the
authorization information, but the device ignores the information.
You can configure a default authentication method for an ISP domain. The default method will be
used for all users who support the authentication method and have no specific authentication
method configured.
You can configure local authentication (local) or no authentication (none) as the backup for remote
authentication that is used when the remote authentication server is unavailable.
Local authentication (local) and no authentication (none) cannot have a backup method.
By default, the device uses the login username of the user for level switching authentication if the
method for level switching authentication references an HWTACACS scheme. If the method for level
switching authentication references a RADIUS scheme, the system uses the username configured for
the corresponding privilege level on the RADIUS server for level switching authentication, rather
than the login username. A username configured on the RADIUS server is in the format $enablevel$,
where level specifies the privilege level that the user wants to enter. For example, if user user1 of
domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for
authentication when the domain name is required and uses $enab3$ for authentication when the
domain name is not required.
Configuration procedure
To configure authentication methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
domain isp-name
N/A
3.
Specify the default

authentication method
for all types of users.
authentication default { hwtacacs-scheme

hwtacacs-scheme-name [ local ] |
ldap-scheme ldap-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
Optional.
4.
Specify the
for LAN users.
authentication lan-access { local | none |

radius-scheme radius-scheme-name [ local |
none ] }
Optional.
Specify the
for login users.
authentication login { hwtacacs-scheme

hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }
Specify the
for portal users.
authentication portal { ldap-scheme

ldap-scheme-name [ local ] | local | none |
radius-scheme radius-scheme-name [ local ] }
5.
6.
53
The default authentication

method is local for all types of
users.

method is used by default.
Optional.
Optional.
Step
Command
Remarks
Optional.
7.
Specify the
for PPP users.
authentication ppp { hwtacacs-scheme

[ local ] }
8.
Specify the
for privilege level
switching.
authentication super { hwtacacs-scheme

hwtacacs-scheme-name | radius-scheme
radius-scheme-name }
Specify the
for users accessing
through APs.
authentication wlan-ap radius-scheme

radius-scheme-name
9.

Support for this feature
depends on the device model.
For more information, see
About the Configuration
Guides for HP Unified
Optional.
Optional.
Configuring authorization methods for an ISP domain

In AAA, authorization is a separate process at the same level as authentication and accounting. It sends
authorization requests to the specified authorization servers and sends authorization information to users
after successful authorization. Authorization method configuration is optional in AAA configuration.
AAA supports the following authorization methods:
No authorization (none)The NAS performs no authorization exchange. After passing

authentication, non-login users can access the network, FTP users can access the root directory of
the NAS, and other login users have Level 0 (visiting) access.
Local authorization (local)The NAS performs authorization according to the user attributes
configured for users.
Remote authorization (scheme)The NAS works with a RADIUS, HWTACACS, or LDAP server to
authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization
can work only after RADIUS authentication is successful, and the authorization information is
included in the Access-Accept message. HWTACACS/LDAP authorization is separate from
HWTACACS/LDAP authentication, and the authorization information is included in the
authorization response after successful authentication. You can configure local authorization or no
authorization as the backup method. The backup method will be used when the remote server is not
available.
Before configuring authorization methods, complete the following tasks:
1.
For HWTACACS or LDAP authorization, configure the HWTACACS or LDAP scheme to be

referenced first. For RADIUS authorization, the RADIUS authorization scheme must be the same as
the RADIUS authentication scheme. Otherwise, it does not take effect.
2.
authorization scheme for each access type and service type to limit the authorization protocols that
can be used for access.
54
3.
Determine whether to configure an authorization method for all access types or service types.
When configuring authorization methods, follow these guidelines:
To configure RADIUS authorization, you must also configure RADIUS authentication, and reference
the same RADIUS scheme for RADIUS authentication and authorization. If the RADIUS
authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also
fails. If RADIUS authorization fails, the server sends an error message to the NAS, indicating that
the server itself is not responding.
You can configure a default authorization method for an ISP domain. This method will be used for
all users who support the authentication method and have no specific authorization method
configured.
You can configure local authorization (local) or no authorization (none) as the backup for remote
authorization that is used when the remote authorization server is unavailable.
Local authorization (local) and no authorization (none) cannot have a backup method.
To configure authorization methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
domain isp-name
N/A
3.
Specify the default

authorization method for
all types of users.
authorization default { hwtacacs-scheme

[ local ] }
Optional.
4.
Specify the command

authorization method.
authorization command { hwtacacs-scheme

hwtacacs-scheme-name [ local | none ] |
local | none }
Optional.
5.
Specify the authorization

method for LAN users.
authorization lan-access { local | none |

radius-scheme radius-scheme-name [ local |
none ] }
Optional.
6.

method for login users.
authorization login { hwtacacs-scheme

[ local ] }
7.

method for portal users.
authorization portal { local | none |

radius-scheme radius-scheme-name
[ local ] }
55
The default authorization

method is local for all types of
users.

Optional.
Optional.
Step
Command
Remarks
Optional.
8.

method for PPP users.
authorization ppp { hwtacacs-scheme

[ local ] }

Configuring accounting methods for an ISP domain

In AAA, accounting is a separate process at the same level as authentication and authorization. This
process sends accounting start/update/end requests to the specified accounting server. Accounting is
optional.
AAA supports the following accounting methods:
No accounting (none)The NAS does not perform accounting for the users.
Local accounting (local)Local accounting is implemented on the NAS. It counts and controls the
number of concurrent users who use the same local user account. It does not provide statistics for
charging. The maximum number of concurrent users using the same local user account is set by the
access-limit command in local user view.
Remote accounting (scheme)The NAS works with a RADIUS server or HWTACACS server for
accounting. You can configure local or no accounting as the backup method, which will be used
when the remote server is not available.
By default, an ISP domain uses the local accounting method.
Before configuring accounting methods, complete the following tasks:
1.
For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be

referenced first. The local and none accounting methods do not require a scheme.
2.
accounting method for each access type and service type to limit the accounting protocols that can
be used for access.
3.
Determine whether to configure an accounting method for all access types or service types.
When configuring accounting methods, follow these guidelines:
You can configure a default accounting method for an ISP domain. This method will be used for all
users who support the accounting method and have no specific accounting method configured.
You can configure local accounting (local) or no accounting (none) as the backup for remote
accounting that is used when the remote accounting server is unavailable.
Local accounting (local) and no accounting (none) cannot have a backup method.
Accounting is not supported for FTP services.
56
If you enable the accounting optional feature, the limit on the number of local user connections
does not take effect.
To configure accounting methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
domain isp-name
N/A
Optional.
With the accounting optional
feature, a device allows users
to use network resources when
no accounting server is
available or communication
with all accounting servers
fails.
3.
Enable the accounting

optional feature.
accounting optional
4.
Specify the default accounting

method for all types of users.
accounting default { hwtacacs-scheme

hwtacacs-scheme-name [ local ] | local
| none | radius-scheme
Optional.
5.
Specify the command

accounting method.
accounting command
hwtacacs-scheme
Optional.
6.
Specify the accounting

method for LAN users.
accounting lan-access { local | none |

[ local | none ] }
Optional.
7.

method for login users.
accounting login { hwtacacs-scheme

Optional.
8.

method for portal users.
accounting portal { local | none |

[ local ] }
Optional.
The default accounting method

is local for all types of users.

is used by default.
is used by default.

is used by default.

is used by default.
Optional.
9.

method for PPP users.
accounting ppp { hwtacacs-scheme

57

is used by default.
Tearing down user connections

Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Tear down AAA user

connections.
cut connection { access-type { dot1x |

mac-authentication | portal } | all | domain isp-name
| interface interface-type interface-number | ip
ip-address | mac mac-address | ucibindex ucib-index
| user-name user-name | vlan vlan-id }
The command
applies only to LAN,
portal, and PPP user
connections.
Configuring local EAP authentication

Local EAP authentication can be used in some simple application environments to authenticate 802.1X
users. In addition, it can help implement the RADIUS offload feature, which enables the NAS to terminate
EAP packets when the remote RADIUS server does not support EAP authentication. For more information
about RADIUS offload, see "Enabling the RADIUS offload feature."
Local EAP authentication is performed by the local EAP authentication server based on either the local
user database (the default) or an LDAP database. The local user database maintains all user accounts
configured on the NAS, but an LDAP database maintains user accounts configured on the LDAP server.
Using the local user database is cost effective but the maximum number of users is limited by the device's
hardware. If an LDAP server is available, using an LDAP database is a good practice because it allows
you to implement centralized user information management in scenarios with multiple NASs.
To implement local EAP authentication, complete these tasks:
1.
Configure the local EAP authentication server. See "Configuring the local EAP authentication
server."
2.
Configure the device to use local authentication for LAN users. This step is optional. See
"Configuring authentication methods for an ISP domain."
3.
Configure local users on the device, or add users on an LDAP server and configure an LDAP
scheme on the device. See "Configuring local users," "Configuring LDAP schemes," or the user
manuals of the LDAP server.
4.
Configure 802.1X on the device.
Configuring the local EAP authentication server

A local EAP authentication server is a local authentication server that uses an EAP profile. An EAP profile
is a collection of local EAP authentication settings, including the authentication method and user
database to be used and, for some authentication methods, the SSL server policy to be referenced. The
following EAP authentication methods are supported:
MD5 challenge
PEAP-GTC
PEAP-MSCHAPv2
58
TLS
TTLS
The device supports these user information query mechanisms: local query, LDAP query, and LDAP query
plus local query. With the last mechanism, local query is used when the LDAP server is not reachable, the
specified LDAP scheme does not exist, or the LDAP server does not support the query.
You can cannot modify or remove an EAP profile that is referenced by the local authentication server.
To configure the local EAP authentication server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an EAP profile and

enter EAP profile view.
eap-profile profile-name
N/A
By default, no EAP authentication
method is specified for an EAP profile.
3.
Specify the EAP

authentication method.
method { md5 | peap-gtc |

peap-mschapv2 | tls | ttls }
To configure multiple EAP

authentication methods, repeat this
step. A method configured earlier has
a higher priority.
PEAP-GTC and PEAP-MSCHAPv2 are
mutually exclusive.
4.
5.
Specify the user credential

verification approach for local
EAP authentication.
Specify the SSL server policy

for EAP authentication.
user-credentials { ldap-scheme
ldap-scheme-name [ local ] |
local }
Optional.
By default, the local user database is
used for user credential verification.
Perform this step when the EAP
authentication method of PEAP-GTC,
PEAP-MSCHAPv2, TLS, or TTLS is
configured.
ssl-server-policy policy-name
By default, no SSL server policy is

specified for an EAP profile.
For more information about SSL server
policy configuration, see "Configuring
SSL."
6.
quit
N/A
7.
Specify the EAP profile for the

local authentication server.
local-server authentication
eap-profile profile-name
N/A
Configuring a NAS ID-VLAN binding

The access locations of users can be identified by their access VLANs. Configure NAS ID-VLAN bindings
on the device in application scenarios where identifying the access locations of users is required. When
a user goes online, the device obtains the NAS ID by the access VLAN of the user and sends the NAS
ID to the RADIUS server through the NAS-identifier attribute.
To configure a NAS ID-VLAN binding:
59
Step
Command
Remarks
system-view
N/A
1.
Enter system view.
2.
Create a NAS ID profile and

enter NAS ID profile view.
aaa nas-id profile profile-name
You can apply a NAS ID profile to

an interface enabled with portal.
See "Configuring portal
authentication."
3.
Configure a NAS ID-VLAN

binding.
nas-id nas-identifier bind vlan

vlan-id
By default, no NAS ID-VLAN

binding exists.
Specifying the device ID

Devices operating in stateful failover mode for portal services are uniquely identified by their device IDs.
In stateful failover mode, a device ID can only be 1 or 2. For more information about the stateful failover
mode for portal services, see "Configuring portal authentication."
Do not configure any device ID for a device operating in standalone mode.
Configuring or changing the device ID of a device will log out all online users of the device. HP
recommends that you save the configuration and reboot the device after configuring or changing the
device ID.
To specify the device ID:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify the device ID.
nas device-id device-id
By default, the device ID is 1.
Displaying and maintaining AAA

Task
Command
Remarks
Display the configuration of

ISP domains.
display domain [ isp-name ] [ | { begin | exclude |

Display information about

user connections.
display connection [ access-type { dot1x |

mac-authentication | portal } | domain isp-name |
interface interface-type interface-number | ip
ip-address | mac mac-address | ucibindex
ucib-index | user-name user-name | vlan vlan-id ]
[ | { begin | exclude | include } regular-expression ]
AAA configuration examples

The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
60
When configuring the 11900/10500/7500 20G unified wired-WLAN module, make sure the settings
are correct (including VLAN settings) on the internal Ethernet interface that connects the module to the
switch. For more information, see HP 11900/10500/7500 20G Unified Wired-WLAN Module Basic
By default, the aggregate interfaces between the access controller engine and the switching engine on
an 830 switch or an 870 appliance are Access interfaces in VLAN 1. When configuring the two
aggregate interfaces, make sure their permitted VLANs are the same. HP also recommends that you set
their link type to be the same.
HWTACACS authentication and authorization for Telnet users

Network requirements
As shown in Figure 10, an HWTACACS server is located on 10.1.1.1/24 and uses the shared key expert
to authenticate AAA packets.
Configure the AC to do the following:
Use the HWTACACS server for user authentication and authorization.
Send usernames that do not include domain names to the server.
Use the shared key expert to authenticate packets exchanged with the server.
Figure 10 Network diagram

Authentication server
10.1.1.1/24
IP network
Telnet user
AP
AC
1.
On the HWTACACS server, set the shared key to expert and add the Telnet user account
information. (Details not shown.)
2.
Configure the AC:

# Assign IP addresses to the interfaces. (Details not shown.)
# Enable the Telnet server on the AC.
<AC> system-view
[AC] telnet server enable
# Configure the AC to use AAA for Telnet users.

[AC] user-interface vty 0 4
[AC-ui-vty0-4] authentication-mode scheme
[AC-ui-vty0-4] quit
# Create an ISP domain bbb and set it as the default ISP domain.
[AC] domain bbb
61
[AC-isp-bbb] quit
[AC] domain default enable bbb
# Create HWTACACS scheme hwtac.

[AC] hwtacacs scheme hwtac
# Specify the primary authentication server and the service port number.
[AC-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Specify the primary authorization server and the service port number.
[AC-hwtacacs-hwtac] primary authorization 10.1.1.1 49
# Set the shared keys for authentication and authorization to expert.

[AC-hwtacacs-hwtac] key authentication simple expert
[AC-hwtacacs-hwtac] key authorization simple expert
# Configure the scheme to remove the domain name from a username before sending the
username to the HWTACACS server.
[AC-hwtacacs-hwtac] user-name-format without-domain
[AC-hwtacacs-hwtac] quit
# Use either of the following methods to configure the authentication and authorization methods:
{
Create an ISP domain, and configure authentication and authorization methods for all login
users in the domain.
[AC] domain bbb
[AC-isp-bbb] authentication login hwtacacs-scheme hwtac
[AC-isp-bbb] authorization login hwtacacs-scheme hwtac
[AC-isp-bbb] quit
Create an ISP domain, and configure the default authentication and authorization methods for
all types of users in the domain.
[AC] domain bbb
[AC-isp-bbb] authentication default hwtacacs-scheme hwtac
[AC-isp-bbb] authorization default hwtacacs-scheme hwtac
Verifying the configuration

1.
Telnet to the AC, and enter the correct username and password.
2.
Use the display connection command on the AC to display information about the user connection.
Local authentication and HWTACACS authorization for Telnet

users
As shown in Figure 11, an HWTACACS server is located on 10.1.1.2/24 and uses the shared key expert
to authenticate AAA packets.
Configure the AC to do the following:
Perform local authentication for Telnet users.
Use the HWTACACS server for Telnet user authorization.
Send usernames that do not include domain names to the server.
Use the shared key expert to authenticate packets exchanged with the server.
62
Add a local user account on the AC, and set both the username and password to telnet. The user uses
this account to Telnet to the AC.
The local authentication and HWTACACS authorization configuration described in this section applies to
other types of users if you correctly modify the service type in the commands.
# Assign IP addresses to the interfaces. (Details not shown.)
# Enable the Telnet server on the AC.
<AC> system-view

[AC-ui-vty0-4] quit
# Create an ISP domain named bbb and set it as the default ISP domain.
[AC] domain bbb
[AC-isp-bbb] quit
# Create HWTACACS scheme hwtac.

# Specify the primary authorization server and the service port number.
[AC-hwtacacs-hwtac] primary authorization 10.1.1.2 49
# Set the shared key for authorization to expert.

[AC-hwtacacs-hwtac] key authorization simple expert
# Configure the scheme to remove the domain name from a username before sending the username to
the HWTACACS server.
# Configure a local user with the name telnet and password telnet.
[AC] local-user telnet
[AC-luser-telnet] service-type telnet
[AC-luser-telnet] password simple telnet
# Use either of the following methods to configure the AAA methods:

63
Create an ISP domain, and configure authentication and authorization methods for all login users
in the domain.
[AC] domain bbb

[AC-isp-system] authentication login local
[AC-isp-bbb] authorization login hwtacacs-scheme hwtac
[AC-isp-bbb] quit
Create an ISP domain, and configure the default authentication and authorization methods for all
types of users.
[AC] domain bbb

[AC-isp-bbb] authentication default local
[AC-isp-bbb] authorization default hwtacacs-scheme hwtac

1.
Telnet to the AC, and enter the username telnet and password telnet.
2.
Use the display connection command on the AC to display information about the user connection.
LDAP authentication for Telnet users

As shown in Figure 12, Active Directory of the Microsoft Windows 2003 Server is an LDAP server located
on 10.1.1.1/24, and the server domain name is ldap.com.
On the LDAP server, set the administrator password as admin!123456, and add a user with the username
of aaa and password of ldap!123456.
Configure the AC to use the LDAP server to authenticate Telnet users.
LDAP server
10.1.1.1/24
Vlan-int2
10.1.1.2/24
IP network
Telnet user
192.168.1.21/24
The AC does not support LDAP authorization. You can configure an HWTACACS scheme as the
authorization scheme to work with LDAP authentication. For more information about HWTACACS
scheme configuration, see "Configuring HWTACACS schemes."
1.
Configure user aaa and the administrator password on the LDAP server:
a. Select Administrative Tools > Active Directory Users and Computers from the Start menu or
launch it from the Windows Control Panel.
The Active Directory Users and Computers window appears.
b. Select Action > New > User in the top menu bar.
The New Object - User window appears.
64
c. Enter aaa in the First name, Full name, User logon name, and User logon name (pre-Windows
2000) fields, as shown in Figure 13, and then click Next.
Figure 13 Creating user aaa
d. Enter ldap!123456 in both the Password and Confirm password fields, select the password
strategy options as needed, and then click Next.
The New Object - User window closes.
Figure 14 Setting the user's password
e. Click ldap.com from the navigation tree.

The list of users in the ldap.com domain appears.
f. Right-click aaa and select Properties from the shortcut menu.
65
The aaa Properties window appears.

g. Click the Member Of tab, and then click Add.
The Select Groups window appears.
Figure 15 Modifying user properties
h. Enter Users in the Enter the object names to select field and click OK.
User aaa is added to the group Users.
Figure 16 Adding user aaa to group Users
i.
Right-click Administrator and select Set Password from the shortcut menu.
j.
In the dialog box, set the password to admin!123456. (Details not shown.)
66
2.
Configure the AC:

# Enable the AC to provide the Telnet service. (This step is optional because the Telnet service is
enabled by default.)
<AC> system-view
# Assign the IP address 10.1.1.2/24 to interface VLAN-interface 2, through which Telnet users
access the AC.
[AC] vlan 2
[AC-vlan2] quit
[AC] interface vlan-interface 2
[AC-Vlan-interface2] ip address 10.1.1.2 24
[AC-Vlan-interface2] quit

[AC-ui-vty0-4] quit
# Create ISP domain bbb and set it as the default ISP domain.
[AC] domain bbb
[AC-isp-bbb] quit
# Configure an LDAP scheme.

[AC] ldap scheme ldap1
# Specify the IP address of the LDAP authentication server.

[AC-ldap-ldap1] authentication-server 10.1.1.1
# Specify the administrator DN.

[AC-ldap-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com
# Set the administrator password.

[AC-ldap-ldap1] login-password simple admin!123456
# Configure the base DN for user search.

[AC-ldap-ldap1] user-parameters search-base-dn dc=ldap,dc=com
[AC-ldap-ldap1] quit
# Use either of the following methods to configure the authentication method:

{
Configure the LDAP scheme to provide the authentication method for login users.
[AC] domain bbb
[AC-isp-bbb] authentication login ldap-scheme ldap1
[AC-isp-bbb] quit
Configure the LDAP scheme to provide the default authentication method for all types of users.
[AC] domain bbb
[AC-isp-bbb] authentication default ldap-scheme ldap1

# Use the username aaa and password ldap!123456 to Telnet to the AC. After authentication in the
default ISP domain bbb is passed, you access the AC user interface.
67
Authentication and authorization for portal users by a RADIUS

server
As shown in Figure 17, the client has a public network IP address assigned manually or obtained through
DHCP.
Configure the AC to provide the following functions:
Authenticate and authorize portal users through the RADIUS server.
Direct portal authentication so that the client can access the Internet only when portal authentication
is passed.
Include the domain name in the usernames sent to the RADIUS server.
Set the shared keys for secure RADIUS communication to expert, and set the ports for
authentication/authorization to 1812.
Configure IP addresses for the devices as shown in Figure 17 and make sure the devices can reach each
other. (Details not shown.)
Configuring the RADIUS server

In this section, the server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301).
1.
Add the AC to the IMC Platform as an access device:

a. Click the Service tab.
b. From the navigation tree, select User Access Manager > Access Device Management > Access
Device.
The Access Device page appears.
c. Click Add.
The Add Access Device page appears, as shown in Figure 18.
d. In the Access Configuration area, configure the following parameters for the access device:
Enter expert in the Shared Key field.

68
Select LAN Access Service from the Service Type list.
Select HP(General) from the Access Device Type list.
Use the default settings for other parameters.
e. In the Device List area, select the access device from the device list or manually add the device
with the IP address 10.1.1.2.
The IP address of the access device must be the same as the source IP address of the RADIUS
packets sent from the AC, which is chosen in the following order:
IP address specified with the nas-ip command.
IP address specified with the radius nas-ip command.
IP address of the outbound interface (the default).
f. Click OK.
Figure 18 Adding an access device
2.
Add a service:
b. From the navigation tree, select User Access Manager > Service Configuration.
The Service Configuration page appears.
c. Click Add.
The Add Service Configuration page appears, as shown in Figure 19.
d. Enter Portal-auth in the Service Name field.
e. Enter dm1 in the Service Suffix field.
Make sure the service suffix is the same as the name of the domain in which portal users are
authenticated.
f. Click OK.
69
Figure 19 Adding a service
3.
Add an account for portal users and assign the previous service to the account:
a. Click the User tab.
b. From the navigation tree, select Access User View > All Access Users.
The All Access Users page appears.
c. Click Add.
The Add Access User page appears, as shown in Figure 20.
d. In the Access Information area, configure the user account:
Select or add a platform user named hello.
Enter portal in the Account Name field.
Set a password for the user and confirm the password.
e. In the Access Service area, select Portal auth on the Access Service list.
f. Click OK.
Figure 20 Adding an access user account
Configuring the portal server

1.
Configure the portal server:

b. From the navigation tree, select User Access Manager > Portal Service > Server.
The Server page appears, as shown in Figure 21.
70
c. In the Portal Page field, enter the URL address of the portal authentication main page, in the
format of http://ip:port/portal, where ip and port are those configured during IMC UAM
installation. The default setting of port 8080 is typically used.
d. Click OK.
Figure 21 Portal server configuration
2.
Configure an IP address group:

a. From the navigation tree, select User Access Manager > Portal Service > IP Group.
The IP Group page appears.
b. Click Add.
The Add IP Group page appears, as shown in Figure 22.
c. Enter Portal_user in the IP Group Name field.
d. Set the start IP address to 192.168.1.1 and the end IP address to 192.168.1.255. Make sure
the IP address group contains the IP address of the AC.
e. Select Normal from the Action list.
f. Click OK.
Figure 22 Adding an IP address group
71
3.
Configure the AC as a portal device:

a. From the navigation tree, select User Access Manager > Portal Service > Device.
The Device page appears.
b. Click Add.
The Add Device page appears, as shown in Figure 23.
c. Enter NAS in the Device Name field.
d. Enter 192.168.1.70 in the IP Address field, which is the IP address of the access interface on
the AC.
e. Enter portal in the Key field. Make sure the key is the same as that configured on the AC.
f. Select No from the Reallocate IP list to disable IP address reallocation in this example.
g. Click OK.
Figure 23 Adding a portal device
4.
Associate the portal device with the IP address group:

a. On the Device Information List as shown in Figure 24, click the icon in the Port Group column
for NAS.
The Configure Port Group page appears.
b. Click Add.
The Add Port Group page appears, as shown in Figure 25.
c. Enter group in the Port Group Name field.
d. Select Portal_user from the IP Group list.
e. Click OK.
Figure 24 Portal device list
72
Figure 25 Associating the portal device with the IP address group
5.
Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the portal server configuration.
Configuring the AC
1.
Configure a RADIUS scheme:

# Create a RADIUS scheme named rs1 and enter its view.
<AC> system-view
[AC] radius scheme rs1
# Set the server type for the RADIUS scheme. To support IMC, set the server type to extended.
[AC-radius-rs1] server-type extended
[AC-radius-rs1] primary authentication 10.1.1.1 1812
# Set the shared key to expert in plain text for secure RADIUS communication.
[AC-radius-rs1] key authentication simple expert
# Specify the scheme to include the domain names in usernames to be sent to the RADIUS server.
[AC-radius-rs1] user-name-format with-domain
[AC-radius-rs1] quit
2.
Configure an authentication domain:

# Create an ISP domain named dm1 and enter its view.
[AC] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.

[AC-isp-dm1] authentication portal radius-scheme rs1
[AC-isp-dm1] authorization portal radius-scheme rs1
[AC-isp-dm1] quit
3.
Configure portal authentication:

# Configure the portal server.
[AC] portal server newpt ip 10.1.1.1 key portal port 50100 url
http://10.1.1.1:8080/portal
[AC] portal free-rule 0 source interface ten-gigabitethernet 1/0/1 destination any
# Enable portal authentication on the interface connecting the wireless client.

[AC-Vlan-interface2] portal server newpt method direct
73
# Specify the portal authentication domain.

[ACVlan-interface2] portal domain dm1
[ACVlan-interface2] quit

The user can initiate portal authentication by using the iNode client or by accessing a web page. All the
initiated web requests will be redirected to the portal authentication page at http://10.1.1.1:8080/portal.
Before passing portal authentication, the user can access only the authentication page. After passing
portal authentication, the user can access the Internet.
After the user passes portal authentication, display the portal user information on the AC.
[AC] display portal user interface vlan-interface 2
Index:19
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
MAC
IP
Vlan
Interface
--------------------------------------------------------------------0015-e9a6-7cfe
192.168.1.58
Vlan-interface2
Total 1 user(s) matched, 1 listed.
# Use the display connection command to view the connection information on the AC.
[AC] display connection
Index=20
,Username=portal@dm1
MAC=00-15-E9-A6-7C-FE
IP=192.168.1.58
IPv6=N/A
Online=03h01m37s
Total 1 connection(s) matched.
Authentication and authorization for 802.1X users by a

RADIUS server
As shown in Figure 26, configure the AC to provide the following functions:
Implement authentication and authorization for the 802.1X user on the client through the RADIUS
server.
Use the WLAN-ESS port as the authentication port.
Include the domain name in the username sent to the RADIUS server. The username is dot1x@bbb.
Set the shared key for secure RADIUS communication to expert, and set the port for
authentication/authorization to 1812.
Configure the RADIUS server to assign the client to VLAN 4 when authentication is passed.
74
Configure the interfaces and VLANs as shown in Figure 26. Make sure the client can get a new IP
address manually or automatically and can access resources in the authorized VLAN after passing
authentication.
Configuring the RADIUS server

1.
Add the AC to the IMC Platform as an access device:

b. From the navigation tree, select User Access Manager > Access Device Management > Access
Device.
The Access Device page appears.
c. Click Add.
The Add Access Device page appears, as shown in Figure 27.
d. In the Access Configuration area, configure the access device:
Enter expert in the Shared Key field.
Select LAN Access Service from the Service Type list.
Select HP(General) from the Access Device Type list.
Use the default settings for other parameters.
e. In the Device List area, select the access device from the device list or manually add the device
with the IP address 10.1.1.2.
The IP address of the access device must be the same as the source IP address of the RADIUS
packets sent from the AC, which is chosen in the following order:
IP address specified with the nas-ip command.
IP address specified with the radius nas-ip command.
IP address of the outbound interface (the default).
f. Click OK.
75
2.
Add a service:
b. From the navigation tree, select User Access Manager > Service Configuration.
The Service Configuration page appears.
c. Click Add.
The Add Service Configuration page appears, as shown in Figure 28.
d. Enter Dot1x auth in the Service Name field.
e. Enter bbb in the Service Suffix field.
Make sure the service suffix is the same as the name of the domain in which the 802.1X user
is authenticated.
f. If certificate authentication is required, configure parameters in the Authorization Information
area:
Click EAP next to the Certificate Authentication field.
Select EAP-PEAP AuthN from the Certificate Type list.
Select MS-CHAPv2 AuthN from the Certificate Sub-Type list.
Select the Deploy VLAN option, and enter 4 in the box.
g. Click OK.
76
Figure 28 Adding a service
3.
Add an account for portal users and assign the previous service to the account:
b. From the navigation tree, select Access User View > All Access Users.
The All Access Users page appears.
c. Click Add.
The Add Access User page appears, as shown in Figure 29.
d. In the Access Information area, configure the access user:
Select or add a platform user named test.
Enter dot1x in the Account Name field.
Set a password for the user and confirm the password.
e. In the Access Service area, select Dot1x auth on the Access Service list.
f. Click OK.
77
Figure 29 Adding an access user account
Configuring the AC
1.

# Create a RADIUS scheme named rad and enter its view.
<AC> system-view
[AC] radius scheme rad
# Set the server type for the RADIUS scheme. To support IMC, set the server type to extended.
[AC-radius-rad] server-type extended
[AC-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key to expert in plain text for secure RADIUS communication.
[AC-radius-rad] key authentication simple expert
# Specify the scheme to include the domain names in usernames to be sent to the RADIUS server.
[AC-radius-rad] user-name-format with-domain
[AC-radius-rad] quit
2.

# Create an ISP domain named bbb and enter its view.
[AC] domain bbb
# Configure the ISP domain to use RADIUS scheme rad.

[AC-isp-bbb] authentication lan-access radius-scheme rad
[AC-isp-bbb] authorization lan-access radius-scheme rad
[AC-isp-bbb] quit
3.
Configure 802.1X authentication:

# Enable port security globally.
[AC] port-security enable
# Specify the 802.1X authentication method.

[AC] dot1x authentication-method eap
# Create a WLAN-ESS interface and configure the port security mode as userLoginSecureExt.
[AC] interface wlan-ess 1
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext
# Enable the key negotiation function for the port.

[AC-WLAN-ESS1] port-security tx-key-type 11key
78
# Disable the online user handshake function.

[AC-WLAN-ESS1] undo dot1x handshake
# Disable the 802.1X multicast trigger function.

[AC-WLAN-ESS1] undo dot1x multicast-trigger
# Configure the port to use mandatory authentication domain bbb. The AC will use the
authentication and authorization methods of this domain for all users accessing this port. This step
is optional.
[AC-WLAN-ESS1] dot1x mandatory-domain bbb
[AC-WLAN-ESS1] quit
# Configure the WLAN service template.

[AC] wlan service-template 1 crypto
[AC-wlan-st-1] ssid sectest
[AC-wlan-st-1] bind WLAN-ESS 1
[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] cipher-suite tkip
[AC-wlan-st-1] security-ie wpa
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit
# Create an AP template named ap1, and specify its model as MSM460-WW and serial number
as CN2AD330S8.
[AC] wlan ap ap1 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8
# Bind service template 1 to radio 1.

[AC-wlan-ap-ap1] radio 1 type dot11an
[AC-wlan-ap-ap1-radio-1] service-template 1
[AC-wlan-ap-ap1-radio-1] radio enable
[AC-wlan-ap-ap1-radio-1] quit
[AC-wlan-ap-ap1] quit

To use the 802.1X client of Windows XP, follow these steps:
1.
Click the Authentication tab on the Properties dialog box of 802.1X connection, select the Enable
IEEE 802.1X authentication for this network option and select Protected EAP (PEAP) from the EAP
Type list.
2.
Enter the correct username and password in the authentication page.
To use the iNode client, enter username dot1x@bbb and the correct password in the client property
window.
After the user passes authentication, the server assigns the port connecting the client to VLAN 4.
# Use the display connect command to view the connection information on the AC.
Index=22
, Username=dot1x@bbb
MAC=0015-e9a6-7cfe
IP=192.168.1.58
IPv6=N/A
Online=00h01m37s
79
# View the information of the specified connection on the AC.

[AC] display connection ucibindex 22
Index=22
, Username=dot1x@bbb
MAC=0015-e9a6-7cfe
IP=192.168.1.58
IPv6=N/A
Access=8021X
,AuthMethod=EAP
Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:1

Initial VLAN=2, Authorized VLAN=4
ACL Group=Disable
User Profile=N/A
CAR=Disable
Traffic Statistic:
InputOctets
=12121212
InputGigawords=1
OutputOctets
=12120
OutputGigawords=0
Priority=Disable
SessionTimeout=60(s), Terminate-Action=Radius-Request
Start=2013-05-26 19:41:12 ,Current=2013-05-26 19:41:25 ,Online=00h00m14s
Total 1 connection matched.
The Authorized VLAN field in the output shows VLAN 4 has been assigned to the user.
Local EAP authentication and authorization for 802.1X users

As shown in Figure 30, configure the AC to perform local EAP authentication and authorization for
802.1X users.
Use the EAP-MD5 authentication method for the 802.1X user.
Add the 802.1X user to user group dot1x.
Configure the authorized VLAN of VLAN 100 for the user group.

Internet
Client
802.1X user
AP
Vlan-int2
192.168.1.1/24
AC
1.
Configure the 802.1X connection properties if the 802.1X client of Windows XP is used:
a. Open the Properties dialog box of the 802.1X connection.
b. On the Authentication tab, select the Enable IEEE 802.1X authentication for this network option
and select MD5-Challenge from the EAP Type list.
c. Click OK.
80
2.
Configure the AC:

# Create user group dot1x, configure the authorized VLAN as VLAN 100.
<AC> system-view
[AC] user-group dot1x
[AC-ugroup-dot1x] authorization-attribute vlan 100
[AC-ugroup-dot1x] quit
# Create local user usera, and add the user to user group dot1x.
[AC] local-user usera
[AC-luser-usera] group dot1x
[AC-luser-usera] password simple 1234
[AC-luser-usera] service-type lan-access
[AC-luser-usera] quit
# Configure the ISP domain to use local authentication and authorization.

[AC] domain mydomain
[AC-isp-mydomain] authentication lan-access local
[AC-isp-mydomain] authorization lan-access local
[AC-isp-mydomain] quit
# Configure an EAP profile, specifying to use EAP-MD5 for authentication.

[AC] eap-profile eapsvr
[AC-eap-prof-eapsvr] method md5
[AC-eap-prof-eapsvr] quit
# Configure the local EAP authentication server, specifying to use EAP profile eapsvr.
[AC] local-server authentication eap-profile eapsvr


# Create a WLAN interface and configure the port security mode as userLoginSecureExt.



# Configure the port to use mandatory authentication domain mydomain. The AC will use the
authentication, authorization, and accounting methods of this domain for all users accessing this
port. This step is optional.
[AC-WLAN-ESS1] dot1x mandatory-domain mydomain
[AC-WLAN-ESS1] quit
# Create a WLAN service template.

81

[AC-wlan-st-1] quit
as CN2AD330S8.


1.
Trigger EAP authentication and enter the 802.1X username usera@mydomain and password
1234.
2.
Use the display connection command on the AC to view the user's connection information.
3.
Use the display interface wlan-dbss command to check that the WLAN-DBSS access port belongs
to VLAN 100.
RADIUS offload for 802.1X users

As shown in Figure 31, configure the AC to work with the RADIUS server for RADIUS authentication,
authorization, and accounting of 802.1X users.
The RADIUS server does not support EAP authentication.
Configure PEAP-MSCHAPv2 authentication between the 802.1X client and the AC.
Configure the AC and the RADIUS server to use the shared key expert to secure RADIUS
authentication and accounting.
82
To use the 802.1X client of Windows XP, configure the 802.1X connection properties as follows:
and select Protected EAP (PEAP) from the EAP Type list.
c. Click Properties, and in the popup dialog box, select Secured password (EAP-MSCHAP v2)
from the Select Authentication Method list and click OK.
d. Click OK.
To use the iNode client, configure the 802.1X connection properties as follows:
a. Open the Properties dialog box of the 802.1X connection in the iNode client.
b. On the General tab, select the Enable advanced authentication option and select the Certificate
authentication option.
c. Click OK.
On the RADIUS server, configure the shared key for authenticating packets exchanged with the AC
to expert, and add a username and password for the 802.1X user. (Details not shown.)
1.
Obtain the CA certificate and local certificate.

If the CA certificate file and local certificate file are already saved on the AC, import the
certificates in offline mode. Otherwise, you must request a local certificate for the AC and obtain
the CA certificate in online mode. Suppose that the PKI domain is eappki. For more information
about the configuration steps, see "Configuring PKI."
2.
Create SSL server policy eapsvr and configure it to use PKI domain eappki.
<AC> system-view
[AC] ssl server-policy eapsvr
[AC-ssl-server-policy-eapsvr] pki-domain eappki
[AC-ssl-server-policy-eapsvr] quit
3.
Configure the local EAP authentication server:

# Create an EAP profile.
# Configure the EAP profile to use PEAP-MSCHAPv2 authentication.

[AC-eap-prof-eapsvr] method peap-mschapv2
# Configure the EAP profile to use SSL server policy eapsvr for EAP authentication.
[AC-eap-prof-eapsvr] ssl-server-policy eapsvr
4.
Configure AAA:
# Configure a RADIUS scheme that supports the EAP offload function.
[AC] radius scheme radoff
[AC-radius-radoff] primary authentication 10.1.1.1
[AC-radius-radoff] primary accounting 10.1.1.1
[AC-radius-radoff] key authentication simple expert
[AC-radius-radoff] key accounting simple expert
83
[AC-radius-radoff] eap offload method peap-mschapv2

[AC-radius-radoff] quit
# Configure the AAA method for the ISP domain.

[AC] domain bbb
[AC-isp-bbb] authentication lan-access radius-scheme radoff
[AC-isp-bbb] authorization lan-access radius-scheme radoff
[AC-isp-bbb] accounting lan-access radius-scheme radoff
[AC-isp-bbb] quit
5.
Configure 802.1X:




[AC-WLAN-ESS1] quit

[AC-wlan-st-1] quit
as CN2AD330S8.

84

1.
Use the display radius scheme radoff and display domain bbb commands to view AAA
configuration.
2.
Use the display dot1x interface wlan-ess1 command to view 802.1X configuration.
3.
After the 802.1X user passes EAP authentication by using the username in the username@bbb
format and successfully logs in, use the display connection command to display the user's
connection information.
Level switching authentication for Telnet users by an

HWTACACS server
As shown in Figure 32, the Telnet user communicates with the AC through the AP and the AC connects
to the HWTACACS server. Configure the AC to use the HWTACACS server for level switching
authentication of the Telnet user:
Configure an ACS server to act as an HWTACACS server for Telnet user authentication. The IP
address of the server is 10.1.1.1/24.
Set the shared key for authenticating authentication packets to expert, and specify that usernames
sent to the HWTACACS server do not include domain names.
Configure the AC to use local authentication for the Telnet user and assign the privilege level of 0
for the user after login.
Configure the AC to use the HWTACACS server and, if HWTACACS authentication is not available,
use local authentication for level switching authenticate of the Telnet user.
1.
Configure the HWTACACS server.

In this example, the HWTACACS server runs ACSv4.0.
Add a user named test on the HWTACACS server, and configure advanced attributes for the user
as follows:
a. Select Max Privilege for any AAA Client and set the privilege level to level 3. This setting
requires the user to enter the password when switching to level 1, level 2, or level 3.
b. Select Use separate password and specify the password as enabpass.
85
Figure 33 Configuring advanced attributes for the Telnet user
2.
Configure the AC:

# Assign an IP address to VLAN-interface 2, the interface used to connect the client.
<AC> system-view
[AC-Vlan-interface2] ip address 192.168.1.70 255.255.255.0
# Assign an IP address to VLAN-interface 3, the interface used to connect the server.

# Enable the AC to provide Telnet services.


[AC-ui-vty0-4] quit
# Create an ISP domain bbb and set it as the default ISP domain.
[AC] domain bbb
[AC-isp-bbb] quit
# Create an HWTACACS scheme named hwtac.

# Specify the IP address of the primary authentication server as 10.1.1.1 and the port for
authentication as 49.
[AC-hwtacacs-hwtac] primary authentication 10.1.1.1 49
86
# Set the shared key for authenticating authentication packets to expert.

[AC-hwtacacs-hwtac] key authentication simple expert
# Specify that usernames sent to the HWTACACS server do not include domain names.
# Configure ISP domain bbb to use local authentication for Telnet users.
[AC] domain bbb
[AC-isp-bbb] authentication login local
# Configure to use HWTACACS scheme hwtac for privilege level switching authentication.
[AC-isp-bbb] authentication super hwtacacs-scheme hwtac
[AC-isp-bbb] quit
# Create a local Telnet user account test.

[AC] local-user test
[AC-luser-test] service-type telnet
[AC-luser-test] password simple aabbcc
# Configure the user level of the Telnet user as 0 after user login.
[AC-luser-test] authorization-attribute level 0
[AC-luser-test] quit
# Configure the AC to use the HWTACACS server for level switching authentication, and to use
local authentication as the backup method.
[AC] super authentication-mode scheme local
# Configure the password for privilege level switching authentication as 654321.

[AC] super password simple 654321
[AC] quit

1.
Telnet to the AC from the client, and enter the username test and password aabbcc. After login,
you can access level 0 commands.
2.
Perform user privilege level switching:

# Execute the command for switching to user privilege level 3 and enter password pass3 as
prompted.
<AC> super 3
Password:
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
# If the ACS server is not reachable, enter password 654321 as prompted for local authentication.
<AC> super 3
Password:
Enter the password for HWTACACS level switching authentication
Error: Invalid configuration or no response from the authentication server.

Info: Change authentication mode to local.
Password:
Enter the password for local level switching authentication
User privilege level is 3, and only those commands can be used

whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
87
Local EAP authentication for 802.1X users by an LDAP server

As shown in Figure 34, an 802.1X client connects to an AC that connects to an LDAP server. The IP
address of the LDAP server is 10.1.1.1/24 and the domain name is ldap.com.
Configure the AC to perform local EAP authentication for 802.1X users and to use the LDAP server for
user identity authentication.
and select the smart card or other certificates as the EAP authentication type.
c. Click Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area
and click OK.
d. Click OK.
1.
Configure the LDAP server.

Set the administrator's password to admin!123456, add user aaa (this username is the DN of the
local certificate) and set the password for the user to ldap!123456. For more information about
LDAP server configuration, see "LDAP authentication for Telnet users."
2.
Configure the AC:

# Obtain the CA certificate and the local certificate.
If the AC has saved the CA certificate file and local certificate file, import them in offline mode.
Otherwise, you must request a local certificate for the AC and obtain the CA certificate in online
mode. Suppose that the PKI domain is eappki. For more information about the configuration steps,
see "Configuring PKI."
88
# Specify an LDAP scheme.

<AC> system-view
[AC] ldap scheme ldap1
# Specify the IP address of the LDAP authentication server.

[AC-ldap-ldap1] authentication-server 10.1.1.1
# Specify the administrator DN.

[AC-ldap-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com
# Specify the administrator password.

[AC-ldap-ldap1] login-password simple admin!123456
# Configure the base directory for user search.

[AC-ldap-ldap1] user-parameters search-base-dn dc=ldap,dc=com
[AC-ldap-ldap1] quit
# Specify the domain to use local authentication/authorization. (Authorization for 802.1X users
by an LDAP server is not supported. Local authorization is used here)
[AC] domain bbb
[AC-isp-bbb] authentication lan-access local
[AC-isp-bbb] authorization lan-access local
[AC-isp-bbb] quit
# Configure the SSL server policy sp1, specifying the PKI domain to be used as eappki.
[AC] ssl server-policy sp1
[AC-ssl-server-policy-sp1] pki-domain eappki
[AC-ssl-server-policy-sp1] quit
# Create an EAP profile and configure it to use EAP-TLS for authentication.

[AC-eap-prof-eapsvr] method tls
# Specify the SSL server policy for EAP authentication as sp1.

[AC-eap-prof-eapsvr] ssl-server-policy sp1
# Use the LDAP database for user credential verification and reference the LDAP scheme ldap1.
[AC-eap-prof-eapsvr] user-credentials ldap-scheme ldap1





89
[AC-WLAN-ESS1] quit

[AC-wlan-st-1] quit
as CN2AD330S8.


1.
Use the display dot1x interface wlan-ess 1 command to check the configuration.
2.
After the 802.1X user passes certificate-based EAP authentication, check the user's connectivity
status by using the display connection command.
Temporary access control of wireless users

Wireless users temporarily access the network through an AP whose ID is CN2AD330S8. The AC uses
local EAP authentication (EAP-TLS) for user authentication.
Configure a guest account on the AC for the wireless users and configure the following restrictions for the
guest account:
The expiration time of the guest account is 12:00:00 on August 8, 2013.
Only users with the SSID aabbcc can use the guest account for login.
90

AC
Internet
Client
AP
L2 switch
Client
and select the smart card or other certificates as the EAP authentication type.
c. Click Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area
and click OK.
d. Click OK.
1.
Obtain the CA certificate and the local certificate.

If the AC has a copy of the CA certificate file and local certificate file, import the certificates in
offline mode. Otherwise, request a certificate for the AC and obtain the CA certificate in online
mode. The PKI domain for the certificate is eappki. (Details not shown. For information about PKI
configuration, see Security Configuration Guide.)
2.
Create the SSL server side policy eapsvr and specify the PKI domain as eappki.
<AC> system-view
[AC] ssl server-policy eapsvr
[AC-ssl-server-policy-eapsvr] pki-domain eappki
[AC-ssl-server-policy-eapsvr] quit
3.
Configure port security:

# Set the 802.1X authentication method to EAP.

# Create a WLAN interface and configure the port security mode.

91
# Disable the multicast trigger function.


# Configure the port to use mandatory authentication domain test. With this configuration, the AC
will use the authentication, authorization, and accounting methods of this domain for all 802.1X
users accessing the port. This configuration is optional.
[AC-WLAN-ESS1] dot1x mandatory-domain test
[AC-WLAN-ESS1] quit
4.
Configure AAA methods:

# Create an ISP domain and configure the domain to use local authentication and authorization
methods.
[AC] domain test
[AC-isp-test] authentication lan-access local
[AC-isp-test] authorization lan-access local
[AC-isp-test] quit
# Configure domain test as the default domain.

[AC] domain default enable test
5.
Configure the local EAP authentication server

# Create an EAP profile and configure it to use EAP-TLS for authentication.
[AC-eap-prof-eapsvr] method tls
# Specify the SSL server side policy for EAP authentication as eapsvr.
[AC-eap-prof-eapsvr] ssl-server-policy eapsvr
6.
Configure WLAN service:

# Configure the service template.
[AC] wlan service-template 1 clear
[AC-wlan-st-1] ssid aabbcc
[AC-wlan-st-1] quit
# Configure the AP.

[AC] wlan ap 1 model MSM460-WW
[AC-wlan-ap-1] serial-id CN2AD330S8
[AC-wlan-ap-1] radio 1 type dot11an
[AC-wlan-ap-1-radio-1] service-template 1
[AC-wlan-ap-1-radio-1] radio enable
[AC-wlan-ap-1-radio-1] quit
[AC-wlan-ap-1] quit
7.
Create a user profile and configure it to permit users with an SSID of aabbcc. For more information
about SSID-based WLAN access control, see WLAN Configuration Guide.
[AC] user-profile manager
92
[AC-user-profile-manager] wlan permit-ssid aabbcc

[AC-user-profile-manager] quit
# Enable the user profile.

[AC] user-profile manager enable
# Create guest account guest and specify the password and service type.
[AC] local-user guest
[AC-luser-guest] password simple guest
[AC-luser-guest] service-type lan-access
# Set the expiration time of the guest account to 12:00:00 on August 8, 2013.
[AC-luser-guest] expiration-date 12:00:00-2013/08/08
# Specify the authorization user profile of the guest account as manager.

[AC-luser-guest] authorization-attribute user-profile manager
[AC-luser-guest] quit

# Verify that wireless clients using the SSID of aabbcc can pass local EAP authentication and log in as
guests before 12:00:00 August 8, 2013.
Troubleshooting AAA
Troubleshooting RADIUS
Symptom 1
User authentication/authorization always fails.
Analysis
Possible reasons include:
A communication failure exists between the NAS and the RADIUS server.
The username is not in the format userid@isp-name or the ISP domain is not correctly configured on
the NAS.
The user is not configured on the RADIUS server.
The password entered by the user is incorrect.
The RADIUS server and the NAS are configured with different shared keys.
Solution
Check the following:
The NAS and the RADIUS server can ping each other.
The username is in the userid@isp-name format and the ISP domain is correctly configured on the
NAS.
The user is configured on the RADIUS server.
The correct password is entered.
The same shared key is configured on both the RADIUS server and the NAS.
93
Symptom 2
RADIUS packets cannot reach the RADIUS server.
Analysis
A communication failure exists between the NAS and the RADIUS server.
The NAS is not configured with the IP address of the RADIUS server.
The authentication/authorization and accounting UDP ports configured on the NAS are incorrect.
The RADIUS server's authentication/authorization and accounting port numbers are being used by
other applications.
Solution
The link between the NAS and the RADIUS server work well at both the physical and data link
layers.
The IP address of the RADIUS server is correctly configured on the NAS.
The authentication/authorization and accounting UDP ports configured on the NAS are the same
as those of the RADIUS server.
The RADIUS server's authentication/authorization and accounting port numbers are available.
Symptom 3
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
The accounting server configuration on the NAS is not correct. Possible reasons include:
The accounting port number configured on the NAS is incorrect.
The accounting server IP address configured on the NAS is incorrect. For example, the NAS is
configured to use a single server to provide authentication, authorization, and accounting services,
but in fact the services are provided by different servers.
Solution
The accounting port number is correctly configured.
The accounting server IP address is correctly configured on the NAS.
Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."
Troubleshooting LDAP
Symptom
User authentication/authorization fails.
94
Analysis
A communication failure exists between the NAS and the LDAP server.
The LDAP server IP address or port number configured on the NAS is not correct.
The username is not in the format userid@isp-name, or the ISP domain is not correctly configured on
the NAS.
The user is not configured on the LDAP server.
The password entered by the user is not correct.
The administrator DN or password is not configured.
Some user attributes (for example, the username attribute) and the group attributes configured on
the NAS are not consistent with those configured on the server.
No user search base DN for authentication is specified for the LDAP scheme.
No group search base DN for authorization is specified for the LDAP scheme.
Solution
The NAS and the LDAP server can ping each other.
The IP addresses and port numbers of authentication and authorization servers configured on the
NAS match those of the servers.
The username is in the correct format and the ISP domain is correctly configured on the NAS.
The user is configured on the LDAP server.
The correct password is entered.
The administrator DN and the administrator password are correctly configured.
The user attributes (for example, the username attribute) and group attributes configured on the
NAS are consistent with those configured on the LDAP servers.
The user search base DN for authentication is specified.
The group search base DN for authorization is specified.
95
802.1X overview
802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN
committee for securing WLANs, and it has also been widely used on Ethernet networks for access
control.
802.1X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports.
802.1X architecture
802.1X operates in the client/server model. It comprises three entities: the client (the supplicant), the
network access device (the authenticator), and the authentication server.
Figure 36 802.1X architecture
ClientA user terminal seeking access to the LAN. It must have 802.1X software to authenticate to
the network access device.
Network access deviceAuthenticates the client to control access to the LAN. In a typical 802.1X
environment, the network access device uses an authentication server to perform authentication.
Authentication serverProvides authentication services for the network access device. The
authentication server authenticates 802.1X clients by using the data sent from the network access
device, and returns the authentication results for the network access device to make access
decisions. The authentication server is typically a RADIUS server. In a small LAN, you can also use
the network access device as the authentication server.
Controlled/uncontrolled port and port

authorization status
802.1X defines two logical ports for the network access port: controlled port and uncontrolled port. Any
packet arriving at the network access port is visible to both logical ports.
Controlled portAllows incoming and outgoing traffic to pass through when it is in the authorized
state, and denies incoming and outgoing traffic when it is in the unauthorized state, as shown
in Figure 37. The controlled port is set in the authorized state if the client has passed authentication,
and in the unauthorized state, if the client has failed authentication.
Uncontrolled portAlways open to receive and transmit EAPOL frames.
96
Figure 37 Authorization state of a controlled port
In unauthorized state, a controlled port controls traffic in one of the following ways:
Performs bidirectional traffic control to deny traffic to and from the client.
Performs unidirectional traffic control to deny traffic from the client.
The HP devices support only unidirectional traffic control.
802.1X-related protocols
802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for the
client, the network access device, and the authentication server. EAP is an authentication framework that
uses the client/server model. It supports a variety of authentication methods, including MD5-Challenge,
EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).
802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the network
access device over a wired or wireless LAN. Between the network access device and the authentication
server, 802.1X delivers authentication information in one of the following methods:
Encapsulates EAP packets in RADIUS by using EAP over RADIUS (EAPOR), as described in "EAP
relay."
Extracts authentication information from the EAP packets and encapsulates the information in
standard RADIUS packets, as described in "EAP termination."
97
Packet formats
EAP packet format
Figure 38 shows the EAP packet format.
Figure 38 EAP packet format
CodeType of the EAP packet. Options include Request (1), Response (2), Success (3), or Failure
(4).
IdentifierUsed for matching Responses with Requests.
LengthLength (in bytes) of the EAP packet. The length is the sum of the Code, Identifier, Length,
and Data fields.
DataContent of the EAP packet. This field appears only in a Request or Response EAP packet. The
Data field comprises the request type (or the response type) and the type data. Type 1 (Identify) and
type 4 (MD5-challenge) are two examples for the type field.
EAPOL packet format

Figure 39 shows the EAPOL packet format.
Figure 39 EAPOL packet format
0
15
7
PAE Ethernet type
Protocol version
2
Type
Length
4
6
Packet body
N
PAE Ethernet typeProtocol type. It takes the value 0x888E for EAPOL.
Protocol versionThe EAPOL protocol version used by the EAPOL packet sender.
TypeType of the EAPOL packet. Table 5 lists the types of EAPOL packets supported by HP
implementation of 802.1X.
Table 5 Types of EAPOL packets
Value
Type
Description
0x00
EAP-Packet
The client and the network access device uses EAP-Packets to

transport authentication information.
0x01
EAPOL-Start
The client sends an EAPOL-Start message to initiate 802.1X

authentication to the network access device.
98
Value
Type
Description
0x02
EAPOL-Logoff
The client sends an EAPOL-Logoff message to tell the network

access device that it is logging off.
LengthData length in bytes, or length of the Packet body. If packet type is EAPOL-Start or
EAPOL-Logoff, this field is set to 0, and no Packet body field follows.
Packet bodyContent of the packet. When the EAPOL packet type is EAP-Packet, the Packet body
field contains an EAP packet.
EAP over RADIUS

RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP
authentication. For the RADIUS packet format, see "Configuring AAA."
EAP-Message
RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 40. The Type field
takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than 253 bytes, RADIUS
encapsulates it in multiple EAP-Message attributes.
Figure 40 EAP-Message attribute format
RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message attribute
to check their integrity. The packet receiver drops the packet if the calculated packet integrity checksum
is different from the Message-Authenticator attribute value. The Message-Authenticator prevents EAP
authentication packets from being tampered with during EAP authentication.
Figure 41 Message-Authenticator attribute format
Initiating 802.1X authentication

Both the 802.1X client and the access device can initiate 802.1X authentication.
802.1X client as the initiator

The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The
destination MAC address of the packet is the IEEE 802.1X specified multicast address
01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client and
99
the authentication server does not support the multicast address, use an 802.1X client, the HP iNode
802.1X client for example, that can send broadcast EAPOL-Start packets.
Access device as the initiator

The access device initiates authentication if a client cannot send EAPOL-Start packets. One example is
the 802.1X client available with Windows XP.
The access device supports the following modes:
Multicast trigger modeThe access device multicasts Identity EAP-Request packets periodically
(every 30 seconds by default) to initiate 802.1X authentication.
Unicast trigger modeUpon receiving a frame with the source MAC address not in the MAC
address table, the access device sends an Identity EAP-Request packet out of the receiving port to
the unknown MAC address. It retransmits the packet if no response has been received within a
certain time interval.
802.1X authentication procedures

802.1X authentication provides two methods: EAP relay and EAP termination. You choose either mode
depending on the support of the RADIUS server for EAP packets and EAP authentication methods.
EAP relay mode:

EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAPoR packets to send
authentication information to the RADIUS server, as shown in Figure 42.
Figure 42 EAP relay
In EAP relay mode, the client must use the same authentication method as the RADIUS server. On
the network access device, you only need to use the dot1x authentication-method eap command
to enable EAP relay.
Some network access devices provide the EAP server function so you can use EAP relay even if the
RADIUS server does not support any EAP authentication method or no RADIUS server is available.
For the local EAP authentication configuration procedure, see "Configuring AAA."
EAP termination mode:

In EAP termination mode, the network access device terminates the EAP packets received from the
client, encapsulates the client authentication information in standard RADIUS packets, and uses
PAP or CHAP to authenticate to the RADIUS server, as shown in Figure 43.
100
Figure 43 EAP termination
Comparing EAP relay and EAP termination

Packet exchange method
Benefits
Limitations
Supports various EAP
The RADIUS server must support the

EAP-Message and
Message-Authenticator attributes,
and the EAP authentication method
used by the client.
authentication methods.
EAP relay
The configuration and processing is

simple on the network access
device.
Supports only MD5-Challenge
EAP termination
Works with any RADIUS server that

supports PAP or CHAP authentication.
EAP authentication and the

"username + password" EAP
authentication initiated by an HP
iNode 802.1X client.
The processing is complex on the

network access device.
EAP relay
Figure 44 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5
is used.
101
Figure 44 802.1X authentication procedure in EAP relay mode

Client
Device
EAPOR
EAPOL
(1) EAPOL-Start
(2) EAP-Request/Identity
(3) EAP-Response/Identity
(4) RADIUS Access-Request

(EAP-Response/Identity)
(5) RADIUS Access-Challenge
(EAP-Request/MD5 challenge)
(6) EAP-Request/MD5 challenge

(7) EAP-Response/MD5 challenge
(8) RADIUS Access-Request

(EAP-Response/MD5 challenge)
(9) RADIUS Access-Accept
(EAP-Success)
(10) EAP-Success
Port authorized
(11) EAP-Request/Identity
(12) EAP-Response/Identity
...
(13) EAPOL-Logoff
Port unauthorized
(14) EAP-Failure
1.
When a user launches the 802.1X client software and enters a registered username and password,
the 802.1X client software sends an EAPOL-Start packet to the network access device.
2.
The network access device responds with an Identity EAP-Request packet to ask for the client
username.
3.
In response to the Identity EAP-Request packet, the client sends the username in an Identity
EAP-Response packet to the network access device.
4.
The network access device relays the Identity EAP-Response packet in a RADIUS Access-Request
packet to the authentication server.
5.
The authentication server uses the identity information in the RADIUS Access-Request to search its
user database. If a matching entry is found, the server uses a randomly generated challenge
(EAP-Request/MD5 challenge) to encrypt the password in the entry, and sends the challenge in a
RADIUS Access-Challenge packet to the network access device.
6.
The network access device relays the EAP-Request/MD5 Challenge packet in a RADIUS
Access-Request packet to the client.
7.
The client uses the received challenge to encrypt the password, and sends the encrypted password
in an EAP-Response/MD5 Challenge packet to the network access device.
8.
The network access device relays the EAP-Response/MD5 Challenge packet in a RADIUS
Access-Request packet to the authentication server.
102
9.
The authentication server compares the received encrypted password with the one it generated at
step 5. If the two are identical, the authentication server considers the client valid and sends a
RADIUS Access-Accept packet to the network access device.
10. Upon receiving the RADIUS Access-Accept packet, the network access device sends an
EAP-Success packet to the client, and sets the controlled port in the authorized state so the client
can access the network.
11. After the client comes online, the network access device periodically sends handshake requests to
check whether the client is still online. By default, if two consecutive handshake attempts fail, the
device logs off the client.
12. Upon receiving a handshake request, the client returns a response. If the client fails to return a
response after a certain number of consecutive handshake attempts (two by default), the network
access device logs off the client. This handshake mechanism enables timely release of the network
resources used by 802.1X users that have abnormally gone offline.
13. The client can also send an EAPOL-Logoff packet to ask the network access device for a logoff.
14. In response to the EAPOL-Logoff packet, the network access device changes the status of the
controlled port from authorized to unauthorized and sends an EAP-Failure packet to the client.
EAP termination
Figure 45 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that
CHAP authentication is used.
103
Figure 45 802.1X authentication procedure in EAP termination mode
In EAP termination mode, the network access device rather than the authentication server generates an
MD5 challenge for password encryption (see Step 4). The network access device then sends the MD5
challenge together with the username and encrypted password in a standard RADIUS packet to the
RADIUS server.
104
Configuring 802.1X
This chapter describes how to configure 802.1X on an HP device. You can also configure the port security
feature to perform 802.1X. Port security combines and extends 802.1X and MAC authentication. It
applies to a network (for example, a WLAN) that requires different authentication methods for different
users on a port. For more information about port security, see "Configuring port security."
HP implementation of 802.1X
Access control methods
HP implements port-based access control as defined in the 802.1X protocol, and extends the protocol to
support MAC-based access control.
Port-based access controlOnce an 802.1X user passes authentication on a port, any subsequent
user can access the network through the port without authentication. When the authenticated user
logs off, all other users are logged off.
MAC-based access controlEach user is separately authenticated on a port. When a user logs off,
no other online users are affected.
802.1X stateful failover

802.1X stateful failover enables two stateful failover ACs to back up 802.1X sessions in real time on
WLAN interfaces. When a primary/backup AC switchover occurs, the backup AC can immediately take
over to provide 802.1X services without disrupting 802.1X sessions. To configure 802.1X stateful failover,
enable port security stateful failover. For more information, see "Configuring port security."
Using 802.1X authentication with other features

VLAN assignment
You can configure the authentication server to assign a VLAN for an 802.1X user that has passed
authentication. The way that the network access device handles VLANs on an 802.1X-enabled port
differs by 802.1X access control mode.
Access control
Port-based
VLAN manipulation
Assigns the VLAN to the port as the port VLAN (PVID). The authenticated 802.1X user
and all subsequent 802.1X users can access the VLAN without authentication.
When the user logs off, the previous PVID restores, and all other online users are
logged off.
105
Access control
VLAN manipulation
If the port is a hybrid port with MAC-based VLAN enabled, maps the MAC address
of each user to the VLAN assigned by the authentication server. The PVID of the port
does not change. When a user logs off, the MAC-to-VLAN mapping for the user is
removed.
MAC-based
If the port is an access, trunk, or MAC-based VLAN disabled hybrid port, assigns
the first authenticated user's VLAN to the port as the PVID. If a different VLAN is
assigned to a subsequent user, the user cannot pass the authentication. To avoid the
authentication failure of subsequent users, be sure to assign the same VLAN to all
802.1X users on these ports.
With 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member. After
the assignment, do not reconfigure the port as a tagged member in the VLAN.
On a periodic online user re-authentication enabled port, if a user has been online before you enable the
MAC-based VLAN function, the access device does not create a MAC-to-VLAN mapping for the user
unless the user passes re-authentication and the VLAN for the user has changed.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration
Guide.
Guest VLAN
You can configure a guest VLAN on a port to accommodate users that have not performed 802.1X
authentication, so they can access a limited set of network resources, such as a software server, to
download anti-virus software and system patches. Once a user in the guest VLAN passes 802.1X
authentication, it is removed from the guest VLAN and can access authorized network resources.
Guest VLAN is supported only on ports that perform MAC-based access control. The following table
describes how the network access device handles VLANs on these ports.
Authentication status
VLAN manipulation
A user has not passed

802.1X authentication yet
Creates a mapping between the MAC address of the user and the 802.1X guest
VLAN. The user can access resources in the guest VLAN.
A user in the 802.1X guest

VLAN fails 802.1X
authentication
A user in the 802.1X guest
VLAN passes 802.1X
authentication
If an 802.1X Auth-Fail VLAN is available, re-maps the MAC address of the user
to the Auth-Fail VLAN. The user can access only resources in the Auth-Fail VLAN.
If no 802.1X Auth-Fail VLAN is configured, the user is still in the 802.1X guest
VLAN.
Re-maps the MAC address of the user to the VLAN specified for the user.
If the authentication server assigns no VLAN, re-maps the MAC address of the
user to the initial PVID on the port.
To use the 802.1X guest VLAN function on a port that performs MAC-based access control, make sure
that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member.
Guide.
Auth-Fail VLAN
You can configure an Auth-Fail VLAN to accommodate users that have failed 802.1X authentication
because of the failure to comply with the organization security strategy, such as using a wrong password.
106
Users in the Auth-Fail VLAN can access a limited set of network resources, such as a software server, to
download anti-virus software and system patches.
The Auth-Fail VLAN does not accommodate 802.1X users that have failed authentication for
authentication timeouts or network connection problems.
Auth-Fail VLAN is supported only on ports that perform MAC-based access control. The following table
describes how the network access device handles VLANs on these ports.
Authentication status
VLAN manipulation
A user fails 802.1X

authentication
Re-maps the MAC address of the user to the Auth-Fail VLAN. The user can
access only resources in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN

fails 802.1X re-authentication
The user is still in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN

passes 802.1X authentication
Re-maps the MAC address of the user to the server-assigned VLAN.

If the authentication server assigns no VLAN, re-maps the MAC address of the
user to the initial PVID on the port.
To perform the 802.1X Auth-Fail VLAN function on a port that performs MAC-based access control, you
must ensure that the port is a hybrid port, and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member.
Guide.
ACL assignment
You can specify an ACL for an 802.1X user to control its access to network resources. After the user
passes 802.1X authentication, the authentication server, either the local access device or a RADIUS
server, assigns the ACL to the port to filter the traffic from this user. In either case, you must configure the
ACL on the access device. You can change ACL rules while the user is online.
Disable ARP snooping.
Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.
If RADIUS authentication is used, create user accounts on the RADIUS server.
If local authentication is used, create local user accounts on the access device and set the service
type to lan-access.
If you want to use EAP relay when the RADIUS server does not support any EAP authentication
method or no RADIUS server is available, configure the EAP server function on your network access
device.
For information about RADIUS client and local EAP authentication configuration, see "Configuring
AAA."
107
802.1X configuration task list

Task
Remarks
Required.
By default, the 802.1X function of
port security is disabled.
Enable port security to enable 802.1X
802.1X must work with the port

security feature to function on a
WLAN port.
Enabling EAP relay or EAP termination
Optional.
Setting the port authorization state
Optional.
Specifying an access control method
Optional.
Setting the maximum number of concurrent 802.1X users on a port
Optional.
Setting the maximum number of authentication request attempts
Optional.
Setting the 802.1X authentication timeout timers
Optional.
Configuring the online user handshake function
Optional.
Configuring the authentication trigger function
Optional.
Specifying a mandatory authentication domain on a port
Optional.
Configuring the quiet timer
Optional.
Enabling the periodic online user re-authentication function
Optional.
Configuring an 802.1X guest VLAN
Optional.
Configuring an Auth-Fail VLAN
Optional.
Specifying supported domain name delimiters
Optional.
Configuring the accounting delay feature
Optional.
Enabling EAP relay or EAP termination

When configuring EAP relay or EAP termination, consider the following factors:
The support of the RADIUS server for EAP packets
The authentication methods supported by the 802.1X client and the RADIUS server
If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP
authentication initiated by an HP iNode 802.1X client, you can use both EAP termination and EAP relay.
To use EAP-TL, PEAP, or any other EAP authentication methods, you must use EAP relay. When you make
your decision, see "Comparing EAP relay and EAP termination" for help.
For more information about EAP relay and EAP termination, see "802.1X authentication procedures."
To configure EAP relay or EAP termination:
108
Step
Enter system
view.
1.
Configure EAP
relay or EAP
termination.
2.
Command
Remarks
system-view
N/A
dot1x authentication-method
{ chap | eap | pap }
By default, the network access device performs EAP

termination and uses CHAP to communicate with the
RADIUS server.
Specify the eap keyword to enable EAP termination.
Specify the chap or pap keyword to enable
CHAP-enabled or PAP-enabled EAP relay.
NOTE:
If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view does not
take effect. The access device sends the authentication data from the client to the server without any
modification.
Setting the port authorization state

The port authorization state determines whether the client is granted access to the network. You can
control the authorization state of a port by using the dot1x port-control command and the following
keywords:
authorized-forcePlaces the port in the authorized state, enabling users on the port to access the
network without authentication.
unauthorized-forcePlaces the port in the unauthorized state, denying any access requests from
users on the port.
autoPlaces the port initially in the unauthorized state to allow only EAPOL packets to pass, and
after a user passes authentication, sets the port in the authorized state to allow access to the network.
You can use this option in most scenarios.
You can set authorization state for one port in interface view, or for multiple ports in system view. If
different authorization state is set for a port in system view and interface view, the one set later takes
effect.
To set the authorization state of a port:
Step
1.
Enter system
view.
2.
Set the port

authorization
state in system
view, Layer 2
Ethernet
interface view, or
WLAN-ESS
interface view.
Command
Remarks
system-view
N/A
In system view:
dot1x port-control { authorized-force | auto |
unauthorized-force } [ interface interface-list ]
In Layer 2 Ethernet interface view or WLAN-ESS

interface view:
a. interface interface-type interface-number

b. dot1x port-control { authorized-force | auto |
unauthorized-force }
109
By default, auto applies.
Specifying an access control method

You can specify an access control method for one port in interface view, or for multiple ports in system
view. If different access control methods are specified for a port in system view and interface view, the
one specified later takes effect.
To specify the access control method:
Step
1.
Enter system view.
2.
Specify an access
control method in
system view, Layer
2 Ethernet
interface view, or
WLAN-ESS
interface view.
Command
Remarks
system-view
N/A
In system view:
dot1x port-method { macbased |
portbased } [ interface interface-list ]
In Layer 2 Ethernet interface view or

WLAN-ESS interface view:
a. interface interface-type
interface-number
b. dot1x port-method { macbased |
portbased }
By default, MAC-based access

control applies.
To use both 802.1X and portal
authentication on a port, you must
specify MAC-based access control.
For information about portal
authentication, see "Configuring
portal authentication."
Setting the maximum number of concurrent 802.1X

users on a port
You can set the maximum number of concurrent 802.1X users for ports individually in interface view or in
bulk in system view. If different settings are configured for a port in both views, the setting configured later
takes effect.
To set the maximum number of concurrent 802.1X users on a port:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
In system view:
2.

concurrent 802.1X users on a
port in system view, Layer 2
Ethernet interface view, or
WLAN-ESS interface view.
dot1x max-user user-number [ interface

interface-list ]
In Layer 2 Ethernet interface view or

WLAN-ESS interface view:
interface-number
b. dot1x max-user user-number
[ interface interface-list ]
110
The default varies with

devices. For more
information, see About
the Command
References for HP
Unified Wired-WLAN
Products.
Setting the maximum number of authentication

request attempts
The network access device retransmits an authentication request if it receives no response to the request
it has sent to the client within a period of time (specified by using the dot1x timer tx-period
tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command). The network
access device stops retransmitting the request if it has made the maximum number of request transmission
attempts but still received no response.
To set the maximum number of authentication request attempts:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the maximum number of attempts for

sending an authentication request.
dot1x retry max-retry-value
Setting the 802.1X authentication timeout timers

The network device uses the following 802.1X authentication timeout timers:
Client timeout timerStarts when the access device sends an EAP-Request/MD5 Challenge packet
to a client. If no response is received when this timer expires, the access device retransmits the
request to the client.
Server timeout timerStarts when the access device sends a RADIUS Access-Request packet to the
authentication server. If no response is received when this timer expires, the access device
retransmits the request to the server.
You can set the client timeout timer to a high value in a low-performance network, and adjust the server
timeout timer to adapt to the performance of different authentication servers. In most cases, the default
settings are sufficient.
To set the 802.1X authentication timeout timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the client timeout

timer.
dot1x timer supp-timeout

supp-timeout-value
The default is 30 seconds.
3.
Set the server timeout

timer.
dot1x timer server-timeout

server-timeout-value
Configuring the online user handshake function

The online user handshake function checks the connectivity status of online 802.1X users. The network
access device sends handshake messages to online users at the interval specified by the dot1x timer
handshake-period command. If no response is received from an online user after the maximum number
111
of handshake attempts (set by the dot1x retry command), the network access device sets the user in the
offline state.
If iNode clients are deployed, you can also enable the online handshake security function to check for
802.1X users that use illegal client software to bypass security inspection such as dual network interface
cards (NICs) detection. This function checks the authentication information in client handshake messages.
If a user fails the authentication, the network access device logs the user off.
Follow these guidelines when you configure the online user handshake function:
To use the online handshake security function, make sure the online user handshake function is
enabled. HP recommends that you use the iNode client software and IMC server to ensure the
normal operation of the online user handshake security function.
If the network has 802.1X clients that cannot exchange handshake packets with the network access
device, disable the online user handshake function to prevent their connections from being
inappropriately torn down.
To configure the online user handshake function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the handshake timer.
dot1x timer handshake-period

handshake-period-value
Optional.
3.
Enter Layer 2 Ethernet

interface view or WLAN-ESS
interface view.
interface interface-type
interface-number
Enable the online handshake

function.
dot1x handshake
Enable the online handshake

security function.
dot1x handshake secure
4.
5.

N/A
Optional.
By default, the function is enabled.
Optional.
By default, the function is disabled.
Configuring the authentication trigger function

The authentication trigger function enables the network access device to initiate 802.1X authentication
when 802.1X clients cannot initiate authentication.
This function provides the following types of authentication trigger:
Multicast triggerPeriodically multicasts Identity EAP-Request packets out of a port to detect 802.1X
clients and trigger authentication.
Unicast triggerEnables the network device to initiate 802.1X authentication when it receives a
data frame from an unknown source MAC address. The device sends a unicast Identity
EAP/Request packet to the unknown source MAC address, and retransmits the packet if it has
received no response within a period of time. This process continues until the maximum number of
112
request attempts set with the dot1x retry command (see "Setting the maximum number of
authentication request attempts") is reached.
The identity request timeout timer sets both the identity request interval for the multicast trigger and the
identity request timeout interval for the unicast trigger.
Follow these guidelines when you configure the authentication trigger function:
Enable the multicast trigger on a port when the clients attached to the port cannot send EAPOL-Start
packets to initiate 802.1X authentication.
Disable the multicast trigger in a wireless LAN. Wireless clients and the wireless module of the
network access device can both initiate 802.1X authentication.
Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and these
clients cannot initiate authentication.
To avoid duplicate authentication packets, do not enable both triggers on a port.
To configure the authentication trigger function on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the username

request timeout timer.
dot1x timer tx-period

tx-period-value
Optional.

interface view or
WLAN-ESS interface
view.
interface-number
3.
The default setting is 30 seconds.
N/A
Required if you want to enable the unicast trigger.

4.
Enable an
authentication trigger.
dot1x { multicast-trigger |
unicast-trigger }
By default, the multicast trigger is enabled, and the

unicast trigger is disabled.
Unicast trigger is not available on a WLAN-ESS
port.
Specifying a mandatory authentication domain on

a port
You can place all 802.1X users in a mandatory authentication domain for authentication, authorization,
and accounting on a port. No user can use an account in any other domain to access the network
through the port. The implementation of a mandatory authentication domain enhances the flexibility of
802.1X access control deployment.
To specify a mandatory authentication domain for a port:
113
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

interface view.
interface-number
N/A
3.
Specify a mandatory 802.1X

authentication domain on the
port.
dot1x mandatory-domain
domain-name
By default, no mandatory 802.1X

authentication domain is specified.
Configuring the quiet timer

The quiet timer enables the network access device to wait a period of time before it can process any
authentication request from a client that has failed an 802.1X authentication.
You can set the quiet timer to a high value in a vulnerable network or a low value for quicker
authentication response.
To configure the quiet timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the quiet timer.
dot1x quiet-period
By default, the timer is disabled.
3.
Set the quiet timer.
dot1x timer quiet-period

quiet-period-value
Optional.
Enabling the periodic online user re-authentication

function
Periodic online user re-authentication tracks the connection status of online users and updates the
authorization attributes assigned by the server, such as the ACL, VLAN, and user profile-based QoS. The
re-authentication interval is user configurable.
To enable the periodic online user re-authentication function:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set the periodic

re-authentication timer.
dot1x timer reauth-period

reauth-period-value
3.

interface view.
interface-number
N/A
Enable periodic online user

re-authentication.
dot1x re-authenticate
By default, the function is disabled.
4.
114
Optional.
The default setting is 3600
seconds.
The periodic online user re-authentication timer can also be set by the authentication server in the
session-timeout attribute. The server-assigned timer overrides the timer setting on the access device, and
enables periodic online user re-authentication, even if the function is not configured. Support for the
server assignment of re-authentication timer and the re-authentication timer configuration on the server
vary with servers.
The VLAN assignment status must be consistent before and after re-authentication. If the authentication
server has assigned a VLAN before re-authentication, it must also assign a VLAN at re-authentication. If
the authentication server has assigned no VLAN before re-authentication, it must not assign one at
re-authentication. Violation of either rule can cause the user to be logged off. The VLANs assigned to an
online user before and after re-authentication can be the same or different.
RADIUS server unreachable can cause an online user being re-authenticated to be logged off.
Configuring an 802.1X guest VLAN

Follow these guidelines when you configure an 802.1X guest VLAN:
802.1X guest VLAN is supported only on a port that performs MAC-based access control.
You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different
ports can be different.
Assign different IDs to the PVID and the 802.1X guest VLAN on a port, so the port can correctly
process incoming VLAN tagged traffic.
Use Table 6 when configuring multiple security features on a port.

Table 6 Relationships of the 802.1X guest VLAN and other security features
Feature
Relationship description
Reference
MAC authentication
guest VLAN on a port that
performs MAC-based
access control
Only the 802.1X guest VLAN take effect. A user

that fails MAC authentication will not be
assigned to the MAC authentication guest
VLAN.
See "Configuring MAC

authentication."
802.1X Auth-Fail VLAN

on a port that performs
MAC-based access
control
The 802.1X Auth-Fail VLAN has a higher

priority.
See "Using 802.1X

authentication with other
features."
Port intrusion protection

MAC-based access
control
The 802.1X guest VLAN function has higher

priority than the block MAC action but lower
priority than the shutdown port action of the port
intrusion protection feature.
See "Configuring port

security."
Create the VLAN to be specified as the 802.1X guest VLAN.
115
On the 802.1X-enabled port that performs MAC-based access control, configure the port as a
hybrid port, enable MAC-based VLAN on the port, and assign the port to the 802.1X guest VLAN
as an untagged member. For more information about the MAC-based VLAN function, see Layer 2
To configure an 802.1X guest VLAN:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Configure an 802.1X
guest VLAN for one or
more ports in system
view, Layer 2 Ethernet
interface view, or
WLAN-ESS interface
view.
In system view:
dot1x guest-vlan guest-vlan-id [ interface

interface-list ]
In Layer 2 Ethernet interface view or WLAN-ESS

interface view:
a. interface interface-type interface-number
By default, no 802.1X
guest VLAN is
configured on any
port.
b. dot1x guest-vlan guest-vlan-id
Configuring an Auth-Fail VLAN

Follow these guidelines when configuring an 802.1X Auth-Fail VLAN:
802.1X Auth-Fail VLAN is supported only on ports that perform MAC-based access control.
Assign different IDs to the PVID and the 802.1X Auth-Fail VLAN on a port, so the port can correctly
process VLAN tagged incoming traffic.
You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on
different ports can be different.
Use Table 7 when configuring multiple security features on a port.

Table 7 Relationships of the 802.1X Auth-Fail VLAN with other features
Feature
Reference
MAC authentication
guest VLAN on a port that
performs MAC-based
access control
The 802.1X Auth-Fail VLAN has a high priority.
See "Configuring MAC

authentication."

MAC-based access
control
The 802.1X Auth-Fail VLAN function has higher

priority than the block MAC action but lower
priority than the shutdown port action of the port
intrusion protection feature.

security."
Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.

116
On the 802.1X-enabled port that performs MAC-based access control, configure the port as a
hybrid port, enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an
untagged member. For more information about the MAC-based VLAN function, see Layer 2
To configure an Auth-Fail VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

interface view or
WLAN-ESS interface
view.
interface-number
N/A
Configure the Auth-Fail

VLAN on the port.
dot1x auth-fail vlan

authfail-vlan-id
By default, no Auth-Fail VLAN is configured.
3.
Specifying supported domain name delimiters

By default, the access device supports the at sign (@) as the delimiter. You can also configure the access
device to accommodate 802.1X users that use other domain name delimiters.
The configurable delimiters include the at sign (@), back slash (\), and forward slash (/).
If an 802.1X username string contains multiple configured delimiters, the leftmost delimiter is the domain
name delimiter. For example, if you configure @, /, and \ as delimiters, the domain name delimiter for
the username string 123/22\@abc is the forward slash (/).
If a username string contains none of the delimiters, the access device authenticates the user in the
mandatory or default ISP domain. The access selects a domain delimiter from the delimiter set in this
order: @, /, and \.
To specify a set of domain name delimiters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a set of domain name

delimiters for 802.1X users.
dot1x domain-delimiter string
By default, only the at sign (@)

delimiter is supported.
NOTE:
If you configure the access device to include the domain name in the username sent to the RADIUS server,
make sure the domain delimiter in the username can be recognized by the RADIUS server. For username
format configuration, see the user-name-format command in Security Command Reference.
117
Configuring the accounting delay feature

By default, the accounting delay feature is disabled. The device sends an accounting request to the
accounting server for an 802.1X user immediately after the user passes authentication, regardless of
whether an IP address has been assigned to the user.
The accounting delay feature enables the device to wait a period of time for an authenticated 802.1X
user to obtain an IP address before sending an accounting request. If the device gets the IP address of the
user before the delay expires, it sends an accounting request for the user. If not, the device proceeds to
the accounting procedure or ends the procedure depending on your configuration.
Enable the accounting delay feature if 802.1X users obtain IP addresses through DHCP and the
accounting server requires user IP addresses.
For a network that deploys iNode clients, follow these configuration guidelines:
If the iNode clients can upload their IP addresses during authentication, disable the accounting
delay feature for efficiency.
If the iNode clients cannot upload their IP addresses, make sure the delay setting is equal to or less
than the accounting delay that the EAD policy allows to prevent access failures. HP recommends a
delay equal to or less than 20 seconds.
To configure the accounting delay feature on an 802.1X-enabled port:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

interface view or
interface interface-type interface-number
N/A
Configure the accounting

delay settings.
dot1x accounting-delay [ logoff | time

time ] *
By default, accounting delay is

disabled.
3.
Displaying and maintaining 802.1X

Task
Command
Remarks
Display 802.1X session

information, statistics, or
configuration information of
specified or all ports.
display dot1x [ sessions | statistics ] [ interface

interface-list ] [ | { begin | exclude | include }
Display 802.1X stateful

failover information.
display dot1x synchronization { connection |

statistics | status } [ interface interface-type
interface-number ] [ | { begin | exclude | include }
Clear 802.1X statistics.
reset dot1x statistics [ interface interface-list ]
Clear 802.1X stateful failover

packet statistics.
reset dot1x synchronization statistics [ interface

interface-type interface-number ]
118
802.1X with ACL assignment configuration

example
This section describes how to configure 802.1X with ACL assignment. For more information about 802.1X
configuration, see WLAN Configuration Guide.
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary with device models.
As shown in Figure 46, the client at 192.168.1.10 connects to port WLAN-ESS 1 of the AC.
Perform 802.1X authentication on the port. Set the port security mode to userlogin-secure-ext.
Use the RADIUS server at 10.1.1.1 as the authentication and authorization server and the RADIUS server
at 10.1.1.2 as the accounting server.
Assign an ACL to WLAN-ESS 1 to deny the access of 802.1X users to the FTP server at 10.0.0.1.
Authentication servers
(RADIUS server cluster)
10.1.1.1
10.1.1.2
IP network
Client
AP
FTP server
192.168.1.10
10.0.0.1
AC
# Assign IP addresses to interfaces. (Details not shown.)
119
# Configure the RADIUS server and specify the ACL to be assigned. (Details not shown.)
# Configure the RADIUS scheme.
<AC> system-view
[AC] radius scheme 2000
[AC-radius-2000] primary authentication 10.1.1.1
[AC-radius-2000] primary accounting 10.1.1.2
[AC-radius-2000] key authentication abc
[AC-radius-2000] key accounting abc
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit
# Create an ISP domain and specify the RADIUS scheme 2000 as the default AAA schemes for the
domain.
[AC] domain 2000
[AC-isp-2000] authentication default radius-scheme 2000
[AC-isp-2000] authorization
default radius-scheme 2000
[AC-isp-2000] accounting default radius-scheme 2000

[AC-isp-2000] quit
# Configure ACL 3000 to deny packets destined for the FTP server at 10.0.0.1.
[AC] acl number 3000
[AC-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
# Set the authentication method to EAP.

# Enable port security.

# Set the port security mode to userlogin-secure-ext, and enable port-security tx-key-type 11key.
[AC-WLAN-ESS1] port link-type hybrid
[AC-WLAN-ESS1] port hybrid vlan 2 untagged
[AC-WLAN-ESS1] port hybrid pvid vlan 2
[AC-WLAN-ESS1] mac-vlan enable
[AC-WLAN-ESS1] dot1x mandatory-domain 2000
# Disable the multicast trigger function and online user handshake function.
[AC-WLAN-ESS1] quit
# Create service template 1 of crypto type, configure its SSID as dot1x, and configure the tkip and ccmp
cipher suite.
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] cipher-suite ccmp
[AC-wlan-st-1] security-ie rsn
120
[AC-wlan-st-1] quit
# Create an AP template named ap1 and its model is MSM460-WW, and configure the serial ID of the
AP as CN2AD330S8.


# After a user passes authentication, use the display connection command to verify that the 802.1X
connection has been set up.
Index=1,Username=localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Online=00h00m53s
[AC] display connection ucibindex 1
Index=1, Username= localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Access=8021X
,AuthMethod=EAP

Initial VLAN=2, Authorization VLAN=N/A
ACL Group=3000
User Profile=N/A
CAR=Disable
Traffic Statistic:
InputOctets
=12121212
InputGigawords=1
OutputOctets
=12120
OutputGigawords=0
Priority=Disable
# Use the user account to pass authentication, and then ping the FTP server.
C:\>ping 10.0.0.1
Pinging 10.0.0.1 with 32 bytes of data:
Request timed out.

Request timed out.
Request timed out.
121
Request timed out.
Ping statistics for 10.0.0.1:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
The output shows that ACL 3000 has taken effect on the user, and the user cannot access the FTP server.
122
Configuring MAC authentication

Overview
MAC authentication controls network access by authenticating source MAC addresses on a port. It does
not require client software and users do not need to enter a username and password for network access.
The device initiates a MAC authentication process when it detects an unknown source MAC address on
a MAC authentication enabled port. If the MAC address passes authentication, the user can access
authorized network resources. If the authentication fails, the device marks the MAC address as a silent
MAC address, drops the packet, and starts a quiet timer. The device drops all subsequent packets from
the MAC address within the quiet time. The quiet mechanism avoids repeated authentication during a
short time.
NOTE:
If the MAC address that has failed authentication is a static MAC address or a MAC address that has
passed any security authentication, the device does not mark the MAC address as a silent address.
User account policies

MAC authentication supports the following user account policies:
One MAC-based user account for each user. The access device uses the source MAC addresses in
packets as the usernames and passwords of users for MAC authentication. This policy is suitable for
an insecure environment.
One shared user account for all users. You specify one username and password, which are not
necessarily a MAC address, for all MAC authentication users on the access device. This policy is
suitable for a secure environment.
Authentication approaches
You can perform MAC authentication on the access device (local authentication) or through a RADIUS
server.
Suppose a source MAC unknown packet arrives at a MAC authentication enabled port.
Local authentication:
If MAC-based accounts are used, the access device uses the source MAC address of the packet as
the username and password to search its local account database for a match.
If a shared account is used, the access device uses the shared account username and password to
search its local account database for a match.
RADIUS authentication:
If MAC-based accounts are used, the access device sends the source MAC address as the
username and password to the RADIUS server for authentication.
If a shared account is used, the access device sends the shared account username and password
to the RADIUS server for authentication.
123
For more information about configuring local authentication and RADIUS authentication, see
"Configuring AAA."
MAC authentication timers

MAC authentication uses the following timers:
Offline detect timerSets the interval that the device waits for traffic from a user before it regards
the user idle. If a user connection has been idle within the interval, the device logs the user out and
stops accounting for the user.
Quiet timerSets the interval that the device must wait before it can perform MAC authentication
for a user that has failed MAC authentication. All packets from the MAC address are dropped
during the quiet time. This quiet mechanism prevents repeated authentication from affecting system
performance.
Server timeout timerSets the interval that the access device waits for a response from a RADIUS
server before it regards the RADIUS server unavailable. If the timer expires during MAC
authentication, the user cannot access the network.
Using MAC authentication with other features

VLAN assignment
You can specify a VLAN in the user account for a MAC authentication user to control its access to
network resources. After the user passes MAC authentication, the authentication server, either the local
access device or a RADIUS server, assigns the VLAN to the port as the default VLAN. After the user logs
off, the initial default VLAN, or the default VLAN configured before any VLAN is assigned by the
authentication server, restores. If the authentication server assigns no VLAN, the initial default VLAN
applies.
A hybrid port is always assigned to a server-assigned VLAN as an untagged member. After the
assignment, do not re-configure the port as a tagged member in the VLAN.
If MAC-based VLAN is enabled on a hybrid port, the device maps the server-assigned VLAN to the MAC
address of the user. The default VLAN of the hybrid port does not change.
ACL assignment
You can specify an ACL in the user account for a MAC authentication user to control its access to network
resources. After the user passes MAC authentication, the authentication server, either the local access
device or a RADIUS server, assigns the ACL to the access port to filter the traffic from this user. You must
configure the ACL on the access device for the ACL assignment function. You can change ACL rules while
the user is online.
Guest VLAN
You can configure a guest VLAN to accommodate MAC authentication users that have failed MAC
authentication on the port. Users in the MAC authentication guest VLAN can access a limited set of
network resources, such as a software server, to download anti-virus software and system patches. If no
124
MAC authentication guest VLAN is configured, the user that fails MAC authentication cannot access any
network resources.
If a user in the guest VLAN passes MAC authentication, that user is removed from the guest VLAN and
can access all authorized network resources. If not, the user is still in the MAC authentication guest
VLAN.
A hybrid port is always assigned to a guest VLAN as an untagged member. After the assignment, do not
re-configure the port as a tagged member in the VLAN.
MAC-after-portal
The MAC-after-portal feature triggers MAC authentication for only portal-authenticated users. The AC
allows only these users to pass MAC authentication and assigns them to VLANs that perform local
forwarding on an AP. For more information about local forwarding, see WLAN Configuration Guide.
When a user accesses the wireless network for the first time, the AC uses the process to implement the
MAC-after-portal feature:
1.
Identifies that the user is not portal authenticated and assigns the user to the MAC authentication
guest VLAN on the access interface.
2.
Performs portal authentication for the user.

After the user passes portal authentication, MAC authentication is triggered.
3.
Determines that the portal-authenticated user passes MAC authentication.
4.
Assigns the user to the server-authorized VLAN that performs local forwarding. The AC issues the
MAC-VLAN entry of the user to the AP for local forwarding.
The portal module tags a portal-authenticated user as always online unless the idle-cut period is reached.
When the user accesses the network during the idle-cut period, the user passes MAC authentication
directly. The AC does not perform portal authentication because the user is tagged as portal
authenticated.
Configuration task list

Task
Remarks
Basic configuration for MAC authentication:
Configuring MAC authentication globally

Configuring MAC authentication on a port
Required.
Specifying a MAC authentication domain
Optional.
Configuring a MAC authentication guest VLAN
Optional.
Configuring the MAC-after-portal feature
Optional.
Basic configuration for MAC authentication

Before you perform basic configuration for MAC authentication, complete the following tasks:
Create and configure an authentication domain, also called "an ISP domain."
125
For local authentication, create local user accounts, and specify the lan-access service for the
accounts.
For RADIUS authentication, check that the device and the RADIUS server can reach each other, and
create user accounts on the RADIUS server.
If you are using MAC-based accounts, make sure the username and password for each account is the
same as the MAC address of the MAC authentication users.
Configuring MAC authentication globally

MAC authentication can take effect on a port only when it is enabled globally and on the port.
To configure MAC authentication globally:
Step
Command
Remarks
system-view
N/A
1.
Enter system view.
2.
Enable MAC
authentication
globally.
mac-authentication
Configure MAC
authentication
timers.
mac-authentication timer
{ offline-detect offline-detect-value |
quiet quiet-value | server-timeout
server-timeout-value }
Optional.
Optional.
Configure the
properties of MAC
authentication user
accounts.
mac-authentication
user-name-format { fixed [ account
name ] [ password { cipher |
simple } password ] | mac-address
[ { with-hyphen | without-hyphen }
[ lowercase | uppercase ] ] }
3.
4.
By default, MAC authentication is disabled

globally.
MAC authentication is enabled globally
after the port security feature is enabled.
By default, the offline detect timer is 300
seconds, the quiet timer is 60 seconds, and
the server timeout timer is 100 seconds.
By default, the username and password for
a MAC authentication user account must be
a MAC address, and the letters in the MAC
address are unhyphenated and in lower
case.
Configuring MAC authentication on a port

You cannot add a MAC authentication-enabled port in to a link aggregation group, or enable MAC
authentication on a port already in a link aggregation group.
To configure MAC authentication on a port:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
126
Step
Command
Remarks
On a group of Ethernet interfaces in system

view:
mac-authentication interface interface-list
On an Ethernet interface in interface view:

Enable MAC
authentication.
2.
interface-number
b. mac-authentication
Use one of the methods.

By default, MAC authentication
is disabled on a port.
On a WLAN-ESS or WLAN-MESH
interface:
See "Configuring port security").
Set the maximum

number of
concurrent MAC
authentication users
allowed on a port.
3.
Optional.
mac-authentication max-user user-number
The default depends on the

device model. For more
information, see About the
Command References for HP
Unified Wired-WLAN Products.
Specifying a MAC authentication domain

By default, MAC authentication users are in the system default authentication domain. To implement
different access policies for users, you can specify authentication domains for MAC authentication users
in the following ways:
Specify a global authentication domain in system view. This domain setting applies to all ports.
Specify an authentication domain for an individual port in interface view.
MAC authentication chooses an authentication domain for users on a port in the following order: the
port-specific domain, the global domain, and the default domain. For more information about
authentication domains, see "Configuring AAA."
To specify an authentication domain for MAC authentication users:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
In system view:
2.
Specify an authentication
domain for MAC
authentication users in
system view or interface
view.
mac-authentication domain
domain-name
In interface view:
interface-number
By default, the system default

authentication domain is used for
MAC authentication users.
b. mac-authentication domain
domain-name
Configuring a MAC authentication guest VLAN

Before you configure a MAC authentication guest VLAN on a port, complete the following tasks:
Enable MAC authentication.

127
Enable MAC-based VLAN on the port.
Create the VLAN to be specified as the MAC authentication guest VLAN.
To configure a MAC authentication guest VLAN:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter WLAN-ESS
interface view.
interface-number
N/A
3.
Specify a MAC
authentication guest
VLAN.
mac-authentication guest-vlan
guest-vlan-id
By default, no MAC authentication guest

VLAN is configured.
You can configure only one MAC
authentication guest VLAN on a port.
Follow the guidelines in Table 8 when configuring a MAC authentication guest VLAN on a port.
Table 8 Relationships of the MAC authentication guest VLAN with other security features
Feature
Reference
Quiet function of MAC

authentication
The MAC authentication guest VLAN function

has higher priority. A user can access any
resources in the guest VLAN.
See "MAC authentication

timers."
The MAC authentication guest VLAN function

has higher priority than the block MAC action,
but lower priority than the shutdown port
action of the port intrusion protection feature.

security."
802.1X guest VLAN on a

port that performs
MAC-based access control
The MAC authentication guest VLAN has a

lower priority.
See "Configuring 802.1X."
Configuring the MAC-after-portal feature

Use the MAC-after-portal feature with the local forwarding and local portal server functions.
Before you configure this feature on a WLAN-ESS interface, complete the following tasks:
Configure a clear-type service.
Enable MAC authentication globally and on the interface.
Enable the MAC-based VLAN function on the interface.
Enable the local portal server function in the MAC authentication guest VLAN.
Configure the MAC authentication guest VLAN, and specify it as the VLAN to perform centralized
forwarding.
Configure VLAN assignment for MAC-authenticated users, and specify the VLAN to perform local
forwarding.
Configure local portal and local MAC authentication parameters.
To configure the MAC-after-portal feature:
128
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter WLAN-ESS
interface view.
interface-number
N/A
3.
Configure
MAC-after-portal.
mac-authentication trigger
after-portal
By default, this feature is disabled.
Displaying and maintaining MAC authentication

Task
Command
Remarks
Display MAC authentication

information.
display mac-authentication [ interface

interface-list ] [ | { begin | exclude |
Clear MAC authentication

statistics.
reset mac-authentication statistics

[ interface interface-list ]
MAC authentication configuration examples

Local MAC authentication configuration example

In the network in Figure 47, perform local MAC and PSK authentication on WLAN-ESS interface of the
AC to control Internet access. Make sure:
All users belong to domain aabbcc.net.
Local users use their MAC address as the username and password for MAC authentication. The
MAC addresses are hyphen separated and in lower case.
The AC detects whether a user has gone offline every 180 seconds.
129

Supplicant
Authenticator
IP network
Client
AP
L2switch
MAC: 00-e0-fc-12-34-56
AC
# Add a local user account, set both the username and password to 00-e0-fc-12-34-56, the MAC address
of the user host, and enable LAN access service for the account.
<AC> system-view
[AC] local-user 00-e0-fc-12-34-56
[AC-luser-00-e0-fc-12-34-56] password simple 00-e0-fc-12-34-56
[AC-luser-00-e0-fc-12-34-56] service-type lan-access
[AC-luser-00-e0-fc-12-34-56] quit
# Configure ISP domain aabbcc.net to perform local authentication for access users.
[AC] domain aabbcc.net
[AC-isp-aabbcc.net] authentication lan-access local
[AC-isp-aabbcc.net] quit
# Specify the ISP domain for MAC authentication.

[AC] mac-authentication domain aabbcc.net
# Set the MAC authentication timers.

[AC] mac-authentication timer offline-detect 180
# Configure MAC authentication to use MAC-based accounts. The MAC address usernames and
passwords are hyphenated and in lower case.
[AC] mac-authentication user-name-format mac-address with-hyphen lowercase

# Configure WLAN port security, using MAC and PSK authentication.

[AC-WLAN-ESS0] port-security port-mode mac-and-psk
[AC-WLAN-ESS0] port-security preshared-key pass-phrase 12345678
[AC-WLAN-ESS0] quit
# Create service template 2 of crypto type, configure its SSID as mac-authentication-local, and bind port
WLAN-ESS 0 to service template 2.
[AC-wlan-st-2] ssid mac-authentication-local
130

[AC-wlan-st-2] quit
# Create an AP template named ap1, specify the model as MSM460-WW and serial number as
CN2AD330S8.

[AC-wlan-ap-ap1-radio-1] return

# After the WLAN user passes MAC authentication, display MAC authentication settings and statistics.
<AC> display mac-authentication interface WLAN-DBSS 0:0
MAC address authentication is enabled.
User name format is MAC address in lowercase, like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Offline detect period is 180s
Quiet period is 60s
Server response timeout value is 100s
The max allowed user number is 20480 per slot
Current user number amounts to 1
Current domain is aabbcc.net
Silent MAC User info:
MAC Addr
From Port
Port Index
WLAN-DBSS0:0 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 4096
Current online user number is 1
MAC Addr
Authenticate State
00e0-fc12-3456
MAC_AUTHENTICATOR_AUTHOR
# Display the online user information.

<AC>display connection
Index=1299,Username=00-e0-fc-l2-34-56@aabbcc.net
MAC=00-E0-FC-12-34-56
IP=N/A
IPv6=N/A
Online=00h00m53s
131
Auth Index
1299
RADIUS-based MAC authentication configuration example

As shown in Figure 48, a WLAN client connects to the AC through a Layer 2 switch. The AC uses RADIUS
servers for authentication, authorization, and accounting.
Perform MAC authentication on WLAN-ESS interface to control Internet access. Make sure that:
The AC detects whether a user has gone offline every 180 seconds.
All MAC authentication users belong to ISP domain 2000 and share the user account aaa with
password 123456.
Make sure the RADIUS server and the AC can reach each other.
# Create a shared account for MAC authentication users on the RADIUS server, and set the username
aaa and password 123456 for the account. (Details not shown.)
# Configure IP addresses of the interfaces. (Details not shown.)
# Configure a RADIUS scheme.
<AC> system-view
[AC-radius-2000] primary authentication 10.1.1.1 1812
[AC-radius-2000] primary accounting 10.1.1.2 1813
[AC-radius-2000] key authentication simple abc
[AC-radius-2000] key accounting simple abc
# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and accounting.
[AC] domain 2000
[AC-isp-2000] authorization default radius-scheme 2000
132
[AC-isp-2000] quit

# Configure the WLAN port security, using MAC and PSK authentication, and specify the domain 2000
as the authentication domain for MAC authentication users on the port.
[AC-WLAN-ESS0] mac-authentication domain 2000
[AC-WLAN-ESS0] quit
# Create service template 2 of crypto type, configure its SSID as mac-authentication-radius and bind
port WLAN-ESS 0 to service template 2.
[AC-wlan-st-2] ssid mac-authentication-radius
[AC-wlan-st-2] quit
CN2AD330S8.

# Set the MAC authentication timers.

[AC] mac-authentication timer offline-detect 180
# Specify username aaa and plaintext password 123456 for the account shared by MAC authentication
users.
[AC] mac-authentication user-name-format fixed account aaa password simple 123456

# After a WLAN user passes MAC authentication, display MAC authentication settings and statistics.
<AC> display mac-authentication interface WLAN-DBSS0:7
User name format is fixed account
Fixed username:aaa
Fixed password:******
Quiet period is 60s
133

Current domain is 2000

MAC Addr
From Port
Port Index
MAC Addr
Authenticate State
000e-35b2-8be9
MAC_AUTHENTICATOR_SUCCESS
Auth Index
1297
# Display the online user information.

<AC> display connection
Index=1297,Username=aaa@2000
MAC=00-0E-35-B2-8B-E9
IP=N/A
IPv6=N/A
Online=00h00m53s
ACL assignment configuration example

As shown in Figure 49, a WLAN client connects to the AC and the AC uses RADIUS servers to perform
authentication, authorization, and accounting.
Perform MAC authentication on port WLAN-ESS 0 to control Internet access. Make sure that an
authenticated user can access the Internet but the FTP server at 10.0.0.1.
Use MAC-based user accounts for MAC authentication users. The MAC addresses are hyphen separated
and in lower case.
134

Authentication servers
(RADIUS server cluster)
10.1.1.1
10.1.1.2
IP network
Client
AP
FTP server
192.168.1.10
10.0.0.1
AC
Make sure the RADIUS server and the AC can reach each other.
1.
Add a user account with 00-e0-fc-12-34-56 as both the username and password on the RADIUS
server, and specify ACL 3000 as the authorization ACL for the user account. (Details not shown.)
2.
Configure the ACL:

# Configure IP addresses of the interfaces. (Details not shown.)
# Configure ACL 3000 to deny packets destined to 10.0.0.1.
<AC> system-view
[AC-acl-adv-3000] rule 0 deny ip destination 10.0.0.1 0
[AC-acl-adv-3000] quit
3.
Configure RADIUS-based MAC authentication on the AC:

# Configure a RADIUS scheme.
[AC-radius-2000] key authentication simple abc
[AC-radius-2000] key accounting simple abc
# Apply the RADIUS scheme to an ISP domain for authentication, authorization, and accounting.
[AC] domain 2000
[AC-isp-2000] authorization default radius-scheme 2000
[AC-isp-2000] quit
# Configure the AC to use MAC-based user accounts, the MAC addresses are hyphen separated
and in lower case.
[AC] mac-authentication user-name-format mac-address with-hyphen lowercase
135

# Configure the WLAN port security, using MAC and PSK authentication, and specify the domain
2000 as the authentication domain for MAC authentication users on the port.
[AC-WLAN-ESS0] mac-authentication domain 2000
[AC-WLAN-ESS0] quit
# Create service template 2 of crypto type, configure its SSID as mac-authentication-acl, and bind
port WLAN-ESS 0 to service template 2.
[AC-wlan-st-2] ssid mac-authentication-acl
[AC-wlan-st-2] quit
CN2AD330S8.


# After a WLAN client passes authentication, display MAC authentication settings and statistics.
<AC>display mac-authentication interface WLAN-DBSS 0:9
User name format is MAC address in lowercase, like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Quiet period is 60s
Current domain is 2000
MAC Addr
From Port
Port Index
136

MAC Addr
Authenticate State
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
Auth Index
1301
# Display online user information.

Index=1301,Username=00-e0-fc-12-34-56@2000
MAC=00-E0-FC-L2-34-56
IP=N/A
IPv6=N/A
Online=00h00m53s
# Ping the FTP server from the client to verify that the ACL 3000 has been assigned to port WLAN-ESS
0 to deny access to the FTP server.
<Client> ping 10.0.0.1
PING 10.0.0.1: 56
data bytes, press CTRL_C to break
Request time out

Request time out
Request time out
Request time out
Request time out
--- 10.0.0.1 ping statistics --5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
137
Configuring portal authentication

Overview
Portal authentication helps control access to the Internet. Portal authentication is also called Web
authentication. A website implementing portal authentication is called a portal website.
With portal authentication, an access device redirects all users to the portal authentication page. All
users can access the free services provided on the portal website. However, to access the Internet, a user
must pass portal authentication.
A user can access a known portal website and enter a username and password for authentication. This
authentication mode is called active authentication. There is another authentication mode, forced
authentication, in which the access device forces a user who is trying to access the Internet through HTTP
to log on to a portal website for authentication.
The portal feature provides the flexibility for ISPs to manage services. A portal website can, for example,
present advertisements and deliver community and personalized services. In this way, broadband
network providers, equipment vendors, and content service providers form an industrial ecological
system.
Extended portal functions

By forcing patching and anti-virus policies, extended portal functions help users to defend against viruses.
Portal authentication supports the following extended functions:
Security checkWorks after identity authentication succeeds to check whether the required
anti-virus software, virus definition file, and operating system patches are installed, and whether
there is any unauthorized software installed on the user host.
Resource access restrictionAllows users passing identity authentication to access only network
resources in the quarantined area, such as the anti-virus server and the patch server. Only users
passing both identity authentication and security check can access restricted network resources.
Portal system components

As shown in Figure 50, a typical portal system has these basic components:
Authentication client
Access device
Portal server
Authentication/accounting server
Security policy server
138
Figure 50 Portal system components
Access device
Portal server
Authentication/accounting
server
An authentication client is an entity seeking access to network resources. It is typically an end-user
terminal such as a PC. A client can use a browser or portal client software for portal authentication. Client
security check is implemented through communications between the client and the security policy server.
To implement security check, the client must be the HP iNode client.
Access device
Access devices control user access. An access device can be a switch or router that provides the
following functions:
Redirecting all HTTP requests from unauthenticated users to the portal server.
Interacting with the portal server, the security policy server, and the authentication/accounting
server for identity authentication, security check, and accounting.
Allowing users who have passed identity authentication and security check to access granted
Internet resources.
Portal server
A portal server listens to authentication requests from authentication clients and exchanges client
authentication information with the access device. It provides free portal services and pushes Web
authentication pages to users.
A portal server can be an entity independent of the access device or an entity embedded in the access
device. In this document, the term "portal server" refers to an independent portal server, and the term
"local portal server" refers to an embedded portal server.
Authentication/accounting server
An authentication/accounting server implements user authentication and accounting through interaction
with the access device.
Only a RADIUS server can serve as the remote authentication/accounting server in a portal system.

A security policy server interacts with authentication clients and access devices for security check and
resource authorization.
139
The components of a portal system interact as follows:

1.
When an unauthenticated user enters a website address in the browser's address bar to access the
Internet, the system creates an HTTP request and sends it to the access device. The access device
then redirects the HTTP request to the portal server's Web authentication homepage. For extended
portal functions, authentication clients must run the portal client software.
2.
On the authentication homepage/authentication dialog box, the user enters and submits the
authentication information, which the portal server then transfers to the access device.
3.
Upon receipt of the authentication information, the access device communicates with the
authentication/accounting server for authentication and accounting.
4.
After successful authentication, the access device checks whether there is a corresponding security
policy for the user. If not, it allows the user to access the Internet. Otherwise, the client
communicates with the access device and the security policy server for security check. If the client
passes the security check, the security policy server authorizes the user to access the Internet
resources.
NOTE:
Portal authentication supports NAT traversal whether it is initiated by a Web client or an HP iNode client.
When the portal authentication client is on a private network, but the portal server is on a public network
and the access device is enabled with NAT, network address translations performed on the access device
do not affect portal authentication. However, in such a case, HP recommends using an interface's public
IP address as the source address of outgoing portal packets.
Portal system using the local portal server

In addition to using a separate device as the portal server, a portal system can also use the local portal
server function of the access device to authenticate Web users directly. In this case, the portal system
consists of only three components: authentication client, access device, and authentication/accounting
server, as shown in Figure 51.
Figure 51 Portal system using the local portal server
No security policy server is needed for local portal service because the portal system using the local
portal server does not support extended portal functions.
The local portal server function of the access device implements only some simple portal server functions.
It only allows users to log on and log off through the Web interface. It cannot take the place of an
independent portal server.
Protocols used for interaction between the client and local portal server
You can use HTTP and HTTPS for interaction between an authentication client and an access device
providing the local portal server function. If you use HTTP, there are potential security problems because
HTTP packets are transferred in plain text. If you use HTTPS, secure data transmission is ensured because
HTTPS packets are transferred in cipher text based on SSL.
140
Authentication page customization support

The local portal server function allows you to customize authentication pages. You can customize
authentication pages by editing the corresponding HTML files, and then compress and save the files to
the storage medium of the device. A set of customized authentication pages consists of the following
authentication pages:
Logon page
Logon success page
Online page
Logoff success page
Logon failure page
System busy page
A local portal server pushes a corresponding authentication page at each authentication phase. If you
do not customize the authentication pages, the local portal server pushes the default authentication
pages. For information about authentication page customization rules, see "Customizing authentication
pages."
Portal authentication modes

Portal authentication may work at Layer 2 or Layer 3 of the OSI model. The device supports only Layer 3
portal authentication.
You can enable Layer 3 authentication on an access device's Layer 3 interfaces that connect
authentication clients. Portal authentication performed on a Layer 3 interface can be direct authentication,
re-DHCP authentication, or cross-subnet authentication. In direct authentication and re-DHCP
authentication, no Layer 3 forwarding devices exist between the authentication client and the access
device. In cross-subnet authentication, Layer 3 forwarding devices may exist between the authentication
client and the access device.
Direct authentication
Before authentication, a user manually configures a public IP address or directly obtains a public IP
address through DHCP, and can access only the portal server and predefined free websites. After
passing authentication, the user can access the network resources. The process of direct authentication
is simpler than that of re-DHCP authentication.
Re-DHCP authentication
Before authentication, a user gets a private IP address through DHCP and can access only the portal
server and predefined free websites. After passing authentication, the user is allocated a public IP
address and can access the network resources. No public IP address is allocated to those who fail
authentication. This solves the IP address planning and allocation problem. For example, a service
provider can allocate public IP addresses to broadband users only when they access networks beyond
the residential community network.
The local portal server does not support re-DHCP portal authentication. IPv6 portal authentication does
not support the re-DHCP authentication mode.
Cross-subnet authentication
Cross-subnet authentication is similar to direct authentication, but it allows Layer 3 forwarding devices to
be present between the authentication client and the access device.
141
In direct authentication, re-DHCP authentication, and cross-subnet authentication, the client's IP address
is used for client identification. After a client passes authentication, the access device generates an ACL
for the client based on the client's IP address to permit packets from the client to go through the access
port. Because no Layer 3 devices are present between the authentication clients and the access device in
direct authentication and re-DHCP authentication, the access device can directly learn the clients' MAC
addresses, and can enhance the capability of controlling packet forwarding by also using the learned
MAC addresses.
Portal support for EAP

Only Layer 3 portal authentication that uses a remote portal server supports EAP authentication.
Authentication by using the username and password is less secure. Digital certificate authentication is
usually used to ensure higher security.
The Extensible Authentication Protocol (EAP) supports several digital certificate-based authentication
methods, for example, EAP-TLS. Working together with EAP, portal authentication can implement digital
certificate-based user authentication.
Figure 52 Portal support for EAP working flow diagram
As shown in Figure 52, the authentication client and the portal server exchange EAP authentication
packets. The portal server and the access device exchange portal authentication packets that carry the
EAP-Message attributes. The access device and the RADIUS server exchange RADIUS packets that carry
the EAP-Message attributes. The RADIUS server that supports the EAP server function processes the EAP
packets encapsulated in the EAP-Message attributes, and provides the EAP authentication result. During
the whole EAP authentication process, the access device does not process the packets that carry the
EAP-Message attributes, but only transports them between the portal server and the RADIUS server.
Therefore, no additional configuration is needed on the access device.
NOTE:
To use portal authentication that supports EAP, the portal server and client must be the HP IMC portal
server and the HP iNode portal client.
Layer 3 portal authentication process

Direct authentication and cross-subnet authentication share the same authentication process. Re-DHCP
authentication has a different process because of the presence of two address allocation procedures.
142
Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication)

Figure 53 Direct authentication/cross-subnet authentication process
The direct authentication/cross-subnet authentication process is as follows:

1.
An authentication client initiates authentication by sending an HTTP request. When the HTTP
packet arrives at the access device, the access device allows it to pass if it is destined for the portal
server or a predefined free website, or redirects it to the portal server if it is destined for other
websites. The portal server pushes a Web authentication page to the user, and the user enters the
username and password.
2.
The portal server and the access device exchange CHAP messages. This step is skipped for PAP
authentication.
3.
The portal server assembles the username and password into an authentication request message,
and it sends the message to the access device. Meanwhile, the portal server starts a timer to wait
for an authentication acknowledgment message.
4.
The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
5.
The access device sends an authentication reply to the portal server.
6.
The portal server sends an authentication success message to the authentication client to notify it of
logon success.
7.
The portal server sends an authentication reply acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:

8.
The security policy server exchanges security check information with the authentication client to
check whether the authentication client meets the security requirements.
9.
Based on the security check result, the security policy server authorizes the user to access certain
resources, and sends the authorization information to the access device. The access device then
controls access of the user based on the authorization information.
143
Re-DHCP authentication process (with CHAP/PAP authentication)

Figure 54 Re-DHCP authentication process
Authentication
client
Portal server
Access device
Authentication/
accounting server
Security
policy server
1) Initiate a connection
2) CHAP authentication
3) Authentication request
4) RADIUS
authentication
Timer
5) Authentication reply
6) Authentication
succeeds
7) The user obtains
a new IP address
8) Discover user IP change
9) Detect user IP change

10) Notify login
success
11) IP change
acknowledgment
12) Security check
13) Authorization
The re-DHCP authentication process is as follows:

Step 1 through step 6 are the same as those in the direct authentication/cross-subnet authentication
process.
7.
After receiving the authentication success message, the authentication client obtains a new public
IP address through DHCP and notifies the portal server that it now has a public IP address.
8.
The portal server notifies the access device that the authentication client has obtained a new public
IP address.
9.
Detecting the change of the IP address by examining ARP packets received, the access device
notifies the portal server of the change.
10. The portal server notifies the authentication client of logon success.
11. The portal server sends a user IP address change acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
12. The security policy server exchanges security check information with the authentication client to
check whether the authentication client meets the security requirements.
13. Based on the security check result, the security policy server authorizes the user to access certain
resources, and sends the authorization information to the access device. The access device then
controls access of the user based on the authorization information.
144
Authentication process with the local portal server

Figure 55 Authentication process with the local portal server
With the local portal server, the direct/cross-subnet authentication process is as follows:
1.
A portal client initiates authentication by sending an HTTP request. When the HTTP packet arrives
at an access device using the local portal server, it is redirected to the local portal server, which
then pushes a Web authentication page for the user to enter the username and password. The
listening IP address of the local portal server is the IP address of a Layer 3 interface on the access
device that can communicate with the portal authentication client.
2.
The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
3.
If the user passes authentication, the local portal server pushes a logon success page to the
authentication client, informing the user of the authentication (logon) success.
Portal support for EAP authentication process

Figure 56 Portal support for EAP authentication process
All portal authentication modes share the same EAP authentication steps. The following example uses
direct portal authentication to show the EAP authentication process:
1.
The authentication client sends an EAP Request/Identity message to the portal server to initiate an
EAP authentication process.
145
2.
The portal server sends a portal authentication request to the access device, and starts a timer to
wait for the portal authentication reply. The portal authentication request contains several
EAP-Message attributes, which are used to encapsulate the EAP packet sent from the
authentication client and carry the certificate information of the client.
3.
After the access device receives the portal authentication request, it constructs a RADIUS
authentication request and sends the request to the RADIUS server. The EAP-Message attributes in
the RADIUS authentication request are those carried in the received portal authentication request.
4.
The access device sends a certificate request to the portal server according to the reply received
from the RADIUS server. The certificate request also contains several EAP-Message attributes,
which are used to transfer the certificate information of the RADIUS server. The EAP-Message
attributes in the certificate request are those carried in the RADIUS authentication reply.
5.
After receiving the certificate request, the portal server sends an EAP authentication reply to the
authentication client, carrying the EAP-Message attribute values.
6.
The authentication client sends another EAP request to continue the EAP authentication with the
RADIUS server, during which there may be several portal authentication requests. The subsequent
authentication processes are the same as that initiated by the first EAP request, except that the EAP
request types vary with the EAP authentication phases.
7.
After the authentication client passes the EAP authentication, the RADIUS server sends an
authentication reply to the access device. This reply carries the EAP-Success message in the
EAP-Message attribute.
8.
The access device sends an authentication reply to the portal server. This reply carries the
EAP-Success message in the EAP-Message attribute.
9.
The portal server notifies the authentication client of the authentication success.
10. The portal server sends an authentication reply acknowledgment to the access device.
The remaining steps are for extended portal authentication. For more information about the steps, see the
portal authentication process with CHAP/PAP authentication.
MAC-based quick portal authentication

Typically, users must provide username and password for portal authentication each time they access the
network. Users who access the network frequently may want to pass authentication without entering
username and password. To meet such requirements, portal supports a MAC-based quick authentication
scheme, which is also referred to as MAC-triggered authentication.
With MAC-triggered authentication, the access device obtains the source MAC address of a user. When
the network traffic of the user is below the specified threshold (1024 bytes for example), the access device
allows the user to access the network without portal authentication. When the user's network traffic
reaches the threshold, the access device triggers portal authentication for the user. The authentication
procedure is as follows:
1.
The access device sends a MAC binding query to the MAC binding server.
2.
When the MAC binding server receives the query, it checks whether the MAC address is bound
with a portal user account.
{
If yes, the MAC binding server obtains the account information of the portal user, and sends the
username and password of the user to the access device to initiate portal authentication. The
user can pass portal authentication without entering the username and password.
146
If not, the MAC binding server notifies the access device to perform normal portal
authentication for the user. The access device redirects the subsequent HTTP packet of the user
to the portal server, which provides a portal authentication page for the user. The user must enter
the username and password to pass portal authentication.
MAC-triggered authentication provides a quick, effective portal authentication for users whose MAC
addresses have been bound with portal user accounts on the MAC binding servers.
A MAC binding server is required for MAC-triggered authentication. An HP IMC portal server should be
used as the MAC binding server. The MAC-to-account bindings of portal users are recorded on the MAC
binding server.
A MAC binding server performs the following functions:
Records bindings between endpoints (identified by MAC addresses) and user accounts. The
bindings facilitate user auditing.
Endpoint-to-account bindings are added to the endpoint device list of the MAC binding server in
the following ways:
{
The MAC binding server automatically learns and records the binding between an endpoint
and an account. The binding does not update automatically. The endpoint is bound only to the
first account that passes authentication on the endpoint, no matter how many accounts pass
authentication later. To unbind the endpoint and the account, you need to delete the binding
from the endpoint device list.
A user manually adds endpoint-to-account bindings on the user self-service center. This method
allows multiple endpoints to be bound to an account.
Records bindings between endpoints (identified by MAC addresses) and manufacturer/device

type/operating system information. The bindings facilitate endpoint auditing.
The MAC binding server automatically obtains the manufacturer, device type, and operating
system information of an endpoint. The binding between the endpoint and the information
obtained the first time is saved in the endpoint device list. When a user initiates authentication on
the endpoint, the MAC binding server compares the current information of the endpoint with the
recorded information. If inconsistency occurs, the MAC binding server logs the endpoint
information conflict.
Provides quick enabling/disabling of MAC-triggered authentication.

If MAC-triggered authentication for endpoints is enabled on the MAC binding server, you can
quickly enable or disable MAC-triggered authentication for specific endpoints in the endpoint
device list.
On an HP IMC portal server, you can configure the fast authentication on smart terminals function to
implement MAC-triggered authentication. For more information about the configuration procedure, see
the configuration manuals for the IMC portal server.
Portal stateful failover

Overview
Stateful failover supports hot backup of services on two devices. Stateful failover can be configured on
key devices to avoid service interruptions caused by single point failures. When operating normally, the
two devices synchronize service information. If one device fails, the other device takes over the services.
147
To implement stateful failover, specify an stateful failover interface on each device and connect the two
stateful failover interfaces through a failover link, or specify a dedicated VLAN (called the backup VLAN)
on each device for stateful failover packets. When both a failover link and a backup VLAN are
configured, add the physical ports at the two ends of the failover link to the backup VLAN. For more
information about the stateful failover feature, see High Availability Configuration Guide.
Figure 57 Network diagram for portal stateful failover configuration
As shown in Figure 57, users have to pass portal authentication to access the Internet. To avoid portal
service interruption caused by single point failures, deploy two access devices (Gateway A and
Gateway B) and configure the portal stateful failover function so that they back up the portal online user
information of each other through the failover link. If either one (Gateway A or Gateway B) fails, the
other can guarantee the normal data communication of the online portal users and perform portal
authentication for new portal users.
Basic concepts
1.
Device states:
{
2.
IndependenceA stable running status of a device when it does not establish the failover link
with the other device.
SynchronizationA stable running status of a device when it establishes the failover link with
the other device successfully and is ready for data backup.
User modes:
{
Stand-aloneIndicates that the user data is stored on the local device only. Currently, the local
device is in independence state or it is in synchronization state, but it has not synchronized the
user data to the peer device yet.
148
PrimaryIndicates that the user logs in from the local device, and the user data is generated on
the local device. The local device is in synchronization state and ready for receiving and
processing packets from the server.
SecondaryIndicates that the user logs in from the peer device, and the user data is
synchronized from the peer device to the local device. The local device is in synchronization
state. It only receives and processes the synchronization messages and does not process
packets from the server.
Portal configuration task list

To configure Layer 3 portal authentication:
Task
Remarks
Specifying a portal server for Layer 3 portal authentication
Required.
Configuring the local portal server
Optional.
Enabling Layer 3 portal authentication
Required.
Configuring a portal-free rule

Configuring a portal-forbidden rule
Controlling access of portal
users
Configuring an authentication source subnet

Setting the maximum number of online portal users
Optional.
Specifying a portal authentication domain

Configuring Layer 3 portal authentication to
support Web proxy
Specifying the NAS ID value carried in a RADIUS
request
Configuring RADIUS related
attributes
Specifying NAS-Port-Type for an interface
Optional.
Specifying the NAS-Port-ID for an interface

Specifying a NAS ID profile for an interface
Specifying a source IP address for outgoing portal packets
Optional.
Configuring MAC-based quick portal authentication
Optional.
Configuring portal stateful failover
Optional.
Associating an SSID and AP with a portal server and an authentication domain
Optional.
Specifying an autoredirection URL for authenticated portal users
Optional.
Configuring online Layer 3 portal user detection

Configuring portal detection
functions
Configuring the portal server detection function
Optional.
Configuring portal user information

synchronization
Logging off portal users
Optional.
Enabling forced logoff for user SSID switching
Optional.
Enabling logging for portal packets
Optional.
149
Task
Remarks
Specifying the parameters to be carried in the redirection URL
Optional.
Enabling host identity check through DHCP snooping
Optional.
Configuring mandatory webpage pushing
Optional.
Although the portal feature provides a solution for user identity authentication and security check, the
portal feature cannot implement this solution by itself. RADIUS authentication must be configured on the
access device to cooperate with the portal feature to complete user authentication.
The prerequisites for portal authentication configuration are as follows:
The portal server and the RADIUS server have been installed and configured properly. Local portal
authentication requires no independent portal server be installed.
With re-DHCP authentication, the IP address check function of the DHCP relay agent is enabled on
the access device, and the DHCP server is installed and configured properly.
The portal client, access device, and servers can reach each other.
With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS
server, and the RADIUS client configurations are performed on the access device. For information
about RADIUS client configuration, see "Configuring AAA."
To implement extended portal functions, install and configure IMC EAD, and make sure that the
ACLs configured on the access device correspond to those specified for the resources in the
quarantined area and for the restricted resources on the security policy server. For information
about security policy server configuration on the access device, see "Configuring AAA."
For installation and configuration about the security policy server, see IMC EAD Security Policy Help.
The ACL for resources in the quarantined area and that for restricted resources correspond to isolation
ACL and security ACL on the security policy server.
You can modify the authorized ACLs on the access device. However, your changes take effect only for
portal users logging on after the modification.
Specifying a portal server for Layer 3 portal

authentication
Perform this task to specify portal server parameters for Layer 3 portal authentication, including the portal
server IP address, shared encryption key, server port, and the URL address for Web authentication.
According to the networking environment, you can configure a remote portal server or a local portal
server as needed.
To configure a remote portal server, specify the IP address of the remote portal server.
To use the local portal server of the access device, specify the IP address of a Layer 3 interface on
the device as the portal server's IP address. The specified interface must be reachable to the client.
Follow these guidelines when you specify a portal server for Layer 3 authentication:
150
The specified parameters of a portal server can be modified or deleted only if the portal server is
not referenced on any interface.
For local portal server configuration, the keywords key, port, and url are usually not required and,
if configured, do not take effect. When using local portal servers for stateful failover in wireless
environments, however, the keyword url is required and the address format must be
http://ip-address/portal/logon.htm or https://ip-address/portal/logon.htm. Which address
format is used depends the protocol type (HTTP or HTTPS, configured by the portal local-server
command) supported by the local portal servers. The ip-address is the virtual IP address of the VRRP
group to which the downlink belongs.
When a local portal server is used, the re-DHCP portal authentication mode (redhcp) can be
configured but, if configured, does not take effect.
The maximum number of portal servers that you can specify on the access device depends on the
device model. For more information, see About the Command References for HP Unified
To specify a portal server for Layer 3 authentication:

Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
By default, no portal server is specified.
Specify a portal
server and configure
related parameters.
portal server server-name { ip

ipv4-address [ key [ cipher |
simple ] key-string | port
port-id | url url-string ] * |
ipv6 ipv6-address [ key
[ cipher | simple ] key-string |
port port-id | url url-string ] * }
The portal server name and URL string cannot

contain any of the following characters: question
mark (?), angle brackets (<>), backward slash
(\), double quotation mark ("), single quotation
mark ('), percent sign (%), ampersand (&), and
pound sign (#).

Configuring a local portal server is required only for local portal authentication. During local portal
authentication, the local portal server pushes authentication pages to users. You can define the
authentication pages for users. Otherwise, the default authentication pages are used during the
authentication process.
In a wireless network, you can bind an SSID to a set of authentication pages. The system selects
authentication pages for a user in this order: the authentication pages bound with the SSID of the user,
the user-defined default authentication pages, and the system default authentication pages.
Customizing authentication pages

Customized authentication pages exist in the form of HTML files. You can compress them, and then save
them in the storage medium of the access device.
A set of authentication pages includes six main authentication pages and their page elements.
The six main authentication pages are the logon page, the logon success page, the logon failure page,
the online page, the system busy page, and the logoff success page.
The page elements refer to the files that the authentication pages reference, for example, back.jpg for
page Logon.htm. Each main authentication page can reference multiple page elements. If you define
151
only some of the main authentication pages, the system uses the default authentication pages for the
undefined ones.
For the local portal server to operate normally and steadily, use the following rules when customizing
authentication pages:
File name rules

The names of the main authentication page files cannot be changed. You can define the names of the
files other than the main authentication page files. File names and directory names are case-insensitive.
Table 9 Main authentication page file names
Main authentication page
File name
Logon page
logon.htm
Logon success page
logonSuccess.htm
Logon failure page
logonFail.htm
Online page
Pushed after the user gets online for online notification
System busy page
Pushed when the system is busy or the user is in the logon process
Logoff success page
online.htm
busy.htm
logoffSuccess.htm
Page request rules

The local portal server supports only Get and Post requests.
Get requestsUsed to get the static files in the authentication pages and allow no recursion. For
example, if file Logon.htm includes contents that perform Get action on file ca.htm, file ca.htm
cannot include any reference to file Logon.htm.
Post requestsUsed when users submit username and password pairs, log on the system, and log
off the system.
Post request attribute rules

1.
Observe the following requirements when editing a form of an authentication page:

{
2.
An authentication page can have multiple forms, but there must be one and only one form
whose action is logon.cgi. Otherwise, user information cannot be sent to the local portal server.
The username attribute is fixed as PtUser. The password attribute is fixed as PtPwd.
Attribute PtButton is required to indicate the action that the user requests, either Logon or Logoff.
A logon Post request must contain PtUser, PtPwd, and PtButton attributes.
A logoff Post request must contain the PtButton attribute.
Authentication pages logon.htm and logonFail.htm must contain the logon Post request.
The following example shows part of the script in page logon.htm.
<form action=logon.cgi method = post >
<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px"
maxlength=64>
<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px"
maxlength=32>
152
<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;"

onclick="form.action=form.action+location.search;>
</form>
3.
Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.
The following example shows part of the script in page online.htm.
<form action=logon.cgi method = post >
<p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;">
</form>
Page file compression and saving rules
A set of authentication page files must be compressed into a standard zip file. The name of a zip
file can contain only letters, numerals, and underscores. The zip file of the default authentication
pages must be saved with name defaultfile.zip.
The set of authentication pages must be located in the root directory of the zip file.
You can transfer zip files to the device through FTP or TFTP. You must save the default authentication
pages file in the root directory of the device. You can save other authentication files in the root
directory or the portal directory under the root directory of the device.
Examples of zip files on the device:
<Sysname> dir
Directory of flash:/portal/
0
-rw-
1405
Feb 28 2013 15:53:31
ssid2.zip
-rw-
1405
Feb 28 2013 15:53:20
ssid1.zip
-rw-
1405
Feb 28 2013 15:53:39
ssid3.zip
-rw-
1405
Feb 28 2013 15:53:44
ssid4.zip
2540 KB total (1319 KB free)
File size and content rules

The following size and content requirements for authentication pages allows the system to push
customized authentication pages smoothly:
The size of the zip file of each set of authentication pages, including the main authentication pages
and the page elements, must be no more than 500 KB.
The size of a single page, including the main authentication page and its page elements, must be
no more than 50 KB before being compressed.
Page elements can contain only static contents such as HTML, JS, CSS, and pictures.
Logging off a user who closes the logon success or online page
After a user passes authentication, the system pushes the logon success page named logonSuccess.htm.
If the user initiates another authentication through the logon page, the system pushes the online page
named online.htm. You can configure the device to forcibly log off the user when the user closes either of
these two pages. To do so, add the following contents in logonSuccess.htm and online.htm:
1.
Reference to JS file pt_private.js.
2.
Function pt_unload(), which is used to trigger page unloading.
3.
Function pt_submit(), the event handler function for Form.
4.
Function pt_init(), which is for triggering page loading.
The following is a script example with the added contents highlighted in gray:
<html>
<head>
153
<script type="text/javascript" language="javascript" src="pt_private.js"></script>

</head>
<body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
<form action=logon.cgi method = post onsubmit="pt_submit()">
... ...
</body>
</html>
If a user refreshes the logon success or online page, or jumps to another website from either of the pages,
the device also logs off the user.
Only Microsoft IE, Mozilla Firefox, and Apple Safari browsers support the device to log off the user when
the user closes the logon success or online page. Google Chrome, Opera, and other browsers do not
support this function.
Make sure the browser of an authentication client permits pop-ups or permits pop-ups from the access
device. Otherwise, the user cannot log off by closing the logon success or online page, and can only
click Cancel to return back to the logon success or online page.
Redirecting authenticated users to a specific webpage

To make the device automatically redirect authenticated users to a specific webpage, do the following in
logon.htm and logonSuccess.htm:
1.
In logon.htm, set the target attribute of Form to blank.

See the contents in gray:
<form method=post action=logon.cgi target="blank">
2.
Add the function for page loading pt_init() to logonSucceess.htm.

See the contents in gray:
<html>
<head>
<title>LogonSuccessed</title>
<script type="text/javascript" language="javascript"
src="pt_private.js"></script>
</head>
<body onload="pt_init();" onbeforeunload="return pt_unload();">
... ...
</body>
</html>
NOTE:
HP recommends using Microsoft IE 6.0 or later on the authentication clients.

To make the local portal server take effect, specify the protocol to be used for communication between
the portal client and local portal server.
To configure the local portal server to support HTTPS, complete the following configurations first:
154
Configure PKI policies, obtain the CA certificate, and apply for a local certificate. For more
information, see "Configuring PKI."
Configure the SSL server policy, and specify the PKI domain to be used, which is configured in the
above step. For more information, see "Configuring SSL."
When you specify the protocol for the local portal server to support, the local portal server loads the
default authentication page file, which is supposed to be saved in the root directory of the device.
Therefore, to make sure the local portal server uses the user-defined default authentication pages, you
must edit and save them properly or else the system default authentication pages are used.
To configure the local portal server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the protocol type for

the local portal server to support
and load the default
authentication page file.
portal local-server { http | https

server-policy policy-name }
By default, the local portal server

does not support any protocol.
Optional.
3.
4.
Configure a binding between

one or more SSIDs and an
authentication page file.
portal local-server bind ssid

ssidname&<1-10> file filename
Configure the welcome banner of

the default authentication pages
of the local portal server.
portal server banner

banner-string
By default, no binding is
configured.
The file to be bound to the SSIDs
must exist.
Optional.
No welcome banner by default.
In Layer 3 cross-subnet portal authentication mode, an AC cannot obtain the SSID of a client associated
with an AP. In this case, the system does not support binding SSIDs to an authentication page file. For
more information about SSID, see WLAN Configuration Guide.
Enabling Layer 3 portal authentication

You must first enable portal authentication on an access interface before it can perform portal
authentication for connected clients.
The destination port number that the access device uses for sending unsolicited packets to the portal
server must be the same as the port number that the remote portal server actually uses.
The portal server and its parameters can be deleted or modified only when the portal server is not
referenced by any interface.
Cross-subnet authentication mode (portal server server-name method layer3) does not require
Layer 3 forwarding devices between the access device and the authentication clients. However, if
Layer 3 forwarding devices exist between the authentication client and the access device, you must
select the cross-subnet portal authentication mode.
In re-DHCP authentication mode, a client can use a public IP address to send packets before
passing portal authentication. However, responses to the packets are restricted.
155
An IPv6 portal server does not support the re-DHCP portal authentication mode.
You can enable both an IPv4 portal server and an IPv6 portal server for Layer 3 portal
authentication on an interface, but you cannot enable two IPv4 or two IPv6 portal servers on the
interface.
Before enabling Layer 3 portal authentication on an interface, make sure that:
An IP address is configured for the interface.
The portal server to be referenced on the interface exists.
To enable Layer 3 portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface-number
The interface must be a Layer 3

interface.
3.
Enable Layer 3 portal

authentication on the
interface.
portal server server-name method

{ direct | layer3 | redhcp }
Not enabled by default.
Controlling access of portal users

Configuring a portal-free rule
A portal-free rule allows specified users to access specified external websites without portal
authentication.
The matching items for a portal-free rule include the source and destination IP address, TCP/UDP port
number, source MAC address, inbound interface, and VLAN. Packets matching a portal-free rule do not
trigger portal authentication, so users sending the packets can directly access the specified external
websites.
If you specify both a VLAN and an interface in a portal-free rule, the interface must belong to the
VLAN. Otherwise, the rule does not take effect.
You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the
system prompts that the rule already exists.
Regardless of whether portal authentication is enabled or not, you can only add or remove a
portal-free rule. You cannot modify it.
To configure a portal-free rule:
Step
1.
Enter system
view.
Command
Remarks
system-view
N/A
156
Step
Command
Remarks
To configure an IPv4 portal-free rule:
2.
portal free-rule rule-number { destination { any | ip

{ ip-address mask { mask-length | mask } | any } [ tcp
tcp-port-number | udp udp-port-number ] | hostname
hostname } | source { any | [ { interface interface-type
interface-number | wlan ssid ssid [ spot spot ] } | ip
{ ip-address mask { mask-length | mask } | any } [ tcp
tcp-port-number | udp udp-port-number ] | mac
mac-address | vlan vlan-id ] * } } *
Configure a
portal-free rule.

command.
To configure an IPv6 portal-free rule:
portal free-rule rule-number { destination { any | ipv6

{ ipv6-address prefix-length | any } } | source { any |
[ { interface interface-type interface-number | wlan ssid
ssid [ spot spot ] } | ipv6 { ipv6-address prefix-length |
any } | mac mac-address | vlan vlan-id ] * } } *
Configuring a portal-forbidden rule

A portal forbidden rule can deny users' access to some specific resources. It contains such criteria as IP
address, domain name, TCP port number, or UDP port number. Any packet that matches the rule cannot
be forwarded.
To configure a portal-forbidden rule:
Step
Command
1.
Enter system view.
system-view
2.
Configure a
portal-forbidden rule.
portal forbidden-rule rule-number destination { ip { hostname | ip-address [ mask

{ mask-length | netmask } ] } | { { tcp | udp } port-number } } *
Configuring an authentication source subnet

By configuring authentication source subnets, you specify that only HTTP packets from users on the
authentication source subnets can trigger portal authentication. If an unauthenticated user is not on any
authentication source subnet, the access device discards all the user's HTTP packets that do not match
any portal-free rule.
Configuration of authentication source subnets applies to only cross-subnet authentication. In direct
authentication mode, the authentication source subnet is 0.0.0.0/0. In re-DHCP authentication mode,
the authentication source subnet of an interface is the subnet to which the private IP address of the
interface belongs.
To configure an authentication source subnet:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface
view.
interface-number
N/A
157
Step
3.
Command
Configure an
authentication
source subnet.
Remarks
portal auth-network
{ ipv4-network-address
{ mask-length | mask } | ipv6
ipv6-network-address prefix-length }
Optional.
By default, the authentication source IPv4
and IPv6 subnets are 0.0.0.0/0 and ::/0,
respectively, which mean that users from any
subnets must pass portal authentication.
You can configure up to 32 authentication source subnets by executing the portal auth-network
command.
Setting the maximum number of online portal users

You can use this feature to control the total number of online portal users in the system.
If the maximum number of online portal you set is less than that of the current online portal users, the limit
can be set successfully and does not impact the online portal users, but the system does not allow new
portal users to log on until the number drops down below the limit.
To set the maximum number of online portal users allowed in the system:
Step
1.
Enter system view.
2.
Set the maximum

number of online portal
users.
Command
Remarks
system-view
N/A
portal max-user
max-number
The default maximum number of online portal

users allowed depends on the device model.
For more information, see About the
Command References for HP Unified
Specifying a portal authentication domain

After you specify an authentication domain for portal users on an interface, the device uses the
authentication domain for AAA of all portal users on the interface, ignoring the domain names carried
in the usernames. This allows you to specify different authentication domains for different interfaces as
needed.
To specify the authentication domain for portal users on an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
domain for portal users on the
interface.
portal domain [ ipv6 ]

domain-name
By default, no authentication domain is

specified for portal users.
The device selects the authentication domain for a portal user on an interface in this order: the
authentication domain specified for the interface, the authentication domain carried in the username,
and the system default authentication domain. For information about the default authentication domain,
see "Configuring AAA."
158
Configuring Layer 3 portal authentication to support Web

proxy
By default, only HTTP requests from non-proxy users can trigger Layer 3 portal authentication. Proxied
HTTP requests cannot trigger Layer 3 portal authentication, and they are silently dropped. To allow such
HTTP requests to trigger portal authentication, configure the port numbers of the Web proxy servers on
the device.
Different clients may have different Web proxy configurations. The following prerequisites must be met
for these clients to trigger portal authentication:
Web proxy configuration on clients
If you use an IMC portal server, perform the following
configurations on the IMC portal server:
{
Scenario 1:
All or some clients use a Web proxy, and
the portal server's IP address is not a
proxy exception.
Select NAT as the type of the IP group associated with the

portal device.
Specify the proxy server's IP address as the IP address after
NAT.
Configure the port group to support NAT
The portal server and the Web proxy server have IP connectivity
to each other.
Scenario 2:
All or some clients use a Web proxy, and
the portal server's IP address is a proxy
exception.
If you use an IMC portal server, configure the IP group and port
group to not support NAT.
If you use an IMC portal server, add the client IP addresses to

Scenario 3:
All clients use a Web proxy server, but
only some clients specify the portal
server's IP address as a proxy exception.
two IP groups according to whether the portal server's IP

address is a proxy exception, and then configure the IP groups
and the port group according to scenarios 1 and 2.
The portal server and the Web proxy server have IP connectivity
to each other.
To configure Layer 3 portal authentication to support a Web proxy:
Step
1.
Enter system view.
2.
Add a Web proxy server port

number.
Command
Remarks
system-view
N/A
portal web-proxy port port-number
By default, no Web proxy server

port number is configured, and
proxied HTTP requests cannot
trigger portal authentication.
If a user's browser uses the WPAD protocol to discover Web proxy servers, add the port numbers of the
Web proxy servers on the device, and configure portal-free rules to allow user packets destined for the
IP address of the WPAD server to pass without authentication.
159
If the Web proxy server port 80 is added on the device, clients that do not use a proxy server can trigger
portal authentication only when they access a reachable host enabled with the HTTP service.
Authorized ACLs to be assigned to users who have passed portal authentication must contain a rule that
permits the Web proxy server's IP address. Otherwise, the users cannot receive heartbeat packets from
the remote portal server.
Configuring RADIUS related attributes

Specifying the NAS ID value carried in a RADIUS request
If the device uses a RADIUS server for authentication, authorization, and accounting of portal users,
when a portal user logs on from an interface, the device sends a RADIUS request that carries the
NAS-Identifier attribute to the RADIUS server. The RADIUS server uses the NAS-Identifier attribute in the
RADIUS request to identify the device.
You can specify the NAS-identifier attribute value to be carried in a RADIUS request in system view or
interface view. The device prefers the value specified in interface view. If no NAS ID is configured for the
interface, the device uses the NAS ID configured in system view.
To specify the NAS ID value carried in a RADIUS request:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
In system view:
portal nas-id nas-identifier
2.
Specify the NAS ID value

carried in a RADIUS request.
In interface view:
interface-number
b. portal nas-id
nas-identifier.
By default, the device name

configured by the sysname
command is used as the NAS ID.
For information about the sysname
command, see Fundamentals
Command Reference.
Specifying NAS-Port-Type for an interface

NAS-Port-Type is a standard RADIUS attribute for indicating a user access port type. With this attribute
specified on an interface, when a portal user logs on from the interface, the device uses the specified
NAS-Port-Type value as that in the RADIUS request to be sent to the RADIUS server. If NAS-Port-Type is not
specified, the device uses the access port type obtained.
If there are multiple network devices between the Broadband Access Server (the portal authentication
access device) and a portal client, the BAS may not be able to obtain a user's correct access port
information. For example, for a wireless client using portal authentication, the access port type obtained
by the BAS may be the type of the wired port that authenticates the user. To make sure that the BAS
delivers the right access port information to the RADIUS server, specify the NAS-Port-Type according to
the practical access environment.
To specify the NAS-Port-Type value for an interface:
160
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Specify the NAS-Port-Type

value for the interface.
portal nas-port-type { ethernet |

wireless }
Not configured by default.
Specifying the NAS-Port-ID for an interface

If the device uses a RADIUS server for authentication, authorization, and accounting of portal users,
when a portal user logs on from an interface, the device sends a RADIUS request that carries the
NAS-Port-ID attribute to the RADIUS server. The portal server configuration determines the usage of the
NAS-Port-ID attribute.
To specify the NAS-Port-ID value carried in a RADIUS request sent from an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
portal nas-port-id nas-port-id-value
By default, no NAS-Port-ID value is

specified for an interface, and the
device uses the information
obtained from the physical
interface where the portal user
accesses as the NAS-Port-ID value
in a RADIUS request.
3.
Configure the NAS-Port-ID

value.
Specifying a NAS ID profile for an interface

In some networks, user access points are identified by their access VLANs. Network carriers need to use
NAS-identifiers to identify user access points. With the NAS ID profile specified on an interface, when a
user logs in from the interface, the access device checks the specified profile to obtain the NAS ID that
is bound with the access VLAN. The value of this NAS ID is used as the NAS-identifier attribute in the
RADIUS packets to be sent to the RADIUS server.
The NAS ID profile defines the binding relationship between VLANs and NAS IDs. A NAS ID-VLAN
binding is defined by the nas-id id-value bind vlan vlan-id command, which is described in detail in AAA
configuration commands in the Security Command Reference.
If no NAS-ID profile is specified for an interface or no matching binding is found in the specified profile:
If the NAS ID is configured using the portal nas-id command, the device uses the configured NAS
ID as that of the interface.
If the interface has no NAS ID configured, the device uses the device name as the interface NAS ID.
To configure a NAS ID profile on an interface:
161
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a NAS ID profile and

enter NAS ID profile view.
aaa nas-id profile profile-name
For more information about the

command, see Security Command
Reference.
3.
Bind a NAS ID with a VLAN.
nas-id nas-identifier bind vlan

vlan-id

Reference.
4.
quit
N/A
5.
interface-number
N/A
6.
Specify a NAS ID profile for

the interface.
portal nas-id-profile profile-name
By default, an interface is specified

with no NAS ID profile.
Specifying a source IP address for outgoing portal

packets
After you specify a source IP address for outgoing portal packets on an interface, the IP address is used
as the source IP address of packets that the access device sends to the portal server, and the destination
IP address of packets that the portal server sends to the access device.
To specify a source IP address for outgoing portal packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface
view.
interface-number
N/A
Optional.
3.
Specify a source IP
address for
outgoing portal
packets.
portal nas-ip { ipv4-address |

ipv6 ipv6-address }
By default, no source IP address is specified, and

the IP address of the user logon interface is used as
the source IP address of outgoing portal packets.
In NAT environments, HP recommends specifying
the interface's public IP address as the source IP
address of outgoing portal packets.
Configuring MAC-based quick portal

authentication
To configure MAC-based quick portal authentication (MAC-triggered authentication), you must complete
the following tasks:
Configure basic Layer 3 portal authentication.
Specify the IP address and port number of a MAC binding server.

162
Enable MAC-triggered authentication on the interface enabled with portal authentication.
Specify the MAC binding server as a portal server. For configuration information, see "Specifying
a portal server for Layer 3 portal authentication."
After MAC-triggered authentication takes effect, the access device checks a user's traffic at a specific
interval (specified by the period period-value option). Before the user traffic reaches the threshold
(specified by the threshold threshold-value option), the user can access the external network without
authentication. When the user traffic reaches the threshold, the device performs MAC-triggered
authentication.
To configure MAC-triggered authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a MAC binding

server.
portal mac-trigger server ip

ip-address [ port port-number ]
By default, no MAC binding server

is specified.
3.
interface-number
N/A
4.
Enable MAC-triggered
authentication.
portal mac-trigger enable [ period

period-value ] [ threshold
threshold-value ]
By default, MAC-triggered
authentication is disabled.
5.
(Optional.) Configure the

NAS-Port-Type value carried
in RADIUS accounting
requests.
portal mac-trigger nas-port-type

value
By default, the port link type

determines the NAS-Port-Type
value.

CAUTION:
Specifying or changing the device ID of a device will log off all online users on the device. Therefore,
configure the device ID only when necessary and, after the configuration, save the configuration and
restart the device.
When two devices are running in stateful failover mode (one active, the other standby), do not delete the
configured backup source IP addresses. Otherwise, online users on the backup may not be able to
receive packets from the server.
To implement stateful failover for portal, configure VRRP for traffic switchover, and perform the following
configurations for service backup on each of the two devices that back up each other:
Specify an interface for backing up portal services, which is referred to as portal service backup
interface in this document, and enable portal on the portal service backup interface.
Specify the portal group to which the portal service backup interface belongs. Be sure to specify the
same portal group for the portal service backup interfaces that back up each other on the two
devices.
Specify the device ID. Make sure the device ID of the local device is different from that of the peer
device.
163
Specify the backup source IP address for outgoing RADIUS packets as the source IP address for
RADIUS packets that is configured on the peer device, so that the peer device can receive packets
from the server. (This configuration is optional.)
Specify the backup VLAN, and enable stateful failover on the VLAN interface. For related
configuration, see High Availability Configuration Guide.
After the stateful failover state of the two devices changes from independence to synchronization and the
portal group takes effect, the two devices start to back up the data of online portal users for each other.
In stateful failover mode, the device does not support re-DHCP portal authentication on the portal
service backup interface.
In stateful failover mode, if a user on either device is logged out, information about the user on the
other device is deleted, too. You can log off a user on the device or on the portal server. For example,
you can use the cut connection and portal delete-user commands on the device to log off users.
The AAA and portal configuration must be consistent on the two devices that back up each other.
For example, you must configure the same portal server on the two devices.
To configure stateful failover:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
By default, the portal service
backup interface does not belong
to any portal group.
Specify the portal group to

which the portal service
backup interface belongs.
portal backup-group group-id
The portal service backup

interfaces on the two devices for
stateful failover must belong to the
same portal group.
4.
quit
N/A
5.
Specify the device ID in

stateful failover mode.
3.
By default, the device ID is 1.

nas device-id device-id
164

Reference.
Step
Command
Remarks
Optional.
Use either method.
Method 1:
6.
Specify a backup source IP

address for outgoing RADIUS
packets.
radius nas-backup-ip
ip-address
Method 2:
a. radius scheme
radius-scheme-name
b. nas-backup-ip ip-address
By default, no backup source IP

address is specified.
You do not need to specify the
backup source IP address if the
device uses the virtual IP address of
the VRRP group to which the uplink
belongs as the source IP address of
outgoing RADIUS packets.
Reference.
Associating an SSID and AP with a portal server

and an authentication domain
After you associate an SSID and AP with a portal server and an authentication domain, the device looks
up the associations for the SSID and AP the user uses when a wireless user attempts to access external
network. If no match is found, the device uses the portal server specified when portal authentication is
enabled on the user connected interface, and the authentication domain configured in system view.
To make the association effective, make sure the specified portal server and authentication domain
already exist, and configure a portal-free rule so that the portal server can receive the packets from the
device. The AP name configured on the AC must be consistent with the NAS ID or NAS port ID
configured in AP template view or radio view. If you configure both NAS ID and NAS port ID, the AP
name must be consistent with the NAS port ID.
To associate an SSID and AP with a portal server and an authentication domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Associate an SSID and AP

name with a portal server and
an authentication domain.
portal wlan ssid ssid-name [ spot

spot-name ] server server-name
[ domain domain-name ]
By default, an SSID and AP name

are not associated with any portal
server or authentication domain.
Specifying an autoredirection URL for authenticated

portal users
If you specify an autoredirection URL on the access device, after an unauthenticated user passes portal
authentication through the portal authentication page, the access device redirects the user to the URL
after a specific period of time.
When no autoredirection URL is specified for authenticated portal users, an authenticated user is usually
redirected to the URL the user entered in the address bar before portal authentication. However, with
165
local portal authentication, if the URL a user entered in the address bar before portal authentication is
more than 255 characters, the user cannot be redirected to the page of the URL after passing portal
authentication.
To use this feature for remote Layer 3 portal authentication, the portal server must be an IMC portal server
that supports the page auto-redirection function.
To specify an autoredirection URL for authenticated portal users:
Step
1.
Enter system view.
2.
Specify an autoredirection
URL for authenticated portal
users.
Command
Remarks
system-view
N/A
portal redirect-url url-string

[ wait-time period ]
By default, an authenticated user is

redirected to the URL the user typed in the
address bar before portal authentication.
The wait-time period option is effective
only on local portal authentication.
Configuring portal detection functions

Configuring online Layer 3 portal user detection
This feature is available only for the direct portal authentication configured on a Layer 3 interface.
With online portal user detection enabled on an interface, the device periodically sends probe packets
(ARP requests) to the portal users on the interface to check whether the portal users are still online, to find
portal users who get offline without logging off.
If the device receives a reply from a portal user before sending probe packets to the portal user for
the maximum number of times, it considers that the portal user is online and keeps sending probe
packets to the portal user.
If the device receives no reply from a portal user after sending probe packets to the portal user for
the maximum number of times, it considers that the portal user is offline, stops sending probe
packets to the portal user, and deletes the user.
To configure online Layer 3 portal user detection:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Configure online Layer 3

portal user detection.
access-user detect type arp

retransmit number interval interval
In stateful failover mode, the actual

interval for sending probe packets
is the sum of probe intervals
configured on the two devices.
NOTE:
Adjust the maximum number of transmission attempts and the interval of sending probe packets
according to the actual network conditions.
166
Configuring the portal server detection function

During portal authentication, if the communication between the access device and portal server is
broken, new portal users are not able to log on and the online portal users are not able to log off normally.
To address this problem, the access device needs to be able to detect the reachability changes of the
portal server quickly and take corresponding actions to deal with the changes. For example, once
detecting that the portal server is unreachable, the access device allows portal users to access network
resources without authentication. This function is referred to as portal authentication bypass. It allows for
flexible user access control.
With the portal server detection function, the device can detect the status of a specific portal server. The
specific configurations include:
1.
Detection methods (you can choose either or both)

{
2.
Probing portal heartbeat packetsA portal server that supports the portal heartbeat function
(only the IMC portal server supports this function) sends portal heartbeat packets to portal
access devices periodically. If an access device receives a portal heartbeat packet or an
authentication packet within a probe interval, the access device considers that the probe
succeeds and the portal server is reachable. Otherwise, it considers that the probe fails and the
portal server is unreachable.
Probe parameters
{
{
3.
Probing HTTP connectionsThe access device periodically sends TCP connection requests to
the HTTP service port of the portal servers configured on its interfaces. If the TCP connection with
a portal server can be established, the access device considers that the probe succeeds (the
HTTP service of the portal server is open and the portal server is reachable). If the TCP
connection cannot be established, the access device considers that the probe fails and the
portal server is unreachable.
Probe intervalInterval at which probe attempts are made.

Maximum number of probe attemptsMaximum number of consecutive probe attempts
allowed. If the number of consecutive probes reaches this value, the access device considers
that the portal server is unreachable.
Actions to be taken when the server reachability status changes (you can choose one or more)
{
Sending a trap messageWhen the status of a portal server changes, the access device sends
a trap message to the NMS. The trap message contains the portal server name and the current
state of the portal server.
Sending a logWhen the status of a portal server changes, the access device sends a log
message. The log message indicates the portal server name and the current state and original
state of the portal server.
Disabling portal authentication (enabling portal authentication bypass)When the device
detects that a portal server is unreachable, it disables portal authentication on the interfaces
that use the portal server (allows all portal users on the interfaces to access network resources).
When the device receives from the portal server portal heartbeat packets or authentication
packets (such as logon requests and logout requests), it re-enables the portal authentication
function.
You can configure any combination of the configuration items described as needed, with respect to the
following:
167
If both detection methods are specified, a portal server is regarded as unreachable as long as one
detection method fails, and an unreachable portal server is regarded as recovered only when both
detection methods succeed.
If multiple actions are specified, the access device executes all the specified actions when the status
of a portal server changes.
The detection function configured for a portal server takes effect on an interface only after you
enable portal authentication and reference the portal server on the interface.
The portal authentication bypass function is not supported on an interface where different portal
servers are specified for different SSID-and-AP associations.
To configure the portal server detection function:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the portal

server detection
function.
portal server server-name server-detect

method { http | portal-heartbeat } * action
{ log | permit-all | trap } * [ interval
interval ] [ retry retries ]

The portal server specified in the
command must exist and must be an
IPv4 portal server.
The portal heartbeat detection method works only when the portal server supports the portal server
heartbeat function. Only the IMC portal server supports the portal server heartbeat function. To
implement detection with this method, you also need to configure the portal server heartbeat function on
the IMC portal server and make sure that the product of interval and retry is greater than or equal to the
portal server heartbeat interval. HP recommends configuring the interval to be greater than the portal
server heartbeat interval configured on the portal server.
Configuring portal user information synchronization

Once the device loses communication with a portal server, the portal user information on the device and
that on the portal server may be inconsistent after the communication resumes. To solve this problem, the
device provides the portal user information synchronization function. This function is implemented by
sending and detecting the portal synchronization packet. The process is as follows:
1.
The portal server sends the online user information to the access device in a user synchronization
packet at the user heartbeat interval, which is set on the portal server.
2.
Upon receiving the user synchronization packet, the access device checks the user information
carried in the packet with its own. If the device finds a nonexistent user in the packet, it informs the
portal server of the information, and the portal server deletes the user. If the device finds that one
of its users does not appear in the user synchronization packets within N consecutive
synchronization probe intervals (N is equal to the value of retries configured in the portal server
user-sync command), it considers that the user does not exist on the portal server and logs the user
off.
To configure the portal user information synchronization function:

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
168
Step
2.
Command
Configure the portal
user information
synchronization
function.
Remarks
portal server server-name

user-sync [ interval
interval ] [ retry retries ]
The portal server specified in the command must exist

and must be an IPv4 portal server. This function can
take effect only when the specified portal server is
referenced on the interface connecting the users.
The user information synchronization function requires that a portal server supports the portal user
heartbeat function. Only the IMC portal server supports the portal user heartbeat function. To implement
the portal user synchronization function, you also need to configure the user heartbeat function on the
portal server and make sure that the product of interval and retry is greater than or equal to the portal
user heartbeat interval. HP recommends configuring the interval to be greater than the portal user
heartbeat interval configured on the portal server.
For redundant user information on the deviceinformation for users who are considered nonexistent on
the portal server, the device deletes the information during the (N+1)th interval, where N is equal to the
value of retries configured in the portal server user-sync command.
Logging off portal users

Logging off a user terminates the authentication process for the user or removes the user from the
authenticated users list.
To log off portal users:
Step
Command
1.
Enter system view.
system-view
2.
Log off users.
portal delete-user { ipv4-address | all | interface interface-type

interface-number | ipv6 ipv6-address }
Enabling forced logoff for user SSID switching

This function logs off a wireless portal user after the user switches SSIDs.
To enable forced logoff for user SSID switching:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable forced logoff for

user SSID switching.
portal wlan ssid-switch logoff
By default, a wireless portal user is not

logged off after switching SSIDs.
Enabling logging for portal packets

You can enable logging for portal packets for maintenance purposes, or disable this feature to avoid
impact on the system performance.
169
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable logging for portal

packets.
portal log packet
By default, portal packet logging is

disabled to avoid impacting system
performances.
Specifying the parameters to be carried in the

redirection URL
You can specify the following parameters that the redirection URL carries, and customize the parameter
names:
nas-idCarries the NAS ID parameter.
nas-ipCarries the NAS IP parameter.
user-macCarries the user MAC parameter.
des-encryptSpecifies DES to encrypt user MAC address in the redirection URL. If you do not
specify this keyword, the redirection URL contains plaintext user MAC address.
To specify the parameters to be carried in the redirection URL:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure carrying
parameters in the
redirection URL.
portal url-param include { nas-id

| nas-ip | user-mac
[ des-encrypt ] } [ param-name
param-name ]
By default, no parameters are carried in

the redirection URL.
Enabling host identity check through DHCP

snooping
When the device serves as a Layer 2 device, it might be unable to learn ARP entries. Therefore, the device
cannot perform host identity check through ARP entries. In this scenario, you can enable host identity
check through DHCP snooping entries. Only the portal users whose host information exists in the DHCP
snooping entries are allowed to continue portal authentication. For more information about DHCP
snooping entries, see Layer 3 Configuration Guide.
To enable host identity check for portal users:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable host identity

check through DHCP
snooping.
portal host-check dhcp-snooping
By default, the device performs host

identity check through ARP entries.
170
Configuring mandatory webpage pushing

With the mandatory webpage pushing function configured on an interface, a user's first Web request is
redirected to a specific webpage. Then, the user can access network resources normally. After a specific
period of time, if the user sends a Web access request again, the system will push the specified webpage
to the user again.
This function can be used, for example, by a hotel or a network carrier to push advertisement pages to
customers periodically.
Like portal, the mandatory webpage pushing function uses the Web request redirection mechanism to
push a webpage to users, but it does not authenticate users and therefore no authentication related
configuration is needed.
You cannot configure both the portal function and the mandatory webpage pushing function on an
interface.
To configure the mandatory webpage pushing function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
By default, mandatory webpage
pushing is disabled.
3.
Configure the mandatory

webpage pushing function
on the interface.
web-redirect url url-string

[ interval interval ]
After you modify the redirection URL

address, online users will not be
redirected to the new URL until the
current redirection interval expires.
Users who access Web for the first time
after the modification are redirected to
the new URL.
Displaying and maintaining portal

Task
Command
Remarks
Display the ACLs on a specific

interface.
display portal acl { all | dynamic |

static } interface interface-type
interface-number [ | { begin | exclude |
Display portal connection statistics

on a specific interface or all
interfaces.
display portal connection statistics { all |

interface-number } [ | { begin | exclude
Display information about a

portal-free rule or all portal-free
rules.
display portal free-rule [ rule-number ]

171
Task
Command
Remarks
Display the portal configuration of

a specific interface.
display portal interface interface-type

interface-number [ | { begin | exclude |
Display configuration information

about the local portal server.
display portal local-server [ | { begin |

Display information about a

specific portal server or all portal
servers.
display portal server [ server-name ] [ |

Display portal server statistics on a

specific interface or all interfaces.
display portal server statistics { all |

interface-number } [ | { begin | exclude
Display TCP spoofing statistics.
display portal tcp-cheat statistics [ |

Display information about portal

users on a specific interface or all
interfaces.
display portal user { all | interface

interface-type interface-number } [ |
Clear portal connection statistics

on a specific interface or all
interfaces.
reset portal connection statistics {all |

interface-number }
Clear portal server statistics on a

specific interface or all interfaces.
reset portal server statistics { all |

interface-number }
Clear TCP spoofing statistics.
reset portal tcp-cheat statistics
Portal configuration examples

172
Configuring direct portal authentication

As shown in Figure 58, the wireless user (Client) belongs to VLAN 1 and the AP belongs to VLAN 3. The
AC performs direct portal authentication for wireless users. Before portal authentication, the wireless user
can access only the portal server. After passing portal authentication, the user can access Internet
resources.
Use a RADIUS server as the authentication/authorization server.
Portal server
192.168.0.111/24
Client
2.2.2.2/24
Gateway : 2.2.2.1/24
AP
L2 switch
Vlan-int1
2.2.2.1/24
Vlan-int2
192.168.0.100/24
RADIUS server
192.168.0.112/24
AC
Configuration prerequisites and guidelines
Configure IP addresses for the client, AC, and servers as shown in Figure 58, and make sure they
have IP connectivity between each other.
Configure the RADIUS server properly to provide authentication/authorization services for users.

This section uses IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301).
1.

a. Log in to IMC and click the Service tab.
b. From the navigation tree, select User Access Manager > Portal Service > Server to enter the
portal server configuration page, as shown in Figure 59.
c. Configure the portal server parameters as needed. This example uses the default settings.
d. Click OK.
173
2.
Configure the IP address group:

a. From the navigation tree, select User Access Manager > Portal Service > IP Group to enter the
portal IP address group configuration page.
b. Click Add to enter the page shown in Figure 60.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure that the client's IP address is in the IP group.
e. Select a service group.
By default, the group Ungrouped is used.
f. Select the IP group type Normal.
g. Click OK.
3.
Add a portal device:

a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the
portal device configuration page.
c. Enter the device name AC.
174
d. Enter the IP address of the router's interface connected to the user.

e. Enter the key, which must be the same as that configured on the access device (AC).
f. Set whether to enable IP address reallocation.
This example uses direct portal authentication. Therefore, select No from the Reallocate IP list.
g. Select whether to support sever heartbeat and user heartbeat functions.
In this example, select No for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
4.

a. As shown in Figure 62, click the icon in the Port Group column of device AC to enter the port
group configuration page.
Figure 62 Device list
b. On the port group configuration page, click Add to enter the page shown in Figure 63.
c. Enter the port group name.
d. Select the configured IP address group. The client's IP address must be within this IP address
group.
e. Use the default settings for other parameters.
f. Click OK.
175
Figure 63 Adding a port group
5.
From the navigation tree, select User Access Manager > Service Parameters > Validate System
Configuration to validate the configurations.
Configuring the AC
1.

<AC> system-view
# Configure the server type for the RADIUS scheme. When using the IMC server, you must
configure the RADIUS server type as extended.
# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC-radius-rs1] primary authentication 192.168.0.112
[AC-radius-rs1] key authentication simple radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS
server.
[AC-radius-rs1] user-name-format without-domain
2.

[AC] domain dm1

[AC-isp-dm1] quit
3.

# Configure the portal server as follows:
{
Name: newpt
IP address: 192.168.0.111
Key: portal (in plaintext)
Port number: 50100
URL: http://192.168.0.111/portal
176
[AC] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[ACVlan-interface1] portal server newpt method direct
Configuring re-DHCP portal authentication

As shown in Figure 64, the wireless user (Client) belongs to VLAN 10 and AP belongs to VLAN 3.
The AC performs re-DHCP authentication for wireless users. The client obtains an IP address from the
DHCP server. Before portal authentication, the DHCP server assigns a private IP address to the client.
After the client passes portal authentication, it gets a public IP address from the DHCP server and can
access Internet resources.
Use a RADIUS server as the authentication/authorization server. On the IMC, specify the internal subnet
as the authentication subnet.
Configure IP addresses for the AC and servers as shown in Figure 64, and make sure that the client,
AC, and servers have IP connectivity between each other.
Configure the RADIUS server to provide authentication/authorization services for users.
Configure a public address pool (20.20.20.0/24, in this example) and a private address pool
(10.0.0.0/24, in this example) on the DHCP server. The configuration steps are omitted. For more
information about DHCP configuration information, see Layer 3 Configuration Guide.
Configure the AC as a DHCP relay agent and configure a primary IP address (a public IP address)
and a secondary IP address (a private IP address) for the portal-enabled interface.
1.
Configure a RADIUS scheme on the AC:

177
# Create a RADIUS scheme named rs1, and enter its view.

<AC> system-view
# Set the server type for the RADIUS scheme. When using the IMC server, you must set the server
type to extended.
server.
2.
Configure an authentication domain on the AC:

[AC] domain dm1

[AC-isp-dm1] quit
3.
Configure portal authentication on the AC:

{
Name: newpt
IP address: 192.168.0.111
Port number: 50100
http://192.168.0.111:8080/portal
# Configure the AC as a DHCP relay agent, and enable the invalid address check function.
[AC] dhcp enable
[AC] dhcp relay server-group 0 ip 192.168.0.112
[ACVlan-interface10] ip address 20.20.20.1 255.255.255.0
[ACVlan-interface10] ip address 10.0.0.1 255.255.255.0 sub
[AC-Vlan-interface10] dhcp select relay
[AC-Vlan-interface10] dhcp relay server-select 0
[AC-Vlan-interface10] dhcp relay address-check enable
# On the interface connected to the client, specify the authentication domain dm1 for portal users,
and enable re-DHCP portal authentication.
[AC-Vlan-interface10] portal domain dm1
[ACVlan-interface10] portal server newpt method redhcp
178
Configuring direct portal authentication with extended

functions
As shown in Figure 65, the wireless user (Client) belongs to VLAN 10 and the AP belongs to VLAN 3.
The AC performs direct portal authentication for wireless users. If the client fails security check after it
passes identity authentication, the client can access only subnet 192.168.0.0/24. After the client passes
security check, the client can access Internet resources.
Configure IP addresses for the client, AC, and servers as shown in Figure 65 and make sure they have IP
connectivity between each other.
Configure the RADIUS server to provide authentication/authorization services for users.
1.

<AC> system-view
# Set the server type for the RADIUS scheme. When using the IMC server, you must set the server
type to extended.
# Configure the IP address of the security policy server.

[AC-radius-rs1] security-policy-server 192.168.0.113
179
2.

[AC] domain dm1

[AC-isp-dm1] quit
3.
On the AC, configure the ACL (ACL 3000) for resources on subnet 192.168.0.0/24 and the ACL
(ACL 3001) for Internet resources.
[AC-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[AC-acl-adv-3001] rule permit ip
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.
4.
Configure extended portal authentication on the AC:

{
Name: newpt
IP address: 192.168.0.111
Port number: 50100
http://192.168.0.111:8080/portal
and enable extended portal authentication.
[AC] quit
Configuring re-DHCP portal authentication with extended

functions
As shown in Figure 66, the wireless user (Client) belongs to VLAN 100 and AP belongs to VLAN 3.
The AC performs extended re-DHCP portal authentication for users. The client obtains an IP address from
the DHCP server. Before extended portal authentication, the DHCP server assigns a private IP address to
the client. After passing the authentication, the client gets a public IP address.
If the client fails security check after it passes identity authentication, the client can access only subnet
192.168.0.0/24. After the client passes security check, the client can access Internet resources.
180
Portal server
192.168.0.111/24
DHCP server
192.168.0.112/24
AP
Client
automatically obtains an IP address
L2 switch
Vlan-int100
20.20.20.1/24 Vlan-int2
10.0.0.1/24 sub 192.168.0.100/24
RADIUS server
192.168.0.113/24
AC
192.168.0.114/24
Configure IP addresses for the AC and servers as shown in Figure 66, and make sure the client, AC,
and servers have IP connectivity between each other.
Configure the RADIUS server to provide authentication and authorization services for users.
Configure a public address pool (20.20.20.0/24, in this example) and a private address pool
(10.0.0.0/24, in this example) on the DHCP server. (Details not shown.)
Configure the AC as a DHCP relay agent and configure a primary IP address (a public IP address)
and a secondary IP address (a private IP address) for the portal-enabled interface. For DHCP relay
configuration information, see Layer 3IP Services Configuration Guide.
1.

<AC> system-view
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
# Configure the IP address of the security policy server.

[AC-radius-rs1] security-policy-server 192.168.0.114
2.

181

[AC] domain dm1

[AC-isp-dm1] quit
3.
On the AC, configure the ACL (ACL 3000) for resources on subnet 192.168.0.0/24 and the ACL
(ACL 3001) for Internet resources.
[AC-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[AC-acl-adv-3001] rule permit ip
Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the
security policy server.
4.
Configure extended portal authentication on the AC:

{
Name: newpt
IP address: 192.168.0.111
Port number: 50100
http://192.168.0.111:8080/portal
# Configure the AC as a DHCP relay agent, and enable the invalid address check function.
[AC] dhcp enable
[ACVlan-interface100] ip address 20.20.20.1 255.255.255.0
[ACVlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[AC-Vlan-interface100] dhcp relay address-check enable
[ACVlan-interface100] portal server newpt method redhcp
182

As shown in Figure 67, a failover link is present between AC 1 and AC 2. Both AC 1 and AC 2 support
portal authentication. Configure stateful failover between AC 1 and AC 2 to support portal service
backup and use VRRP to implement traffic switchover between the ACs.
When AC 1 operates normally, Host accesses AC 1 for portal authentication before accessing the
Internet. When AC 1 fails, Host accesses the Internet through AC 2. The VRRP uplink/downlink
detection mechanism is used to ensure non-stop traffic forwarding.
Use the RADIUS server as the authentication/authorization server. In this example, Server takes the
responsibilities of the portal server and the RADIUS server.
AC 1 and AC 2 use the failover link to transmit stateful failover related packets and specify VLAN
8 on the ACs as the VLAN dedicated for stateful failover related packets.

Server
192. 168.0. 111/ 24
L3 switch
Gateway9.9.1.1/ 24
Master
Vlan-int 20
192.168.0.5/ 24
Virtual IP address
:
Backup
192.168.0.1/24
Failover link
AC1
Vlan-int20
192. 168.0.6/ 24
AC 2
Vlan-int 10
9.9.1.6/ 24
Vlan-int 10
9.9.1.5/24
L 2 switch
AP
1.1.1.3/24
Client
IP : 9.9.1.2/24
Gateway: 9.9.1.1/24

Configure IP addresses for the client, server, and ACs as shown in Figure 67 and make sure they have IP
On the authentications server, specify the access device's IP address as the virtual IP address of the VRRP
group. For more information about VRRP, see High Availability Configuration Guide.
You must use consistent device roles for AC stateful failover and VRRP. If you use an AC as the master for
stateful failover, use the AC as the master in a VRRP group, too. Otherwise, in local portal authentication,
the access device cannot push authentication pages according to the SSID. If your network cannot meet
the requirement, for example, the two ACs are configured for load balancing, related portal-free rules
should be configured.
183
For information about stateful failover configuration, see High Availability Configuration Guide.

1.

c. Configure the portal server parameters as needed. This example uses the default settings.
d. Click OK.
2.

d. Enter the start IP address and end IP address of the IP group.
Make sure that the client's IP address is in the IP group.
g. Click OK.
184
3.

d. Enter the virtual IP address of the VRRP group that holds the portal-enabled interface.
e. Enter the key, which must be the same as that configured on the ACs.
g. Set whether to support the portal server heartbeat and user heartbeat functions.
In this example, select No for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
4.

185
Perform the following configurations.
d. Select the configured IP address group.
The client's IP address must be within this IP address group.
f. Click OK.
5.
From the navigation tree, select User Access Manager > User Access Manager > Service
Parameters > Validate System Configuration to validate the configurations.
Configuring AC 1
1.
Configure VRRP:
# Create a VRRP group, and configure the virtual IP address of the VRRP group as 192.168.0.1.
<AC1> system-view
[AC1] interface vlan-interface 20
[AC1Vlan-interface20] vrrp vrid 1 virtual-ip 192.168.0.1
# Set the priority of VLAN-interface 20 in the VRRP group to 200.

[AC1Vlan-interface20] vrrp vrid 1 priority 200
# On VLAN-interface 20, configure the interface to be tracked as VLAN-interface 10 and reduce

the priority of VLAN-interface 20 in the VRRP group by 150 when the interface state of
VLAN-interface 10 becomes Down or Removed.
[AC1Vlan-interface20] vrrp vrid 1 track interface vlan-interface10 reduced 150
[AC1Vlan-interface20] quit
2.

# Create RADIUS scheme rs1 and enter its view.
[AC1] radius scheme rs1
[AC1-radius-rs1] server-type extended
[AC1-radius-rs1] primary authentication 192.168.0.111
186
[AC1-radius-rs1] key authentication simple expert
# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server. (Optional, configure the username format as needed.)
[AC1-radius-rs1] user-name-format without-domain
[AC1-radius-rs1] quit
3.

# Create ISP domain dm1 and enter its view.
[AC1] domain dm1
# Configure AAA methods for the ISP domain.

[AC1-isp-dm1] authentication portal radius-scheme rs1
[AC1-isp-dm1] authorization portal radius-scheme rs1
[AC1-isp-dm1] quit
4.
Enable portal authentication on the interface connecting the host:

# Configure a portal server on AC 1. Make sure the IP address, port number and URL match those
of the actual portal server.
[AC1] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Configure a portal-free rule on AC 1, allowing packets from AC 2 to pass through without portal
authentication. This configuration is required only when the roles (master/backup) of the ACs for
stateful failover are different from those for VRRP.
[AC1] portal free-rule 0 source interface bridge-aggregation 1 destination any
[AC1Vlan-interface10] portal domain dm1
[AC1Vlan-interface10] portal server newpt method direct
# Specify the source IP address of outgoing portal packets as 192.168.0.1, the virtual IP address
of the VRRP group.
[AC1Vlan-interface10] portal nas-ip 192.168.0.1
5.
Configure portal stateful failover:

# Assign interface VLAN-interface 10 to portal group 1.
[AC1Vlan-interface10] portal backup-group 1
# Set the device ID for AC 1 in stateful failover mode to 1.

[AC1] nas device-id 1
# Specify the source IP address of outgoing RADIUS packets as 192.168.0.1, the virtual IP
address of the VRRP group.
[AC1] radius nas-ip 192.168.0.1
NOTE:
Make sure you add the access device with IP address 192.168.0.1 on the RADIUS server.
6.
Configure the WLAN service:

# Specify the backup AC address.
[AC1] wlan backup-ac ip 1.1.1.2
# Enable hot backup.

187
[AC1] hot-backup enable
# Configure VLAN 8 as the VLAN for AC hot backup.

[AC1] hot-backup vlan 8
[AC1] quit
# Create interface WLAN-ESS 1, and add it to VLAN 10.

[AC1] interface wlan-ess 1
[AC1-WLAN-ESS1] port link-type hybrid
[AC1-WLAN-ESS1] port hybrid vlan 10 untagged
[AC1-WLAN-ESS1] port hybrid pvid vlan 10
[AC1-WLAN-ESS1] quit
# Configure a WLAN service template, and bind the WLAN service template with interface
WLAN-ESS 1.
[AC1] wlan service-template 1 clear
[AC1-wlan-st-1] ssid abc
[AC1-wlan-st-1] bind wlan-ess 1
[AC1-wlan-st-1] service-template enable
[AC1-wlan-st-1] quit
# Configure AP on AC 1. (Set the access priority of AP to 7. A higher value represents a higher

priority. The default priority value is 4.)
[AC1] wlan ap ap1 model MSM460-WW
[AC1-wlan-ap-ap1] serial-id CN2AD330S8
[AC1-wlan-ap-ap1] priority level 7
[AC1-wlan-ap-ap1] radio 1
[AC1-wlan-ap-ap1-radio-1] service-template 1
[AC1-wlan-ap-ap1-radio-1] radio enable
[AC1-wlan-ap-ap1-radio-1] quit
[AC1-wlan-ap-ap1] quit
7.
Configure the stateful failover function:

# Configure the VLAN for stateful failover as VLAN 8.
[AC1] dhbk vlan 8
# Enable stateful failover and configure it to support the symmetric path.

[AC1] dhbk enable backup-type symmetric-path
Configuring AC 2
1.
Configure VRRP:
# Create a VRRP group, and configure the virtual IP address of the VRRP group as 192.168.0.1.
[AC2] system-view
# Set the priority of VLAN-interface 20 in the VRRP group to 150.

2.

188
RADIUS server. (Optional. Configure the username format as needed.)
3.

[AC2] domain dm1

[AC2-isp-dm1] quit
4.
Enable portal authentication on the interface connecting the host:

# Configure the portal server as needed.
[AC2] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
[AC2-Vlan-interface10] portal domain dm1
[AC2Vlan-interface10] portal server newpt method direct
# Specify the source IP address of outgoing portal packets as 192.168.0.1, the virtual IP address
of the VRRP group.
5.

# Set the ID of the device in the stateful failover mode to 2.

# Specify the source IP address of outgoing RADIUS packets as 192.168.0.1, the virtual IP
address of the VRRP group.
[AC2] radius nas-backup-ip 192.168.0.1
189
NOTE:
Make sure that you have added the access device with IP address 192.168.0.1 on the RADIUS server.
6.



[AC2] quit

WLAN-ESS 1.
# Configure AP on AC 2, using the default access priority of 4 for the AP.

7.
Configure stateful failover:

# Configure the VLAN for stateful failover as VLAN 8.
[AC2] dhbk vlan 8
# Enable stateful failover and configure it to support the symmetric path.


# After the client logs in through AC 1, display the user authentication information by using the display
portal user command on AC 1 and AC 2, respectively.
[AC1] display portal user all
Index:3
State:ONLINE
SubState:NONE
ACL:NONE
190
Work-mode: primary
MAC
IP
Vlan
Interface
--------------------------------------------------------------------000d-88f8-0eac
9.9.1.2
10
Vlan-interface10
Vlan
Interface

Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: secondary
MAC
IP
--------------------------------------------------------------------000d-88f8-0eac
9.9.1.2
10
Vlan-interface10
The output shows that the portal information of the client is stored on both AC 1 and AC 2. The user mode
is primary on AC 1 and secondary on AC 2, indicating that the client logged in from AC 1 and the
client's authentication information has been synchronized to AC 2.
Configuring portal server detection and portal user information

synchronization
As shown in Figure 73, a wireless client (in VLAN 10) is connected to the access device (AC) and must
pass portal authentication to access the Internet. Use a RADIUS server as the
authentication/authorization server.
Detailed requirements are as follows:
Configure a public IP address for the client or configure the client to obtain a public IP address from
the DHCP server. Before passing portal authentication, the client can access only the portal server.
After passing portal authentication, the client can access the Internet.
The access device (AC) can detect whether the portal server is reachable and send trap messages
upon state changes. When the portal server is unreachable due to, for example, a connection
failure, network device failure, or portal server failure, the access device can disable portal
authentication, allowing users to access the Internet without authentication.
The access device can synchronize portal user information with the portal server periodically.
191
Configuration considerations
Configure the portal server and enable portal server heartbeat function and the portal user
heartbeat function.
Configure the RADIUS server to implement authentication and authorization.
Configure direct portal authentication on interface VLAN-interface 10, which is connected to the
client.
Configure the portal server detection function on the access device, so that the access device can
detect the status of the portal server by cooperating with the portal server heartbeat function.
Configure the portal user information synchronization function, so that the access device can
synchronize portal user information with the portal server by cooperating with the portal user
heartbeat function.
Configure IP addresses for the client, AP, AC, and servers as shown in Figure 73, and make sure they
Configure the RADIUS server to provide authentication and authorization services for users.

1.

a. Log in to the IMC management platform and click the Service tab.
c. Configure the portal server heartbeat interval and user heartbeat interval.
d. Use default values for other parameters.
e. Click OK.
192
2.

d. Enter the start IP address and end IP address of the IP group. Make sure the client's IP address
is in the IP group.
g. Click OK.
3.

193
d. Enter the IP address of the AC's interface connected to the user.

e. Enter the key, which must be the same as that configured on the AC.
g. Select Yes for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
4.

Perform the following configurations:
d. Select the configured IP address group. The IP address used by the user to access the network
must be within this IP address group.
f. Click OK.
194
5.
From the navigation tree, select User Access Manager > Service Parameters > Validate System
Configuration to validate the configurations.
Configuring the AC
1.

<AC> system-view
RADIUS server.
2.

[AC] domain dm1

[AC-isp-dm1] quit
3.

# Configure a portal server on the AC, making sure the IP address, port number and URL match
those of the actual portal server.
http://192.168.0.111:8080/portal
195

4.
Configure the portal server detection function:

# Configure the access device to detect portal server newpt, specifying the detection method as
portal heartbeat probe, setting the server probe interval to 100 seconds, and specifying the access
device to send a server unreachable trap message and disable portal authentication to permit
unauthenticated portal users if two consecutive probes fail.
[AC] portal server newpt server-detect method portal-heartbeat action trap permit-all
interval 100 retry 2
NOTE:
The product of interval and retry must be greater than or equal to the portal server heartbeat interval,
and HP recommends configuring the interval as a value greater than the portal server heartbeat
interval configured on the portal server.
5.
Configure portal user synchronization:

# Configure the access device to synchronize portal user information with portal server newpt,
setting the synchronization probe interval to 600 seconds, and specifying the access device to log
off users if the users do not appear in the user synchronization packets sent from the server in two
consecutive probe intervals.
[AC] portal server newpt user-sync interval 600 retry 2
NOTE:
The product of interval and retry must be greater than or equal to the portal user heartbeat interval,
and HP recommends configuring the interval as a value greater than the portal user heartbeat
interval configured on the portal server.

Use the following command to view information about the portal server.
<AC> display portal server newpt
Portal server:
1)newpt:
IP
: 192.168.0.111
Port : 50100
Key
: ******
URL
: http://192.168.0.111:8080/portal
Status
: Up
The Up state of the portal server indicates that the portal server is reachable. If the AC detects that the
portal server is unreachable, you can see the portal server status is Down in the output, and the AC
generates a server unreachable trap "portal server newpt lost," and disables portal authentication on the
access interface, so the client can access the external network without authentication.
196
Configuring direct portal authentication using local portal

server
As shown in Figure 79, a wireless client is connected to the network through the AP. The client belongs to
VLAN 2 and the AP belongs to VLAN 3. The client must pass direct portal authentication to access
Internet resources. Before authentication, the client can access only the local portal server.
The AC (access device) uses the local portal server that runs HTTPS to perform direct portal authentication
for users. The local portal server can push customized pages according to the SSID of the user logon
interface.
Configure IP addresses for the client, AC, and server as shown in Figure 79, and make sure they
Configure the RADIUS server properly to provide authentication and authorization services for
users.
Complete the PKI domain configuration, and get the local certificate and the CA certificate. For
more configuration information, see "Configuring PKI."
Configure the SSL server policy access-policy. For more configuration information, see "Configuring
SSL."
Edit the authentication page files to be bound with the client SSID.
Do not configure the wireless client and the AP to be in the same subnet. Otherwise, after portal
authentication is enabled for the subnet, the AP cannot establish a connection with the AC.
1.

<AC> system-view
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
197
server.
2.

[AC] domain dm1

[AC-isp-dm1] quit
3.
Configure the WLAN service on the AC:

# Create interface WLAN-ESS 1 and add it to VLAN 2.
[AC-WLAN-ESS1] port hybrid vlan 2 untagged
[AC-WLAN-ESS1] quit
# Configure a WLAN service template, and bind the WLAN service template with the WLAN-ESS
interface.
[AC-wlan-st-1] ssid abc
[AC-wlan-st-1] quit
# Configure AP on the AC.

4.

# Configure the local portal server to support HTTPS and reference the configured SSL server
policy access-policy.
[AC] portal local-server https server-policy access-policy
# Bind client SSID abc with the customized authentication page file ssid1.zip, which is saved in
directory flash:/portal/ of the AC. This configuration is optional. If you do not configure the
binding, the AC pushes the system default authentication pages for users.
198
[AC] portal local-server bind ssid abc file ssid1.zip
# Configure the local portal server name as newpt and IP address as 192.168.1.1. Other
parameters do not need to be configured.
[AC] portal server newpt ip 192.168.1.1
# On VLAN-interface 2, the interface connected to the client, specify the authentication domain
dm1 and portal server newpt for portal users and enable direct portal authentication.

After the wireless client is connected to the wireless network whose SSID is abc, when the user accesses
subnet 1.1.1.0/24 by using a web browser, the user is redirected to page
https://192.168.1.1/portal/logon.htm. This page is the authentication page that is bound with SSID abc.
After entering the correct username and password on the web page, the user passes the authentication.
You can view information about the user by using the display portal user command on the AC.
Configuring portal stateful failover with local portal servers

As shown in Figure 80, a failover link is present between AC 1 and AC 2. Both AC 1 and AC 2 support
portal authentication. Configure stateful failover between AC 1 and AC 2 to support portal service
backup and use VRRP to implement traffic switchover between the ACs.
When AC 1 operates normally, Client accesses AC 1 for portal authentication before accessing the
Internet. When AC 1 fails, Client accesses the Internet through AC 2. Use VRRP uplink/downlink
detection mechanism to ensure non-stop traffic forwarding.
Use the RADIUS server as the authentication/authorization server. Use local portal servers on the ACs.
AC 1 and AC 2 use the failover link to transmit stateful failover related packets. Specify VLAN 10 on the
ACs as the VLAN dedicated for stateful failover related packets.
199
Configure IP addresses for the server, client, switches, and ACs and make sure they have IP
Make sure the client can access the authentication server through AC 1 and AC 2.
Configure VRRP group 1 and VRRP group 2 to implement backup for downstream and upstream
links respectively. For more information about VRRP, see High Availability Configuration Guide.
On the RADIUS server, specify the access device's IP address as the virtual IP address of VRRP
group 2.
You must use consistent device roles for AC stateful failover and VRRP. If you use an AC as the
master for stateful failover, use the AC as the master in a VRRP group, too. Otherwise, in local portal
authentication, the access device cannot push the authentication page according to the SSID. If
your network cannot meet the requirement, for example, the two ACs are configured for load
balancing, related portal-free rules should be configured. For more information about stateful
failover, see High Availability Configuration Guide.
Configuring AC 1
1.
Configure VRRP:
# Create VRRP group 1, and configure the virtual IP address of VRRP group 1 as 16.16.0.8.
<AC1> system-view
# Set the priority of VLAN-interface 100 in VRRP group 1 to 200.

200

the priority of VLAN-interface 100 in VRRP group 1 by 120 when the interface state of
VLAN-interface 8 becomes Down or Removed.
# Set the priority of VLAN-interface 8 in VRRP group 2 to 200.


the priority of VLAN-interface 8 in VRRP group 2 by 120 when the interface state of VLAN-interface
100 becomes Down or Removed.
2.

# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
# Configure the scheme to remove the ISP domain name in the username sent to the RADIUS server.
(By default, the ISP domain name is carried in the username. Configure the username format as
needed.)
3.

[AC1] domain dm1

[AC1-isp-dm1] quit
4.
Enable portal authentication on the interface connected to the client:

# Configure the portal server, with name configured as local, IP address as 16.16.0.8 (the virtual
IP address of VRRP group 1), and URL as http://16.16.0.8/portal/logon.htm.
[AC1] portal server local ip 16.16.0.8 url http://16.16.0.8/portal/logon.htm
# Configure the local portal server to support HTTP.

201
[AC1] portal local-server http
[AC1Vlan-interface100] portal server local method direct
# Specify the source IP address for outgoing portal packets as 16.16.0.8, the virtual IP address of
VRRP group 1.
5.

# Set the device ID of AC 1 in the stateful failover mode to 1.

# Configure the source IP address of RADIUS packets to be sent as 8.1.1.68, the virtual IP address
of VRRP group 2.
6.



[AC1] quit

WLAN-ESS 1.
# Configure AP on AC 1.
202
7.

# Configure VLAN 10 as the backup VLAN for stateful failover.
[AC1] dhbk vlan 10
# Enable symmetric-path mode stateful failover.

Configuring AC 2
1.
Configure VRRP:
<AC2> system-view
2.

# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
# Configure the scheme to remove the ISP domain name in the username sent to the RADIUS server.
(By default, the ISP domain name is carried in the username. Configure the username format as
needed.)
3.

[AC2] domain dm1

[AC2-isp-dm1] quit
4.
Enable portal authentication on the interface connected to the client:

# Configure the portal server, with name configured as local, IP address as 16.16.0.8 (the virtual
IP address of VRRP group 1), and URL as http://16.16.0.8/portal/logon.htm.
[AC2] portal server local ip 16.16.0.8 url http://16.16.0.8/portal/logon.htm
203
[AC2]portal free-rule 0 source interface bridge-aggregation 1 destination any
# Configure the local portal server to support HTTP.

[AC2]portal local-server http
[AC2Vlan-interface100] portal server local method direct
# Specify the source IP address for outgoing portal packets as 16.16.0.8, the virtual IP address of
VRRP group 1.
5.

# Set the device ID of AC 2 in the stateful failover mode to 2.

# Configure the source IP address for outgoing RADIUS packets as 8.1.1.68, the virtual IP address
of VRRP group 2.
6.

# Specify the backup AC IP address.


[AC2] quit

WLAN-ESS 1.
# Configure AP on AC 2, using the default access priority of 4 for the AP.

204

7.

# Configure VLAN 10 as the backup VLAN for stateful failover.
[AC2] dhbk vlan 10


# After the user client logs in to AC 1, use the display portal user command on AC 1 and AC 2 to view
the authentication information of the user.
Index:3
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: primary
MAC
IP
Vlan
Interface
--------------------------------------------------------------------000d-88f8-0eac
16.16.0.12
100
Vlan-interface100
Vlan
Interface

Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: secondary
MAC
IP
--------------------------------------------------------------------000d-88f8-0eac
16.16.0.12
100
Vlan-interface100
The output shows that the portal information of the user is stored on both AC 1 and AC 2. The user mode
is primary on AC 1 and secondary on AC 2, indicating that the user logged in from AC 1 and the user's
authentication information has been synchronized to AC 2.
Configuring MAC-based quick portal authentication

As shown in Figure 81, the wireless user client belongs to VLAN 3, and the AP belongs to VLAN 5.
Detailed requirements are as follows:
Enable direct portal authentication on the AC.

205
The client can access only the portal server before authentication and can access the external
network after passing portal authentication.
When reconnecting to the external network, the authenticated client can pass portal authentication
without the username and password.
Use the RADIUS server as the authentication/authorization server.
Configuring the AC
1.

# Create a RADIUS scheme named rs1, and enter its view.
<AC> system-view
# Set the server type for the RADIUS scheme. When you use the IMC server, set the server type to
extended.
[AC-radius-rs1] key authentication simple 123456789
server.
# Specify the NAS IP of the AC.

[AC-radius-rs1] nas-ip 112.113.1.1
2.

# Configure an ISP domain named dm1, and enter its view.
[AC] domain dm1

[AC-isp-dm1] quit
3.

{
Name: 5
IP address: 8.1.1.40
Key: 123456789 (in plaintext)

206
Port number: 50100
URL: http://8.1.1.40:8080/portal
[AC] portal server 5 ip 8.1.1.40 key simple 123456789 port 50100 url
http://8.1.1.40:8080/portal
# Create VLAN 5 and configure the IP address of VLAN-interface 5 as 112.115.1.1/16.

[AC] vlan 5
[AC-vlan5] quit
[AC] interface vlan 5
# Create VLAN 3 and configure the IP address of VLAN-interface 3 as 112.113.1.1/16.

[AC] vlan 3
[AC-vlan3] quit
[AC] interface vlan 3
# On the interface connected to the client, specify the authentication domain as dm1 for portal
users, and enable direct portal authentication.
[ACVlan-interface3] portal server 5 method direct
# Configure the NAS IP of the AC as 112.113.1.1.

[AC-Vlan-interface3] portal nas-ip 112.113.1.1
# Specify the IP address of the MAC binding server as 8.1.1.40.

[AC] portal mac-trigger server ip 8.1.1.40
# On the portal authentication-enabled interface, enable MAC-based quick portal authentication.

[AC-Vlan-interface3] portal mac-trigger enable

This section uses IMC PLAT 5.2 (E0401) and IMC UAM 5.2 (E0402).
1.

The Portal Page field displays http://8.1.1.40:8080/portal, which is the URL of the portal
server.
c. Use default values for other parameters.
d. Click OK.
207
Figure 82 Configuring the portal server
2.

a. From the navigation tree, select User Access Manager > Portal Service > IP Group.
c. Enter the IP group name IP_group.
d. Enter the start IP address 112.113.0.0 and the end IP address 112.113.255.254.
Make sure the client's IP address is in the IP group.
e. Select the service group Ungrouped.
f. Select Normal for Action.
g. Click OK.
3.

c. Enter the device name Portal.
208
d. Select the IP address 112.113.1.1, which is the IP address of the AC interface that connects to
the client.
e. Enter the key 123456789, which must be the same as that configured on the AC.
f. Select No for both Support Server Heartbeat and Support User Heartbeat.
g. Click OK.
4.

b. As shown in Figure 85, click the icon in the Operation column for device Portal and select
Configure Port Group.
c. On the port group configuration page, click Add to enter the page shown in Figure 86.
d. Enter the port group name hp_portal.
e. Select the configured IP address group IP_group.
The client's IP address must be within this IP address group.
f. Select Supported for Fast Authentication on Smart Terminals.
g. Use default values for other parameters.
209
h. Click OK.
5.
Configure an access rule:

a. From the navigation tree, select User Access Manager > Access Rule Management.
c. Enter the access rule name mac-trigger.
d. Use default values for other parameters.
e. Click OK.
210
Figure 87 Adding an access rule
6.
Configure fast authentication on smart terminals:

a. From the navigation tree, select User Access Manager > Service Configuration.
c. Enter the service name dot1x.
d. Select mac-trigger for Default Access Rule.
e. Select Portal Fast Authentication on Endpoints.
f. Click OK.
Figure 88 Adding a service configuration
211
7.
Configure the access device:

a. From the navigation tree, select User Access Manager > Access Device Management > Access
Device.
b. On the access device configuration page, click Add.
c. Enter and confirm the shared key 123456789.
d. Click Add Manually on the device list.
e. On the Add Access Device Manually window, enter the access device IP address 112.113.1.1
in the Start IP field, and click OK.
8.
Configure the access user:

b. From the navigation tree, select All Access Users > Ungrouped.
c. Click Add to enter the access user configuration page shown in Figure 90.
d. Enter the user name Portal, the account name dot1x, and the password 123456789.
e. Select 5 for Max. Smart Terminal Bindings for Portal.
You can set this parameter according to actual requirements.
f. Select dot1x in the access service list.
212
Figure 90 Adding an access user
9.
Configure HTTP user agent feature identification:

b. From the navigation tree, select User Access Manager > Endpoint Identification Management.
c. Click the HTTP User Agent Feature Identification Configuration tab.
The page displays smart terminals in the HTTP User Agent Feature Identification Configuration
List. If the list contains no smart terminals, click Add to add devices.
Figure 91 Configuring HTTP user agent feature identification
10. Enable BYOD fast authentication:

b. From the navigation tree, select User Access Manager > Service Parameters > System Settings.
c. Click BYOD System Settings.
d. Select Yes for Enable Fast Authentication.
e. Use default values for other parameters.
f. Click OK.
213
Figure 92 Configuring BYOD system settings
11. From the navigation tree, select User Access Manager > Service Parameters > Validate to validate
the configurations.

# Use the client to access an external network, the portal authentication page appears. Enter the
username Portal and password 123456789 to log in.
# On the AC, display portal user information.
[AC] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
MAC
IP
Vlan
Interface
---------------------------------------------------------------------------3ca9-f414-4c20
112.113.0.1
Vlan-interface3
# Disconnect from the external network and then access the network again. The portal authentication
page does not appear. On the AC, display portal user information. The output shows that the client has
logged in.
[AC] display portal user all
Index:3
State:ONLINE
SubState:NONE
ACL:NONE
MAC
IP
Vlan
Interface
---------------------------------------------------------------------------3ca9-f414-4c20
112.113.0.1
Vlan-interface3
214
Troubleshooting portal
Inconsistent keys on the access device and the portal server
Symptom
When a user is forced to access the portal server, the portal server displays a blank webpage, rather
than the portal authentication page or an error message.
Analysis
The keys on the access device and those on the portal server are not configured consistently, causing
CHAP message exchange failure. As a result, the portal server does not display the authentication page.
Solution
Use the display portal server command to display the key for the portal server on the access device
and view the key for the access device on the portal server.
Use the portal server command to modify the key on the access device or modify the key for the
access device on the portal server to make sure that the keys are consistent.
Incorrect server port number on the access device

Symptom
After a user passes the portal authentication, you cannot force the user to log off by executing the portal
delete-user command on the access device, but the user can log off by using the disconnect attribute on
the authentication client.
Analysis
When you execute the portal delete-user command on the access device to force the user to log off, the
access device actively sends a REQ_LOGOUT message to the portal server. The default listening port of
the portal server is 50100. However, if the listening port configured on the access device is not 50100,
the destination port of the REQ_LOGOUT message is not the actual listening port on the server, and the
portal server cannot receive the REQ_LOGOUT message. As a result, you cannot force the user to log off
the portal server.
When the user uses the disconnect attribute on the client to log off, the portal server actively sends a
REQ_LOGOUT message to the access device. The source port is 50100 and the destination port of the
ACK_LOGOUT message from the access device is the source port of the REQ_LOGOUT message so that
the portal server can receive the ACK_LOGOUT message correctly, no matter whether the listening port
is configured on the access device. The user can log off the portal server.
Solution
Use the display portal server command to display the listening port of the portal server configured on the
access device and use the portal server command in the system view to modify it to make sure that it is
the actual listening port of the portal server.
215
Configuring port security

Port security is available on Ethernet and WLAN ports. Supported port types depend on the command.
For more information, see Security Command Reference.
Overview
Port security combines and extends 802.1X and MAC authentication to provide MAC-based network
access control. HP recommends that you configure port security in a WLAN network.
Port security prevents unauthorized access to a network by checking the source MAC address of inbound
traffic and prevents access to unauthorized devices by checking the destination MAC address of
outbound traffic.
Port security can control MAC address learning and authentication on a port to make sure the port learns
only source trusted MAC addresses.
A frame is illegal if its source MAC address cannot be learned in a port security mode, or if it is from a
client that has failed 802.1X or MAC authentication. The port security feature automatically takes a
pre-defined action on illegal frames. This automatic mechanism enhances network security and reduces
human intervention.
For more information about 802.1X and MAC authentication, see "Configuring 802.1X" and
"Configuring MAC authentication."
Port security features

Port security supports the need to know (NTK) feature, intrusion protection, and port security traps.
NTK
NTK prevents traffic interception by checking the destination MAC address in outbound frames. The
feature ensures that frames are sent only to hosts that have passed authentication or whose MAC
addresses have been learned or configured on the access device.
Intrusion protection
The intrusion protection feature checks the source MAC address in inbound frames for illegal frames and
takes a pre-defined action on each detected illegal frame. The action can be disabling the port
temporarily, disabling the port permanently, or blocking frames from the illegal MAC address for three
minutes (not user configurable).
Port security traps

To monitor user behavior, configure the port security module to send traps for port security events such as
login, logoff, and MAC authentication.
Port security modes

Port security supports the following categories of security mode:
MAC learning controlMAC address learning is disabled on ports in secure mode.

216
AuthenticationImplements MAC authentication, 802.1X authentication, or a combination of the

two authentication methods.
Upon receiving a frame, the port in a security mode searches the MAC address table for the source MAC
address. If a match is found, the port forwards the frame. If no match is found, the port learns the MAC
address or performs authentication, depending on the security mode. If the frame is illegal, the port takes
the pre-defined NTK, intrusion protection, or trapping action.
The maximum number of users a port supports equals the maximum number of MAC addresses that port
security allows or the maximum number of concurrent users the authentication mode in use allows,
whichever is smaller. For example, if 802.1X allows more concurrent users than port security's limit on the
number of MAC addresses on the port in userLoginSecureExt mode, port security's limit takes effect.
Table 10 describes the port security modes and the security features.
Table 10 Port security modes
Purpose
Turning off the port security
feature
Controlling MAC address
learning
Performing 802.1X
authentication
Security mode
Features that can be

triggered
noRestrictions (the default mode).

In this mode, port security is disabled on the port
and access to the port is not restricted.
N/A
secure
NTK/intrusion
protection
userLogin
N/A
userLoginSecure
userLoginSecureExt
NTK/intrusion
protection
userLoginWithOUI
Performing MAC authentication
Performing a combination of
MAC authentication and
802.1X authentication
macAddressWithRadius
Or
Else
NTK/intrusion
protection
macAddressOrUserLoginSecure
macAddressOrUserLoginSecureExt
macAddressElseUserLoginSecure
NTK/intrusion
protection
macAddressElseUserLoginSecureExt
TIP:
userLogin specifies 802.1X authentication and port-based access control.
macAddress specifies MAC authentication.
Else specifies that the authentication method before Else is applied first. If the authentication fails,
whether to turn to the authentication method following Else depends on the protocol type of the
authentication request.
Typically, in a security mode with Or, the authentication method to be used depends on the protocol type
of the authentication request. For wireless users, the network access device always use 802.1X
authentication first.
userLogin with Secure specifies 802.1X authentication and MAC-based access control.
Ext indicates allowing multiple 802.1X users to be authenticated and serviced at the same time. A
security mode without Ext allows only one user to pass 802.1X authentication.
217
Controlling MAC address learning

secure: MAC address learning is disabled on a port in this mode. You configure MAC addresses by
using the mac-address static and mac-address dynamic commands. For more information about
configuring MAC address table entries, see Layer 2 Configuration Guide.
A port in secure mode allows only frames sourced from the manually configured MAC addresses to pass.
Performing 802.1X authentication
userLogin
A port in this mode performs 802.1X authentication and implements port-based access control.
The port can service multiple 802.1X users. Once an 802.1X user passes authentication on the
port, any subsequent 802.1X users can access the network through the port without
authentication.
userLoginSecure
A port in this mode performs 802.1X authentication and implements MAC-based access control.
The port services only one user passing 802.1X authentication.
userLoginSecureExt
This mode is similar to the userLoginSecure mode except that this mode supports multiple online
802.1X users.
userLoginWithOUI
This mode is similar to the userLoginSecure mode. The difference is that a port in this mode also
permits frames from one user whose MAC address contains a specific OUI.
{
For wired users, the port performs 802.1X authentication upon receiving 802.1X frames, and
performs OUI check upon receiving non-802.1X frames.
For wireless users, the port performs OUI check at first. If the OUI check fails, the port performs
802.1X authentication.
NOTE:
An OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization. In MAC
addresses, the first three octets are the OUI.
Performing MAC authentication

macAddressWithRadius: A port in this mode performs MAC authentication and services multiple users.
Performing a combination of MAC authentication and 802.1X authentication
macAddressOrUserLoginSecure
This mode is the combination of the macAddressWithRadius and userLoginSecure modes.
{
For wired users, the port performs MAC authentication 30 seconds after receiving non-802.1X
frames and performs 802.1X authentication upon receiving 802.1X frames.
For wireless users, the port performs 802.1X authentication first. If 802.1X authentication fails,
MAC authentication is performed.
macAddressOrUserLoginSecureExt
This mode is similar to the macAddressOrUserLoginSecure mode except that this mode supports
multiple 802.1X and MAC authentication users.
macAddressElseUserLoginSecure
218
This mode is the combination of the macAddressWithRadius and userLoginSecure modes, with
MAC authentication having a higher priority as the Else keyword implies.
{
For wired users, the port performs MAC authentication 30 seconds after receiving non-802.1X
frames.
For wireless users, the port performs MAC authentication upon receiving non-802.1X frames.
Upon receiving 802.1X frames, the port performs MAC authentication, and if the MAC
authentication fails, it performs 802.1X authentication.
macAddressElseUserLoginSecureExt
This mode is similar to the macAddressElseUserLoginSecure mode except that this mode supports
multiple 802.1X and MAC authentication users as the keyword Ext implies.
Support for WLAN

CAUTION:
Do not configure static MAC address entries for wireless users that use the 802.1X or MAC authentication
service. If the source MAC address and the VLAN of a wireless user match a static MAC address entry in
the MAC address table, the user cannot pass 802.1X authentication or MAC authentication.
Table 11 describes the port security modes that implement wireless access security at the link layer.
Table 11 Port security modes for WLAN ports
Features that can be
triggered
Security mode
Description
presharedKey
A user must use a pre-configured static key, also called

"the pre-shared key (PSK)," to negotiate the session key
with the device and can access the network only after the
negotiation succeeds.
macAddressAndPr
esharedKey
A user must pass MAC authentication and then use the

pre-configured PSK to negotiate with the device. Only
when the negotiation succeeds, can the user access the
network.
userLoginSecureExt
OrPresharedKey
A user interacts with the device, choosing the

UserLoginSecure mode or using the PSK to negotiate with
the device.
NTK/intrusion protection
PSK users refer to users that have passed authentication in presharedKey mode. The maximum number of
PSK users on a port varies with security modes.
presharedKey modeThe maximum number of PSK users on the port is the port specification limit
on the number of wireless users or port security's limit on the number of MAC addresses, whichever
is smaller. The actual maximum number of PSK users on the port also depends on the total number
of PSK users that the system can support. For more information, see About the Configuration Guides
for HP Unified Wired-WLAN Products.
macAddressAndPresharedKey modeThe maximum number of PSK users on the port is the MAC
authentication feature's limit on the number of concurrent users or port security's limit on the number
of MAC addresses, whichever is smaller. The actual maximum number of PSK users on the port also
depends on the total number of PSK users that the system can support.
219
userLoginSecureExtOrPresharedKey modeThe number of PSK users on the port cannot exceed

the port limit on the number of wireless users, the number of 802.1X users cannot exceed the 802.1X
feature's limit on the number of concurrent users, and the total number of PSK and 802.1X users
cannot exceed port security's limit on the number of MAC addresses on the port. The maximum
number of PSK or 802.1X users also depends on the system specification.
Working with guest VLAN and Auth-Fail VLAN

An 802.1X guest VLAN is the VLAN that a user is in before initiating authentication.
An 802.1X Auth-Fail VLAN or a MAC authentication guest VLAN is the VLAN that a user is in after failing
authentication.
Support for the guest VLAN and Auth-Fail VLAN features varies with security modes.
You can use the 802.1X guest VLAN and 802.1X Auth-Fail VLAN features together with port security
modes that support 802.1X authentication. For more information about the 802.1X guest VLAN and
Auth-Fail VLAN on a port that performs MAC-based access control, see "Configuring 802.1X."
You can use the MAC authentication VLAN feature together with security modes that support MAC
authentication. For more information about the MAC authentication guest VLAN, see "Configuring
MAC authentication."
If you configure both an 802.1X Auth-Fail VLAN and a MAC authentication guest VLAN on a port
that performs MAC-based access control, the 802.1X Auth-Fail VLAN has a higher priority.
Port security stateful failover

In a dual-AC network, the ACs can provide client information stateful failover to avoid client logoff during
primary/backup AC switchovers. When a client logs in or logs off, the primary AC synchronizes the
client information (authentication and authorization information, client data, and client status) to the
backup AC through the IACTP tunnel in real time. Therefore, when a primary/backup AC switchover
occurs, the backup AC can immediately take over to provide normal communication for online clients.
For more information about AC backup, see WLAN Configuration Guide.
Port security supports stateful failover only for 802.1X client information.
The Auth-Fail VLAN and guest VLAN do not support stateful failover. If a client is added to an Auth-Fail
VLAN on the primary AC, the VLAN information cannot be synchronized to the backup AC.
Stop-Account-Buffer packets, if any, cannot be synchronized from the primary AC to the backup AC.
The failover link between two ACs is the basic for client information synchronization on both the ACs.
Make sure the failover link operates correctly. If the failover link is disconnected and then reconnected,
the client information might change.

Task
Remarks
Enabling port security
Required.
Setting port security's limit on the number of MAC addresses on a port
Optional.
Setting the port security mode
Required.
220
Task
Remarks
Configuring port security features:
Optional.
Configuring NTK
Configuring intrusion protection
Enabling port security traps
Configure one or more

features as required.
Configuring port security for WLAN ports:
Setting the port security mode of a WLAN port

Enabling key negotiation
Configuring a PSK
Required for WLAN

ports.
Ignoring authorization information from the server
Optional.
Configuring NAS ID profile for port security
Optional.
Configuring port security stateful failover
Optional.
Enabling port security

When port security is enabled, you cannot manually enable 802.1X or MAC authentication, or change
the access control mode or port authorization state. The port security automatically modifies these
settings in different security modes.
Before you enable port security, disable 802.1X and MAC authentication globally.
To enable port security:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable port security.
port-security enable
By default, port security is enabled.
You can use the undo port-security enable command to disable port security when no online users are
present.
Enabling or disabling port security resets the following security settings to the default:
802.1X access control mode is MAC-based, and the port authorization state is auto.
Port security mode is noRestrictions.
For more information about Configuring 802.1X, see "Configuring 802.1X."

For more information about MAC authentication configuration, see "Configuring MAC authentication."
Setting port security's limit on the number of MAC

addresses on a port
You can set the maximum number of MAC addresses that port security allows on a port to control the
number of concurrent users on the port. The maximum number of concurrent users on the port equals this
limit or the limit of the authentication mode (802.1X for example) in use, whichever is smaller.
221
The port security's limit on the number of MAC addresses on a port is independent of the MAC learning
limit described in MAC address table configuration in the Layer 2 Configuration Guide.
To set the maximum number of secure MAC addresses allowed on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Set the limit of port security on the

number of MAC addresses.
port-security max-mac-count count-value
Not limited by default.
Setting the port security mode

After enabling port security, you can change the port security mode of a port only when the port is
operating in noRestrictions (the default) mode. To change the port security mode for a port in any other
mode, first use the undo port-security port-mode command to restore the default port security mode.
You can specify a port security mode when port security is disabled, but your configuration cannot take
effect.
You cannot change the port security mode of a port when online users are present.
Before you set a port security mode for a port, complete the following tasks:
Disable 802.1X and MAC authentication.
Check that the port does not belong to any aggregation group.
To enable a port security mode:

Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set an OUI value for

user authentication.
port-security oui oui-value

index index-value
interface-number
Set the port security

mode.
port-security port-mode
{ mac-authentication |
mac-else-userlogin-secure |
mac-else-userlogin-secure-e
xt | secure | userlogin |
userlogin-secure |
userlogin-secure-ext |
userlogin-secure-or-mac |
userlogin-secure-or-mac-ext
| userlogin-withoui }
3.
4.
222
Required for the userlogin-withoui mode.

To set multiple OUI values, repeat this step.
To specify the userLoginWithOUI mode, you must
enter Layer 2 Ethernet interface view or WLAN-ESS
interface view.
By default, a port operates in noRestrictions mode.
If you configure the MAC authentication quiet timer
after you have configured the port-security
port-mode { mac-authentication |
userlogin-secure-or-mac-ext } command, the quiet
timer does not take effect. For more information
about the MAC authentication quiet timer, see
"Configuring MAC authentication."
Configuring port security features

Configuring NTK
The NTK feature checks destination MAC addresses in outbound frames to make sure frames are
forwarded only to authenticated devices. Any unicast frame with an unknown destination MAC address
is discarded. Not all port security modes support triggering the NTK feature. For more information,
see Table 10.
The NTK feature supports the following modes:
ntkonlyForwards only unicast frames with authenticated destination MAC addresses.
ntk-withbroadcastsForwards only broadcast frames and unicast frames with authenticated

destination MAC addresses.
ntk-withmulticastsForwards only broadcast frames, multicast frames, and unicast frames with
authenticated destination MAC addresses.
To configure the NTK feature:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Configure the NTK feature.
port-security ntk-mode
{ ntk-withbroadcasts |
ntk-withmulticasts | ntkonly }
By default, NTK is disabled on a

port and all frames are allowed to
be sent.
Configuring intrusion protection

Intrusion protection enables a device to take one of the following actions in response to illegal frames:
blockmacAdds the source MAC addresses of illegal frames to the blocked MAC addresses list
and discards the frames. All subsequent frames sourced from a blocked MAC address will be
dropped. A blocked MAC address is restored to normal state after being blocked for three minutes.
The interval is fixed and cannot be changed.
disableportDisables the port until you bring it up manually.
disableport-temporarilyDisables the port for a specific period of time. The period can be
configured with the port-security timer disableport command.
On a port operating in either the macAddressElseUserLoginSecure mode or the

macAddressElseUserLoginSecureExt mode, intrusion protection is triggered only after both MAC
authentication and 802.1X authentication fail for the same frame.
To configure the intrusion protection feature:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
223
Step
Command
Remarks
By default, intrusion protection is
disabled.
Configure the intrusion

protection feature.
port-security intrusion-mode
{ blockmac | disableport |
disableport-temporarily }
4.
quit
N/A
5.
Set the silence timeout period

during which a port remains
disabled.
port-security timer
disableport time-value
Optional.
3.
The disableport keyword is not supported

on a WLAN-ESS interface.
20 seconds by default.
Enabling port security traps

You can configure the port security module to send traps for the following categories of events:
addresslearnedLearning of new MAC addresses.
dot1xlogfailure/dot1xlogon/dot1xlogoff802.1X authentication failure, success, and 802.1X

user logoff.
ralmlogfailure/ralmlogon/ralmlogoffMAC authentication failure, MAC authentication user

logon, and MAC authentication user logoff.
intrusionDetection of illegal frames.
To enable port security traps:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable port
security traps.
port-security trap { addresslearned | dot1xlogfailure

| dot1xlogoff | dot1xlogon | intrusion |
ralmlogfailure | ralmlogoff | ralmlogon }
By default, port security

traps are disabled.
Configuring port security for WLAN ports

Table 12 describes the key negotiation and PSK requirements for different port security modes on WLAN
ports.
Table 12 Port security configuration for WLAN ports
Port security mode
Description
On WPA or RSN networks using any of these modes, key
negotiation must be enabled.
presharedKey, userLoginSecureExt,
userLoginSecureExtOrPresharedKey, and
macAddressAndPresharedKey
In presharedKey and macAddressAndPresharedKey modes,

you need to configure the PSK.
In userLoginSecureExt mode, you do not need to configure the

PSK.
In userLoginSecureExtOrPresharedKey mode, you can

determine whether to configure any PSK.
224
Port security mode
Description
Port security modes other than

presharedKey,
userLoginSecureExtOrPresharedKey, and
macAddressAndPresharedKey
No key negotiation is performed and you do not need to enable

key negotiation.
For more information about WLAN service templates, see WLAN Configuration Guide.
By default, an 802.1X-enabled access device periodically multicasts Identity EAP-Request packets out of
ports to detect 802.1X clients and trigger authentication. To save the bandwidth of WLAN ports, HP
recommends you disable the multicast trigger function (see "Configuring 802.1X").
Setting the port security mode of a WLAN port

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
Set a port security mode for

the WLAN port.
port-security port-mode
{ mac-and-psk |
mac-authentication |
mac-else-userlogin-secure |
mac-else-userlogin-secure-ext |
psk | userlogin-secure |
userlogin-secure-ext |
userlogin-secure-ext-or-psk |
userlogin-secure-or-mac-ext |
userlogin-withoui }
By default, a port operates in

noRestrictions mode.
3.
Enabling key negotiation

After a user passes 802.1X authentication, a WLAN port uses EAPOL-Key frames to negotiate the
link-layer session key with the user if the key negotiation function is enabled.
If key negotiation is enabled, an authenticated user is allowed to access to the port only after the
key negotiation succeeds.
If key negotiation is disabled, a user can directly access the port after passing authentication.
To enable key negotiation:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Enable key negotiation of the

11key type.
port-security tx-key-type 11key
225
Configuring a PSK
A PSK pre-configured on the device is used to negotiate the session key between the user and the device.
To configure a PSK:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface
view.
N/A
3.
Configure a PSK.
port-security preshared-key { pass-phrase |

raw-key } [ cipher | simple ] key
By default, no PSK is configured.
Ignoring authorization information from the server

You can configure a port to ignore the authorization information received from the server (an RADIUS
server or the local device) after an 802.1X user or MAC authentication user passes authentication.
To configure a port to ignore authorization information from the server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Ignore the authorization

information received from the
authentication server.
port-security authorization ignore
By default, a port uses the

authorization information received
from the authentication server.
Configuring NAS ID profile for port security

Perform this task to specify a NAS ID profile for interface-specific or global port security. When a user
logs in from an interface by passing port security authentication, the device searches the NAS ID to be
sent to the RADIUS server in the following order:
1.
NAS ID configured in the AP template
2.
NAS ID configured in radio view
3.
NAS ID profile specified for port security on the interface
4.
NAS ID profile specified for port security in system view
5.
Device name
To specify a NAS ID profile for port security in system view:

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
226
Step
Command
2.
port-security nas-id-profile
profile-name
Specify a NAS ID profile.
Remarks
Optional.
By default, no NAS ID profile is
specified in system view.
To specify a NAS ID profile for port security on an interface:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Specify a NAS ID profile.
port-security nas-id-profile
profile-name
Optional.
By default, no NAS ID profile is
specified on an interface.
Configuring port security stateful failover

Perform this task to provide client information stateful failover on two ACs that support stateful failover.
After you configure stateful failover for the two ACs and on the WLAN-ESS interfaces (with the same
interface number) of the two ACs, the primary AC synchronizes the online client information on the
WLAN-ESS interface and the corresponding WLAN-DBSS interface to the backup AC. When a
primary/backup AC switchover occurs, the backup AC takes over to provide access services for the
online clients without re-authenticating the clients.
Port security supports stateful failover only for 802.1X client information.
To implement port security stateful failover, complete the following tasks:
Configure AC hot backup (stateful failover). For more information, see WLAN Configuration Guide.
Configure WLAN client information backup. For more information, see WLAN Configuration
Guide.
Configure VRRP. You need to configure a VRRP group on the interface connected to the
authentication server. For more information, see High Availability Configuration Guide.
Configure stateful failover. You need to configure a backup VLAN for the stateful failover function.
For more information, see High Availability Configuration Guide.
Configure different device IDs for the ACs that back up each other. For more information, see
"Configuring AAA."
Specify the virtual IP address of the VRRP group as the source address of outgoing RADIUS packets.
For more information, see "Configuring AAA."
To configure port security stateful failover:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter WLAN-ESS interface

view.
interface wlan-ess
interface-number
N/A
227
Step
Enable stateful failover for
port security.
3.
Command
Remarks
port-security synchronization
enable
By default, stateful failover is

disabled for port security.
Displaying and maintaining port security

Task
Command
Remarks
Display port security

configuration information,
operation information, and
statistics about one or more ports
or all ports.
display port-security [ interface interface-list ] [ |


blocked MAC addresses.
display port-security mac-address block

[ interface interface-type interface-number ] [ vlan
vlan-id ] [ count ] [ | { begin | exclude | include }
Display information about PSK

users.
display port-security preshared-key user

[ interface interface-type interface-number ] [ |
Port security configuration examples

Configuring the userLoginWithOUI mode

As shown in Figure 93, a client is connected to the AC through port WLAN-ESS 1. The AC authenticates
the client with a RADIUS server. If the authentication succeeds, the client is authorized to access the
Internet.
The RADIUS server at 192.168.1.2/24 functions as the primary authentication server and the
secondary accounting server. The RADIUS server at 192.168.1.3/24 functions as the secondary
authentication server and the primary accounting server. The shared key for authentication is name,
and the shared key for accounting is money.
228
All users use the default authentication, authorization, and accounting methods of ISP domain sun,
which can accommodate up to 30 users.
The RADIUS server response timeout time is 5 seconds. The maximum number of RADIUS packet
retransmission attempts is five. The AC sends real-time accounting packets to the RADIUS server at
an interval of 15 minutes, and sends user names without domain names to the RADIUS server.
Configure port WLAN-ESS 1 of the AC to:
Allow only one 802.1X user to be authenticated.
Allow up to five OUI values to be configured and allow one terminal that uses any of the OUI values
to access the port in addition to an 802.1X user.
The following configuration steps cover some AAA/RADIUS configuration commands. For more
information about the commands, see Security Command Reference.
Configuration procedures for the client and RADIUS servers are not shown.
1.
Configure the RADIUS protocol:

# Configure a RADIUS scheme named radsun.
<AC> system-view
[AC] radius scheme radsun
# Specify the IP address of the primary authentication RADIUS server as 192.168.1.2/24, and
that of the primary accounting RADIUS server as 192.168.1.3/24.
[AC-radius-radsun] primary authentication 192.168.1.2
[AC-radius-radsun] primary accounting 192.168.1.3
# Specify the IP address of the secondary authentication RADIUS server as 192.168.1.3/24, and
that of the secondary accounting RADIUS server as 192.168.1.2/24.
[AC-radius-radsun] secondary authentication 192.168.1.3
[AC-radius-radsun] secondary accounting 192.168.1.2
# Set the shared key for authenticating RADIUS authentication/authorization packets as name.
[AC-radius-radsun] key authentication name
# Set the shared key for authenticating RADIUS accounting packets as money.
[AC-radius-radsun] key accounting money
# Set the RADIUS server response timeout to 5 seconds, and set the maximum transmission
attempts of RADIUS packets to 5.
[AC-radius-radsun] timer response-timeout 5
[AC-radius-radsun] retry 5
229
# Set the interval between sending real time accounting packets to the RADIUS server to 15
minutes.
[AC-radius-radsun] timer realtime-accounting 15
# Exclude the ISP domain name in the username sent to the RADIUS server.
[AC-radius-radsun] user-name-format without-domain
[AC-radius-radsun] quit
# Configure ISP domain sun to use RADIUS scheme radsun for authentication, authorization, and
accounting of all types of users.
[AC] domain sun
[AC-isp-sun] authentication default radius-scheme radsun
[AC-isp-sun] authorization default radius-scheme radsun
[AC-isp-sun] accounting default radius-scheme radsun
# Specify that the ISP domain can contain up to 30 users.

[AC-isp-sun] access-limit enable 30
[AC-isp-sun] quit
2.
Set the 802.1X authentication method to CHAP. By default, the authentication method is CHAP for
802.1X.
[AC] dot1x authentication-method chap
3.

# Add five OUI values.

[AC] port-security oui 1234-0100-1111 index 1
# Configure the mandatory authentication domain sun for 802.1X users on WLAN-ESS 1. Set the
port security mode to userLoginWithOUI.
[AC-WLAN-ESS1] dot1x mandatory-domain sun
[AC-WLAN-ESS1] port-security port-mode userlogin-withoui
[AC-WLAN-ESS1] quit
# Create service template 2, set its template type to clear and SSID to mactest, bind interface
WLAN-ESS 1 to it, and enable open system authentication.
[AC-wlan-st-2] ssid mactest
[AC-wlan-st-2] quit
# Create an AP template named ap1, and set its model to MSM460-WW and serial ID to
CN2AD330S8.
230
# Map service template 2 to radio 1, and enable the radio.


# Display the configuration of the RADIUS scheme named radsun.
<AC> display radius scheme radsun
SchemeName
: radsun
Index = 1
Type : standard
Primary Auth Server:

IP: 192.168.1.2
Port: 1812
State: active
Port: 1813
State: active
Port: 1812
State: active
Port: 1813
State: active
Encryption Key : N/A

Probe username : N/A
Probe interval : N/A
Primary Acct Server:
IP: 192.168.1.3
Second Auth Server:
IP: 192.168.1.3
Second Acct Server:
IP: 192.168.1.2
Auth Server Encryption Key : ******
Acct Server Encryption Key : ******
Accounting-On packet disable, send times = 5 , interval : 3s
Interval for timeout(second)
: 5
Retransmission times for timeout
: 5
Interval for realtime accounting(minute)
: 15
Retransmission times of realtime-accounting packet
: 5
Retransmission times of stop-accounting packet
: 500
Quiet-interval(min)
: 5
Username format
: without-domain
Data flow unit
: Byte
Packet unit
: one
# Display the configuration of the ISP domain named sun.

<AC> display domain sun
Domain = sun
State = Active
Access-limit = 30
Accounting method = Required
231
Default authentication scheme
: radius=radsun
Default authorization scheme
: radius=radsun
Default accounting scheme
: radius=radsun
Domain User Template:

Idle-cut = Disable
Session-time : exclude-idle-time
Self-service = Disable
Authorization attributes:
# Display the port security configuration.

<AC> display port-security interface wlan-ess 1
Equipment port-security is enabled
Trap is disabled
Disableport Timeout: 20s
OUI value:
Index is 1,
OUI value is 123401
Index is 2,
OUI value is 123402
Index is 3,
OUI value is 123403
Index is 4,
OUI value is 123404
Index is 5,
OUI value is 123405
WLAN-ESS1 is link-up
Port mode is userLoginWithOUI
NeedToKnow mode is disabled
Intrusion Protection mode is NoAction
Max MAC address number is not configured
Stored MAC address number is 0
Authorization is permitted
Synchronization is disabled
After an 802.1X user gets online, you can see that the number of MAC addresses stored is 1.
# Display the 802.1X user connection.
Index=1,Username= test@sun
MAC=12-34-01-00-11-11
IP=10.1.0.1
IPv6=N/A
Online=00h00m53s
<AC> display connection ucibinedx 1
Index=2054, Username= test@sun
MAC=12-34-01-00-11-11
IP=10.1.0.1
IPv6=N/A
Access=8021X
,AuthMethod=CHAP

Initial VLAN=1, Authorization VLAN= N/A
ACL Group=Disable
232
User Profile=N/A
CAR=Disable
Traffic Statistic:
InputOctets
=12121212
InputGigawords=1
OutputOctets
=12120
OutputGigawords=0
Priority=Disable
SessionTimeout=86236(s), Terminate-Action=Default
Configuring the userLoginSecureExt mode on a WLAN port

Clients are wirelessly connected to the AC through port WLAN-ESS 1. The AC uses the RADIUS server to
authenticate its clients. If the authentication for a client succeeds, key negotiation is performed. If key
negotiation succeeds, the client can access the network resources.
The RADIUS server at 192.168.1.2/24 is the primary authentication server and the backup accounting
server. The RADIUS server at 192.168.1.3/24 is the backup authentication server and the primary
accounting server. Both the authentication and accounting shared keys are name.
All users use the default authentication, authorization, and accounting methods of the ISP domain sun.
RADIUS server
SSID 1
AP
IP network
Client A
AC
Client B
This example covers only some of the required AAA and RADIUS configuration commands. For more
information, see Security Command Reference.
The client-side and RADIUS server-side configuration procedures are not shown in this example.
For more information about WLAN configuration, see WLAN Configuration Guide.
1.
Enable port security.

<AC> system-view
2.
Configure RADIUS:
# Configure RADIUS scheme 2000.
233
# Specify the IP address of the primary authentication RADIUS server as 192.168.1.2/24, and
that of the primary accounting RADIUS server as 192.168.1.3/24.
[AC-radius-2000] primary authentication 192.168.1.2
[AC-radius-2000] primary accounting 192.168.1.3
# Specify the IP address of the secondary authentication RADIUS server as 192.168.1.3/24, and
that of the secondary accounting RADIUS server as 192.168.1.2/24.
[AC-radius-2000] secondary authentication 192.168.1.3
[AC-radius-2000] secondary accounting 192.168.1.2
# Set the shared keys for authenticating RADIUS authentication and accounting packets as name.
[AC-radius-2000] key authentication name
[AC-radius-2000] key accounting name
# Exclude the ISP domain name in the username sent to the RADIUS server.
# Configure ISP domain sun, and configure the domain to use RADIUS scheme 2000 for
authentication, authorization, and accounting of all types of users.
[AC] domain sun
[AC-isp-sun] authentication default radius-scheme 2000
[AC-isp-sun] authorization default radius-scheme 2000
[AC-isp-sun] accounting default radius-scheme 2000
[AC-isp-sun] quit
# Create interface WLAN-ESS 1.

# Set the port security mode to userLoginSecureExt.

# Enable key negotiation of the 11key type.

# Disable the 802.1X multicast trigger and online user handshake functions.
[AC-WLAN-ESS1] quit
# Specify the default authentication domain as the domain sun.

[AC] domain default sun
# Set the 802.1X authentication mode to EAP.

3.
Configure the WLAN service template, and the AP:

# Create a WLAN service template of the crypto type, enter its view, and set an SSID.
[AC-wlan-st-1] ssid SSID1
# Bind the interface to the service template.

# Enable open system authentication, the AES-CCMP cipher suite, and the RSN-IE in the beacon
and probe responses.
234
# Enable the service template function.

[AC-wlan-st-1] quit
# Create an AP template named ap1, and set its model to MSM460-WW and serial ID to
CN2AD330S8.
# Bind the service template 1 to the port radio 1, and enable the radio.

# Display the port security configuration.
<AC> display port-security interface wlan-ess 1
Equipment port-security is enabled
Trap is disabled
Disableport Timeout: 20s
OUI value:
WLAN-ESS1 is link-up
Port mode is userLoginSecureExt
NeedToKnow mode is disabled
Intrusion Protection mode is NoAction
Max MAC address number is not configured
Stored MAC address number is 0
Authorization is permitted
Synchronization is disabled
# If a user comes online, you can use the display connection and display wlan client commands to
display information about the user.
<AC> display connection ucibindex 315
Index=315 , Username=test@sectest.com
MAC=00-17-9A-00-7B-2F
IP=N/A
IPv6=N/A
Access=8021X
,AuthMethod=EAP

Initial VLAN=1, Authorization VLAN=N/A
ACL Group=Disable
User Profile=N/A
CAR=Disable
Traffic Statistic:
InputOctets
=12121212
InputGigawords=1
OutputOctets
=12120
OutputGigawords=0
Priority=Disable
SessionTimeout=86236(s), Terminate-Action=Default
235

<AC> display wlan client verbose
Total Number of Clients: 1
Total Number of Clients Connected : 1
Client Information
------------------------------------------------------------------------------MAC Address
: 0017-9a00-7b2f
AID
: 1
AP Name
: AP1
Radio Id
: 1
SSID
: sectest
BSSID
: 000f-e278-8020
Port
: WLAN-DBSS1:0
VLAN
: 1
State
: Running
Power Save Mode
: Active
Wireless Mode
: 11g
QoS Mode
: WMM
Listen Interval (Beacon Interval) : 10

RSSI
: 37
Rx/Tx Rate
: 5.5/18
Client Type
: WPA
Authentication Method
: Open System
AKM Method
: 802.1X
4-Way Handshake State
: PTKINITDONE
Group Key State
: IDLE
Encryption Cipher
: TKIP
Roam Status
: Normal
Roam Count
: 0
Up Time (hh:mm:ss)
: 00:43:19
Configuring an 802.1X guest VLAN for a port security-enabled

port
As shown in Figure 95, an AP connects to an AC through a switch. The AC performs 802.1X
authentication for the wireless users, implements MAC-based access control on the ingress port, and
accepts concurrent 802.1X users.
Configure a guest VLAN on the ingress port of the AC, so any user that has failed authentication can
access VLAN 1.
236
The client-side and RADIUS server-side configuration procedures are not shown in this example.
1.
Perform RADIUS-related configurations. See steps in "Configuring the userLoginWithOUI mode."
2.
Configure the AC:

# Create VLAN 2.
<AC> system-view
[AC] vlan 2
[AC-vlan2] quit


# Set the port security mode of WLAN-ESS 1 to userLoginSecureExt. In this mode, the port performs
802.1X authentication, implements MAC-based access control, and allows more than one
802.1X user.
# Enable the MAC-based VLAN function and configure VLAN 1 as the guest VLAN.
[AC-WLAN-ESS1] port hybrid vlan 1 to 2 untagged
[AC-WLAN-ESS1] dot1x guest-vlan 1
[AC-WLAN-ESS1] quit

[AC-wlan-st-1] ssid SSID1
237

[AC-wlan-st-1] quit
# Configure the service template of the AP.

[AC-wlan-ap-1] radio 1
[AC-wlan-ap-1-radio-1] return

# Before Client 1 is authenticated (using the username of mac and MAC address of 000f-e2cc-6a21), the
guest VLAN function takes effect. You can use the display mac-vlan all command to display the
MAC-to-VLAN mapping.
<AC> display mac-vlan all
The following MAC VLAN addresses exist:
S:Static
D:Dynamic
MAC ADDR
MASK
VLAN ID
PRIO
STATE
-------------------------------------------------------000f-e2cc-6a21
ffff-ffff-ffff
Total MAC VLAN address count:1
# If Client 1 initiates authentication and passes the authentication, you can use the display connection
command to display the user information, and use the display mac-vlan all command to verify that the
MAC-to-VLAN mapping entry has been removed.
<AC> display connection user-name mac@sun
Index=18
, Username=mac@sun
MAC=000f-e2cc-6a21
IP=8.4.4.199
IPv6=N/A
Online=00h00m31s
Configuring port security with guest VLAN and VLAN

assignment
Clients connect to the AC through the AP. he AC uses the RADIUS server to authenticate its clients. The
access port WLAN-ESS 1 of the AC is in VLAN 1, the RADIUS server is in VLAN 2, and the update server
for client software download and upgrade is in VLAN 10.
Clients can access the Internet after passing authentication.
238

AC
AP
AN
VL
Client
VLAN
10
VLAN 5
Update server
Client
IP network
As shown in Figure 97, enable 802.1X and set VLAN 10 as the guest VLAN on port WLAN-ESS 1. If the
AC sends an EAP-Request/Identity packet from the port for the maximum number of times but still receives
no response, the AC adds the MAC address of the client to its guest VLAN. In this case, the client and the
update server are both in VLAN 10, and therefore the host can access the update server and download
the 802.1X client.
As shown in Figure 98, after the host passes the authentication and logs in, the client is added to VLAN
5. In this case, the client and WLAN-ESS 1 are both in VLAN 5, and therefore the client can access the
Internet.
239
Use the iNode client in this example. The client that comes with Windows does not support the function.
<AC> system-view
[AC-radius-2000] key authentication abc
[AC-radius-2000] key accounting abc
# Create ISP domain test, and set it as the default ISP domain. By default, the system default ISP domain
is system.
[AC] domain test
[AC-isp-test] quit
[AC] domain default enable test
# Create ISP domain test, and configure the domain to use RADIUS scheme 2000 for authentication,
authorization, and accounting of LAN users.
[AC] domain test
[AC-isp-test] authentication lan-access radius-scheme 2000
[AC-isp-test] authorization lan-access radius-scheme 2000
[AC-isp-test] accounting lan-access radius-scheme 2000
[AC-isp-test] quit
# Enable port security in system view.


240
# Configure wireless port WLAN-ESS 1.

[AC-WLAN-ESS1] port hybrid vlan 1 to 2 5 10 untagged
[AC-WLAN-ESS1] dot1x guest-vlan 10
[AC-WLAN-ESS1] dot1x mandatory-domain test
[AC-WLAN-ESS1] quit
# Configure service template 1. The template must be in clear text mode.

[AC-wlan-st-1] quit
# Configure an AP template named 1.

[AC-wlan-ap-1-radio-1] return

# Before Client 1 is authenticated (using the username of mac and MAC address of 000f-e2cc-6a21), the
guest VLAN function takes effect. You can use the display mac-vlan all command to display the
MAC-to-VLAN mapping.
<AC> display mac-vlan all
The following MAC VLAN addresses exist:
S:Static
D:Dynamic
MAC ADDR
MASK
VLAN ID
PRIO
STATE
-------------------------------------------------------000f-e2cc-6a21
ffff-ffff-ffff
10
Total MAC VLAN address count:1
# If Client 1 initiates authentication and passes the authentication, you can use the display connection
command to display the user information, and use the display mac-vlan all command to verify that the
MAC-to-VLAN mapping entry has been removed.
<AC> display connection user-name mac@test
Index=18
, Username=mac@test
MAC=000f-e2cc-6a21
IP=8.4.4.199
IPv6=N/A
Online=00h00m31s
241
Configuring 802.1X stateful failover for port security

AC 1 and AC 2 support stateful failover. To avoid 802.1X client re-authentication and traffic interruption
in case of a primary/backup AC switchover, configure AC 1 and AC 2 to support stateful failover for
802.1X client information and use VRRP to implement traffic switchover between the ACs.
When AC 1 operates normally, the client passes 802.1X authentication on AC 1 to access the external
network. When AC 1 fails, the client accesses the external network through AC 2.
A RADIUS server is used as the AAA server. The NAS IP of the access device configured on the RADIUS
server is 192.168.100.5/24.
AC 1 and AC 2 use a failover link to transmit the stateful failover packets and the backup VLAN for
stateful failover is VLAN 10.
Complete the following tasks:
Configure IP addresses for interfaces. Create VLAN 8 and VLAN 10. Configure the RADIUS server.
(Details not shown.)
Create the WLAN-ESS interface, set a port security mode for 802.1X authentication on the interface,
and enable stateful failover for port security.
Enable global port security.
Enable stateful failover and specify the backup VLAN.
Configure a VRRP group on the interface connected to the RADIUS server.
Configure an AAA authentication domain and a RADIUS scheme.

242
Configure AC backup and the client information backup.
Enable the AC hot backup function
Configuring AC 1
1.

# Specify the 802.1X authentication method as EAP.
<AC1> system-view
[AC1] dot1x authentication-method eap
# Create interface WLAN-ESS 1 and enter its view.

# Set the port security mode to userlogin-secure-ext.

[AC1-WLAN-ESS1] port-security port-mode userlogin-secure-ext
# Enable stateful failover for port security.

[AC1-WLAN-ESS1] port-security synchronization enable
# Enable key negotiation.

[AC1-WLAN-ESS1] port-security tx-key-type 11key
# Specify the authentication domain for 802.1X users as domain 2003.

[AC1-WLAN-ESS1] dot1x mandatory-domain 2003
[AC1-WLAN-ESS1] undo dot1x multicast-trigger
[AC1-WLAN-ESS1] undo dot1x handshake
# Enable global port security.

[AC1] port-security enable
2.

# Specify VLAN 10 as the backup VLAN for stateful failover.
[AC1] dhbk vlan 10

3.
Create VRRP group 1 on interface VLAN-interface 8.

[AC1] interface vlan 8
[AC1-Vlan-interface8] ip address 192.168.100.1 24
[AC1-Vlan-interface8] vrrp vrid 1 virtual-ip 192.168.100.5
[AC1-Vlan-interface8] quit
4.
Configure AAA:
# Specify the device ID to be used in stateful failover mode as 1.

[AC1] radius scheme 2003
[AC1-radius-2003] primary authentication 192.168.0.2
[AC1-radius-2003] primary accounting 192.168.0.2
[AC1-radius-2003] key authentication simple aabbcc
[AC1-radius-2003] key accounting simple aabbcc
[AC1-radius-2003] user-name-format without-domain
[AC1-radius-2003] nas-ip 192.168.100.5
243
[AC1-radius-2003] quit
# Create authentication domain 2003, and specify the AAA methods.

[AC1] domain 2003
[AC1-isp-2003] authentication lan-access radius-scheme 2003
[AC1-isp-2003] authorization lan-access radius-scheme 2003
[AC1-isp-2003] accounting lan-access radius-scheme 2003
[AC1-isp-2003] quit
5.
Configure AC backup and client information backup:

# Specify AC 2 as the backup AC of AC 1.
# Configure a WLAN service template, configure the SSID as abc, encryption mode as AES-CCMP,
and bind interface WLAN-ESS 1 to the service template.
[AC1] wlan service-template 1 crypto
[AC1-wlan-st-1] authentication-method open-system
[AC1-wlan-st-1] cipher-suite ccmp
[AC1-wlan-st-1] security-ie rsn
# Configure the AP information.

[AC1-wlan-ap-ap1] radio 1 type dot11an
# Configure the source IP address of the IACTP tunnel as 1.1.1.4 (the address of AC 1) and the IP
address of the IACTP tunnel member (AC 2) as 1.1.1.5.
[AC1] wlan mobility-group roam
[AC1-wlan-mg-roam] source ip 1.1.1.4
[AC1-wlan-mg-roam] member ip 1.1.1.5
# Enable the IACTP tunnel.

[AC1-wlan-mg-roam] mobility-group enable
[AC1-wlan-mg-roam] quit
# Enable client information backup.

[AC1] wlan backup-client enable
# Enable the AC hot backup function.

# Set VLAN 10 as the VLAN for AC hot backup.

Configuring AC 2
1.

# Specify the 802.1X authentication method as EAP.
244
<AC2> system-view
[AC2] dot1x authentication-method eap
# Create interface WLAN-ESS 1 and enter its view.

# Set the port security mode to userlogin-secure-ext.

[AC2-WLAN-ESS1] port-security port-mode userlogin-secure-ext
# Enable stateful failover for port security.

[AC2-WLAN-ESS1] port-security synchronization enable
# Enable key negotiation.

[AC2-WLAN-ESS1] port-security tx-key-type 11key
# Specify the authentication domain for 802.1X users as domain 2003.

[AC2-WLAN-ESS1] dot1x mandatory-domain 2003
[AC2-WLAN-ESS1] undo dot1x multicast-trigger
[AC2-WLAN-ESS1] undo dot1x handshake
# Enable global port security.

[AC2] port-security enable
2.

# Specify VLAN 10 as the backup VLAN for stateful failover.
[AC2] dhbk vlan 10

3.
Create VRRP group 1 on interface VLAN-interface 8.

[AC2] interface vlan 8
[AC2-Vlan-interface8] vrrp vrid 1 virtual-ip 192.168.100.5
4.
Configure AAA:
# Specify the device ID to be used in stateful failover mode as 2.

[AC2] radius scheme 2003
[AC2-radius-2003] primary authentication 192.168.0.2
[AC2-radius-2003] primary accounting 192.168.0.2
[AC2-radius-2003] key authentication simple aabbcc
[AC2-radius-2003] key accounting simple aabbcc
[AC2-radius-2003] user-name-format without-domain
[AC2-radius-2003] nas-ip 192.168.100.5
[AC2-radius-2003] quit
# Create authentication domain 2003, and specify the AAA methods.

[AC2] domain 2003
[AC2-isp-2003] authentication lan-access radius-scheme 2003
[AC2-isp-2003] authorization lan-access radius-scheme 2003
[AC2-isp-2003] accounting lan-access radius-scheme 2003
245
[AC2-isp-2003] quit
5.
Configure AC backup and client information backup:

# Specify AC 1 as the backup AC of AC 2.
# Configure a WLAN service template, configure the SSID as abc, encryption mode as AES-CCMP,
and bind interface WLAN-ESS 1 to the service template.
[AC2] wlan service-template 1 crypto
[AC2-wlan-st-1] authentication-method open-system
[AC2-wlan-st-1] cipher-suite ccmp
[AC2-wlan-st-1] security-ie rsn
# Configure the AP information.

[AC2-wlan-ap-ap1] radio 1 type dot11an
# Configure the source IP address of the IACTP tunnel as 1.1.1.5 (the address of AC 2) and the IP
address of the IACTP tunnel member (AC 1) as 1.1.1.4.
[AC2] wlan mobility-group roam
[AC2-wlan-mg-roam] source ip 1.1.1.5
[AC2-wlan-mg-roam] member ip 1.1.1.4
# Enable the IACTP tunnel.

[AC2-wlan-mg-roam] mobility-group enable
[AC2-wlan-mg-roam] quit
# Enable client information backup.

[AC2] wlan backup-client enable
# Enable the AC hot backup function.

# Set VLAN 10 as the VLAN for AC hot backup.


After you complete the configurations, use the display dot1x synchronization status command to display
the 802.1X stateful failover status on AC 1 and AC 2.
After the client passes 802.1X authentication, execute the display wlan client verbose command on AC
1 (the primary AC) to display detailed information about the client. Execute the display wlan client
verbose command on AC 2 (the backup AC), and you can see the same client information as that on AC
1.
Execute the display dot1x synchronization connection command on AC 1 and AC 2 to display the
802.1X synchronization information. You can see that the client information is the same on the ACs and
246
the primary and backup link states are different, indicating that the ACs have synchronized the client
information.
When AC 1 fails, AC 2 becomes active. In case of a primary/backup AC switchover, the client can
access the network through AC 2 without being re-authenticated.
Troubleshooting port security

Cannot change port security mode when a user is online
Symptom
Port security mode cannot be changed when an 802.1X authenticated or MAC authenticated user is
online.
[AC-WLAN-ESS1] undo port-security port-mode
Error:Cannot configure port-security for there is 802.1X user(s) on line on port
WLAN-ESS1.
Analysis
Changing port security mode is not allowed when an 802.1X authenticated or MAC authenticated user
is online.
Solution
1.
Unbind the interface from the service template.
2.
Use the cut connection command to disconnect the user connection.
3.
Use the undo port-security port-mode command to set the port security mode to noRestrictions.
4.
Set the port to operate in the desired port security mode.
247
Configuring a user profile

Overview
A user profile provides a configuration template to save predefined configurations, such as a Committed
Access Rate (CAR) policy or a Quality of Service (QoS) policy.
The user profile implements service applications on a per-user basis. Every time a user accesses the
device, the device automatically applies the configurations in the user profile that are associated only
with this user.
User-based traffic policing is more flexible than interface-based traffic policing. In interface-based traffic
policing, if a user moves between ports to access a device, you must remove the policy from the previous
port, and then configure the same policy on the port being used to restrict user behaviors. The
configuration task is tedious and error prone.
The user profile supports working with PPPoE, 802.1X authentication, MAC authentication, and portal
authentication, and restricts authenticated users' behaviors as follows:
1.
After the authentication server verifies a user, the server sends the device the name of the user
profile associated with the user.
{
2.
If the profile is enabled, the device applies the configurations in the user profile, and allows user
access based on all valid configurations.
If the user profile is disabled, the device denies the user access.
After the user logs out, the device automatically disables the configurations in the user profile, and
the restrictions on the user access are removed.
User profile configuration task list

Task
Remarks
Creating a user profile
Required.
Performing configurations in user profile view
Required.
Enabling a user profile
Required.
Creating a user profile

Before you create a user profile, complete the following tasks:
Configure authentication parameters on the device.
Perform configurations on the client, the device, and the authentication server. For example,
configure the username, password, authentication scheme, domain, and bind the user profile with
a user.
To create a user profile:
248
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user profile,

and enter its view.
user-profile profile-name
You can use the command to enter the view of

an existing user profile.
Performing configurations in user profile view

After a user profile is created, perform configurations in user profile view. The configuration made in user
profile view takes effect when the user profile is enabled and a user using the user profile goes online.
Supported configurations include QoS policies, WLAN configurations, and firewall configurations. The
QoS policies applied in user profile view support only the remark, car, and filter actions.
For more information about QoS policies, see ACL and QoS Configuration Guide.
For more information about firewall configuration, see "Configuring firewall."
Enabling a user profile

Enable a user profile so that configurations in the profile can be applied by the device to restrict user
behaviors. If the device detects that the user profile is disabled, the device denies the associated user,
even if the user has been verified by the authentication server.
You can only edit or remove the configurations in a disabled user profile.
Disabling a user profile logs out the users that are using the user profile.
To enable a user profile:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable a user profile.
user-profile profile-name enable
A user profile is disabled by

default.
Displaying and maintaining user profile

Task
Command
Remarks
Display information about all the

created user profiles.
display user-profile [ | { begin | exclude

249
Configuring password control

Overview
Password control refers to a set of functions provided by the local authentication server to control user
login passwords, super passwords, and user login status based on predefined policies. The rest of this
section describes password control functions in detail.
Minimum password length

By setting a minimum password length, you can enforce users to use passwords long enough for
system security. If a user specifies a shorter password, the system rejects the setting and prompts
the user to re-specify a password.
Minimum password update interval

This function allows you to set the minimum interval at which users can change their passwords. If
a non-manage level user logs in to change the password but the time elapsed since the last change
is less than this interval, the system denies the request. For example, if you set this interval to 48
hours, a non-manage level user cannot change the password twice within 48 hours. This prevents
users from changing their passwords frequently.
This function is not effective on users of the manage level. For information about user levels, see
Fundamentals Configuration Guide.
This function is not effective on a user who is prompted to change the password at the first login or
a user whose password has just been aged out.
Password aging
Password aging imposes a lifecycle on a user password. After the password aging time expires,
the user needs to change the password.
If a user enters an expired password when logging in, the system displays an error message and
prompts the user to provide a new password and to confirm it by entering it again. The new
password must be a valid one and the user must enter exactly the same password when confirming
it.
Early notice on pending password expiration

When a user logs in, the system checks whether the password will expire in a time equal to or less
than the specified notification period. If so, the system notifies the user when the password will
expire and provides a choice for the user to change the password. If the user sets a new password
that is complexity-compliant, the system records the new password and the setup time. If the user
chooses not to change the password or the user fails to change it, the system allows the user to log
in using the current password.
Telnet, SSH, and terminal users (log in to the device through console or AUX interfaces) can
change their passwords by themselves, but FTP users can only have their passwords changed by
the administrator.
Login with an expired password

You can allow a user to log in a certain number of times within a specific period of time after the
password expires, so that the user does not need to change the password immediately. For
example, if you set the maximum number of logins with an expired password to 3 and the time
period to 15 days, a user can log in three times within 15 days after the password expires.
250
Password history
With this feature enabled, the system maintains certain entries of passwords that a user has used.
When a user changes the password, the system checks the new password against the used ones.
The new password must be different from the used ones by at least four characters and the four
characters must not be the same. Otherwise, the user will fail to change the password and the
system displays an error message.
You can set the maximum number of history password records for the system to maintain for each
user. When the number of history password records exceeds your setting, the latest record
overwrites the earliest one.
Login attempt limit

Limiting the number of consecutive failed login attempts can effectively prevent password
guessing.
If an FTP or VTY user fails authentication due to a password error, the system adds the user to a
password control blacklist. If a user fails to provide the correct password after the specified
number of consecutive attempts, the system takes action as configured:
{
Prohibiting the user from logging in until the user is removed from the password control blacklist
manually.
Allowing the user to try continuously and removing the user from the password control blacklist
when the user logs in to the system successfully or the blacklist entry times out (a blacklist entry
times out after 1 minute).
Prohibiting the user from logging in within a configurable period of time, and allowing the user
to log in again after the period of time elapses or the user is removed from the password control
blacklist.
A password control blacklist can contain up to 1024 entries.

A login attempt using a wrong username will undoubtedly fail, but the username will not be added
into the password control blacklist.
Users accessing the system through the console or AUX interface are not blacklisted, because the
system is unable to obtain the IP addresses of these users and these users are privileged and
therefore relatively secure to the system.
Password composition policy

A password can be a combination of characters from the following four types:
{
Uppercase letters A to Z.
Lowercase letters a to z.
Digits 0 to 9.
Special characters. For information about special characters, see the password command in
Security Command Reference.
Depending on the system's security requirements, you can set the minimum number of character
types a password must contain and the minimum number of characters for each type, as shown
in Table 13.
Table 13 Password composition policy
Password combination
level
Minimum number of
character types
Minimum number of characters for

each type
Level 1
One
One
Level 2
Two
One
251
Password combination
level
Minimum number of
character types
Minimum number of characters for

each type
Level 3
Three
One
Level 4
Four
One
In non-FIPS mode, all the combination levels are available for a password. In FIPS mode, only the
level 4 combination is available for a password.
When a user sets or changes a password, the system checks if the password meets the composition
requirement. If not, the system displays an error message.
Password complexity checking policy

A less complicated password such as a password containing the username or repeated characters
is more likely to be cracked. For higher security, you can configure a password complexity
checking policy to make sure all user passwords are relatively complicated. With such a policy
configured, when a user configures a password, the system checks the complexity of the password.
If the password is complexity-incompliant, the system refuses the password and displays a
password configuration failure message.
You can impose the following password complexity requirements:
{
A password cannot contain the username or the reverse of the username. For example, if the
username is abc, a password such as abc982 or 2cba is not complex enough.
No character of the password appears three or more times consecutively. For example,
password a111 is not complex enough.
Password display in the form of a string of asterisks (*)

For the sake of security, the password a user enters is displayed in the form of a string of asterisks
(*).
Authentication timeout management

Authentication timeout management is only for Telnet and Terminal users.
The authentication period is from when the server obtains the username to when the server finishes
authenticating the user's password. If a user fails to log in within the configured period of time, the
system tears down the connection.
Maximum account idle time

You can set the maximum account idle time so that accounts staying idle for this period of time
become invalid. For example, if you set the maximum account idle time to 60 days and the user of
the account test has not logged in successfully within 60 days after the last successful login, the
account becomes invalid and the user is unable to log in again.
Logging
The system logs all successful password changing events and the events of adding users to the
password control blacklist.
FIPS compliance
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
252
Password control configuration task list

The password control functions can be configured in several views, and different views support different
functions. The settings configured in different views or for different objects have different application
ranges and different priorities:
Global settings in system view apply to all local user passwords and super passwords.
Settings in user group view apply to the passwords of all local users in the user group.
Settings in local user view apply to only the password of the local user.
Settings for super passwords apply to only super passwords.
The previous four types of settings have the following priorities:
For local user passwords, the settings with a smaller application scope have a higher priority.
For super passwords, the settings configured specifically for super passwords, if any, override those
configured in system view.
To configure password control:

Task at a glance
(Required.) Enabling password control
(Optional.) Setting global password control parameters
(Optional.) Setting user group password control parameters
(Optional.) Setting local user password control parameters
(Optional.) Setting super password control parameters
(Optional.) Setting a local user password in interactive mode
Enabling password control

1.
Enable the global password control feature in system view.

Password control configurations take effect only after the password control feature is enabled
globally.
2.
Enable password control functions individually.

The following password control functions need to be enabled individually after the password
control feature is enabled globally:
{
Password aging
Minimum password length
Password history
Password composition checking
To enable password control:

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
253
Step
Command
Remarks
In non-FIPS mode, the global
2.
3.
password control feature is

disabled by default.
Enable the global password

control feature.
password-control enable
Enable a specific password

control function.
password-control { aging |
composition | history | length }
enable
In FIPS mode, the global
password control feature is

enabled and cannot be
disabled by default.
Optional.
By default, all of the four password
control functions are enabled.
After global password control is enabled, local user passwords configured on the device are not
displayed when you use the corresponding display command.
Setting global password control parameters

The password-control login-attempt command takes effect immediately and can affect the users already
in the password control blacklist. Other password control configurations do not take effect on users that
have been logged in or passwords that have been configured.
To set global password control parameters:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set the password aging time.
password-control aging aging-time
3.

update interval.
password-control password
update interval interval

length.
4.
Optional.
90 days by default.
Optional.
24 hours by default.
Optional.
10 characters by default.
Optional.
In non-FIPS mode, a default

5.
6.

composition policy.

complexity checking policy.
password-control complexity
{ same-character | user-name }
check
254
password must contain at least

one character type and at least
one character for each type.
In FIPS mode, a default
password must contain at least

four character types and at
least one character for each
type.
Optional.
By default, the system does not
perform password complexity
checking.
Step
7.
8.
9.

history password records for
each user.
Command
Remarks
password-control history
max-record-num
Optional.
4 by default.
Optional.
Specify the maximum number

of login attempts and the
action to be taken when a
user fails to log in after the
specified number of attempts.
password-control login-attempt
login-times [ exceed { lock |
lock-time time | unlock } ]
By default, the maximum number

of login attempts is 3 and a user
failing to log in after the specified
number of attempts must wait for 1
minute before trying again.
Set the number of days during

which the user is notified of
the pending password
expiration.
password-control
alert-before-expire alert-time
Optional.
7 days by default.
Optional.
10. Set the maximum number of

days and maximum number
of times that a user can log in
after the password expires.
password-control
expired-user-login delay delay
times times
11. Set the authentication timeout

time.
password-control
authentication-timeout
authentication-timeout
Optional.
12. Set the maximum account idle

time.
password-control login idle-time

idle-time
Optional.
By default, a user can log in three

times within 30 days after the
password expires.
90 days by default.
Setting user group password control parameters

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and enter

user group view.
user-group group-name
N/A
3.

aging time for the user group.
Optional.
By default, the aging time of the

user group is the same as the
global password aging time.
Optional.
4.
Configure the minimum

password length for the user
group.

composition policy for the
user group.
By default, the minimum password

length of the user group is the same
as the global minimum password
length.
Optional.
5.
255
By default, the password

composition policy of the user
group is the same as the global
password composition policy.
Setting local user password control parameters

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a local user and enter

local user view.
N/A
Optional.
3.

aging time for the local user.
By default, the setting equals that

for the user group to which the
local user belongs. If no aging time
is configured for the user group,
the global setting applies to the
local user.
Optional.
4.
Configure the minimum

password length for the local
user.
By default, the setting equals that

local user belongs. If no minimum
password length is configured for
the user group, the global setting
applies to the local user.
Optional.
5.

composition policy for the
local user.
By default, the settings equal those

local user belongs. If no password
composition policy is configured
for the user group, the global
settings apply to the local user.
Setting super password control parameters

CLI commands include four levels: visit, monitor, system, and manage, in ascending order. Accordingly,
login users include four levels, each corresponding to a command level. A user of a certain level can only
use the commands at that level or lower levels.
To switch from a lower user level to a higher one, a user needs to enter a password for authentication.
This password is called a super password. For more information on super passwords, see Fundamentals
To set super password control parameters:
Step
1.
Enter system view.
2.
Set the password aging time

for super passwords.
Command
Remarks
system-view
N/A
Optional.
password-control super aging

aging-time
256
By default, the super password

aging time is the same as the
global password aging time.
Step
Command
Remarks
Optional.
3.
Configure the minimum length

for super passwords.
password-control super length

length
4.

composition policy for super
passwords.
password-control super
composition type-number
type-number [ type-length
type-length ]
By default, the minimum super

password length is the same as the
global minimum password length.
Optional.
By default, the super password
composition policy is the same as
the global password composition
policy.
Setting a local user password in interactive mode

You can set a password for a local user in interactive mode. When doing so, you need to confirm the
password.
To set a password for a local user in interactive mode:
Step
Command
1.
Enter system view.
system-view
2.
Create a local user and enter local user view.
3.
Set the password for the local user in interactive mode.
password
Displaying and maintaining password control

Task
Command
Remarks
Display password control

configuration information.
display password-control [ super ]

Display information about users in

the password control blacklist.
display password-control blacklist

[ user-name name | ip
ipv4-address | ipv6 ipv6-address ]
Delete users from the password

control blacklist.
reset password-control blacklist

{ all | user-name name }

Clear history password records.
reset password-control
history-record [ user-name name |
super [ level level ] ]
257
This command can delete the

history password records of one or
all users even when the password
history function is disabled.
Password control configuration example

Configure a global password control policy to meet the following requirements:
An FTP or VTY user failing to provide the correct password in two successive login attempts is
permanently prohibited from logging in.
A user can log in five times within 60 days after the password expires.
The password expires after 30 days.
The minimum password update interval is 36 hours.
An account becomes invalid if it has been idle for 30 days.
A password cannot contain the username or the reverse of the username.
No character occurs consecutively three or more times in a password.
Configure a super password control policy to meet the following requirements: A super password must
contain at least three character types and at least five characters for each type.
Configure a password control policy for the local Telnet user test to meet the following requirements:
The password must contain at least 12 characters.
The password must contain at least two character types and at least five characters for each type.
The password for the local user expires after 20 days.
# Enable the password control feature globally.
<AC> system-view
[AC] password-control enable
# Prohibit the user from logging in forever after two successive login failures.
[AC] password-control login-attempt 2 exceed lock
# Globally set all passwords to expire after 30 days.

[AC] password-control aging 30
# Set the minimum password update interval to 36 hours.

[AC] password-control password update interval 36
# Specify that a user can log in five times within 60 days after the password expires.
[AC] password-control expired-user-login delay 60 times 5
# Set the maximum account idle time to 30 days.

258
[AC] password-control login idle-time 30
# Refuse any password that contains the username or the reverse of the username.
[AC] password-control complexity user-name check
# Specify that no character can appear three or more times consecutively in a password.
[AC] password-control complexity same-character check
# Specify that a super password must contain at least three character types and at least five characters
for each type.
[AC] password-control super composition type-number 3 type-length 5
# Configure a super password.

[AC] super password level 3 simple 12345ABGFTweuix
# Create a local user named test.

[AC] local-user test
# Set the service type of the user to Telnet.

[AC-luser-test] service-type telnet
# Set the minimum password length to 12 for the local user.

[AC-luser-test] password-control length 12
# Specify that the password of the local user must contain at least two character types and at least five
characters for each type.
[AC-luser-test] password-control composition type-number 2 type-length 5
# Set the password for the local user to expire after 20 days.
[AC-luser-test] password-control aging 20
# Configure the password of the local user in interactive mode.

[AC-luser-test] password
Password:***********
Confirm :***********
Updating user(s) information, please wait........
[AC-luser-test] quit

# Display the global password control configuration.
<AC> display password-control
Global password control configurations:
Password control:
Enabled
Password aging:
Enabled (30 days)
Password length:
Enabled (10 characters)
Password composition:
Enabled (1 types,
Password history:
Enabled (max history record:4)
1 characters per type)
Early notice on password expiration: 7 days

User authentication timeout:
60 seconds
Maximum failed login attempts:
2 times
Login attempt-failed action:
Lock
Minimum password update time:
36 hours
User account idle-time:
30 days
Login with aged password:
5 times in 60 day(s)
Password complexity:
Enabled (username checking)
259
Enabled (repeated characters checking)
# Display the password control configuration for super passwords.

<AC> display password-control super
Super password control configurations:
Password aging:
Enabled (30 days)
Password length:
Enabled (3 types,
# Display the password control configuration for local user test.

<AC> display local-user user-name test
The contents of local user test:
State:
Active
ServiceType:
telnet
Access-limit:
Disable
User-group:
system
Current AccessNum: 0
Bind attributes:
Authorization attributes:
Password aging:
Enabled (20 days)
Password length:
Enabled (2 types,
Total 1 local user(s) matched.
260
Managing public keys

To protect data confidentiality during transmission, the data sender uses an algorithm and a key to
encrypt the plain text data before sending the data out. The receiver uses the same algorithm with the
help of a key to decrypt the data, as shown in Figure 100.
Figure 100 Encryption and decryption
The keys that participate in the conversion between plain text and cipher text can be the same or different,
dividing the encryption and decryption algorithms into the following types:
Symmetric key algorithmThe keys for encryption and decryption are the same.
Asymmetric key algorithmThe keys for encryption and decryption are different. One is the public
key, and the other is the private key. The information encrypted with the public key can only be
decrypted with the corresponding private key, and vice versa. The private key is kept secret, and the
public key may be distributed widely. The private key cannot be practically derived from the public
key. The device supports RSA and DSA asymmetric key algorithms.
The asymmetric key algorithms can be used for the following purposes:
To encrypt and decrypt dataAny public key receiver can use the public key to encrypt information,
but only the private key owner can decrypt the information. This mechanism ensures confidentiality.
To authenticate a senderAlso called "digital signature." The key owner uses the private key to
"sign" information to be sent, and the receiver decrypts the information with the sender's public key
to verify information authenticity.
Asymmetric key algorithms are widely used in various applications. For example, SSH, SSL, and PKI use
the algorithms for digital signature. For information about SSH, SSL, and PKI, see "Configuring SSH,"
"Configuring SSL," and "Configuring PKI."

Public key configuration tasks enable you to manage the local asymmetric key pairs and configure the
peer host public keys on the local device. By completing these tasks, the local device is ready to work
with applications such as SSH and SSL to implement data encryption/decryption, or digital signature.
Complete these tasks to configure public keys:
Task
Configuring a local
asymmetric key pair on the
local device
Remarks
Creating a local asymmetric key pair
Displaying or exporting the local host public key
Destroying a local asymmetric key pair
261
Choose one or more

tasks.
Task
Remarks
Specifying the peer public key on the local device
Creating a local asymmetric key pair

When you create a local asymmetric key pair, follow these guidelines:
The key algorithm must be the same as required by the security application.
The key modulus length must be appropriate (see Table 14).
Table 14 A comparison of different types of asymmetric key algorithms

Type
Number of key pairs
Modulus length
Remarks
In non-FIPS mode: 512 to
RSA
Two key pairs, one server key

pair and one host key pair.
Each key pair contains a public
key and a private key
To achieve high
security, specify at least
768 bits in non-FIPS
mode.
2048 bits and defaults to

1024 bits.
In FIPS mode: 2048 bits.

In non-FIPS mode: 512 to
DSA
2048 bits and defaults to

1024 bits.
One key pair, the host key pair.
In FIPS mode: 2048 bits.
To achieve high
security, specify at least
768 bits in non-FIPS
mode.
IMPORTANT:
Only SSH1.5 uses the RSA server key pair.
To create a local asymmetric key pair:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, no asymmetric key pair exists.
2.
Create a local
asymmetric key pair.
public-key local create { dsa

| rsa }
If the type of the key pair to be created already

exists, the system asks you whether you want to
overwrite the existing key pair.
The created key pairs are automatically saved
and can survive system reboots.
Displaying or exporting the local host public key

In some applications, such as SSH, to allow your local device to be authenticated by a peer device
through digital signature, you must display or export the local host public key, which will then be
specified on the peer device.
To display or export the local host public key, choose one of the following methods:
Displaying and recording the host public key information
Displaying the host public key in a specific format and saving it to a file
Exporting the host public key in a specific format to a file

262
If your local device functions to authenticate the peer device, you must specify the peer public key on the
local device. For more information, see "Specifying the peer public key on the local device."
Displaying and recording the host public key

information
Task
Command
Remarks
Display the local RSA public keys.
display public-key local rsa public [ | { begin

Display the local DSA public keys.
display public-key local dsa public [ | { begin

Use at least one

command.
The display public-key local rsa public command displays both the RSA server and host public keys.
Recording the RSA host public key is enough.
After you display the host public key, record the key information for manual configuration of the key on
the peer device.
Displaying the host public key in a specific format

and saving it to a file
After you display the host public key in a specific format, save the key to a file, and transfer the file to the
peer device.
To display a local host public key in a specific format:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Display the local RSA host public key in a specific

format:
{
2.
Display the local host

public key in a specific
format.
In non-FIPS mode:
public-key local export rsa { openssh | ssh1 |
ssh2 }
In FIPS mode:
public-key local export rsa { openssh | ssh2 }
Use at least one

command.
Display the local DSA host public key in a specific

format:
public-key local export dsa { openssh | ssh2 }
Exporting the host public key in a specific format to

a file
After you export a host public key in a specific format to a file, transfer the file to the peer device.
263
To export a local host public key in a specific format to a file:

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Export a local RSA host public key in a specific

format to a file:
{
2.
Export a local host

public key in a specific
format to a file.
In non-FIPS mode:
public-key local export rsa { openssh | ssh1 |
ssh2 } filename
In FIPS mode:
public-key local export rsa { openssh | ssh2 }
filename
Use at least one

command.
Export a local DSA host public key in a specific

format to a file:
public-key local export dsa { openssh | ssh2 }
filename
Destroying a local asymmetric key pair

You might have to destroy a local asymmetric key pair and generate a new pair when an intrusion event
has occurred, the storage media of the device is replaced, the asymmetric key has been used for a long
time, or the local certificate expires. For more information about the local certificate, see "Configuring
PKI."
To destroy a local asymmetric key pair:
Step
Command
1.
Enter system view.
system-view
2.
Destroy a local asymmetric key pair.
public-key local destroy { dsa| rsa }
Specifying the peer public key on the local device

In SSH, to enable the local device to authenticate a peer device, specify the peer public key on the local
device. The device supports up to 20 peer public keys.
For information about displaying or exporting the host public key, see "Displaying or exporting the local
host public key."
264
To specify the peer public key on the local device:

Method
Import the public key
from a public key file
(recommended)
Prerequisites
Remarks
1.
Save the host public key of the intended

asymmetric key pair in a file.
2.
Transfer a copy of the file through FTP

or TFTP in binary mode to the local
device.
Display and record the public key of the

intended asymmetric key pair.
Manually configure
the public keyinput
or copy the key data
If the peer device is an H3C device, use

the display public-key local public
command to view and record its public
key. A public key displayed by other
methods for the H3C device might not be
in a correct format.
During the import process, the system

automatically converts the public key to
a string in Public Key Cryptography
Standards (PKCS) format.
The recorded public key must be in

the correct format. Otherwise, the
manual configuration of a
format-incompliant public key will
fail.
Always use the first method if you

are not sure about the format of the
recorded public key.
To import the host public key from a public key file to the local device:
Step
Command
1.
Enter system view.
system-view
2.
Import the host public key from the public key file.
public-key peer keyname import sshkey filename
To manually configure the peer public key on the local device:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a name for the public

key and enter public key view.
public-key peer keyname
N/A
3.
Enter public key code view.
public-key-code begin
N/A
4.
Configure the peer public key.
Type or copy the key
Spaces and carriage returns are allowed

between characters.
5.
Return to public key view.
public-key-code end
When you exit public key code view, the

system automatically saves the public key.
6.
peer-public-key end
N/A
Displaying public keys

Task
Command
Remarks
Display the local public keys
display public-key local { dsa| rsa } public

Display the specified or all peer

public keys on the local device.
display public-key peer [ brief | name

publickey-name ] [ | { begin | exclude |
265
Public key configuration examples

Manually specifying the peer public key on the local device

As shown in Figure 101, to prevent illegal access, the AC authenticates the device (the peer device)
through a digital signature. Before configuring authentication parameters on the device, configure the
public key of the device on the AC.
Configure the AC to use the asymmetric key algorithm of RSA to authenticate the device.
Manually specify the host public key of the device's public key pair on the AC.
1.
Configure the device:

# Create local RSA key pairs on the device, setting the modulus length to the default, 1024 bits.
<Device> system-view
[Device] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.

[Device] display public-key local rsa public
266
=====================================================
Time of Key pair created: 09:50:06
2013/08/07
Key name: HOST_KEY

Key type: RSA Encryption Key
=====================================================
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7
66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA32647
0034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
=====================================================
2013/08/07
Key name: SERVER_KEY

=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB6158E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B44
90DACBA3CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0
203010001
2.
Configure the AC:

# Configure the host public key of the device's RSA key pairs on the AC. In public key code view,
enter the host public key of the device. The host public key is the content of HOST_KEY displayed
on the device by using the display public-key local rsa public command.
<AC> system-view
[AC] public-key peer device
Public key view: return to System View with "peer-public-key end".
[AC-pkey-public-key] public-key-code begin
Public key code view: return to last view with "public-key-code end".
[AC-pkey-key-code]30819F300D06092A864886F70D010101050003818D0030818902818100D9000
3FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51
E5E353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14AB
C62DB125035EA326470034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B
2BF9C4A10203010001
[AC-pkey-key-code] public-key-code end
[AC-pkey-public-key] peer-public-key end
# Display the host public key of the device saved on the AC.
[AC] display public-key peer name device
=====================================
Key Name
: device
Key Type
: RSA
Key Module: 1024

=====================================
Key Code:
267
The output shows that the host public key of the device saved on the AC is consistent with the one
created on the device.
Importing a public key from a public key file

As shown in Figure 102, to prevent illegal access, the AC (the local device) authenticates the device (the
peer device) through a digital signature. Before configuring authentication parameters on the device,
configure the public key of the device on the AC
Configure the AC to use the asymmetric key algorithm of RSA to authenticate Device A.
Import the host public key of the device from the public key file to the AC.
1.
Create key pairs on the device and export the host public key:
# Create local RSA key pairs on the device, setting the modulus length to the default, 1024 bits.
[Device] public-key local create rsa
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.

[Device] display public-key local rsa public
=====================================================
2013/08/07
Key name: HOST_KEY

=====================================================
Key code:
=====================================================
268
2013/08/07
Key name: SERVER_KEY

=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB6158E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B44
90DACBA3CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0
203010001
# Export the RSA host public key HOST_KEY to a file named device.pub.
[Device] public-key local export rsa ssh2 device.pub
2.
Enable the FTP server function on the device:

# Enable the FTP server function, and create an FTP user with the username ftp, password 123, and
user level 3. This user level makes sure the user has the permission to perform FTP operations.
[Device] ftp server enable
[Device] local-user ftp
[Device-luser-ftp] password simple 123
[Device-luser-ftp] service-type ftp
[Device-luser-ftp] authorization-attribute level 3
[Device-luser-ftp] quit
3.
On the AC, get the public key file of the device:

# From the AC, use FTP to log in to the device, and get the public key file device.pub with the file
transfer mode of binary.
<AC> ftp 10.1.1.1
Trying 10.1.1.1 ...
Press CTRL+K to abort
Connected to 10.1.1.1.
220 FTP service ready.
User(10.1.1.1:(none)):ftp
331 Password required for ftp.
Password:
230 User logged in.
[ftp] binary
200 Type set to I.
[ftp] get device.pub
227 Entering Passive Mode (10,1,1,1,5,148).
125 BINARY mode data connection already open, transfer starting for /device.pub.
226 Transfer complete.
FTP: 299 byte(s) received in 0.189 second(s), 1.00Kbyte(s)/sec.
[ftp] quit
221 Server closing.
4.
Import the host public key of the device to the AC:

# Import the host public key of the device from the key file device.pub to the AC.
<AC> system-view
[AC] public-key peer device import sshkey device.pub
# Display the host public key of the device on the AC.
269
[AC] display public-key peer name device
=====================================
Key Name
: device
Key Type
: RSA
Key Module: 1024

=====================================
Key Code:
The output shows that the host public key of the device saved on the AC is consistent with the one
created on the device.
270
Configuring PKI
Overview
The PKI uses a general security infrastructure to provide information security through public key
technologies.
PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key
pair consists of a private key and a public key. The private key must be kept secret, but the public key
needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other.
A key problem with PKI is how to manage the public keys. PKI employs the digital certificate mechanism
to solve this problem. The digital certificate mechanism binds public keys to their owners, helping
distribute public keys in large networks securely.
With digital certificates, the PKI system provides network communication and e-commerce with security
services such as user authentication, data non-repudiation, data confidentiality, and data integrity.
HP's PKI system provides certificate management for IPsec and SSL.
PKI terms
Digital certificate
A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the
identity information of the entity, the public key of the entity, the name and signature of the CA, and the
validity period of the certificate, where the signature of the CA ensures the validity and authority of the
certificate. A digital certificate must comply with the international standard of ITU-T X.509. The most
common standard is X.509 v3.
This document involves local certificate and CA certificate. A local certificate is a digital certificate
signed by a CA for an entity, and a CA certificate is the certificate of a CA. If multiple CAs are trusted
by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root
CA has a CA certificate signed by itself and each lower level CA has a CA certificate signed by the CA
at the next higher level.
CRL
An existing certificate might need to be revoked when, for example, the username changes, the private
key leaks, or the user stops the business. Revoking a certificate will remove the binding of the public key
with the user identity information. In PKI, the revocation is made through certificate revocation lists (CRLs).
Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have
been revoked. The CRLs contain the serial numbers of all revoked certificates and provide an effective
way for checking the validity of certificates.
A CA might publish multiple CRLs when the number of revoked certificates is so large that publishing
them in a single CRL might degrade network performance, and it uses CRL distribution points to indicate
the URLs of these CRLs.
271
CA policy
A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking
certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice
statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and
email. Because different CAs might use different methods to examine the binding of a public key with an
entity, make sure you understand the CA policy before selecting a trusted CA for certificate request.
PKI architecture
A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown
in Figure 103.
Figure 103 PKI architecture
Entity
An entity is an end user of PKI products or services, such as a person, an organization, a device like a
router or a switch, or a process running on a computer.
CA
A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues
certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing
CRLs.
RA
A registration authority (RA) is an extended part of a CA or an independent authority. An RA can
implement functions including identity authentication, CRL management, key pair generation and key
pair backup. The PKI standard recommends that an independent RA be used for registration
management to achieve higher security of application systems.
PKI repository
A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database.
It stores and manages information like certificate requests, certificates, keys, CRLs and logs when it
provides a simple query function.
LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user information
and digital certificates from the RA server and provides directory navigation service. From an LDAP server,
an entity can obtain local and CA certificates of its own as well as certificates of other entities.
272
PKI operation
In a PKI-enabled network, an entity can request a local certificate from the CA, and the device can check
the validity of certificates. Here is how it works:
1.
An entity submits a certificate request to the RA.
2.
The RA reviews the identity of the entity, and then sends the identity information and the public key
with a digital signature to the CA.
3.
The CA verifies the digital signature, approves the application, and issues a certificate.
4.
The RA receives the certificate from the CA, sends it to the LDAP server or other distribution points
to provide directory navigation service, and notifies the entity that the certificate is successfully
issued.
5.
The entity retrieves the certificate. With the certificate, the entity can communicate with other
entities safely through encryption and digital signature.
6.
The entity makes a request to the CA when it needs to revoke its certificate. The CA approves the
request, updates the CRLs and publishes the CRLs on the LDAP server or other distribution points.
PKI applications
The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI
has a wide range of applications. The following lists some common application examples:
VPNA VPN is a private data communication network built on the public communication
infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec) in
conjunction with PKI-based encryption and digital signature technologies for confidentiality.
Secure emailEmails require confidentiality, integrity, authentication, and non-repudiation. PKI

can address these needs. The secure email protocol that is developing rapidly is S/MIME, which is
based on PKI and allows for transfer of encrypted mails with signature.
Web securityFor web security, two peers can establish an SSL connection first for transparent and
secure communications at the application layer. With PKI, SSL enables encrypted communications
between a browser and a server. Both of the communication parties can verify each other's identity
through digital certificates.
PKI configuration task list

Task
Remarks
Configuring a PKI entity
Required.
Configuring a PKI domain
Required.
Requesting a certificate
Configuring automatic certificate request
Required.
Manually requesting a certificate
Use either method.
Obtaining certificates
Optional.
Verifying PKI certificates
Optional.
Destroying the local RSA key pair
Optional.
Removing a certificate
Optional.
273
Task
Remarks
Configuring a certificate access control policy
Optional.
Configuring a PKI entity

A certificate is the binding of a public key and the identity information of an entity, where the identity
information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant
uniquely by entity DN.
An entity DN is defined by these parameters:
Common name of the entity.
Country code of the entity, a standard 2-character code. For example, CN represents China and US
represents the United States.
FQDN of the entity, a unique identifier of an entity on the network. It consists of a host name and
a domain name and can be resolved to an IP address. For example, www.whatever.com is an
FQDN, where www is a host name and whatever.com a domain name.
IP address of the entity.
Locality where the entity resides.
Organization to which the entity belongs.
Unit of the entity in the organization.
State where the entity resides.
The configuration of an entity DN must comply with the CA certificate issue policy. You need to determine,
for example, which entity DN parameters are mandatory and which are optional. Otherwise, certificate
requests might be rejected.
To configure a PKI entity:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create an entity and enter its

view.
pki entity entity-name
3.
Configure the common name

for the entity.
common-name name
Configure the country code

for the entity.
country country-code-str
Configure the FQDN for the

entity.
fqdn name-str
Configure the IP address for

the entity.
ip ip-address
Configure the locality for the

entity.
locality locality-name
4.
5.
6.
7.
No entity exists by default.
274
You can create up to two entities on a

device.
Optional.
No common name is specified by default.
Optional.
No country code is specified by default.
Optional.
No FQDN is specified by default.
Optional.
No IP address is specified by default.
Optional.
No locality is specified by default.
Step
8.
9.
Command
Configure the organization
name for the entity.
organization org-name
Configure the unit name for

the entity.
organization-unit
org-unit-name
10. Configure the state or

province for the entity.
Remarks
Optional.
No organization is specified by default.
Optional.
No unit is specified by default.
Optional.
state state-name
No state or province is specified by

default.
NOTE:
The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the entity
DN in a certificate request goes beyond a certain limit, the server will not respond to the certificate request.
Configuring a PKI domain

Before requesting a PKI certificate, an entity needs to be configured with some enrollment information,
which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other
applications like IKE and SSL, and has only local significance. The PKI domain configured on a device
is invisible to the CA and other devices, and each PKI domain has its own parameters.
A PKI domain is defined by these parameters:
Trusted CAAn entity requests a certificate from a trusted CA.
EntityA certificate applicant uses an entity to provide its identity information to a CA.
RAGenerally, an independent RA is in charge of certificate request management. It receives the

registration request from an entity, examines its qualification, and determines whether to ask the CA
to sign a digital certificate. The RA only examines the application qualification of an entity. It does
not issue any certificate. Sometimes, the registration management function is provided by the CA,
in which case no independent RA is required. HP recommends you to deploy an independent RA.
URL of the registration serverAn entity sends a certificate request to the registration server
through SCEP, a dedicated protocol for an entity to communicate with a CA.
Polling interval and countAfter an applicant makes a certificate request, the CA might need a
long period of time if it verifies the certificate request manually. During this period, the applicant
needs to query the status of the request periodically to get the certificate as soon as possible after
the certificate is signed. You can configure the polling interval and count to query the request status.
IP address of the LDAP serverAn LDAP server is usually deployed to store certificates and CRLs.
If this is the case, you need to configure the IP address of the LDAP server.
Fingerprint for root certificate verificationAfter receiving the root certificate of the CA, an entity
needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate
content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not
match the one configured for the PKI domain, the entity will reject the root certificate.
To configure a PKI domain:

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
275
Step
2.
Command
Create a PKI domain and
enter its view.
Remarks
No PKI domain exists by default.
pki domain domain-name
You can configure up to 32 PKI domains

on a device.
No trusted CA is specified by default.
3.
Specify the trusted CA.
ca identifier name
The CA name is required only when you

obtain a CA certificate. It is not used for
local certificate request.
4.
Specify the entity for

certificate request.
certificate request entity

entity-name
No entity is specified by default.
5.
Specify the authority for

certificate request.
certificate request from { ca

| ra }
6.
Configure the URL of the

server for certificate request.
certificate request url

url-string
7.
Configure the polling interval

and attempt limit for querying
the certificate request status.
certificate request polling

{ count count | interval
minutes }
8.
Specify the LDAP server.
ldap-server ip ip-address
[ port port-number ]
[ version version-number ]
9.
Configure the fingerprint for

root certificate verification.
root-certificate fingerprint
{ md5 | sha1 } string
The specified entity must exist.

No authority is specified by default.
No URL is configured by default.
The URL does not support domain name
resolution.
Optional.
By default, the polling interval is 20
minutes, and the maximum number of
attempts is 50.
Optional.
No LDP server is specified by default.
Required when the certificate request
mode is auto and optional when the
certificate request mode is manual. In the
latter case, if you do not configure this
command, the fingerprint of the root
certificate must be verified manually.
No fingerprint is configured by default.
Requesting a certificate
When you request a certificate for an entity, the entity introduces itself to the CA by providing its identity
information and public key, which will be the major components of the certificate. A certificate request
can be submitted to a CA in offline mode or online mode. In offline mode, a certificate request is
submitted to a CA by an out-of-band means such as phone, disk, or email.
Online certificate request falls into manual mode and auto mode.
Configuring automatic certificate request

In auto mode, an entity automatically requests a certificate from the CA server if it has no local certificate
for an application working with PKI. The entity requests the certificate through SCEP, and saves the local
certificate after retrieving it from the CA. If the PKI domain has no CA certificate before the entity submits
the certificate request, the entity automatically retrieves the CA certificate first.
276
If an automatically requested certificate will expire or has expired, the entity does not initiate a re-request
to the CA automatically, and the services using the certificate might be interrupted.
To configure automatic certificate request:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
N/A
3.
Set the certificate request

mode to auto.
certificate request mode auto [ key-length

key-length | password { cipher | simple }
password ] *
Manual by default.
Manually requesting a certificate

In manual mode, you must submit a local certificate request for an entity. Before the request, you must
obtain a CA certificate and generate a key pair for the PKI domain.
The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate.
Generating a key pair is an important step in certificate request. The key pair includes a public key and
a private key. The private key is kept by the user. The public key is transferred to the CA along with some
other information. For more information about RSA key pair configuration, see "Managing public keys."
If a PKI domain already has a local certificate, creating an RSA key pair might result in
inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the
local certificate, and then execute the public-key local create command. For more information
about the public-key local create command, see Security Command Reference.
A newly created key pair overwrites the existing one. If you perform the public-key local create
command in the presence of a local RSA key pair, the system asks you whether you want to
overwrite the existing one.
If a PKI domain already has a local certificate, you cannot request another certificate for it. This
helps avoid inconsistency between the certificate and the registration information resulting from
configuration changes. Before requesting a new certificate, use the pki delete-certificate command
to delete the existing local certificate and the CA certificate stored locally.
When it is impossible to request a certificate from the CA through SCEP, you can print the request
information or save the request information to a local file, and then send the printed information or
saved file to the CA by an out-of-band means. To print the request information, use the pki
request-certificate domain command with the pkcs10 keyword. To save the request information to
a local file, use the pki request-certificate domain command with the pkcs10 filename filename
option.
Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the
certificate is abnormal.
In FIPS mode, you cannot import MD5 certificates.
To manually request a certificate:
277
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Set the certificate request

mode to manual.
certificate request mode manual
4.
quit
N/A
5.
Retrieve a CA certificate
manually.
See "Obtaining certificates"
N/A
6.
Generate a local RSA key

pair.
public-key local create rsa
Submit a local certificate

request manually.
pki request-certificate domain

domain-name [ password ]
[ pkcs10 [ filename filename ] ]
7.
Optional.
Manual by default.
By default, no local RSA key pair

exists.
In FIPS mode, the RSA key modulus
length must be 2048 bits.
This command is not saved in the
configuration file.
Obtaining certificates
You can download CA certificates or local certificates from the CA server and save them locally. To do
so, use either the offline mode or the online mode. In offline mode, you must obtain a certificate by an
out-of-band means such as FTP, disk, or email, and then import it into the local PKI system.
Certificate retrieval serves the following purposes:
Locally store the certificates associated with the local security domain for improved query efficiency
and reduced query count.
Prepare for certificate verification.
Before retrieving a local certificate in online mode, make sure to complete LDAP server configuration.
If a PKI domain already has a CA certificate, you cannot obtain another CA certificate for it. This
restriction helps avoid inconsistency between the certificate and registration information resulting from
configuration changes. To obtain a new CA certificate, use the pki delete-certificate command to delete
the existing CA certificate and the local certificate first.
Be sure that the device system time falls in the validity period of the certificate so that the certificate is
valid.
To obtain certificates:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
In online mode:
2.
Retrieve a certificate
manually
pki retrieval-certificate { ca | local } domain

domain-name
In offline mode:
pki import-certificate { ca | local } domain

domain-name { der | p12 | pem } [ filename
filename ]
278
Use either command.

The pki
retrieval-certificate
configuration is not saved
in the configuration file.
Verifying PKI certificates

A certificate needs to be verified before you use it. Verifying a certificate examines that the certificate is
signed by the CA and that the certificate has neither expired nor been revoked.
You can specify whether CRL checking is required in certificate verification. If you enable CRL checking,
CRLs are used in verification of a certificate. In this case, make sure to obtain the CA certificate and CRLs
to the local device before the certificate verification. If you disable CRL checking, you only need to obtain
the CA certificate.
The CRL update period defines the interval at which the entity downloads CRLs from the CRL server. The
CRL update period setting manually configured on the device takes precedence over that carried in the
CRLs.
Verifying certificates with CRL checking

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
Optional.
3.
Specify the URL of the CRL

distribution point.
crl url url-string
No CRL distribution point URL is specified

by default.
The CRL distribution point URL does not
support DNS. Do not include domain
names in the URL.
Optional.
By default, the CRL update period
depends on the next update field in the
CRL file.
4.
Set the CRL update period.
crl update-period hours
5.
Enable CRL checking.
crl check enable
6.
quit
N/A
7.
Retrieve the CA certificate.
N/A
8.
Retrieve the CRLs.
pki retrieval-crl domain

domain-name
This command is not saved in the

configuration file.
9.
Verify the validity of a

certificate.
pki validate-certificate { ca |
local } domain domain-name
N/A
Optional.
Enabled by default.
Verifying certificates without CRL checking

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Disable CRL checking.
crl check disable
Enabled by default.
279
Step
Command
Remarks
4.
quit
N/A
5.
Retrieve the CA certificate.
N/A
6.
Verify the validity of the

certificate.
pki validate-certificate { ca | local }

domain domain-name
N/A
Destroying the local RSA key pair

A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate
is about to expire, you can destroy the old RSA key pair, and then create a pair to request a new
certificate.
To destroy the local RSA key pair:
Step
Command
1.
Enter system view.
system-view
2.
Destroy a local RSA key pair.
public-key local destroy rsa
Removing a certificate
When a certificate requested manually is about to expire or you want to request a new certificate, you
can delete the current local certificate or CA certificate.
To remove a certificate:
Step
Command
1.
Enter system view.
system-view
2.
Delete certificates.
pki delete-certificate { ca | local } domain domain-name
Configuring a certificate access control policy

By configuring a certificate access control policy, you can further control access to the server, providing
additional security for the server.
To configure a certificate access control policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a certificate attribute

group and enter its view.
pki certificate attribute-group

group-name
No certificate attribute group

exists by default.
280
Step
Command
Remarks
3.
Configure an attribute rule for

the certificate issuer name,
certificate subject name, or
alternative subject name.
attribute id { alt-subject-name
{ fqdn | ip } | { issuer-name |
subject-name } { dn | fqdn | ip } }
{ ctn | equ | nctn | nequ }
attribute-value
Optional.
4.
quit
N/A
5.
Create a certificate access

control policy and enter its
view.
pki certificate access-control-policy

policy-name
No access control policy exists by

default.
6.
Configure a certificate access

control rule.
rule [ id ] { deny | permit }

group-name
No restriction exists on the issuer

name, certificate subject name
and alternative subject name by
default.
No access control rule exists by

default.
A certificate attribute group must
exist to be associated with a rule.
Displaying and maintaining PKI

Task
Command
Remarks
Display the contents or request

status of a certificate.
display pki certificate { { ca | local }

domain domain-name |
request-status } [ | { begin |
exclude | include }
Display CRLs.
display pki crl domain

domain-name [ | { begin | exclude
Display information about one or

all certificate attribute groups.
display pki certificate

attribute-group { group-name |
all } [ | { begin | exclude |

all certificate access control
policies.
display pki certificate

access-control-policy { policy-name
| all } [ | { begin | exclude |
PKI configuration examples

IMPORTANT:
When the CA uses Windows Server, the SCEP add-on is required. You must use the certificate request
from ra command to specify that the entity requests a certificate from an RA.
When the CA uses RSA Keon, the SCEP add-on is not required. You must use the certificate request
from ca command to specify that the entity requests a certificate from a CA.
281
Certificate request from an RSA Keon CA server

As shown in Figure 104, the AC submits a local certificate request to the CA server.
The AC acquires the CRLs for certificate verification.
Configure the CA server

1.
Create a CA server named myca:

In this example, configure these basic attributes on the CA server:
{
{
NicknameName of the trusted CA.

Subject DNDN information of the CA, including the Common Name (CN), Organization Unit
(OU), Organization (O), and Country (C).
You can use the default values for the other attributes.
2.
Configure extended attributes:

Enter the management interface for the CA server, and do the following for the jurisdiction
configuration:
3.
Select the proper extension profiles.
Enable the SCEP autovetting function.
Specify the IP address list for SCEP autovetting.
Configure the CRL distribution behavior.

After completing the previous configuration, you must perform CRL related configurations. In this
example, select the local CRL distribution mode of HTTP and set the HTTP URL to
http://4.4.4.133:447/myca.crl.
282
Configure the AC
1.
Synchronize the system time of the AC with the CA server, so that the AC can correctly request a
certificate.
2.
Configure the entity name as aaa and the common name as name.
<AC> system-view
[AC] pki entity aaa
[AC-pki-entity-aaa] common-name name
[AC-pki-entity-aaa] quit
3.
Configure the PKI domain:

# Create PKI domain torsa and enter its view.
[AC] pki domain torsa
# Configure the name of the trusted CA as myca.

[AC-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port.

[AC-pki-domain-torsa] certificate request url http://4.4.4.133:446
# Set the registration authority to CA.

[AC-pki-domain-torsa] certificate request from ca
# Specify the entity for certificate request as aaa.

[AC-pki-domain-torsa] certificate request entity aaa
# Configure the URL for the CRL distribution point.

[AC-pki-domain-torsa] crl url http://4.4.4.133:447/myca.crl
[AC-pki-domain-torsa] quit
4.
Generate a local host key pair using RSA:

[AC] public-key local create rsa
Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
5.
Apply for certificates:

# Retrieve the CA certificate and save it locally.
[AC] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5
fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB
SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8
Is the finger print correct?(Y/N):y
Saving CA/RA certificates chain, please wait a moment......
CA certificates retrieval success.
283
# Retrieve CRLs and save them locally.

[AC] pki retrieval-crl domain torsa
Connecting to server for retrieving CRL. Please wait a while.....
CRL retrieval success!
# Request a local certificate manually.

[AC]pki request-certificate domain torsa
Certificate is being requested, please wait......
Enrolling the local certificate,please wait a while......
[AC]
Certificate request Successfully!
Saving the local certificate to device......
Done!

# Use the following command to view information about the local certificate acquired.
<AC> display pki certificate local domain torsa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9A96A48F 9A509FD7 05FFF4DF 104AD094
Signature Algorithm: sha1WithRSAEncryption
Issuer:
C=cn
O=org
OU=test
CN=myca
Validity
Not Before: Jan
8 09:26:53 2013 GMT
Not After : Jan
8 09:26:53 2013 GMT
Subject:
CN=aaa
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00D67D50 41046F6A 43610335 CA6C4B11
F8F89138 E4E905BD 43953BA2 623A54C0
EA3CB6E0 B04649CE C9CDDD38 34015970
981E96D9 FF4F7B73 A5155649 E583AC61
D3A5C849 CBDE350D 2A1926B7 0AE5EF5E
D1D8B08A DBF16205 7C2A4011 05F11094
73EB0549 A65D9E74 0F2953F2 D4F0042F
19103439 3D4F9359 88FB59F3 8D4B2F6C
2B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 CRL Distribution Points:
284
URI:http://4.4.4.133:447/myca.crl
836213A4 F2F74C1A 50F4100D B764D6CE
B30C0133 C4363F2F 73454D51 E9F95962
EDE9E590 E7458FA6 765A0D3F C4047BC2
9C391FF0 7383C4DF 9A0CCFA9 231428AF
987B029C C857AD96 E4C92441 9382E798
8FCC1E4A 3E598D81 96476875 E2F86C33
75B51661 B6556C5E 8F546E97 5197734B
C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C
You can also use some other display commands to view detailed information about the CA certificate
and CRLs. For more information about the display pki certificate ca domain and display pki crl domain
commands, see Security Command Reference.
Certificate request from a Windows 2003 CA server

As shown in Figure 105, configure PKI entity AC to request a local certificate from the CA server.
Configure the CA server

1.
Install the certificate server suites:

a. From the start menu, select Control Panel > Add or Remove Programs.
b. Select Add/Remove Windows Components > Certificate Services.
c. Click Next to begin the installation.
2.
Install the SCEP add-on:

The Windows 2003 server does not support SCEP by default. Install the SCEP add-on so that the
AC can register and obtain its certificate automatically. After the SCEP add-on installation
completes, a URL is displayed, which you must configure on the AC as the URL of the server for
certificate registration.
3.
Modify the certificate service attributes:

a. From the start menu, select Control Panel > Administrative Tools > Certificate Authority.
If you install the certificate service component and SCEP add-on successfully, there should be
two certificates issued by the CA to the RA.
b. In the navigation tree, right-click the CA server and select Properties > Policy Module.
285
c. Click Properties, and then select Follow the settings in the certificate template, if applicable.
Otherwise, automatically issue the certificate.
4.
Modify the Internet Information Services (IIS) attributes:

a. From the start menu, select Control Panel > Administrative Tools > Internet Information Services
(IIS) Manager.
b. From the navigation tree, select Web Sites.
c. Right-click Default Web Site and select Properties > Home Directory.
d. In the Local path box, specify the path for certificate service.
e. Specify an available port number as the TCP port number for the default website to avoid
conflict with existing services. In this example, port 8080 is used.
Configure the AC
1.
Synchronize the system time of the AC with the CA server, so that the AC can properly request a
certificate.
2.
Configure the entity DN:

# Configure the entity name as aaa and the common name as AC.
<AC> system-view
[AC] pki entity aaa
[AC-pki-entity-aaa] common-name AC
[AC-pki-entity-aaa] quit
3.
Configure the PKI domain:

# Create PKI domain torsa and enter its view.
[AC] pki domain torsa
# Configure the name of the trusted CA as myca.

[AC-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port/

certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA
server.
[AC-pki-domain-torsa] certificate request url
http://4.4.4.1:8080/certsrv/mscep/mscep.dll
# Set the registration authority to RA.

[AC-pki-domain-torsa] certificate request from ra
# Specify the entity for certificate request as aaa.

[AC-pki-domain-torsa] certificate request entity aaa
4.
Generate a local key pair using RSA:

Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
286
+++++++++++++++++++++++
5.
Apply for certificates:

# Retrieve the CA certificate and save it locally.
[AC] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5
fingerprint:766C D2C8 9E46 845B 4DCE 439C 1C1F 83AB
SHA1 fingerprint:97E5 DDED AB39 3141 75FB DB5C E7F8 D7D7 7C9B 97B4
Is the finger print correct?(Y/N):y

Saving CA/RA certificates chain, please wait a moment......
CA certificates retrieval success.
# Request a local certificate manually.

[AC] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[AC]
Enrolling the local certificate,please wait a while......
Certificate request Successfully!
Saving the local certificate to device......
Done!

# Use the following command to view information about the local certificate acquired.
<AC> display pki certificate local domain torsa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
48FA0FD9 00000000 000C
Issuer:
CN=CA server
Validity
Not Before: Nov 21 12:32:16 2013 GMT
Not After : Nov 21 12:42:16 2013 GMT
Subject:
CN=AC
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00A6637A 8CDEA1AC B2E04A59 F7F6A9FE
5AEE52AE 14A392E4 E0E5D458 0D341113
0BF91E57 FA8C67AC 6CE8FEBB 5570178B
10242FDD D3947F5E 2DA70BD9 1FAF07E5
1D167CE1 FC20394F 476F5C08 C5067DF9
287
CB4D05E6 55DC11B6 9F4C014D EA600306

81D403CF 2D93BC5A 8AF3224D 1125E439
78ECEFE1 7FA9AE7B 877B50B8 3280509F
6B
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B68E4107 91D7C44C 7ABCE3BA 9BF385F8 A448F4E1
X509v3 Authority Key Identifier:
keyid:9D823258 EADFEFA2 4A663E75 F416B6F6 D41EE4FE
X509v3 CRL Distribution Points:

URI:http://l00192b/CertEnroll/CA%20server.crl
URI:file://\\l00192b\CertEnroll\CA server.crl
Authority Information Access:
CA Issuers - URI:http://l00192b/CertEnroll/l00192b_CA%20server.crt
CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt
1.3.6.1.4.1.311.20.2:
.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e
81029589 7BFA1CBD 20023136 B068840B
(Omitted)
You can also use some other display commands to view detailed information about the CA certificate.
For more information about the display pki certificate ca domain command, see Security Command
Reference.
Certificate access control policy configuration example

As shown in Figure 106, the client accesses the remote HTTP Secure (HTTPS) server through the
HTTPS protocol.
SSL is configured to make sure that only legal clients log into the HTTPS server.
Create a certificate access control policy to control access to the HTTPS server.
288
For more information about SSL configuration, see "Configuring SSL."
The PKI domain to be referenced by the SSL policy must be created in advance. For more information
about PKI domain configuration, see "Configure the PKI domain" in Configure the AC.
1.
Configure the SSL policy for the HTTPS server to use:

<AC> system-view
[AC] ssl server-policy myssl
[AC-ssl-server-policy-myssl] pki-domain 1
[AC-ssl-server-policy-myssl] client-verify enable
[AC-ssl-server-policy-myssl] quit
2.
Configure the certificate attribute group:

# Create certificate attribute group mygroup1 and add two attribute rules. The first rule specifies
that the DN of the subject name includes the string aabbcc, and the second rule specifies that the
IP address of the certificate issuer is 10.0.0.1.
[AC] pki certificate attribute-group mygroup1
[AC-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc
[AC-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ 10.0.0.1
[AC-pki-cert-attribute-group-mygroup1] quit
# Create certificate attribute group mygroup2 and add two attribute rules. The first rule specifies
that the FQDN of the alternative subject name does not include the string of apple, and the second
rule specifies that the DN of the certificate issuer name includes the string aabbcc.
[AC] pki certificate attribute-group mygroup2
[AC-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple
[AC-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc
[AC-pki-cert-attribute-group-mygroup2] quit
3.
Configure the certificate access control policy

# Create the certificate access control policy of myacp and add two access control rules.
[AC] pki certificate access-control-policy myacp
[AC-pki-cert-acp-myacp] rule 1 deny mygroup1
[AC-pki-cert-acp-myacp] rule 2 permit mygroup2
[AC-pki-cert-acp-myacp] quit
4.
Apply the SSL server policy and certificate access control policy to HTTPS service and enable
HTTPS service.
# Apply SSL server policy myssl to HTTPS service.
[AC] ip https ssl-server-policy myssl
# Apply the certificate access control policy of myacp to HTTPS service.

[AC] ip https certificate access-control-policy myacp
# Enable HTTPS service.

[AC] ip https enable
289
Troubleshooting PKI
Failed to obtain the CA certificate
Symptom
Failed to obtain a CA certificate.
Analysis
The network connection is not proper. For example, the network cable might be damaged or loose.
No trusted CA is specified.
The URL of the registration server for certificate request is not correct or not configured.
No authority is specified for certificate request.
The system clock of the device is not synchronized with that of the CA.
1.
Make sure the network connection is physically proper.
2.
Check that the required commands are configured properly.
3.
Use the ping command to verify that the RA server is reachable.
4.
Specify the authority for certificate request.
5.
Synchronize the system clock of the device with that of the CA.
Solution
Failed to request local certificates

Symptom
Failed to request a local certificate.
Analysis
No CA certificate has been obtained.
The current key pair has been bound to a certificate.
No trusted CA is specified.
The URL of the registration server for certificate request is not correct or not configured.
No authority is specified for certificate request.
Some required parameters of the entity DN are not configured.
1.
2.
Retrieve a CA certificate.
3.
Regenerate a key pair.
4.
Specify a trusted CA.
Solution
290
5.
Use the ping command to verify that the RA server is reachable.
6.
Specify the authority for certificate request.
7.
Configure the required entity DN parameters.
Failed to obtain CRLs

Symptom
Failed to obtain CRLs.
Analysis
No CA certificate has been obtained before you try to obtain CRLs.
The IP address of LDAP server is not configured.
The CRL distribution URL is not configured.
The LDAP server version is wrong.
1.
2.
Retrieve a CA certificate.
3.
Specify the IP address of the LDAP server.
4.
Specify the CRL distribution URL.
5.
Re-configure the LDAP version.
Solution
291
Configuring SSH
Overview
Secure Shell (SSH) is a network security protocol. Using encryption and authentication, SSH implements
remote login and file transfer securely over an insecure network.
SSH uses the typical client-server model to establish a channel for secure data transfer based on TCP.
SSH includes two versions: SSH1.x and SSH2.0 (hereinafter referred to as SSH1 and SSH2), which are
not compatible. SSH2 is better than SSH1 in performance and security.
The device can work as an SSH server or as an SSH client. When acting as an SSH server, the device
provides services to SSH clients and supports the following SSH versions:
SSH2 and SSH1 in non-FIPS mode.
SSH2 in FIPS mode.
When acting as an SSH client, the device supports SSH2 only. It allows users to establish SSH
connections with an SSH server.
The device supports the following SSH applications:
StelnetProvides secure and reliable network terminal access services. Through Stelnet, a user can
log in to a remote server securely. Stelnet protects devices against attacks such as IP spoofing and
plain text password interception. The device can act as both the Stelnet server and Stelnet client.
SFTPBased on SSH2, it uses the SSH connection to provide secure file transfer. The device can
serve as the SFTP server, allowing a remote user to log in to the SFTP server for secure file
management and transfer. The device can also serve as an SFTP client, enabling a user to log in
from the device to a remote device for secure file transfer.
SCPBased on SSH2, it offers a secure approach to copying files. The device can act as the SCP
server, allowing a user to log in to the device for file upload and download. The device can also act
as an SCP client, enabling a user to log in from the device to a remote server for secure file transfer.
How SSH works

This section uses SSH2 as an example to describe the stages to establish an SSH session. For more
information about these stages, see SSH Technology White Paper.
Table 15 Stages to establish an SSH session
Stages
Description
Connection establishment
The SSH server listens to the connection requests on port 22. After a client
initiates a connection request, the server and the client establish a TCP
connection.
Version negotiation
The two parties determine a version to use.
292
Stages
Description
SSH supports multiple algorithms. Based on the local algorithms, the two parties
determine to use the following algorithms:
Algorithm negotiation
Key exchange algorithm for generating session keys.

Encryption algorithm for encrypting data.
Public key algorithm for digital signature and authentication.
HMAC algorithm for protecting data integrity.
The two parties use the Diffie-Hellman (DH) exchange algorithm to dynamically
generate the session keys and session ID:
Key exchange
The session keys are used for protecting data transfer.

The session ID is used for identifying the SSH connection.
In this stage, the client also authenticates the server.
Authentication
The SSH server authenticates the client in response to the client's authentication
request.
Session request
After passing authentication, the client sends a session request to the server to
request the establishment of a session (Stelnet, SFTP, or SCP).
After the server grants the request, the client and the server start to communicate
with each other in the session.
Interaction
In this stage, you can execute commands from the client by pasting the
commands in text format. The text must be within 2000 bytes. To execute the
commands successfully, HP recommends that you paste the commands that are
in the same view.
If you want to execute commands of more than 2000 bytes, you can save the
commands in a configuration file, upload it to the server through SFTP, and use
it to restart the server.
SSH authentication
When the device acts as an SSH server, it supports the following authentication methods:
Password authenticationThe SSH server uses AAA to authenticate the client. During password
authentication, the SSH client performs the following operations:
a. Encrypts its username and password.
b. Encapsulates the encrypted information into an authentication request.
c. Sends the request to the server.
After receiving the request, the SSH server performs the following operations:
a. Decrypts the request to get the username and password in plain text.
b. Checks the validity of the username and password locally or through remote AAA
authentication.
c. Informs the client of the authentication result.
If the AAA server requires the user for a secondary password authentication, it sends the SSH
server an authentication response with a prompt. The prompt is transparently transmitted to the
client to notify the user to enter a specific password. When the user enters the correct password,
the AAA sever examines the password validity. If the password is valid, an authentication success
message is sent to the client.
293
NOTE:
Only clients that run SSH2 or a later version support secondary password authentication that is
initiated by the AAA server.
Publickey authenticationThe server authenticates the client through the digital signature. During
publickey authentication, the client sends the server a publickey authentication request that contains
the following information:
{
Username.
Public key of the client.
Publickey algorithm information (or the digital certificate that carries the public key information).
The server examines the validity of the public key. If the public key is invalid, the authentication
fails. If the public key is valid, the server authenticates the client by using the digital signature.
Finally, it informs the client of the authentication result. The device supports using the publickey
algorithms RSA and DSA for digital signature.
A client can send public key information to the SSH server for validity check by using one of the
following methods:
{
The client directly sends the user's public key information to the server. The server checks the
validity of the user's public key.
The client sends the user's public key information to the server through a digital certificate. The
server checks the validity of the digital certificate. When acting as a client, the device does not
support this method.
Password-publickey authenticationThe server requires SSH2 clients to pass both password

authentication and publickey authentication. However, SSH1 clients only need to pass either
authentication.
Any authenticationThe server requires the client to pass password authentication or publickey
authentication.
FIPS compliance
commands, and parameters might differ in FIPS mode and non-FIPS mode. For more information about
FIPS mode, see "Configuring FIPS."
Configuring the device as an SSH server

You can configure the device as an Stelnet, SFTP or SCP server. Because the configuration procedures
are similar, the SSH server represents the Stelnet, SFTP, and SCP server unless otherwise specified.
SSH server configuration task list

Task
Remarks
Generating local DSA and RSA key pairs
Required.
Enabling the SSH server function
Required for Stelnet, SFTP, and SCP servers.
Enabling the SFTP server function
Required only for the SFTP server.

294
Task
Remarks
Configuring the user interfaces for SSH clients
Required.
Required if the following conditions exist:
Publickey authentication is configured for users.

The clients directly send the public keys to the
Configuring a client's host public key
server for validity check.
See "Configuring PKI."

Required if the following conditions exist:
Configuring the PKI domain for verifying the client
certificate
Publickey authentication is configured for users.

The clients send the public keys to the server
through digital certificates for validity check.
The PKI domain must have the CA certificate to verify

the client certificate.
Configuring an SSH user
Required for publickey authentication users and

optional for other authentication users.
Setting the SSH management parameters
Optional.
Generating local DSA and RSA key pairs

DSA and RSA key pairs are required for generating session keys and the session ID in the key exchange
stage. The key pairs can also be used by a client to authenticate the server. When a client authenticates
the server, it compares the public key received from the server with the server's public key that it saved
locally. If the keys are consistent, the client uses the public key to authenticate the digital signature
received from the server. If the digital signatures are consistent, the authentication succeeds.
When you generate local DSA and RSA key pairs, follow these restrictions and guidelines:
To support SSH clients that use different types of key pairs, generate both DSA and RSA key pairs
on the SSH server.
The public-key local create rsa command generates a server RSA key pair and a host RSA key pair.
Each of the key pairs consists of a public key and a private key. In SSH1, the public key in the server
key pair is used to encrypt the session key for secure transmission of the session key. Because SSH2
uses the DH algorithm to generate each session key on the SSH server and the client, no session key
transmission is required. The server key pair is not used in SSH2.
The public-key local create dsa command generates only a host key pair. SSH1 does not support
the DSA algorithm.
DSA algorithm is not supported in FIPS mode.
To generate local RSA and DSA key pairs on the SSH server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Generate RSA and DSA key

pairs.
public-key local create { dsa | rsa }
By default, both RSA and DSA key

pairs do not exist.
295
Enabling the SSH server function

The SSH server function allows clients to communicate with the device through SSH.
When the device acts as an SCP server, only one SCP user is allowed to access to the SCP server at one
time.
To enable the SSH server function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SSH server function.
ssh server enable
Enabling the SFTP server function

This SFTP server function enables clients to log in to the SFTP server through SFTP.
When the device functions as the SFTP server, only one client can access the SFTP server at a time.
To enable the SFTP server function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SFTP server

function.
sftp server enable
Configuring the user interfaces for SSH clients

SSH clients access the device through VTY user interfaces. You must configure the user interfaces for SSH
clients to allow SSH login. The configuration takes effect on the clients only at the next login.
IMPORTANT:
Before you configure a user interface to support SSH, you must configure its authentication mode to
scheme. Otherwise, the protocol inbound command does not take effect.
To configure the user interfaces for SSH clients:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VTY user interface view.
user-interface vty number

[ ending-number ]
N/A
3.
Set the login authentication

mode to scheme.
authentication-mode scheme
By default, the authentication

mode is password.
4.
Configure the user interface to

support SSH login.
Optional.
protocol inbound { all | ssh }
296
By default, Telnet and SSH are

supported.
For more information about the authentication-mode and protocol inbound commands, see
Fundamentals Command Reference.
Configuring a client's host public key

This configuration task is only necessary for the clients that directly send the public key to the server in
publickey authentication.
In publickey authentication, the server first compares the SSH username and client's host public key
received from the client with those saved locally. If they are consistent, the server examines the digital
signature that the client sends. The digital signature is calculated by the client according to the private
key that is associated with the host public key.
For successful authentication, you must perform the following tasks:
1.
Configure the client's DSA and RSA host public key on the server.
You can configure up to 20 SSH client's public keys on an SSH server.
2.
Specify the associated host private key on the client to generate the digital signature. If the device
serves as an SSH client, specify the public key algorithm on the client. The algorithm determines
the associated host private key for generating the digital signature.
You can enter the content of a client's host public key or import the client's host public key from the public
key file. HP recommends that you import the client's host public key.
For more information about client public key configuration, see "Managing public keys."
Entering a client's host public key

Before you enter the client's host public key, you must use the display public-key local public command
on the client to obtain the client's host public key.
To enter a client's host public key:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter public key view.
public-key peer keyname
N/A
3.
Enter public key code view.
public-key-code begin
N/A
4.
5.
6.
The host public key must be in the

DER encoding format without
being converted.
Configure a client's host

public key.
Enter the content of the host public

key
Return to public key view and

save the configured host
public key.
public-key-code end
When you exit public key code

view, the system automatically
saves the public key.
peer-public-key end
N/A
Spaces and carriage returns are

allowed between characters.
Importing the client's host public key from the public key file
Before you import the host public key, upload the client's public key file (in binary) to the server, for
example, through FTP or TFTP. During the import process, the server automatically converts the host
public key in the public key file to a string in PKCS format.
297
To import a client's host public key from the public key file:
Step
Command
1.
Enter system view.
system-view
2.
Import the client's public key

from the public key file.
public-key peer keyname import sshkey filename
Configuring an SSH user

To configure an SSH user that uses publickey authentication, you must perform the procedure in this
section.
If the authentication method is password or password-publickey, you must perform one of the following
tasks:
For local authentication, configure a local user account by using the local-user command.
For remote authentication, configure an SSH user account on an authentication server, for example,
a RADIUS server.
If the authentication method is password, you do not need to create an SSH user. However, if you want
to display all SSH users, including the password-only SSH users, for centralized management, you can
use this command to create them. If such an SSH user has been created, make sure you have specified
the correct service type and authentication method.
Configuration restrictions and guidelines

When you configure an SSH user, follow these restrictions and guidelines:
You can set the service type to Stelnet, SFTP, or SCP.
You can specify one of the following authentication methods for the SSH user:
{
PasswordThe user must pass password authentication.
Publickey authenticationThe user must pass publickey authentication.
AnyThe user can use either password authentication or publickey authentication.
For all authentication methods except password authentication, you must specify a client's host
public key or digital certificate.
{
Password-publickey authenticationAs an SSH2.0 user, the user must pass both password and
publickey authentication. As an SSH1 user, the user must pass either password or publickey
authentication.
For a client that directly sends the user's public key information to the server, you must specify
the client's host public key on the server. The specified client's host public key must already exist.
For more information about public keys, see "Configuring a client's host public key."
For a client that sends the user's public key information to the server through a digital certificate,
you must specify the PKI domain on the server. This PKI domain verifies the client certificate. To
make sure the authorized SSH users can pass the authentication, the specified PKI domain must
have the correct CA certificate. For more information about configuring a PKI domain, see
"Configuring PKI."
The command level accessible to an SSH user depends on the authentication method:
{
If the authentication method is publickey or password-publickey, the command level accessible

to the SSH user is set by using the user privilege level command on the user interface.
298
If the authentication method is password, the command level accessible to the SSH user is
authorized by AAA.
SSH1 does not support SFTP or SCP. For an SSH1 client, you must set the service type to stelnet or
all.
For an SFTP SSH user, the working folder depends on the authentication method:
{
{
If the authentication method is password, the working folder is authorized by AAA.

If the authentication method is publickey or password-publickey, the working folder is set by
using the ssh user command.
If you change the authentication method or public key for a logged-in SSH user, the change takes
effect on the user at the next login.
To configure an SSH user and specify the service type and authentication method:
Step
1.
Command
Enter system view.
system-view
Create an SSH user, and specify the service type and authentication
2.
Create an SSH user, and

specify the service type
and authentication
method.
method for Stelnet users:

ssh user username service-type stelnet authentication-type { password |
{ any | password-publickey | publickey } assign { pki-domain pkiname |
publickey keyname } }
Create an SSH user, and specify the service type and authentication
method for all users, SCP or SFTP users:

ssh user username service-type { all | scp | sftp } authentication-type
{ password | { any | password-publickey | publickey } assign
{ pki-domain pkiname | publickey keyname } work-directory
directory-name }
Setting the SSH management parameters

Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable the SSH server to

support SSH1 clients.
ssh server compatible-ssh1x

enable
Optional.
By default, the SSH server supports
SSH1 clients.
Optional.
3.
Set the RSA server key pair

update interval.
ssh server rekey-interval hours
By default, the interval is 0, and the

RSA server key pair is not updated.
This command takes effect only on
SSH1 users.
Optional.
4.
Set the SSH user

authentication timeout timer.
ssh server authentication-timeout

time-out-value
299

If a user does not finish the
authentication when the timeout
timer expires, the connection
cannot be established.
Step
Command
Remarks
Optional.
5.

SSH authentication attempts.
6.
Configure the SFTP

connection idle timeout
period.
ssh server authentication-retries

times
Authentication fails if the number of

authentication attempts (including
both publickey and password
authentication) exceeds the upper
limit.
Optional.
The default setting is 10 minutes.
sftp server idle-timeout

time-out-value
When the idle timeout timer

expires, the system automatically
tears the connection down.
Configuring the device as an Stelnet client

This section describes how to configure the device as an Stelnet client.
Stelnet client configuration task list

Task
Remarks
Specifying a source IP address or source interface for SSH packets
Optional.
Enabling and disabling first-time authentication
Optional.
Establishing a connection to an Stelnet server
Required.
Specifying a source IP address or source interface for SSH

packets
HP recommends that you specify a loopback interface or dialer interface as the source interface for SSH
packets for the following purposes:
Ensuring the communication between the Stelnet client and the Stelnet server.
Improving the manageability of Stelnet clients in authentication service.
To specify a source IP address or source interface for SSH packets:

Step
1.
Command
Enter system
view.
Remarks
N/A
system-view
300
Step
Command
Remarks
Specify a source IPv4 address or source

Specify a
source IP
address or
source
interface for
SSH packets.
2.
interface for SSH packets:

ssh client source { interface interface-type
interface-number | ip ip-address }
Specify a source IPv6 address or source
interface for SSH packets:

ssh client ipv6 source { interface interface-type
interface-number | ipv6 ipv6-address }
By default, the source IP address or

source interface for SSH packets is
not configured. The SSH packets
use the IP address of the output
interface specified in the routing
entry as their source address.

When the device works as an SSH client, you can enable or disable first-time authentication for the client.
When a client not configured with the server's host public key accesses the server for the first time, one
of the following conditions exists:
If first-time authentication is disabled, the client cannot access the server.
To enable the client to access the server, you must complete the following tasks in advance:
a. Configure the server's host public key locally.
b. Specify the public key name for authentication on the client.
If first-time authentication is enabled, the client accesses the server, and saves the server's host
public key on the client. When accessing the server next time, the client uses the locally saved
server's host public key to authenticate the server.
In a secure network, enabling first-time authentication simplifies client configuration, but it also brings
potential security risks.
Enabling first-time authentication

Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable first-time
authentication.
ssh client first-time enable
Optional.
Enabled by default.
Disabling first-time authentication

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Disable first-time
authentication.
undo ssh client first-time
Enabled by default.
3.
Configure the server host

public key.
See "Configuring a client's host

public key"
The method for configuring the

server host public key on the client
is similar to that for configuring
client public key on the server.
4.
Specify the host public key

name of the server.
ssh client authentication server

server assign publickey keyname
N/A
301
Establishing a connection to an Stelnet server

You can launch the Stelnet client to establish a connection to an Stelnet server, and specify the following
algorithms for SSH connection establishment:
Public key algorithm.
Preferred encryption algorithm.
Preferred HMAC algorithm.
Preferred key exchange algorithm.
To establish a connection to an Stelnet server:

Task
Command
Remarks
Establish a connection to an IPv4 server:

{
Establish a connection
to an Stelnet server.
In non-FIPS mode:
ssh2 server [ port-number ] [ identity-key { dsa |
rsa } | prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | des } |
prefer-ctos-hmac { md5 | md5-96 | sha1 |
sha1-96 } | prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | prefer-stoc-cipher
{ 3des | aes128 | des } | prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
In non-FIPS mode:
ssh2 server [ port-number ] [ identity-key rsa |
prefer-ctos-cipher { aes128 | aes256 } |
prefer-ctos-hmac { sha1 | sha1-96 } | prefer-kex
dh-group14 | prefer-stoc-cipher { aes128 |
aes256 } | prefer-stoc-hmac { sha1 | sha1-96 } ] *
Establish a connection to an IPv6 server:

{
Use one of the

commands in user view.
In FIPS mode:
ssh2 ipv6 server [ port-number ] [ identity-key { dsa
| rsa } | prefer-compress { zlib | zlib-openssh }
|prefer-ctos-cipher { 3des | aes128 | des } |
{ 3des | aes128 | des } | prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
In non-FIPS mode:
ssh2 ipv6 server [ port-number ] [ identity-key rsa |
prefer-ctos-hmac { sha1 | sha1-96 } | prefer-kex
dh-group14 | prefer-stoc-cipher { aes128 |
aes256 } | prefer-stoc-hmac { sha1 | sha1-96 } ] *
Configuring the device as an SFTP client

This section describes how to configure the device as an SFTP client.
302
SFTP client configuration task list

Task
Remarks
Specifying a source IP address or source interface for SFTP packets
Optional.
Optional.
Establishing a connection to an SFTP server
Required.
Working with SFTP directories
Optional.
Working with SFTP files
Optional.
Displaying help information
Optional.
Terminating the connection with the SFTP server
Optional.
Specifying a source IP address or source interface for SFTP

packets
HP recommends that you specify a loopback interface or dialer interface as the source interface for SFTP
packets for the following purposes:
Ensuring the communication between the SFTP client and the SFTP server.
Improving the manageability of SFTP clients in the authentication service.
To specify a source IP address or interface for SFTP packets:

Step
1.
Enter system
view.
Command
Remarks
system-view
N/A
Specify a source IPv4 address or

2.
Specify a source
IP address or
interface for
SFTP packets.
interface for SFTP packets:

sftp client source { interface
interface-type interface-number | ip
ip-address }
Specify a source IPv6 address or
interface for SFTP packets:

sftp client ipv6 source { interface
interface-type interface-number | ipv6
ipv6-address }
By default, the source IP address or

source interface for SFTP packets is not
configured. The SFTP packets use the IP
address of the output interface specified
in the routing entry as their source
address.
Establishing a connection to an SFTP server

You can launch the SFTP client to establish a connection to an SFTP server, and specify the following
algorithms for SFTP connection establishment:
Public key algorithm.
Preferred encryption algorithm.
Preferred HMAC algorithm.
Preferred key exchange algorithm.

303
After the connection is established, you can directly enter SFTP client view on the server to perform
directory and file operations.
To establish a connection to an SFTP server:
Task
Command
Remarks
Establish a connection to an IPv4 SFTP server:

{
Establish a connection
to an SFTP server and
enter SFTP client view.
In non-FIPS mode:
sftp server [ port-number ] [ identity-key { dsa |
rsa } | prefer-compress { zlib | zlib-openssh }
|prefer-ctos-cipher { 3des | aes128 | des } |
{ 3des | aes128 | des } | prefer-stoc-hmac
{ md5 | md5-96 | sha1 | sha1-96 } ] *
In FIPS mode:
sftp server [ port-number ] [ identity-key rsa |
prefer-ctos-hmac { sha1 | sha1-96 } |
prefer-kex dh-group14 | prefer-stoc-cipher
{ aes128 | aes256 } | prefer-stoc-hmac { sha1 |
sha1-96 } ] *
Establish a connection to an IPv6 SFTP server:

{
In non-FIPS mode:
sftp ipv6 server [ port-number ] [ identity-key
{ dsa | rsa } | prefer-compress { zlib |
zlib-openssh } | prefer-ctos-cipher { 3des |
aes128 | des } | prefer-ctos-hmac { md5 |
md5-96 | sha1 | sha1-96 } | prefer-kex
{ dh-group-exchange | dh-group1 |
dh-group14 } | prefer-stoc-cipher { 3des |
aes128 | des } | prefer-stoc-hmac { md5 |
md5-96 | sha1 | sha1-96 } ] *
Use one of the commands

in user view.
In FIPS mode:
sftp ipv6 server [ port-number ] [ identity-key rsa
| prefer-ctos-cipher { aes128 | aes256 } |
prefer-ctos-hmac { sha1 | sha1-96 } |
prefer-kex dh-group14 | prefer-stoc-cipher
{ aes128 | aes256 } | prefer-stoc-hmac { sha1 |
sha1-96 } ] *
Working with SFTP directories

Step
Command
Remarks
1.
Enter SFTP client view.

"Establishing a connection to an
SFTP server."
N/A
2.
Change the working directory

of the remote SFTP server.
cd [ remote-path ]
Optional.
3.
Return to the upper-level

directory.
cdup
Optional.
304
Step
Command
Remarks
Optional.
4.
Display the current working

directory on the SFTP server.
pwd
5.
Display files under a

directory.
dir [ -a | -l ] [ remote-path ]
ls [ -a | -l ] [ remote-path ]
6.
Change the name of a

directory on the SFTP server.
rename oldname newname
Optional.
7.
Create a new directory on the

SFTP server.
mkdir remote-path
Optional.
8.
Delete one or more directories

from the SFTP server.
rmdir remote-path&<1-10>
Optional.
Command
Remarks
Optional.
The dir command functions as the
ls command.
Working with SFTP files

Step
1.

SFTP server."
N/A
2.
Change the name of a file on

the SFTP server.
rename old-name new-name
Optional.
3.
Download a file from the

remote server and save it
locally.
get remote-file [ local-file ]
Optional.
4.
Upload a local file to the SFTP

server.
put local-file [ remote-file ]
Optional.
5.
Display the files under a

directory.
dir [ -a | -l ] [ remote-path ]
ls [ -a | -l ] [ remote-path ]
6.
Delete one or more directories

from the SFTP server.
delete remote-file&<1-10>
remove remote-file&<1-10>
Optional.
The dir command functions as the
ls command.
Optional.
The delete command functions as
the remove command.
Displaying help information

Use the help command to display all commands or the help information of an SFTP client command,
including the command format and parameters.
To display all commands or the help information of an SFTP client command:
Step
Command
1.
For more information, see "Establishing a connection to an

SFTP server."
2.
Display all commands or the help

information of an SFTP client command.
help [ all | command-name ]

305
Terminating the connection with the SFTP server

Step
Command
Remarks
1.

SFTP server."
N/A
2.
Terminate the connection with

the SFTP server and return to
user view.
bye
exit
quit
These commands function in the

same way.
Configuring the device as an SCP client

This section describes how to configure the device as an SCP client.
SCP client configuration task list

Task
Remarks
Optional.
Transferring files with an SCP server
Required.
306
Transferring files with an SCP server

Task
Command
Upload a file to the SCP server:
{
Connect to the SCP

server, and transfer files
with the server.
In non-FIPS mode:
scp [ ipv6 ] server [ port-number ] put source-file-path [ destination-file-path ]
identity-key { dsa | rsa } | [ prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | des } | prefer-ctos-hmac { md5 |
md5-96 | sha1 | sha1-96 } | prefer-kex { dh-group-exchange | dh-group1
| dh-group14 } | prefer-stoc-cipher { 3des | aes128 | des } |
prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 } ] *
In FIPS mode:
scp [ ipv6 ] server [ port-number ] put source-file-path [ destination-file-path ]
[ identity-key rsa | prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { aes128 | aes256 } | prefer-ctos-hmac { sha1 | sha1-96 }
| prefer-kex dh-group14 | prefer-stoc-cipher { aes128 | aes256 } |
prefer-stoc-hmac { sha1 | sha1-96 } ] *
Download a file from the SCP server:

{
In non-FIPS mode:
scp [ ipv6 ] server [ port-number ] get source-file-path [ destination-file-path ]
[ identity-key { dsa | rsa } | prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | des } | prefer-ctos-hmac { md5 |
md5-96 | sha1 | sha1-96 } | prefer-kex { dh-group-exchange | dh-group1
| dh-group14 } | prefer-stoc-cipher { 3des | aes128 | des } |
prefer-stoc-hmac { md5 | md5-96 | sha1 | sha1-96 } ] *
In FIPS mode:
scp [ ipv6 ] server [ port-number ] get source-file-path [ destination-file-path ]
[ identity-key rsa | prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { aes128 | aes256 } | prefer-ctos-hmac { sha1 | sha1-96 }
| prefer-kex dh-group14 | prefer-stoc-cipher { aes128 | aes256 } |
prefer-stoc-hmac { sha1 | sha1-96 } ] *
Displaying and maintaining SSH

Task
Command
Remarks
Display the source IP address or

interface configured for the SFTP
client.
display sftp client source [ | { begin | exclude

Display the source IP address or

interface information configured for
the Stelnet client.
display ssh client source [ | { begin | exclude

Display SSH server status

information or session information
on an SSH server.
display ssh server { status | session } [ |

Display the mappings between

SSH servers and their host public
keys on an SSH client.
display ssh server-info [ | { begin | exclude |

307
Task
Command
Remarks

all SSH users on an SSH server.
display ssh user-information [ username ] [ |

Display the public keys of the local

key pairs.
display public-key local { dsa | rsa } public

Display the public keys of the SSH

peers.
display public-key peer [ brief | name

publickey-name ] [ | { begin | exclude |
Stelnet configuration examples

This section provides examples of configuring Stelnet.
Password authentication enabled Stelnet server configuration

example
As shown in Figure 107:
You can log in to the AC through the Stelnet client (SSH2) that runs on the client.
The AC acts as the Stelnet server and uses password authentication.
The username and password of the client are saved on the AC.
The client and the AC can reach each other.
308
1.
Generate an RSA key pair on the Stelnet client:

a. Launch PuTTYGen.exe, select SSH-2 RSA, and click Generate.
Figure 108 Generating an RSA key pair on the client
b. Continuously move the mouse and do not place the mouse over the green progress bar shown
in Figure 109. Otherwise, the progress bar stops moving and the key pair generating progress
stops.
309
Figure 109 Generating process
c. After the key pair is generated, click Save public key to save the public key.
A file saving window appears.
Figure 110 Saving the RSA key pair on the client
310
d. Enter a file name (key.pub in this example), and click Save.

e. On the page as shown in Figure 110, click Save private key to save the private key.
A confirmation dialog box appears.
f. Click Yes.
g. Enter a file name (private.ppk, in this example), and click Save.
h. Transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the Stelnet server AC:

# Generate the RSA key pairs.
<AC> system-view
# Enable the SSH server function.

[AC] ssh server enable
# Configure an IP address for VLAN-interface 2. The Stelnet client uses this address as the
destination address for SSH connection.
# Set the authentication mode to AAA for the user interfaces.

# Enable the user interfaces to support SSH.

[AC-ui-vty0-4] protocol inbound ssh
[AC-ui-vty0-4] quit
# Create a local user client001.

[AC] local-user client001
# Specify the password as aabbcc for the local user.

[AC-luser-client001] password simple aabbcc
# Set the user privilege level to 3 for the local user.

[AC-luser-client001] authorization-attribute level 3
# Specify the service type as ssh for the local user.

[AC-luser-client001] service-type ssh
[AC-luser-client001] quit
# Create an SSH user client001. Specify the service type as stelnet and the authentication method
as password for the user. By default, password authentication is used if no SSH user is created.
[AC] ssh user client001 service-type stelnet authentication-type password
3.
Establish a connection to the Stelnet server:

The device supports different types of Stelnet client software, such as PuTTY and OpenSSH. The
following example uses PuTTY version 0.58 on the Stelnet client.
To establish a connection to the Stelnet server:
a. Launch PuTTY.exe on the Stelnet client.
311
Figure 111 Specifying the host name (or IP address)
b. In the Host Name (or IP address) filed, enter the IP address 192.168.1.40 of the Stelnet server.
c. Click Open to connect to the server.
If the connection is successfully established, the system notifies you to enter the username and
password. After entering the username (client001) and password (aabbcc), you can enter the
CLI of the server.
Publickey authentication enabled Stelnet server configuration

example
You can log in to the AC through the Stelnet client (SSH2) that runs on the client.
The AC acts as the Stelnet server, and uses publickey authentication and the RSA public key
algorithm.
312
In the server configuration, the client public key is required. Use the client software to generate the RSA
key pair on the client before configuring the Stelnet server.
The device supports different types of Stelnet client software, such as PuTTY and OpenSSH. The following
example uses PuTTY version 0.58 on the Stelnet client.
1.
Generate an RSA key pair on the Stelnet client:

a. Launch PuTTYGen.exe, select SSH-2 RSA, and click Generate.
Figure 113 Generating an RSA key pair on the client
b. Continuously move the mouse and do not place the mouse over the green progress bar shown
in Figure 114. Otherwise, the progress bar stops moving and the key pair generating progress
stops.
313
Figure 114 Generating process
c. After the key pair is generated, click Save public key to save the public key.
Figure 115 Saving the RSA key pair on the client
314
d. Enter a file name (key.pub in this example), and click Save.

e. On the page as shown in Figure 115, click Save private key to save the private key.
A confirmation dialog box appears.
f. Click Yes.
g. Enter a file name (private.ppk, in this example), and click Save.
h. Transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the Stelnet server AC:

<AC> system-view

[AC] ssh server enable


[AC-ui-vty0-4] protocol inbound ssh
# Set the user command privilege level to 3.

[AC-ui-vty0-4] user privilege level 3
[AC-ui-vty0-4] quit
# Import the client's public key from file key.pub and name it Key001.
[AC] public-key peer Key001 import sshkey key.pub
# Create an SSH user client002. Specify the authentication method as publickey for the user, and
assign the public key Key001 to the user.
[AC] ssh user client002 service-type stelnet authentication-type publickey assign
publickey Key001
3.

a. Launch PuTTY.exe on the Stelnet client.
315
Figure 116 Specifying the host name (or IP address)
b. In the Host Name (or IP address) field, enter the IP address 192.168.1.40 of the Stelnet server.
c. Select Connection > SSH > Auth from the navigation tree.
d. Click Browse to bring up the file selection window, navigate to the private key file (private
in this example) and click OK.
316
Figure 117 Specifying the private key file
e. Click Open to connect to the server.

If the connection is successfully established, the system notifies you to enter the username and
password. After entering the username (client002), you can enter the CLI of the server.
Password authentication enabled Stelnet client configuration

example
You can log in to the switch through the Stelnet client that runs on AC.
The switch acts as the Stelnet server and uses password authentication.
The username and password of AC are saved on the switch.
317
1.
Configure the Stelnet server:

<Switch> system-view
[Switch] public-key local create rsa

[Switch] ssh server enable
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[Switch-Vlan-interface2] quit

[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme

[Switch-ui-vty0-4] protocol inbound ssh
[Switch-ui-vty0-4] quit

[Switch] local-user client001

[Switch-luser-client001] password simple aabbcc
# Set the user privilege level to 3 for the local user.

[Switch-luser-client001] authorization-attribute level 3

[Switch-luser-client001] service-type ssh
[Switch-luser-client001] quit
# Create an SSH user client001. Specify the service type as stelnet and the authentication method
as password for the user.
[Switch] ssh user client001 service-type stelnet authentication-type password
2.

# Configure an IP address for VLAN-interface 2.
<AC> system-view
[AC] quit
# Configure AC not to support first-time authentication.

[AC] undo ssh client first-time
# Configure the host public key of the SSH server and name the key key1.
[AC] public-key peer key1
[AC-pkey-public-key] public-key-code begin
[AC-pkey-key-code]308201B73082012C06072A8648CE3804013082011F0281810
0D757262C4584C44C211F18BD96E5F0
[AC-pkey-key-code]61C4F0A423F7FE6B6B85B34CEF72CE14A0D3A5222FE08CECE
318
65BE6C265854889DC1EDBD13EC8B274
[AC-pkey-key-code]DA9F75BA26CCB987723602787E922BA84421F22C3C89CB9B0
6FD60FE01941DDD77FE6B12893DA76E
[AC-pkey-key-code]EBC1D128D97F0678D7722B5341C8506F358214B16A2FAC4B3
68950387811C7DA33021500C773218C
[AC-pkey-key-code]737EC8EE993B4F2DED30F48EDACE915F0281810082269009E
14EC474BAF2932E69D3B1F18517AD95
[AC-pkey-key-code]94184CCDFCEAE96EC4D5EF93133E84B47093C52B20CD35D02
492B3959EC6499625BC4FA5082E22C5
[AC-pkey-key-code]B374E16DD00132CE71B020217091AC717B612391C76C1FB2E
88317C1BD8171D41ECB83E210C03CC9
[AC-pkey-key-code]B32E810561C21621C73D6DAAC028F4B1585DA7F42519718CC
9B09EEF0381840002818000AF995917
[AC-pkey-key-code]E1E570A3F6B1C2411948B3B4FFA256699B3BF871221CC9C5D
F257523777D033BEE77FC378145F2AD
[AC-pkey-key-code]D716D7DB9FCABB4ADBF6FB4FDB0CA25C761B308EF53009F71
01F7C62621216D5A572C379A32AC290
[AC-pkey-key-code]E55B394A217DA38B65B77F0185C8DB8095522D1EF044B465E
8716261214A5A3B493E866991113B2D
[AC-pkey-key-code]485348
[AC-pkey-key-code] public-key-code end
[AC-pkey-public-key] peer-public-key end
# Specify the host public key for the Stelnet server 192.168.1.40 as key1.
[AC] ssh client authentication server 192.168.1.40 assign publickey key1
[AC] quit
# Establish an SSH connection to the Stelnet server 192.168.1.40.

<AC> ssh2 192.168.1.40
Username: client001
Trying 192.168.1.40
Connected to 192.168.1.40...
Enter password:
******************************************************************************
* Copyright (c) 2010-2013 Hewlett-Packard Development Company, L.P.
* Without the owner's prior written consent,
* no decompiling or reverse-engineering shall be allowed.
******************************************************************************
<Switch>
Publickey authentication enabled Stelnet client configuration

example
You can log in to the switch through the Stelnet client that runs on AC.
319
The switch acts as the Stelnet server and uses publickey authentication and the RSA public key
algorithm.
In the server configuration, the client public key is required. Use the client software to generate RSA key
pairs on the client before configuring the Stelnet server.
1.
Configure the Stelnet client AC:

# Create VLAN-interface 2 and assign an IP address to it.
<AC> system-view
# Generate RSA key pairs.

# Export the RSA public key to the file key.pub.

[AC] public-key local export rsa ssh2 key.pub
[AC] quit
# Transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the Stelnet server:

<Switch> system-view
[Switch] public-key local create rsa

[Switch] ssh server enable
# Configure an IP address for VLAN-interface 2. The SSH client uses this address as the destination
address for SSH connection.
[Switch] interface vlan-interface 2
[Switch-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[Switch-Vlan-interface2] quit

[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme

[Switch-ui-vty0-4] protocol inbound ssh
# Set the user command privilege level to 3.

[Switch-ui-vty0-4] user privilege level 3
[Switch-ui-vty0-4] quit
320
# Import the peer public key from the file key.pub, and name it Key001.
[Switch] public-key peer Key001 import sshkey key.pub
# Create an SSH user client002. Specify the authentication method as publickey for the user, and
assign the public key Key001 to the user.
[Switch] ssh user client002 service-type stelnet authentication-type publickey assign
publickey Key001
3.
Establish an SSH connection to the Stelnet server 192.168.1.40.

<AC> ssh2 192.168.1.40
Username: client002
Trying 192.168.1.40 ...
Connected to 192.168.1.40 ...
The Server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
******************************************************************************
* Copyright (c) 2010-2013 Hewlett-Packard Development Company, L.P.
* Without the owner's prior written consent,
* no decompiling or reverse-engineering shall be allowed.
******************************************************************************
<Switch>
SFTP configuration example

An SSH connection is established between AC 1 and AC 2.
AC 1 acts as an SFTP client to log into AC 2 for file management and file transfer.
The username is client001 and password is aabbcc.
321
1.
Configure the SFTP server AC 2:

# Generate RSA key pairs and enable the SSH server.
<AC2> system-view
[AC2] public-key local create rsa
[AC2] ssh server enable
# Configure an IP address for VLAN-interface 2. The client uses this address as the destination
address for SSH connection.
[AC2-Vlan-interface2] ip address 192.168.0.1 255.255.255.0

[AC2] user-interface vty 0 4
[AC2-ui-vty0-4] authentication-mode scheme

[AC2-ui-vty0-4] protocol inbound ssh
[AC2-ui-vty0-4] quit

[AC2] local-user client001
[AC2-luser-client001] password simple aabbcc
[AC2-luser-client001] authorization-attribute level 3
[AC2-luser-client001] service-type ssh
[AC2-luser-client001] quit
# Configure the AC to authenticate SSH users by using password authentication, and provide
SFTP services.
[AC2] ssh user client001 service-type sftp authentication-type password
NOTE:
To use publickey authentication, configure the public key of AC 1 on AC 2. For configuration steps,
see "Publickey authentication enabled Stelnet server configuration example."
# Enable the SFTP server.
[AC2] sftp server enable
2.
Configure the client AC 1:

322
<AC1> system-view
[AC1] quit
# Establish a connection with the remote SFTP server and enter SFTP client view.
<AC1> sftp 192.168.0.1
Input Username: client001
Trying 192.168.0.1 ...
Connected to 192.168.0.1 ...

Enter password:
<sftp-client>
# Display files under the current directory of the server, delete the file z, and verify the result.
<sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 startup.cfg

225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey1
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
-rwxrwxrwx
1 noone
nogroup
0 Sep 01 08:00 z
End of file
Success
<sftp-client> delete z
The following File will be deleted:
/z
Are you sure to delete it? [Y/N]:y
This operation may take a long time. Please wait...
Success
File successfully Removed
<sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey1
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
End of file
Success
# Add a directory new1 and verify the result.

<sftp-client> mkdir new1
Success
New directory created
sftp-client> dir
323
-rwxrwxrwx
1 noone
nogroup
-rwxrwxrwx
1 noone
nogroup

225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey1
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:30 new1
End of file
Success
# Rename the directory new1 to new2 and verify the result.

<sftp-client> rename new1 new2
Success
File successfully renamed
<sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
-rwxrwxrwx
1 noone
nogroup

225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey1
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:33 new2
End of file
Success
# Download the pubkey2 file from the server and save it as local file public.
<sftp-client> get pubkey2 public
Remote
file:/pubkey2 --->
Local file: public
End of file
Success
Downloading file successfully ended
# Upload a local file pu to the server, save it as puk, and verify the result.
<sftp-client> put pu puk
Local file:pu --->
Remote file: /puk
Success
Uploading file successfully ended
<sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey1
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:33 new2
-rwxrwxrwx
1 noone
nogroup
283 Sep 02 06:35 pub
-rwxrwxrwx
1 noone
nogroup
283 Sep 02 06:36 puk
End of file
Success
<sftp-client>
# Terminate the connection with the remote SFTP server.

<sftp-client> quit
Bye
<AC1>
324
SCP configuration example

This section provides examples of configuring SCP for file transfer with password authentication.
AC 1 acts as the SCP client. AC 2 acts as the SCP server.
A user can securely transfer files with AC 2 through AC 1.
AC 2 uses the password authentication method.
The client 's username and password are saved on AC 2.
1.
Configure the SCP server AC 2:

<AC2> system-view
[AC2] public-key local create rsa

[AC2] ssh server enable
# Configure an IP address for VLAN-interface 2. The client uses this address as the destination
address for SCP connection.

[AC2] user-interface vty 0 4
[AC2-ui-vty0-4] authentication-mode scheme
325

[AC2-ui-vty0-4] protocol inbound ssh
[AC2-ui-vty0-4] quit

[AC2] local-user client001

[AC2-luser-client001] password simple aabbcc

[AC2-luser-client001] service-type ssh
[AC2-luser-client001] quit
# Create an SSH user client001. Specify the service type as scp and authentication method as
password for the user. By default, password authentication is used if no SSH user is created.
[AC2] ssh user client001 service-type scp authentication-type password
2.
Configure an IP address for VLAN-interface 2 on the SCP client AC 1:

<AC1> system-view
[AC1] quit
3.
Connect to the SCP server, download the file remote.bin from the server, and save it locally with
the name local.bin.
<AC1> scp 192.168.0.1 get remote.bin local.bin
Username: client001
Trying 192.168.0.1 ...
Connected to 192.168.0.1 ...

Enter password:
18471 bytes transfered in 0.001 seconds.
326
Configuring SSL
Overview
Secure Sockets Layer (SSL) is a security protocol that provides secure connection services for TCP-based
application layer protocols such as HTTP. It is widely used in e-business and online banking to provide
secure data transmission over the Internet.
SSL security mechanism

Secure connections provided by SSL have these features:
PrivacySSL uses a symmetric encryption algorithm to encrypt data and uses the asymmetric key
algorithm of RSA to encrypt the key to be used by the symmetric encryption algorithm.
AuthenticationSSL supports certificate-based identity authentication of the server and client by

using the digital signatures. The SSL server and client obtain certificates from a CA through the PKI.
IntegritySSL uses the key-based message authentication code (MAC) to verify message integrity.
A MAC algorithm transforms a message of any length to a fixed-length message. With the key, the
sender uses the MAC algorithm to compute the MAC value of a message. Then, the sender
appends the MAC value to the message and sends the result to the receiver. The receiver uses the
same key and MAC algorithm to compute the MAC value of the received message, and compares
the locally computed MAC value with that received. If the two values match, the receiver considers
the message intact. Otherwise, the receiver considers the message tampered with in transit and
discards the message.
Figure 122 Message integrity verification by a MAC algorithm
For more information about symmetric key algorithms, asymmetric key algorithm RSA, and digital
signature, see "Managing public keys."
For more information about PKI, certificate, and CA, see "Configuring PKI."
SSL protocol stack

The SSL protocol consists of two layers of protocols: the SSL record protocol at the lower layer and the SSL
handshake protocol, change cipher spec protocol, and alert protocol at the upper layer.
327
Figure 123 SSL protocol stack
SSL record protocolFragments data to be transmitted, computes and adds MAC to the data, and
encrypts the data before transmitting it to the peer end.
SSL handshake protocolNegotiates the cipher suite to be used for secure communication
(including the symmetric encryption algorithm, key exchange algorithm, and MAC algorithm),
securely exchanges the key between the server and client, and implements identity authentication
of the server and client. Through the SSL handshake protocol, a session is established between a
client and the server. A session consists of a set of parameters, including the session ID, peer
certificate, cipher suite, and master secret.
SSL change cipher spec protocolUsed for notification between the client and the server that the
subsequent packets are to be protected and transmitted based on the newly negotiated cipher suite
and key.
SSL alert protocolEnables the SSL client and server to send alert messages to each other. An alert
message contains the alert severity level and a description.

Task
Remarks
Configuring an SSL server policy
Required.
Configuring an SSL client policy
Optional.
Configuring an SSL server policy

An SSL server policy is a set of SSL parameters for a server to use when booting up. An SSL server policy
takes effect only after it is associated with an application such as HTTPS.
SSL versions include SSL 2.0, SSL 3.0, and TLS 1.0 (or SSL 3.1). When the device acts as the SSL server,
it can communicate with clients running SSL 3.0 or TLS 1.0, and can identify the SSL 2.0 Client Hello
message from a client supporting both SSL 2.0 and SSL 3.0/TLS 1.0, and notify the client to use SSL 3.0
or TLS 1.0 for communication.
In FIPS mode, only TLS 1.0 is supported.
To configure an SSL server policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an SSL server policy

and enter its view.
ssl server-policy policy-name
N/A
328
Step
Command
Remarks
Optional.
By default, no PKI domain is
specified for an SSL server policy,
and the SSL server generates and
signs a certificate for itself and
does not obtain a certificate from a
CA server.
3.
Specify a PKI domain for the

SSL server policy.
pki-domain domain-name
If SSL clients authenticate the server

through a digital certificate, you
must use this command to specify a
PKI domain and request a local
certificate for the SSL server in the
PKI domain.
For information about how to
configure a PKI domain, see
"Configuring PKI."
In non-FIPS mode:
4.
Specify the cipher suites for

the SSL server policy to
support.
ciphersuite
[ rsa_3des_ede_cbc_sha |
rsa_aes_128_cbc_sha |
rsa_des_cbc_sha |
rsa_rc4_128_md5 |
rsa_rc4_128_sha ] *
In FIPS mode:
Optional.
By default, an SSL server policy
supports all cipher suites.
ciphersuite
[ dhe_rsa_aes_128_cbc_sha |
dhe_rsa_aes_256_cbc_sha |
rsa_aes_256_cbc_sha ] *
5.
Set the handshake timeout

time for the SSL server.
handshake timeout time
Optional.
Optional.
6.
Set the SSL connection close

mode.
close-mode wait
By default, an SSL server sends a

close-notify alert message to the
client and closes the connection
without waiting for the close-notify
alert message from the client.
Optional.
7.

cached sessions and the
caching timeout time.
The defaults are as follows:

session { cachesize size | timeout
time } *
500 for the maximum number

of cached sessions.
3600 seconds for the caching

timeout time.
8.
Configure the server to require

certificate-based SSL client
authentication.
Optional.
client-verify enable
329
By default, the SSL server does not

require the client to be
authenticated.
Step
Command
Remarks
Optional.
9.
Enable SSL client weak

authentication.
client-verify weaken
This command takes effect only

when the client-verify enable
command is configured.
Configuring an SSL client policy

An SSL client policy is a set of SSL parameters for a client to use when connecting to the server. An SSL
client policy takes effect only after it is associated with an application layer protocol.
To configure an SSL client policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an SSL client policy

and enter its view.
ssl client-policy policy-name
N/A
Optional.
No PKI domain is specified by
default.
3.
Specify a PKI domain for the

SSL client policy.
pki-domain domain-name
If the SSL server authenticates the

SSL client through a digital
certificate, you must use this
command to specify a PKI domain
and request a local certificate for
the SSL client in the PKI domain.
For information about how to
configure a PKI domain, see
"Configuring PKI."
In non-FIPS mode:
4.
Specify the preferred cipher

suite for the SSL client policy.
prefer-cipher
{ rsa_3des_ede_cbc_sha |
rsa_des_cbc_sha |
rsa_rc4_128_md5 |
rsa_rc4_128_sha }
In FIPS mode:
Optional.
rsa_rc4_128_md5 by default.
prefer-cipher
{ dhe_rsa_aes_128_cbc_sha d
dhe_rsa_aes_256_cbc_sha |
rsa_aes_256_cbc_sha }
5.
Specify the SSL protocol

version for the SSL client
policy.
version { ssl3.0 | tls1.0 }
330
Optional.
TLS 1.0 by default.
Step
6.
Command
Enable certificate-based SSL
server authentication.
server-verify enable
Remarks
Optional.
Enabled by default.
Displaying SSL
Task
Command
Remarks
Display SSL server policy

information.
display ssl server-policy { policy-name | all } [ |

Display SSL client policy

information.
display ssl client-policy { policy-name | all } [ | { begin

SSL server policy configuration example

Configure the AC to operate as an HTTP Security (HTTPS) server so that the client accesses the HTTPS
server through HTTPS. Configure a CA server to issue certificates.
331
1.
Request a certificate for the AC:

# Create a PKI entity named en and configure it.
<AC> system-view
[AC] pki entity en
[AC-pki-entity-en] common-name http-server1
[AC-pki-entity-en] fqdn ssl.security.com
[AC-pki-entity-en] quit
# Create a PKI domain and configure it.

[AC] pki domain 1
[AC-pki-domain-1] ca identifier ca1
[AC-pki-domain-1] certificate request url http://10.1.2.2/certsrv/mscep
[AC-pki-domain-1] certificate request from ra
[AC-pki-domain-1] certificate request entity en
[AC-pki-domain-1] quit
# Create the local RSA key pairs.

# Retrieve the CA certificate.

[AC] pki retrieval-certificate ca domain 1
# Request a local certificate.

[AC] pki request-certificate domain 1
2.
Configure an SSL server policy:

# Create an SSL server policy named myssl.
[AC] ssl server-policy myssl
# Specify the PKI domain for the SSL server policy as 1.

[AC-ssl-server-policy-myssl] pki-domain 1
# Enable client authentication.

[AC-ssl-server-policy-myssl] client-verify enable
[AC-ssl-server-policy-myssl] quit
3.
Associate HTTPS service with the SSL server policy and enable HTTPS service:
# Configure HTTPS service to use SSL server policy myssl.
[AC] ip https ssl-server-policy myssl
# Enable HTTPS service.

[AC] ip https enable
4.
Verify your configuration:

Launch IE on the client and enter https://10.1.1.1 in the address bar. You should be able to log
in to the AC and manage it.
For more information about PKI configuration commands and the public-key local create rsa command,
see Security Command Reference.
332
Troubleshooting SSL
SSL handshake failure
Symptom
As the SSL server, the device fails to handshake with the SSL client.
Analysis
SSL handshake failure might result from the following causes:
The SSL client is configured to authenticate the SSL server, but the SSL server has no certificate, or
the certificate is not trusted.
The SSL server is configured to authenticate the SSL client, but the SSL client has no certificate, or the
certificate is not trusted.
The server and the client have no matching cipher suite.
1.
Issue the debugging ssl command and view the debugging information to locate the problem:
Solution
2.
If the SSL client is configured to authenticate the SSL server but the SSL server has no certificate,
request one for it.
If the servers certificate cannot be trusted, install the root certificate of the CA that issued the
local certificate to the SSL server on the SSL client, or let the server request a certificate from the
CA that the SSL client trusts.
If the SSL server is configured to authenticate the client, but the SSL client has no certificate or the
certificate cannot be trusted, request and install a certificate for the client.
Use the display ssl server-policy command to view the cipher suites that the SSL server policy
supports. If the server and the client have no matching cipher suite, use the ciphersuite command
to modify the cipher suite configuration of the SSL server.
333
Configuring TCP attack protection

Overview
Attackers can attack the device during the process of TCP connection establishment. To prevent such
attacks, the device provides the SYN Cookie feature.
Enabling the SYN Cookie feature

As a general rule, the establishment of a TCP connection involves the following three handshakes:
1.
The request originator sends a SYN message to the target server.
2.
After receiving the SYN message, the target server establishes a TCP connection in
SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response.
3.
After receiving the SYN ACK message, the originator returns an ACK message, establishing the
TCP connection.
Attackers may mount SYN Flood attacks during TCP connection establishment. They send a large number
of SYN messages to the server to establish TCP connections, but they never make any response to SYN
ACK messages. As a result, a large number of incomplete TCP connections are established, resulting in
heavy resource consumption and making the server unable to handle services correctly.
The SYN Cookie feature can prevent SYN Flood attacks. After receiving a TCP connection request, the
server directly returns a SYN ACK message, instead of establishing an incomplete TCP connection. The
server can establish a connection only after receiving an ACK message from the client. The server then
enters ESTABLISHED state. In this way, incomplete TCP connections can be avoided to protect the server
against SYN Flood attacks.
To enable the SYN Cookie feature:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SYN Cookie feature.
tcp syn-cookie enable
Enabled by default.
If you enable MD5 authentication for TCP connections, the SYN Cookie configuration is ineffective. Then,
if you disable MD5 authentication for TCP connections, the SYN Cookie configuration automatically
becomes effective.
With the SYN Cookie feature enabled, only the maximum segment size (MSS) is negotiated during TCP
connection establishment, instead of the window's zoom factor and timestamp.
334
Displaying TCP attack protection

Task
Command
Remarks
Display current TCP connection state.
display tcp status [ | { begin | exclude |

335
Configuring ARP attack protection

ARP attacks and viruses threaten LAN security. This chapter describes multiple features used to detect and
prevent such attacks.
Overview
Although ARP is easy to implement, it provides no security mechanism and is vulnerable to network
attacks. An attacker can exploit ARP vulnerabilities to attack network devices in the following ways:
Acts as a trusted user or gateway to send ARP packets so the receiving devices obtain incorrect ARP
entries.
Sends a large number of unresolvable IP packets (ARP cannot find MAC addresses for those
packets) to keep the receiving device busy with resolving target IP addresses until the CPU is
overloaded.
Sends a large number of ARP packets to overload the CPU of the receiving device.
For more information about ARP attack features and types, see ARP Attack Protection Technology White
Paper.
ARP attack protection configuration task list

Perform the following tasks to prevent flood attacks:
Task
Configuring
unresolvable IP attack
protection
Remarks
Configuring ARP
source suppression
Optional.
Enabling ARP
blackhole routing
Optional.
Configuring ARP packet rate limit

Configuring source MAC-based ARP attack
detection
Configure this function on gateways (recommended).

Optional.
Configure this function on access devices (recommended).
Optional.
Perform the following tasks to prevent user and gateway spoofing:

Task
Remarks
Optional.
Configuring ARP active acknowledgement

Optional.
Configuring authorized ARP
336
Task
Remarks
Optional.
Configuring ARP detection

Optional.
Configuring ARP gateway protection

Optional.
Configuring ARP filtering
Configuring unresolvable IP attack protection

If a device receives from a host a large number of IP packets that cannot be resolved by ARP (called
unresolvable IP packets), the following situations can occur:
The device sends a large number of ARP requests, overloading the target subnets.
The device keeps trying to resolve target IP addresses, overloading its CPU.
To protect the device from such IP packet attacks, you can configure the following features:
ARP source suppressionStops resolving packets from a host if the upper limit on unresolvable IP
packets from the host is reached within an interval of 5 seconds. The device continues ARP
resolution when the interval elapses. This feature is applicable if the attack packets have the same
source addresses.
ARP blackhole routingCreates a blackhole route destined for an unresolvable IP address. The
device drops all matching packets until the blackhole route ages out. This feature is applicable
regardless of whether the attack packets have the same source addresses.
Configuring ARP source suppression

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable ARP source suppression.
arp source-suppression enable
3.
Set the maximum number of unresolvable

packets that the device can receive from a
device in 5 seconds.
arp source-suppression limit

limit-value
Optional.
10 by default.
Enabling ARP blackhole routing

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Enable ARP blackhole

routing.
arp resolving-route enable
337
Enabled by default.
The aging time for a blackhole
route is 25 seconds.
Displaying and maintaining ARP source suppression

Task
Command
Remarks
Display ARP source suppression

configuration information.
display arp source-suppression [ |

Configuration example
and might vary by device model.
As shown in Figure 125, a LAN contains two areas: an R&D area in VLAN 10 and an office area in
VLAN 20. Each area connects to the gateway (AC) through an AP.
A large number of ARP requests are detected in the office area and are considered a consequence of an
IP flood attack. To prevent such attacks, configure ARP source suppression and ARP blackhole routing.
338
If the attack packets have the same source address, you can enable the ARP source suppression function
as follows:
1.
Enable ARP source suppression.
2.
Set the threshold to 100. If the number of unresolvable IP packets received from a host within 5
seconds exceeds 100, the device stops resolving packets from the host until the 5 seconds elapse.
If the attack packets have different source addresses, enable the ARP blackhole routing function on the
AC.
# Enable ARP source suppression and set the threshold to 100.
<AC> system-view
[AC] arp source-suppression enable
[AC] arp source-suppression limit 100
# Enable ARP blackhole routing.

[AC] arp resolving-route enable
Configuring ARP packet rate limit

The ARP packet rate limit feature allows you to limit the rate of ARP packets to be delivered to the CPU.
For example, if an attacker sends a large number of ARP packets to an ARP detection enabled device, the
CPU of the device becomes overloaded because all the ARP packets are redirected to the CPU for
inspection. As a result, the device is unable to provide other functions or can crash. To solve this problem,
configure ARP packet rate limit.
Configure this feature when ARP detection, ARP snooping, or ARP fast-reply is enabled, or when ARP
flood attacks are detected.
To configure ARP packet rate limit:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet interface/Layer

2 aggregate interface/WLAN-ESS
interface view.
N/A
Configure or disable ARP packet rate

limit.
arp rate-limit { disable | rate pps drop }
3.

detection
This feature checks the number of ARP packets received from the same MAC address within 5 seconds
against a specific threshold. If the threshold is exceeded, the device adds the MAC address in an ARP
attack entry.
Before the entry is aged out, the device handles the attack by using either of the following methods:
339
MonitorOnly generates log messages.
FilterGenerates log messages and filters out subsequent ARP packets from that MAC address.
After an ARP attack detection entry expires, ARP packets sourced from the MAC address in the entry can
be processed correctly.
You can exclude the MAC addresses of some gateways and servers from detection. This feature does not
inspect ARP packets from those devices even if they are attackers.
Only the ARP packets delivered to the CPU are checked.
To configure source MAC-based ARP attack detection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable source MAC-based

ARP attack detection and
specify the handling method.
arp anti-attack source-mac { filter |

monitor }
3.
Configure the threshold.
arp anti-attack source-mac threshold

threshold-value
Optional.
4.
Configure the lifetime for ARP

attack entries.
arp anti-attack source-mac aging-time

time
Optional.
Configure excluded MAC

addresses.
arp anti-attack source-mac exclude-mac

mac-address&<1-10>
5.
The threshold is 50.

Optional.
No MAC address is excluded
by default.
Displaying and maintaining source MAC-based ARP attack

detection
Task
Command
Remarks
Display attacking MAC addresses

detected by source MAC-based ARP
attack detection.
display arp anti-attack source-mac

[ interface interface-type
interface-number ] [ | { begin | exclude |
Source MAC-based ARP attack detection configuration

example
340
As shown in Figure 126, the hosts access the Internet through a gateway (AC). If malicious users send a
large number of ARP requests to the gateway, the gateway might crash and cannot process requests from
the clients. To solve this problem, configure source MAC-based ARP attack detection on the gateway.
An attacker might forge a large number of ARP packets by using the MAC address of a valid host as the
source MAC address. To prevent such attacks, configure the gateway as follows:
1.
Enable source MAC-based ARP attack detection and specify the handling method.
2.
Set the threshold.
3.
Set the lifetime for ARP attack entries.
4.
Exclude the MAC address of the server from this detection
# Enable source MAC-based ARP attack detection and specify the handling method.
<AC> system-view
[AC] arp source-mac filter
# Set the threshold to 30.

[AC] arp source-mac threshold 30
# Set the lifetime for ARP attack entries to 60 seconds.

[AC] arp source-mac aging-time 60
341
# Exclude 0012-3f86-e94c from this detection.

[AC] arp source-mac exclude-mac 0012-3f86-e94c
Configuring ARP packet source MAC consistency

check
This feature enables a gateway to filter out ARP packets whose source MAC address in the Ethernet
header is different from the sender MAC address in the message body, so that the gateway can learn
correct ARP entries.
To enable ARP packet source MAC address consistency check:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable ARP packet source MAC

address consistency check.
arp anti-attack valid-check enable
Configuring ARP active acknowledgement

Configure this feature on gateway devices to prevent user spoofing.
ARP active acknowledgement prevents a gateway from generating incorrect ARP entries. For more
information about its working mechanism, see ARP Attack Protection Technology White Paper.
To configure ARP active acknowledgement:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the ARP active

acknowledgement function.
arp anti-attack active-ack enable
Configuring authorized ARP

Authorized ARP entries are generated based on the DHCP clients' address leases on the DHCP server or
dynamic client entries on the DHCP relay agent.
With authorized ARP enabled, an interface is disabled from learning dynamic ARP entries to prevent user
spoofing and allows only authorized clients to access network resources.
Follow these guidelines when you configure authorized ARP:
This feature is only supported on VLAN interfaces.
With the arp authorized enable command executed, an interface of a DHCP server (or a DHCP
relay agent) that does not support authorized ARP is disabled from dynamically learning ARP
entries and cannot generate authorized ARP entries.
342
Static ARP entries can overwrite authorized ARP entries, and authorized ARP entries can overwrite
dynamic ARP entries. But authorized ARP entries cannot overwrite static ARP entries, and dynamic
ARP entries cannot overwrite authorized ARP entries.
For more information about DHCP server and DHCP relay agent, see Layer 3 Configuration Guide.
To enable authorized ARP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
Configure the DHCP server (or

DHCP relay agent) to support
authorized ARP.
dhcp update arp
Enable authorized ARP on the

interface.
arp authorized enable
4.
Authorized ARP configuration example (on a DHCP server)

Configure the DHCP server with an IP address pool of 10.1.1.0/24 on the AC.
Enable authorized ARP on VLAN-interface 10 of the AC to ensure user validity.
Configure the DHCP client to obtain an IP address from the DHCP server.
# Configure the client in VLAN 10 to connect the AC through the interface WLAN-ESS 0. (Details not
shown.)
# Configure DHCP.
<AC> system-view
343
[AC] dhcp enable

[AC] dhcp server ip-pool 10
[AC-dhcp-pool-10] network 10.1.1.0 mask 255.255.255.0
[AC-dhcp-pool-10] gateway-list 10.1.1.1
[AC-dhcp-pool-10] quit
# Configure the IP address of VLAN-interface 10.

# Enable authorized ARP.

[AC-Vlan-interface10] dhcp update arp
[AC-Vlan-interface10] arp authorized enable
# After the client obtains an IP address from the AC, display information about the authorized ARP entry
generated based on the lease.
[AC] display arp
Type: S-Static
D-Dynamic
A-Authorized
IP Address
MAC Address
VLAN ID
Interface
Aging Type
10.1.1.2
0000-8279-aa02
10
WLAN-DBSS5:52
N/A
The output shows that the AC assigned an IP address 10.1.1.2 to the client.
The client must use the IP address and MAC address in the authorized ARP entry to communicate with the
AC. Otherwise, the communication fails, and user validity is ensured.
Authorized ARP configuration example (on a DHCP relay

agent)
Configure the device as a DHCP server with an IP address pool of 10.1.1.0/24.
Configure the AC as a DHCP relay agent. Enable authorized ARP on VLAN-interface 10 of the AC to
ensure user validity.
Configure the client as a DHCP client to obtain an IP address.
344

DHCP Server
Device
10.2.1.2/24
DHCP Relay
DHCP Client
VLAN 10
10.1.1.1/24
AC
Switch
AP
Client
1.
Configure the DHCP server:

[Device] dhcp enable
[Device] dhcp server ip-pool 10
[Device-dhcp-pool-10] network 10.1.1.0 mask 255.255.255.0
[Device-dhcp-pool-10] gateway-list 10.1.1.1
[Device] interface vlan-interface 20
[Device-Vlan-interface20] ip address 10.2.1.2 255.255.255.0
[Device-Vlan-interface20] quit
2.
Configure the AC:

# Configure the client in VLAN 10 to connect the AC through the interface WLAN-ESS 0. (Details
not shown.)
# Enable DHCP.
<AC> system-view
[AC] dhcp enable
# Configure the IP address of the DHCP server.

# Configure the IP address of VLAN-interface 10.

# Enable DHCP relay agent on VLAN-interface 10.

# Correlate VLAN-interface 10 to DHCP server group 1.

# Enable authorized ARP.

[AC-Vlan-interface10] dhcp update arp
[AC-Vlan-interface10] arp authorized enable
# After the client obtains the IP address from Switch, display information about the authorized ARP
entry generated based on the lease.
[AC] display arp
Type: S-Static
D-Dynamic
345
A-Authorized
IP Address
MAC Address
VLAN ID
Interface
Aging Type
10.1.1.2
0000-8279-aa02
10
WLAN-DBSS5:52
N/A
The output shows that the AC assigned an IP address 10.1.1.2 to the client.
The client must use the IP address and MAC address in the authorized ARP entry to communicate
with AC. Otherwise, the communication fails, and the user validity is ensured.
Configuring ARP detection

ARP detection enables access devices to block ARP packets from unauthorized clients to prevent user
spoofing and gateway spoofing attacks.
ARP detection provides the following functions:
User validity check
ARP packet validity check
ARP restricted forwarding
If both ARP packet validity check and user validity check are enabled, ARP packet validity check applies
first, and then user validity check applies.
ARP detection does not check ARP packets received from ARP trusted ports.
Configuring user validity check

After you enable this feature, the device checks user validity as follows:
1.
Upon receiving an ARP packet from an ARP untrusted port, the device compares the sender IP and
MAC addresses of the ARP packet against user validity check rules. If a matching rule is found, the
ARP packet is processed according to the rule.
2.
If no matching rule is found, the device compares the ARP packet's sender IP and MAC addresses
against the DHCP snooping entries and 802.1X security entries. If a match is found in any of the
entries, the ARP packet is considered valid and is forwarded.
3.
If no match is found, the ARP packet is considered invalid and is discarded.
Dynamic DHCP snooping entries are automatically generated by DHCP snooping. For more information,
see Layer 3 Configuration Guide.
802.1X security entries are generated by 802.1X. After a client passes 802.1X authentication and
uploads its IP address to an ARP detection enabled device, the device automatically generates an 802.1X
security entry. The 802.1X client must be enabled to upload its IP address to the device. For more
information, see "Configuring 802.1X."
To configure user validity check:
Step
1.
2.
3.
Command
Remarks
Enter system view.
system-view
N/A
Configure a user validity check

rule.
arp detection id-number { deny |

permit } ip { any | ip-address
[ ip-address-mask ] } mac { any |
mac-address [ mac-address-mask ] }
[ vlan vlan-id ]
Enter VLAN view.
vlan vlan-id
346
Optional.
N/A
Step
Command
Remarks
4.
Enable ARP detection.
arp detection enable
5.
quit
N/A
6.
Enter Layer 2 Ethernet interface

view/Layer 2 aggregate
interface/WLAN-ESS interface
view.
interface-number
N/A
Configure the port as a trusted

port that is excluded from ARP
detection.
arp detection trust
7.
Optional.
A port is an untrusted port
by default.
At least a user validity check rule, a DHCP snooping entry, or an 802.1X security entry must be available
to perform user validity check. Otherwise, ARP packets received from ARP untrusted ports are discarded.
Configuring ARP packet validity check

Perform this task to enable validity check for ARP packets received on untrusted ports and specify the
following objects to be checked:
src-macChecks whether the sender MAC address in the message body is identical to the source
MAC address in the Ethernet header. If they are identical, the packet is forwarded. Otherwise, the
packet is discarded.
dst-macChecks the target MAC address of ARP replies. If the target MAC address is all-zero,
all-one, or inconsistent with the destination MAC address in the Ethernet header, the packet is
considered invalid and discarded.
ipChecks the sender and target IP addresses of ARP replies, and the sender IP address of ARP
requests. All-zero, all-one, or multicast IP addresses are considered invalid and the corresponding
packets are discarded.
To configure ARP packet validity check:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VLAN view.
vlan vlan-id
N/A
3.
Enable ARP detection.
arp detection enable
4.
quit
N/A
5.
Enable ARP packet validity check

and specify the objects to be
checked.
arp detection validate { dst-mac | ip |

src-mac } *

view/Layer 2 aggregate
interface/WLAN-ESS interface
view.
interface-number
N/A
6.
7.
Configure the port as a trusted

port that is excluded from ARP
detection.
Optional.
arp detection trust
347
The port is an untrusted

port by default.
Configuring ARP restricted forwarding

ARP restricted forwarding controls the forwarding of ARP packets that are received on untrusted
interfaces and have passed user validity check as follows:
If the packets are ARP requests, they are forwarded through the trusted interface.
If the packets are ARP replies, they are forwarded according to their destination MAC address. If no
match is found in the MAC address table, they are forwarded through the trusted interface.
Before configuring this feature, configure user validity check.

To enable ARP restricted forwarding:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VLAN view.
vlan vlan-id
N/A
3.
Enable ARP restricted

forwarding.
arp restricted-forwarding enable
Displaying and maintaining ARP detection

Task
Command
Remarks
Display the VLANs enabled

with ARP detection.
display arp detection [ | { begin | exclude |

Display the ARP detection

statistics.
display arp detection statistics [ interface

interface-type interface-number ] [ | { begin |
Clear the ARP detection

statistics.
reset arp detection statistics [ interface

interface-type interface-number ]
User validity check configuration example

Configure the DHCP server on the device.

348
Configure 802.1X on the AC.
Enable ARP detection in VLAN 10 to check user validity based on 802.1X entries.
Configure Client 1 and Client 2 as 802.1X users.

Gateway
DHCP server
Device
10.1.1.1/24
Radius server
DHCP snooping
Switch
AP1
Client 1
DHCP client
AC
AP2
Client 2
10.1.1.6
0001-0203-0607
1.
Add the port connecting the device on the switch to VLAN 10, and configure the IP address of
VLAN-interface 10 on the device. (Details not shown.)
2.
Configure DHCP address pool 0 on the device.

3.
Configure Client 1 and Client 2 as 802.1X clients and configure them to upload IP addresses for
ARP detection. (Details not shown.)
4.
Configure the RADIUS server. (Details not shown.)
5.
Configure the AC:

# Create RADIUS scheme rad.
[AC] radius scheme rad
# Set the IP address of the primary authentication server to 8.1.1.16.

[AC-radius-rad] primary authentication 8.1.1.16
# Set the IP address of the primary accounting server to 8.1.1.16.

[AC-radius-rad] primary accounting 8.1.1.16
# Set the shared key to expert for the AC and the authentication server to exchange packets.
[AC-radius-rad] key authentication expert
# Set the shared key for the AC and the accounting server to exchange packets
[AC-radius-rad] key accounting expert
349
# Set the service type of the RADIUS server to extended.

[AC-radius-rad] server-type extended
# Exclude the domain name from the username sent to the RADIUS server.
[AC-radius-rad] user-name-format without-domain
[AC-radius-rad] quit
# Create ISP domain imc.

[AC] domain imc
# Configure RADIUS authentication, authorization, and accounting for LAN access users.
[AC-isp-imc] authentication lan-access radius-scheme rad
[AC-isp-imc] authorization lan-access radius-scheme rad
[AC-isp-imc] accounting lan-access radius-scheme rad
[AC-isp-imc] quit
# Set the default ISP domain to imc.

[AC] domain default enable imc

# Configure EAP relay for 802.1X user authentication.

# Enable wireless 802.1X authentication on the AC.

<AC> system-view
[AC-WLAN-ESS0] port access vlan 10
[AC-WLAN-ESS0] quit
# Configure a clear-type WLAN service template, set the service set identifier (SSID) to dot1x, and
bind the WLAN-ESS port to the template.
# Enable open system authentication.

# Enable TKIP cipher suite.

# Enable the WPA-IE in the beacon and probe responses.

[AC-wlan-st-1] quit
# Create AP template 2100 with the model MSM460-WW and serial number CN2AD330S8.
# Bind the WLAN service template to radio 1, and enable the radio.
350
# The ports connecting the AC and APs reside in VLAN 1 by default. Configure the IP address for
the VLAN interface on the AC and APs. (Details not shown.)
# Enable ARP detection for VLAN 10 to check user validity based on 802.1X entries.
[AC] vlan 10
[AC-vlan10] arp detection enable
# Configure the upstream port as a trusted port. The downstream WLAN-ESS port uses the default
setting untrusted.
[AC-vlan10] interface ten-gigabitethernet 1/0/1
[AC-Ten-GigabitEthernet1/0/1] arp detection trust
[AC-Ten-GigabitEthernet1/0/1] quit
After the configuration, the AC checks ARP packets received on WLAN-ESS 0 against 802.1X
entries.
User validity check and ARP packet validity check

configuration example
Configure the device as a DHCP server.
Enable DHCP snooping on the AC.
Configure Client 1 as a DHCP client. Configure Client 2's IP address 10.1.1.6 and MAC address
0001-0203-0607.
Enable user validity check and ARP packet validity check in VLAN 10.
351
1.
Add the port connecting the device on the switch to VLAN 10, and configure the IP address of
VLAN-interface 10 on the device. (Details not shown.)
2.
Configure DHCP address pool 0 on the device.

3.
Configure DHCP clients Client 1 and Client 2. (Details not shown.)
4.
Configure the AC:

# Create a WLAN-ESS interface and add the interface to VLAN 10.
<AC> system-view
[AC-WLAN-ESS0] port access vlan 10
[AC-WLAN-ESS0] quit
# Configure a clear-type WLAN service template, set the SSID to test, and bind the WLAN-ESS
interface to the template.
[AC-wlan-st-1] ssid test
# Create AP template 2100 with the model MSM460-WW and serial number CN2AD330S8.
# Bind the WLAN service template to radio 1, and enable the radio.
352
# The ports connecting the AC and APs reside in VLAN 1 by default. Configure the IP address of
the VLAN interface on the AC and APs. (Details not shown.)
# Enable DHCP snooping.
<AC> system-view
[AC] dhcp-snooping
[AC] interface ten-gigabitethernet 1/0/1
[AC-Ten-GigabitEthernet1/0/1] dhcp-snooping trust
# Enable ARP detection for VLAN 10 to check user validity.

[AC] vlan 10
[AC-vlan10] arp detection enable
# Configure the upstream port as a trusted port and the downstream ports as untrusted ports (a port
is an untrusted port by default).
[AC-vlan10] interface ten-gigabitethernet 1/0/1
[AC-Ten-GigabitEthernet1/0/1] arp detection trust
# Enable ARP packet validity check.

[AC] arp detection validate dst-mac ip src-mac
After the configuration, the AC will first check the validity of ARP packets received on the
WLAN-ESS interface, and then check the ARP packets against DHCP snooping entries.
Configuring ARP gateway protection

Configure this feature on interfaces not connected with the gateway to prevent gateway spoofing attacks.
When such a port receives an ARP packet, it checks whether the sender IP address in the packet is
consistent with that of any protected gateway. If yes, it discards the packet. If not, it handles the packet
correctly.
Follow these guidelines when you configure ARP gateway protection:
You can enable ARP gateway protection for up to eight gateways on a port.
Commands arp filter source and arp filter binding cannot be both configured on a port.
If ARP gateway protection works with ARP detection, ARP snooping, and ARP fast-reply, ARP
gateway protection applies first.
To configure ARP gateway protection:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet interface or

interface-number
N/A
3.
Enable ARP gateway protection for

a specific gateway.
arp filter source ip-address
353
As shown in Figure 131, Client 2 launches gateway spoofing attacks to the AC. As a result, traffic that the
AC intends to send to the gateway is sent to Client 2.
Configure the AC to block such attacks.
Gateway
Device
10.1.1.1/24
Switch
AP 1
Client 1
AC
AP 2
Client 2
# Configure the clients to connect the AC through interface WLAN-ESS 0. (Details not shown.)
# Configure ARP gateway protection on the AC.
<AC> system-view
[AC-WLAN-ESS0] arp filter source 10.1.1.1
[AC-WLAN-ESS0] quit
After the configuration is complete, the AC discards the ARP packets whose source IP address is that of
the gateway.
354
Configuring ARP filtering

The ARP filtering feature can prevent gateway spoofing and user spoofing attacks.
An interface enabled with this feature checks the sender IP and MAC addresses in a received ARP packet
against permitted entries. If a match is found, the packet is handled correctly. If not, the packet is
discarded.
Follow these guidelines when you configure ARP filtering:
You can configure up to eight permitted entries on an interface.
The arp filter source and arp filter binding commands cannot be both configured on an interface.
If ARP filtering works with ARP detection, ARP snooping, and ARP fast-reply, ARP filtering applies
first.
To configure ARP filtering:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.

or WLAN-ESS interface view.
N/A
3.
Enable ARP filtering and

configure a permitted entry.
arp filter binding ip-address

mac-address
As shown in Figure 132, the IP and MAC addresses of Client 1 are 10.1.1.2 and 000f-e349-1233. The IP
and MAC addresses of Client 2 are 10.1.1.3 and 000f-e349-1234.
Configure ARP filtering on GigabitEthernet 1/0/1 of the AC to permit ARP packets from the two hosts
only.
355
# Configure wireless services and the AP, and configure the radio port as WLAN-ESS 0. (Details not
shown.)
# Configure ARP filtering on the AC.
<AC> system-view
[AC-WLAN-ESS0] arp filter binding 10.1.1.2 000f-e349-1233
[AC-WLAN-ESS0] arp filter binding 10.1.1.3 000f-e349-1234
After the configuration is complete, GigabitEthernet 1/0/1 permits ARP packets from Client 1 and Client
2, and discards other ARP packets.
356
Configuring IPsec
The term "router" in this document refers to both routers and routing-capable HP wireless products.
All HP wireless products support IPsec between ACs and APs. Only HP 830 series PoE+ unified
wired-WLAN switches support IPsec between ACs.
Overview
IP Security (IPsec) is a security framework defined by the IETF for securing IP communications. It transmits
data in a secure tunnel established between two endpoints.
IPsec provides the following security services in insecure network environments:
ConfidentialityThe sender encrypts packets before transmitting them over the Internet. This
protects the packets from being eavesdropped en route.
Data integrityThe receiver verifies the packets received from the sender to make sure they are not
tampered with during transmission.
Data origin authenticationThe receiver verifies the authenticity of the sender.
Anti-replayThe receiver examines packets and drops outdated and duplicate packets.
IPsec delivers the following benefits:
Reduced key negotiation overheads and simplified maintenance by supporting the IKE protocol.
IKE provides automatic key negotiation and automatic IPsec security association (SA) setup and
maintenance.
Good compatibility. You can apply IPsec to all IP-based application systems and services without
modifying them.
Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for flexibility
and greatly enhances IP security.
IPsec includes a set of protocols, including Authentication Header (AH), Encapsulating Security Payload
(ESP), Internet Key Exchange (IKE), and algorithms for authentication and encryption. AH and ESP
provides security services and IKE performs automatic key exchange. For more information about IKE,
see "Configuring IKE."
Basic concepts
Security protocols
IPsec comes with two security protocols:
AH (protocol 51)Provides data origin authentication, data integrity, and anti-replay services by
adding an AH header to each IP packet. AH is suitable only for transmitting non-critical data
because it cannot prevent eavesdropping, although it can prevent data tampering. AH supports
authentication algorithms such as MD5 and SHA-1.
ESP (protocol 50)Provides data encryption as well as data origin authentication, data integrity,
and anti-replay services by inserting an ESP header and an ESP trailer in IP packets. Unlike AH, ESP
encrypts data before encapsulating the data to guarantee data confidentiality. ESP supports
357
encryption algorithms such as DES, 3DES, and AES, and authentication algorithms such as MD5
and SHA-1. The authentication function is optional to ESP.
Both AH and ESP provide authentication services, but the authentication service provided by AH is
stronger. In practice, you can choose either or both security protocols. When both AH and ESP are used,
an IP packet is encapsulated first by ESP, and then by AH. Figure 133 shows the format of IPsec packets.
Security association
A security association is an agreement negotiated between two communicating parties called IPsec
peers. It includes a set of parameters for data protection, including security protocols, encapsulation
mode, authentication and encryption algorithms, and shared keys and their lifetime. SAs can be set up
manually or through IKE.
An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional
communication. If two peers want to use both AH and ESP to protect data flows between them, they
construct an independent SA for each protocol.
An SA is identified by a triplet, which consists of the security parameter index (SPI), destination IP address,
and security protocol identifier (AH or ESP).
An SPI is a 32-bit number for uniquely identifying an SA. It is transmitted in the AH/ESP header. A
manually configured SA requires an SPI to be specified manually for it. An IKE-created SA will have an
SPI generated at random.
A manually configured SA never ages out. An IKE created SA has a specific period of lifetime, which
comes in two types:
Time-based lifetimeDefines how long the SA can be valid after it is created.
Traffic-based lifetimeDefines the maximum traffic that the SA can process.
The SA becomes invalid when either of the lifetime timers expires. Before the SA expires, IKE negotiates
a new SA, which takes over immediately after its creation.
Encapsulation modes
IPsec supports the following IP packet encapsulation modes:
Tunnel modeIPsec protects the entire IP packet, including both the IP header and the payload. It
uses the entire IP packet to calculate an AH or ESP header, and then encapsulates the original IP
packet and the AH or ESP header with a new IP header. If you use ESP, an ESP trailer is also
encapsulated. Typically, tunnel mode is used for protecting gateway-to-gateway communications.
Transport modeIPsec protects only the IP payload. It uses only the IP payload to calculate the AH
or ESP header, and inserts the calculated header between the original IP header and payload. If
you use ESP, an ESP trailer is also encapsulated. Typically, the transport mode is used for protecting
host-to-host or host-to-gateway communications.
NOTE:
IPsec between an AC and an AP supports only the tunnel mode.
Figure 133 shows how the security protocols encapsulate an IP packet in different encapsulation modes.
358
Figure 133 Encapsulation by security protocols in different modes
Authentication algorithms and encryption algorithms
Authentication algorithms:
IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length
digest for an arbitrary-length message. IPsec peers calculate message digests for each packet. If
the resulting digests are identical, the packet is considered intact.
IPsec supports the following hash algorithms for authentication:
{
{
MD5Takes a message of arbitrary length as input and produces a 128-bit message digest.
SHA-1Takes a message of a maximum length less than the 64th power of 2 in bits as input
and produces a 160-bit message digest.
Compared with SHA-1, MD5 is faster but less secure.
Encryption algorithms:
IPsec mainly uses symmetric encryption algorithms, which encrypt and decrypt data by using the
same keys. The following encryption algorithms are available for IPsec on the device:
{
DESEncrypts a 64-bit plain text block with a 56-bit key. DES is the least secure but the fastest
algorithm. It is sufficient for general security requirements.
3DESEncrypts plain text data with three 56-bit DES keys. The key length totals up to 168 bits.
It provides moderate security strength and is slower than DES.
AESEncrypts plain text data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest
security strength and is slower than 3DES.
IPsec SA setup modes

There are two IPsec SA setup modes:
Manual modeIn this mode, you manually configure and maintain all SA settings. Advanced
features like periodical key update are not available. However, this mode implements IPsec
independently of IKE.
ISAKMP modeIn this mode, IKE automatically negotiates and maintains IPsec SAs for IPsec.
IPsec tunnel
An IPsec tunnel is a bidirectional channel created between two peers. An IPsec tunnel includes one or
more pairs of SAs.
359
IPsec stateful failover

The IPsec stateful failover function enables hot backup of IPsec service data between two devices. It is
usually deployed on two redundant gateways at the headquarters to improve the availability of IPsec
service.
The IPsec stateful failover function must work with the stateful failover feature and the VRRP feature.
The two devices in IPsec stateful failover must join the same VRRP group to act as a single virtual device.
They use the virtual IP address of the virtual device to communicate with remote devices.
The IPsec stateful failover function can operate only in standard VRRP mode. In this mode, the master
processes and forwards IPsec traffic, and the backup device only synchronizes IPsec service data with the
master. When the master fails, the backup immediately takes over to forward IPsec traffic. This switchover
process is transparent to remote devices. No extra configuration is required on remote devices, and no
IPsec re-negotiation is required after the switchover.
Figure 134 IPsec stateful failover
LAN
Virtual router 2
Master
Backup
Failover link
Device B
Virtual router 1
nn
e
Device A
IP
se
c
tu
Internet
Device C
LAN
As shown in Figure 134, Device A and Device B form an IPsec stateful failover system and Device A is
elected the master in the VRRP group. When Device A works correctly, it establishes an IPsec tunnel to
Device C, and synchronizes its IPsec service data to Device B. The synchronized IPsec service data
includes the IKE SA, IPsec SAs, anti-replay sequence number and window, SA lifetime in bytes, and DPD
packet sequence number. Based on the IPsec service data, Device B creates standby IKE SA and standby
IPsec SAs to back up the active IKE SA and active IPsec SAs on Device A. When Device A fails, the VRRP
mechanism switches IPsec traffic from Device A to Device B. Because Device B has an instant copy of
Device A's IPsec service data, Device B can process IPsec traffic immediately to provide nonstop IPsec
service.
360
RFC 2401, Security Architecture for the Internet Protocol
RFC 2402, IP Authentication Header
RFC 2406, IP Encapsulating Security Payload
RFC 4301, Security Architecture for the Internet Protocol
RFC 4302, IP Authentication Header
RFC 4303, IP Encapsulating Security Payload (ESP)
Implementing ACL-based IPsec

The following is the generic configuration procedure for implementing ACL-based IPsec:
1.
Configure an ACL for identifying data flows to be protected.
2.
Configure IPsec transform sets to specify the security protocols, and authentication and encryption
algorithms.
3.
Configure an IPsec policy group to associate data flows with the IPsec transform sets and specify
the SA negotiation mode, the peer IP addresses (the start and end points of the IPsec path), the
required keys, and the SA lifetime.
4.
Apply the IPsec policies to interfaces to finish IPsec configuration.
Complete the following tasks to configure ACL-based IPsec:

Task
Remarks
Configuring an ACL
Configuring an IPsec transform set
Required.
Configuring an IPsec policy

Applying an IPsec policy group to an interface
Configuring the IPsec anti-replay function
Enabling invalid SPI recovery
Optional.
Configuring IPsec stateful failover
Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and
50. Make sure that flows of these protocols are not denied on the interfaces with IKE or IPsec configured.
Configuring an ACL
ACLs can be used to identify traffic. They are widely used in scenarios where traffic identification is
desired, such as QoS and IPsec.
Keywords in ACL rules

IPsec uses ACLs to identify data flows. An ACL is a collection of ACL rules. Each ACL rule is a deny or
permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement
identifies a data flow that is not protected by IPsec. With IPsec, a packet is matched against the
referenced ACL rules and processed according to the first rule that it matches:
361
Each ACL rule matches both the outbound traffic and the returned inbound traffic. Suppose there is
a rule rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255. This rule matches
both traffic from 1.1.1.0 to 2.2.2.0 and traffic from 2.2.2.0 to 1.1.1.0.
In the outbound direction, if a permit statement is matched, IPsec considers that the packet requires
protection and continues to process it. If a deny statement is matched or no match is found, IPsec
considers that the packet does not require protection, and it delivers the packet to the next function
module.
In the inbound direction:

{
{
Non-IPsec packets that match a permit statement are dropped.

IPsec packets destined for the device itself are de-encapsulated. The de-encapsulated packets
are compared against the ACL rules. Only those that match a permit statement are processed by
other modules. Other packets are dropped.
When defining ACL rules for IPsec, follow these guidelines:
Permit only data flows that need to be protected and use the any keyword with caution. With the
any keyword specified in a permit statement, all outbound traffic matching the permit statement is
protected by IPsec and all inbound IPsec packets matching the permit statement is received and
processed. However, all inbound non-IPsec packets are dropped. This causes all the inbound traffic
that does not need IPsec protection to be dropped.
Avoid statement conflicts in the scope of IPsec policy groups. When creating a deny statement, be
careful with its matching scope and matching order relative to permit statements. The policies in an
IPsec policy group have different match priorities. ACL rule conflicts between them are prone to
cause mistreatment of packets. For example, when configuring a permit statement for an IPsec
policy to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches
a deny statement in a higher priority IPsec policy. Otherwise, the packets are sent out as normal
packets. If they match a permit statement at the receiving end, they are dropped by IPsec.
The following configuration example shows how an improper statement causes unexpected packet
dropping. Only the ACL-related configurations are presented.
Router A connects the segment 1.1.2.0/24 and Router B connects the segment 3.3.3.0/24. On Router A,
apply the IPsec policy group test to the outbound interface of Router A. The IPsec policy group contains
two policies, test 1 and test 2. The ACLs referenced by the two policies each contain a rule that matches
traffic from 1.1.2.0/24 to 3.3.3.0/24. The one referenced in policy test 1 is a deny statement and the one
referenced in policy test 2 is a permit statement. Because test 1 is matched before test 2, traffic from
1.1.2.0/24 to 3.3.3.0/24 matches the deny statement and is sent as normal traffic. When the traffic
arrives at Router B, it is dropped if it matches a permit statement in the ACL referenced in the applied
IPsec policy.
Configure Router A:
acl number 3000
rule 0 permit ip source 1.1.1.0 0.0.0.255 destination 2.2.2.0 0.0.0.255
rule 1 deny ip
acl number 3001
rule 1 deny ip
#
ipsec policy test 1 isakmp
security acl 3000
ike-peer aa
transform-set 1
362
#
security acl 3001
ike-peer bb
transform-set 1
Configure Router B:
acl number 3001
rule 1 deny ip
#
security acl 3001
ike-peer aa
transform-set 1
Mirror image ACLs

To make sure that SAs can be set up and the traffic protected by IPsec can be processed correctly at the
remote peer, on the remote peer, create a mirror image ACL rule for each ACL rule created at the local
peer. As shown in Figure 135, ACL rules on Router B are mirror images of the rules on Router A. This
makes sure that SAs can be created successfully for the traffic between Host A and Host C and the traffic
between Network 1 and Network 2.
Figure 135 Mirror image ACLs
If the ACL rules on peers do not form mirror images of each other, SAs can be set up only when both of
the following requirements are met:
The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the other
peer. As shown in Figure 136, the range specified by the ACL rule configured on Router A is covered
by its counterpart on Router B.
The peer with the narrower rule initiates SA negotiation. If a wider ACL rule is used by the SA
initiator, the negotiation request might be rejected because the matching traffic is beyond the scope
of the responder. As shown in Figure 136, the SA negotiation initiated by Host A to Host C is
accepted, but the SA negotiations from Host C to Host B or from Host D to Host A is rejected.
363
Figure 136 Non-mirror image ACLs
Protection modes
Data flows can be protected in the following modes:
Standard modeOne tunnel protects one data flow. The data flow permitted by an ACL rule is
protected by one tunnel that is established solely for it.
Aggregation modeOne tunnel protects all data flows permitted by all the rules of an ACL. This
mode is configurable only in IPsec policies that use IKE negotiation.
Per-host modeOne tunnel protects one host-to-host data flow. One host-to-host data flow is
identified by one ACL rule and protected by one tunnel established solely for it. This mode is
configurable only in IPsec policies that use IKE negotiation.
For more information about ACL configuration, see ACL and QoS Configuration Guide.
To use IPsec in combination with QoS, make sure that IPsec's ACL classification rules match the QoS
classification rules. If the rules do not match, QoS might classify the packets of one IPsec SA to different
queues, causing packets to be sent out of order. When the anti-replay function is enabled, IPsec discards
the packets beyond the anti-replay window in the inbound direction, resulting in packet loss. For more
information about QoS classification rules, see ACL and QoS Configuration Guide.
Configuring an IPsec transform set

An IPsec transform set, part of an IPsec policy, defines the security parameters for IPsec SA negotiation,
including the security protocol, and the encryption and authentication algorithms.
You can configure up to 10000 IPsec transform sets in the system.
To configure an IPsec transform set:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IPsec transform set

and enter its view.
ipsec transform-set
transform-set-name
By default, no IPsec transform set

exists.
3.
Specify the security protocol

for the IPsec transform set.
transform { ah | ah-esp | esp }
364
Optional.
ESP by default.
Step
Command
Remarks
Specify the encryption

algorithm for ESP:
esp encryption-algorithm
{ 3des | aes-cbc-128 |
aes-cbc-192 | aes-cbc-256 |
des } *
4.
Specify the security

algorithms.
You configure security algorithms

for a security protocol only after
you specify the security protocol in
the IPsec transform set. For
example, you can specify the
ESP-specific security algorithms
only when you select ESP as the
security protocol. ESP supports
three IP packet protection schemes:
encryption only, authentication
only, or both encryption and
authentication.
In FIPS mode:
Specify the authentication
ESP does not support DES,
Specify the authentication
AH does not support MD5
algorithm for ESP:

esp authentication-algorithm
{ md5 | sha1 } *
algorithm for AH:
ah authentication-algorithm
{ md5 | sha1 } *
3DES, or MD5. It uses AES-128

for encryption and SHA-1 for
authentication by default.
authentication, and it uses
SHA-1 for authentication.
You must specify both an

encryption algorithm and an
authentication algorithm.
In non-FIPS mode:
ESP uses DES for encryption

and MD5 for authentication by
default.
AH uses MD5 for

authentication by default.
Optional.
5.
Specify the IP packet

encapsulation mode for the
IPsec transform set.
encapsulation-mode { transport |
tunnel }
Tunnel mode by default.

Transport mode applies only when
the source and destination IP
addresses of data flows match
those of the IPsec tunnel.
Changes to an IPsec transform set affect only SAs negotiated after the changes. To apply the changes to
existing SAs, execute the reset ipsec sa command to clear the SAs so that they can be set up using the
updated parameters.
Configuring an IPsec policy

IPsec policies define which IPsec transform sets should be used to protect which data flows. An IPsec
policy is uniquely identified by its name and sequence number.
IPsec policies are divided into the following categories:
Manual IPsec policyThe parameters are configured manually, such as the keys, the SPIs, and the
IP addresses of the two ends in tunnel mode.
365
IKE-based IPsec policyThe parameters are automatically negotiated through IKE.
Configuring a manual IPsec policy

When you configure a manual IPsec policy, make sure the IPsec configuration at both ends of the IPsec
tunnel meets the following requirements:
The IPsec policies at the two ends must have IPsec proposals that use the same security protocols,
security algorithms, and encapsulation mode.
The remote IP address configured on the local end must be the same as the IP address of the remote
end.
At each end, configure parameters for both the inbound SA and the outbound SA and make sure
that different SAs use different SPIs.
The local inbound SA must use the same SPI and keys as the remote outbound SA. The same is true
of the local outbound SA and remote inbound SA.
The keys for the local and remote inbound and outbound SAs must be in the same format. For
example, if the local inbound SA uses a key in characters, the local outbound SA and remote
inbound and outbound SAs must use keys in characters.
To configure a manual IPsec policy:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a manual IPsec

policy and enter its view.
ipsec policy policy-name

seq-number manual
By default, no IPsec policy exists.

By default, an IPsec policy references no
ACL.
3.
Assign an ACL to the

IPsec policy.
security acl acl-number
The ACL supports match criteria of the

VPN attribute.
An IPsec policy can reference only one
ACL. If you apply multiple ACLs to an
IPsec policy, only the last one takes
effect.
By default, an IPsec policy references no
IPsec proposal.
4.
Assign an IPsec proposal

to the IPsec policy.
proposal proposal-name
A manual IPsec policy can reference only

one IPsec proposal. To change an IPsec
proposal for an IPsec policy, you must
remove the reference first.
5.
Configure the local

address of the IPsec
tunnel
tunnel local ip-address
Configure the remote

address of the IPsec
tunnel
tunnel remote ip-address
Configure an SPI for an

SA.
sa spi { inbound | outbound } { ah

| esp } spi-number
By default, no SPI is configured for an

SA.
6.
7.
366
Step
Command
Remarks
Configure an authentication
key in hexadecimal for AH:
sa authentication-hex
{ inbound | outbound } ah
[ cipher string-key | simple
hex-key ]
key in characters for AH:
sa string-key { inbound |
outbound } ah [ cipher |
simple ] string-key
Configure a key in characters

8.
Configure keys for the

SA.
for ESP:
sa string-key { inbound |
outbound } esp [ cipher |
simple ] string-key
key in hexadecimal for ESP:

sa
authentication-hex.{ inbound
| outbound } esp [ cipher
string-key | simple hex-key ]
Configure keys correctly for the security

protocol (AH or ESP) you have specified.
If you configure a key in two modes:
string and hexadecimal, only the last
configured one is used.
ESP supports three IP packet protection
schemes: encryption only, authentication
only, or both encryption and
authentication.
If you configure a key in characters for
ESP, the device automatically generates
an authentication key and an encryption
key for ESP.
Configure an encryption key in

hexadecimal for ESP:
sa encryption-hex.{ inbound |
outbound } esp [ cipher
string-key | simple hex-key ]
NOTE:
You cannot change the creation mode of an IPsec policy from manual to through IKE, or vice versa. To
create an IKE-based IPsec policy, delete the manual IPsec policy, and then use IKE to configure an IPsec
policy.
Directly configuring an IKE-based IPsec policy

To configure an IKE-based IPsec policy, use one of the following methods:
Directly configure it by configuring the parameters in IPsec policy view.
Configure it by referencing an existing IPsec policy template with the parameters to be negotiated
configured. A device referencing an IPsec policy that is configured in this way cannot initiate SA
negotiation, but it can respond to a negotiation request. The parameters not defined in the template
are determined by the initiator. This method applies to scenarios where the remote end's
information, such as the IP address, is unknown.
Before you configure an IKE-based IPsec policy, complete the following tasks:
Configure the ACLs and the IPsec transform sets for the IPsec policy.
Configure the IKE peer. For more information about IKE peer configuration, see "Configuring IKE."
The parameters for the local and remote ends must match.
To configure an IKE-based IPsec policy directly:
367
Step
Command
Remark
1.
Enter system view.
system-view
N/A
2.
Create an IKE-based IPsec

policy and enter its view.

seq-number isakmp
3.
Configure an IPsec connection

name.
connection-name name
By default, no IPsec connection

name is configured.
4.
Assign an ACL to the IPsec

policy.

[ aggregation | per-host ]
By default, an IPsec policy

references no ACL.
5.
Assign IPsec transform sets to

the IPsec policy.
transform-set
transform-set-name&<1-6>

references no IPsec transform set.
6.
Specify an IKE peer for the

IPsec policy.
ike-peer peer-name
N/A
7.
Set the SA lifetime.
sa duration { time-based seconds |

traffic-based kilobytes }
Optional.
Optional.
By default, the global SA lifetime is
used.
Optional.
8.
9.
Set the anti-replay information

synchronization intervals in
IPsec stateful failover mode.
Enable the IPsec policy.
10. Return to system view.
synchronization
anti-replay-interval inbound
inbound-number outbound
outbound-number
policy enable
By default, the inbound anti-replay

window information is
synchronized whenever 1000
packets are received, and the
outbound anti-replay sequence
number is synchronized whenever
100000 packets are sent.
Support for this feature depends on
your device model. For more
Configuration Guides for HP
Optional.
Enabled by default.
N/A
quit
Optional.
11. Set the global SA lifetime.
ipsec sa global-duration
{ time-based seconds |
3600 seconds for time-based SA

lifetime by default.
1843200 kilobytes for
traffic-based SA lifetime by default.
Configuring an IKE-based IPsec policy by referencing an IPsec policy template

The parameters configurable for an IPsec policy template are the same as those you configure when
directly configuring an IKE-based IPsec policy.
Required configuration: The IPsec transform sets and IKE peer.
Optional configuration: The ACL. Unlike the direct configuration, ACL configuration to be
referenced by an IPsec policy is optional. The responder without ACL configuration accepts the
initiator's ACL configuration.
368
To configure an IKE-based IPsec policy by referencing an IPsec policy template:

Step
Command
Remark
1.
Enter system view.
system-view
N/A
2.
Create an IPsec policy

template and enter its view.
ipsec policy-template
template-name seq-number
By default, no IPsec policy template

exists.
3.
Specify the ACL for the IPsec

policy to reference.

references no ACL.
4.
Specify the IPsec transform

sets for the IPsec policy to
reference.
transform-set
transform-set-name&<1-6>

references no IPsec transform set.
5.
Specify the IKE peer for the

IPsec policy to reference.
ike-peer peer-name
N/A
6.
Configure the SA lifetime.
sa duration { time-based seconds |

Optional.
Optional.
By default, the global SA lifetime
settings are used.
Optional.
7.
Set the anti-replay information

synchronization intervals in
IPsec stateful failover mode.
synchronization
anti-replay-interval inbound
inbound-number outbound
outbound-number
8.
Enable the IPsec policy.
policy enable
9.
quit
By default, the inbound anti-replay

window information is
synchronized whenever 1000
packets are received, and the
outbound anti-replay sequence
number is synchronized whenever
100000 packets are sent.
Support for this feature depends on
your device model. For more
Configuration Guides for HP
Optional.
Enabled by default.
N/A
10. Configure the global SA

lifetime.
ipsec sa global-duration
{ time-based seconds |
11. Create an IPsec policy by

referencing an IPsec policy
template.

seq-number isakmp template
template-name
Optional.
By default, time-based SA lifetime
is 3600 seconds and traffic-based
SA lifetime is 1843200 kilobytes.
An IPsec policy can reference only one ACL. If you specify an ACL for an IPsec policy multiple times, the
most recent configuration takes effect.
With SAs to be established through IKE negotiation, an IPsec policy can reference up to six IPsec
transform sets. During negotiation, IKE searches for a fully matched IPsec transform set at the two ends of
the expected IPsec tunnel. If no match is found, no SA can be set up and the packets expecting to be
protected are dropped.
369
An SA uses the global lifetime settings when it is not configured with lifetime settings in IPsec policy view.
When negotiating to set up SAs, IKE uses the local lifetime settings or those proposed by the peer,
whichever are smaller.
You can set both the time-based SA lifetime and the traffic-based SA lifetime. Once the time-based
lifetime or traffic-based lifetime of an SA elapses, the SA is aged.
You cannot modify an IPsec policy created by referencing an IPsec policy template in IPsec policy view.
You can perform the modifications in IPsec policy template view.
You cannot directly modify the creation mode (direct creation or template-based creation) of an IPsec
policy. To do so, delete the IPsec policy, and then re-create the IPsec policy in the desired mode.
Applying an IPsec policy group to an interface

An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers.
In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority.
You can apply an IPsec policy group to an interface to protect certain data flows. To cancel the IPsec
protection, remove the application of the IPsec policy group.
For each packet to be sent out an IPsec protected interface, the system looks through the IPsec policies in
the IPsec policy group in ascending order of sequence numbers. If an IPsec policy matches the packet,
the system uses the IPsec policy to protect the packet. If no match is found, the system sends the packet out
without IPsec protection.
An interface can reference only one IPsec policy group. An IKE-based IPsec policy can be applied to
more than one interface. A manual IPsec policy can be applied to only one interface.
To apply an IPsec policy group to an interface:
Step
Command
1.
Enter system view.
system-view
2.
3.
Apply an IPsec policy group to the interface.
Configuring the IPsec anti-replay function

The IPsec anti-replay function protects networks against anti-replay attacks by using a sliding window
mechanism called anti-replay window. This function checks the sequence number of each received IPsec
packet against the current IPsec packet sequence number range of the sliding window. If the sequence
number is not in the current sequence number range, the packet is considered a replayed packet and is
discarded.
IPsec packet de-encapsulation involves complicated calculation. De-encapsulation of replayed packets
not only makes no sense, but also consumes large amounts of resources and degrades performance,
resulting in DoS. IPsec anti-replay checking, when enabled, is performed before the de-encapsulation
process, reducing resource waste.
In some cases, however, the sequence numbers of some normal service data packets might be out of the
current sequence number range, and the IPsec anti-replay function might drop them as well, affecting the
normal communications. If this happens, disable IPsec anti-replay checking or adjust the size of the
anti-replay window as required.
370
IPsec anti-replay checking does not affect manually created IPsec SAs. According to the IPsec protocol,
only IPsec SAs negotiated by IKE support anti-replay checking.
IMPORTANT:
IPsec anti-replay checking is enabled by default. Do not disable it unless it needs to be disabled.
A wider anti-replay window results in higher resource cost and more system performance degradation,
which is against the original intention of the IPsec anti-replay function. Specify an anti-replay window
size that is as small as possible.
To configure IPsec anti-replay checking:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable IPsec anti-replay

checking.
ipsec anti-replay check
Set the size of the IPsec

anti-replay window.
ipsec anti-replay window width
3.
Optional.
Enabled by default.
Optional.
32 by default.
Enabling invalid SPI recovery

When the security gateway at one end of an IPsec tunnel loses its SAs due to rebooting or any other
reason, its peer security gateway might not know the problem and sends IPsec packets to it. These
packets will be discarded by the receiver because the receiver cannot find appropriate SAs for them,
resulting in a traffic blackhole. The problem persists till the old SAs on the sender are aged out and new
SAs are established between the two peers. To prevent such service interruption, configure the invalid SPI
recovery feature.
The invalid SPI recovery feature allows the receiver to send an INVALID SPI NOTIFY message to tell the
sender the invalid SPIs. Upon receiving the message, the sender immediately deletes the corresponding
SAs. The subsequent traffic triggers the two peers to set up new SAs for data transmission.
Because attackers might exploit INVALID SPI NOTIFY messages to attack the IPsec packet sender (DoS
attack), the invalid SPI recovery feature is disabled by default, making the receiver discard packets with
invalid SPIs.
To enable invalid SPI recovery:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable invalid SPI recovery.
ipsec invalid-spi-recovery enable
Configuring IPsec stateful failover

In an IPsec stateful failover scenario, these restrictions apply:
VRRP must operate in the standard protocol mode.

371
Optional.
IPsec stateful failover supports only the active/standby failover mode.
RSA signature authentication is not supported in IKE negotiation.
The keepalive mechanism for IKE to maintain the link status of IKE SAs is not supported.
Before you configure IPsec stateful failover, complete the tasks in this section on the two devices.
1.

{
{
Configure the devices to operate in the active/standby mode.

Specify the interfaces between the devices as failover interfaces for transferring state
negotiation messages and backing up IPsec service data.
For more information about stateful failover, see High Availability Configuration Guide.
2.
Configure VRRP:
{
On each device, configure a VRRP group for the uplink interface and a VRRP group for the
downlink interface, and assign virtual IP addresses to the groups.
Set the priorities of the devices in the groups, making sure that one of the devices is the master
in both VRRP groups.
Configure the devices to operate in the same mode (preemption mode or non-preemptive mode)
in both VRRP groups. To deploy the preemption mode, set the preemption delay of the backup
device to 0 so the backup device can immediately take over when the priority of the master
comes down, and set the preemption delay of the backup to a bigger value such as 255
seconds so the master has enough time to synchronize IPsec service data with the backup device
after it recovers.
For more information about VRRP, see High Availability Configuration Guide.
3.
Configure IPsec and IKE:

{
{
{
Create and configure the same IKE peers on the two devices. The local gateway addresses of
the IKE peers must be the virtual IP address of the uplink VRRP group.
Create and configure the same IPsec policies or IPsec profiles that use IKE on the two devices.
Apply the IPsec policies or IPsec profiles to the uplink interfaces on the two devices. If you
change the virtual IP address after applying the IPsec policy to an interface, be sure to re-apply
the IPsec policy to the interface.
To implement IPsec stateful failover on two devices, you must enable IPsec stateful failover on both
devices.
To configure IPsec stateful failover on a device:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable IPsec stateful

failover.
ipsec synchronization enable
By default, IPsec stateful

failover is enabled.
372
Displaying and maintaining IPsec

Task
Command
Remarks
Display IPsec policy information.
display ipsec policy [ brief | name

policy-name [ seq-number ] ] [ | { begin |
Display IPsec policy template

information.
display ipsec policy-template [ brief | name

template-name [ seq-number ] ] [ | { begin |
Display IPsec transform set

information.
display ipsec transform-set

[ transform-set-name ] [ | { begin | exclude |

Display IPsec SA information.
display ipsec sa [ active | brief | policy

policy-name [ seq-number ] | remote
ip-address | standby ] [ | { begin | exclude |
Display IPsec packet statistics.
display ipsec statistics [ tunnel-id integer ] [ |

Support for the active and

standby keywords
depends on your device
model. For more
the Command References
for HP Unified
Display IPsec tunnel information.
display ipsec tunnel [ active | standby ] [ |


standby keywords
model. For more
for HP Unified
Clear SAs.
reset ipsec sa [ active | parameters

dest-address protocol spi | policy
policy-name [ seq-number ] | remote
ip-address | standby ]
Clear IPsec statistics.
reset ipsec statistics
373

standby keywords
model. For more
for HP Unified
IPsec configuration examples

Configuration example for IPsec between AC and AP

For more information, see WLAN Configuration Guide.
IPsec stateful failover for LWAPP protection configuration

example
A company uses ACs and APs to construct its internal network. IPsec and reliability are required between
ACs and APs.
Configure the ACs as follows:
Assign the ACs to the VLAN to which the AP belongs.
Configure stateful failover between AC 1 and AC 2. The ACs send heartbeat packets to each other
through the switch.
Set up an IPsec tunnel between AC 1 and the AP and an IPsec tunnel between AC 2 and the AP,
and set up connections based on the IPsec tunnels.
374
Configuring AC 1
<AC1> system-view
[AC1] interface Vlan-interface 1
# Enable stateful failover and set the stateful failover heartbeat interval.
[AC1] hot-backup hellointerval 100
# Set the IKE SA keepalive interval.

[AC1] ike sa keepalive-timer interval 20
# Set the IKE SA keepalive timeout.

[AC1] ike sa keepalive-timer timeout 60
# Enable invalid SPI recovery.

[AC1] ipsec invalid-spi-recovery enable
# Create an IPsec transform set named tran1.

[AC1] ipsec transform-set tran1
# Configure the IPsec transform set to use security protocol ESP, authentication algorithm SHA-1, and
encryption algorithm AES-CBC-128.
[AC1-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[AC1-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[AC1-ipsec-transform-set-tran1] quit
# Create IKE proposal 1.

[AC1] ike proposal 1
# Specify encryption algorithm AES-CBC-128 and DH group 2 for IKE proposal 1.

[AC1-ike-proposal-1] encryption-algorithm aes-cbc 128
[AC1-ike-proposal-1] dh group2
[AC1-ike-proposal-1] quit
375
# Create a DPD named dpd.

[AC1] ike dpd dpd
[AC1-ike-dpd-dpd] quit
# Create an IKE peer named peer1.

[AC1] ike peer peer1
# Apply dpd to IKE peer peer1.

[AC1-ike-peer-peer1] dpd dpd
# Apply IKE proposal 1 to IKE peer peer1.

[AC1-ike-peer-peer1] proposal 1
# Configure a plaintext pre-shared key 123456 for IKE negotiation.

[AC1-ike-peer-peer1] pre-shared-key simple 123456
# Specify the IP address of the remote IKE peer as 133.1.1.33.

[AC1-ike-peer-peer1] remote-address 133.1.1.33
[AC1-ike-peer-peer1] quit
# Create an IPsec policy template named pt with the sequence number 1.

[AC1] ipsec policy-template pt 1
# Reference the IPsec transform set tran1 for the IPsec policy template.
[AC1-ipsec-policy-template-pt-1] transform-set tran1
# Specify the IKE peer peer1 for the IPsec policy template.
[AC1-ipsec-policy-template-pt-1] ike-peer peer1
[AC1-ipsec-policy-template-pt-1] quit
# Create an IPsec policy named map with the sequence number 1 by referencing IPsec policy template
pt.
[AC1] ipsec policy map 1 isakmp template pt
# Apply the IPsec policy to VLAN-interface 1.

[AC1-Vlan-interface1] ipsec policy map
# Create an AP template named ap, specify the AP model and AP serial number, specify the IP address
of the backup AC, and configure the connection priority for the AP.
[AC1] wlan ap ap model MSM460-WW
[AC1-wlan-ap-ap] serial-id CN2AD330S8
[AC1-wlan-ap-ap] backup-ac ip 133.1.1.2
[AC1-wlan-ap-ap] priority level 7
# Create and enter the provision view for the AP.

[AC1-wlan-ap-ap] provision
# Configure the IPsec pre-shared key as plaintext 123456 for the AP.
[AC1-wlan-ap-ap-prvs] tunnel encryption ipsec pre-shared-key simple 123456
# Enable IPsec encryption for the AP data tunnel.

[AC1-wlan-ap-ap-prvs] data-tunnel encryption enable
# After the AP comes online, save the AP configuration to the AP's configuration file.
[AC1-wlan-ap-ap-prvs] save wlan ap provision name ap
[AC1-wlan-ap-ap-prvs] quit
376
[AC1-wlan-ap-ap] quit
[AC1] quit
# Reboot the AP.

<AC1> reset wlan ap name ap
This command will reset all master connection AP's.
Do you want to continue [Y/N]:y
Configuring AC 2
<AC2> system-view
# Enable stateful failover and set the stateful failover heartbeat interval.
[AC2] hot-backup hellointerval 100
# Set the IKE SA keepalive interval.

[AC2] ike sa keepalive-timer interval 20
# Set the IKE SA keepalive timeout.

[AC2] ike sa keepalive-timer timeout 60
# Enable invalid SPI recovery.

[AC2] ipsec invalid-spi-recovery enable
# Create an IPsec transform set named tran1.

[AC2] ipsec transform-set tran1
# Configure the IPsec transform set to use security protocol ESP, authentication algorithm SHA-1, and
encryption algorithm AES-CBC-128.
[AC2-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[AC2-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[AC2-ipsec-transform-set-tran1] quit
# Create IKE proposal 1.

[AC2] ike proposal 1
# Specify encryption algorithm AES-CBC-128 and DH group 2 for IKE proposal 1.

[AC2-ike-proposal-1] encryption-algorithm aes-cbc 128
[AC2-ike-proposal-1] dh group2
[AC2-ike-proposal-1] quit
# Create a DPD named dpd.

[AC2] ike dpd dpd
[AC2-ike-dpd-dpd] quit
# Create an IKE peer named peer1.

[AC2] ike peer peer1
# Apply dpd to IKE peer peer1.

[AC2-ike-peer-peer1] dpd dpd
# Apply IKE proposal 1 to IKE peer peer1.

[AC1-ike-peer-peer1] proposal 1
377
# Configure a plaintext pre-shared key 123456 for IKE negotiation.

[AC2-ike-peer-peer1] pre-shared-key simple 123456
# Specify the IP address of the remote IKE peer as 133.1.1.33.

[AC2-ike-peer-peer1] remote-address 133.1.1.33
[AC2-ike-peer-peer1] quit
# Create an IPsec policy template named pt with the sequence number 1.

[AC2] ipsec policy-template pt 1
# Reference the IPsec transform set tran1 for the IPsec policy template.
[AC2-ipsec-policy-template-pt-1] transform-set tran1
# Specify the IKE peer peer1 for the IPsec policy template.
[AC2-ipsec-policy-template-pt-1] ike-peer peer1
[AC2-ipsec-policy-template-pt-1] quit
# Create an IPsec policy with named map with the sequence number 1 by referencing IPsec policy
template pt.
[AC2] ipsec policy map 1 isakmp template pt
# Apply the IPsec policy to VLAN-interface 1.

[AC2-Vlan-interface1] ipsec policy map
# Create an AP template named ap , specify the AP model and AP serial number, specify the IP address
of the backup AC, and configure the connection priority for the AP.
[AC2] wlan ap ap model MSM460-WW
[AC2-wlan-ap-ap] serial-id CN2AD330S8
[AC2-wlan-ap-ap] backup-ac ip 133.1.1.1
[AC2-wlan-ap-ap] priority level 1
[AC2-wlan-ap-ap] quit

# Execute the display wlan ap all command on each AC to display the AP information.
<AC1> display wlan ap all
Total Number of APs configured
: 1
Total Number of configured APs connected : 1

Total Number of auto APs connected
: 0
AP Profiles
State : I = Idle,
J = Join, JA = JoinAck,
C = Config, R = Run,
IL = ImageLoad
KU = KeyUpdate, KC = KeyCfm
--------------------------------------------------------------------------AP Name
State Model
Serial-ID
--------------------------------------------------------------------------ap
R/M
MSM460-WW
CN2AD330S8
--------------------------------------------------------------------------<AC1>
<AC2>display wlan ap all
Total Number of APs configured
: 1
Total Number of configured APs connected : 1
378
Total Number of auto APs connected
: 0
AP Profiles
State : I = Idle,
J = Join, JA = JoinAck,
C = Config, R = Run,
IL = ImageLoad
KU = KeyUpdate, KC = KeyCfm
--------------------------------------------------------------------------AP Name
State Model
Serial-ID
--------------------------------------------------------------------------ap
R/B
MSM460-WW
CN2AD330S8
--------------------------------------------------------------------------<AC2>
# Execute the display ipsec sa command on each AC to display information about IPsec SAs.
<AC1> display ipsec sa
===============================
Interface: Vlan-interface1
path MTU: 1500
===============================
----------------------------IPsec policy name: "pt"

sequence number: 1
mode: template
----------------------------connection id: 7
encapsulation mode: tunnel
perfect forward secrecy:
tunnel:
local
address: 133.1.1.1
remote address: 133.1.1.33

flow:
sour addr: 133.1.1.1/255.255.255.255
dest addr: 133.1.1.33/255.255.255.255
port: 12223
port: 0
[inbound ESP SAs]

spi: 220165574 (0x0d1f75c6)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843177/3261
max received sequence-number: 126
anti-replay check enable: Y
anti-replay window size: 32
udp encapsulation used for nat traversal: N
status: --
[outbound ESP SAs]

spi: 620434955 (0x24fb160b)
379
protocol: UDP
protocol: UDP

status: --

sequence number: 1
mode: template
----------------------------connection id: 8
tunnel:
local
address: 133.1.1.1

flow:
sour addr: 133.1.1.1/255.255.255.255
dest addr: 133.1.1.33/255.255.255.255
port: 12222
port: 0
protocol: UDP
[inbound ESP SAs]

spi: 2106938486 (0x7d955476)
status: --
[outbound ESP SAs]

spi: 1822532692 (0x6ca1a454)
status: -<AC1>
<AC2> display ipsec sa

===============================
Interface: Vlan-interface1
path MTU: 1500
===============================
-----------------------------
380
protocol: UDP
IPsec policy name: "pt"

sequence number: 1
mode: template
----------------------------connection id: 6
tunnel:
local
address: 133.1.1.2

flow:
sour addr: 133.1.1.2/255.255.255.255
dest addr: 133.1.1.33/255.255.255.255
port: 12223
port: 0
protocol: UDP
protocol: UDP
[inbound ESP SAs]

spi: 1636801638 (0x618f9c66)
status: --
[outbound ESP SAs]

spi: 1048421470 (0x3e7da45e)
status: --

sequence number: 1
mode: template
----------------------------connection id: 7
tunnel:
local
address: 133.1.1.2

flow:
sour addr: 133.1.1.2/255.255.255.255
381
port: 12222
protocol: UDP
dest addr: 133.1.1.33/255.255.255.255
port: 0
protocol: UDP
[inbound ESP SAs]

spi: 1751951131 (0x686ca71b)
status: --
[outbound ESP SAs]

spi: 2945451878 (0xaf900766)
status: -<AC2>
# Execute the display ike sa command to display information about IKE SAs.
<AC1> display ike sa
total phase-1 SAs:
connection-id
peer
flag
phase
doi
status
----------------------------------------------------------------------60
133.1.1.33
RD
IPSEC
--
61
133.1.1.33
RD
IPSEC
--
62
133.1.1.33
RD
IPSEC
--
flag meaning
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
<AC1>
<AC2> display ike sa

total phase-1 SAs:
connection-id
peer
flag
phase
doi
status
----------------------------------------------------------------------117
133.1.1.33
RD
IPSEC
--
120
133.1.1.33
RD
IPSEC
--
121
133.1.1.33
RD
IPSEC
--
flag meaning
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
<AC2>
382
After the IKE negotiation succeeds and IPsec SAs are successfully established, all packets between the AP
and the ACs are encrypted by IPsec.
383
Configuring IKE
Overview
Built on a framework defined by the Internet Security Association and Key Management Protocol
(ISAKMP), Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services
for IPsec, simplifying the application, management, configuration and maintenance of IPsec
dramatically.
Instead of transmitting keys directly across a network, IKE peers transmit keying materials between them,
and calculate shared keys. Even if a third party captures all exchanged data for calculating the keys, it
cannot calculate the keys.
NOTE:
Unless otherwise specified, IKE in this chapter refers to IKEv1.
IKE security mechanism

IKE has a series of self-protection mechanisms and supports secure identity authentication, key
distribution, and IPsec SA establishment on insecure networks.
Data authentication
Data authentication involves two concepts:
Identity authenticationMutual identity authentication between peers. Two authentication

methods are available: pre-shared key authentication and PKI-based digital signature
authentication (RSA signature).
Identity protectionEncrypts the identity information with the generated keys before sending the
information.
DH
The DH algorithm is a public key algorithm. With this algorithm, two peers can exchange keying material,
and then use the material to calculate the shared keys. Due to the decryption complexity, a third party
cannot decrypt the keys even after intercepting all keying materials.
IKE operation
IKE negotiates keys and establishes SAs for IPsec in two phases:
1.
Phase 1The two peers establish an ISAKMP SA, a secure, authenticated channel for
communication. In this phase, two modes are available: main mode and aggressive mode.
2.
Phase 2Using the ISAKMP SA established in phase 1, the two peers negotiate to establish IPsec
SAs.
384
Figure 138 IKE exchange process in main mode

Peer 1
Send local
IKE policy
Peer 2
Confirmed policy
SA exchange
Receive the
policy
Search for
matched policy
Key generation
Initiators key information
Receivers key
information
Key exchange
Algorithm
negotiation
Initiators policy
Generate the key
Identity
authentication
Generate the key

Initiators identity and
authentication data
Receivers identity and
ID and authentication
data exchange
Perform ID/exchange
authentication
Perform ID/exchange
authentication
authentication data
As shown in Figure 138, the main mode of IKE negotiation in phase 1 involves three pairs of messages:
SA exchangeUsed for negotiating the security policy.
Key exchangeUsed for exchanging the DH public value and other values like the random number.
Key data is generated in this stage.
ID and authentication data exchangeUsed for identity authentication and authentication of data
exchanged in phase 1.
The main difference between the main mode and the aggressive mode is that the aggressive mode does
not provide identity protection and exchanges only three messages, rather than three pairs. The main
mode provides identity protection, but it is slower.
IKE functions
IKE provides the following functions for IPsec:
Automatically negotiates IPsec parameters such as the keys.
Performs DH exchange when establishing an SA, making sure that each SA has a key independent
of other keys.
Automatically negotiates SAs when the sequence number in the AH or ESP header overflows,
making sure that IPsec provides the anti-replay service correctly by using the sequence number.
Provides end-to-end dynamic authentication.
Identity authentication and management of peers influence IPsec deployment. A large-scale IPsec
deployment needs the support of CAs or other institutes that manage identity data centrally.
385
Relationship between IKE and IPsec

Figure 139 Relationship between IKE and IPsec
Figure 139 illustrates the relationship between IKE and IPsec:
IKE is an application layer protocol using UDP and functions as the signaling protocol of IPsec.
IKE negotiates SAs for IPsec and delivers negotiated parameters and generated keys to IPsec.
IPsec uses the SAs set up through IKE negotiation for encryption and authentication of IP packets.
RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409, The Internet Key Exchange (IKE)
RFC 2412, The OAKLEY Key Determination Protocol
Configuration task list for IKE

Determine the following parameters prior to IKE configuration:
The strength of the algorithms for IKE negotiation (the security protection level), including the
identity authentication method, encryption algorithm, authentication algorithm, and DH group.
Different algorithms provide different levels of protection. A stronger algorithm means more
resistance to decryption of protected data but requires more resources. Generally, the longer the key,
the stronger the algorithm.
The pre-shared key or the PKI domain the certificate belongs to. For more information about PKI
configuration, see "Configuring PKI."
To configure IKE:
Task
Remarks
Configuring a name for the local security gateway
Optional.
Optional.
Configuring an IKE proposal
Required if you want to specify an IKE proposal for

an IKE peer to reference.
386
Task
Remarks
Configuring an IKE peer
Required.
Setting keepalive timers
Optional.
Setting the NAT keepalive timer
Optional.
Configuring a DPD detector
Optional.
Disabling next payload field checking
Optional.
Configuring a name for the local security gateway

If the IKE negotiation peer uses the security gateway name as its ID to initiate IKE negotiation (the id-type
name or id-type user-fqdn command is configured on the initiator), configure the ike local-name
command in system view or the local-name command in IKE peer view on the local device. If you
configure both commands, the name configured by in IKE peer view is used.
To configure a name for the local security gateway:
Step
1.
Enter system view.
2.
Configure a name for the

local security gateway.
Command
Remarks
system-view
N/A
Optional.
ike local-name name
By default, the device name is used as the

name of the local security gateway.
Configuring an IKE proposal

An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You might
create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented
by its sequence number. The lower the sequence number, the higher the preference.
Two peers must have at least one matching IKE proposal for successful IKE negotiation. During IKE
negotiation, the initiator sends its IKE proposals to the peer, and the peer searches its own IKE proposals
for a match. The search starts from the IKE proposal with the lowest sequence number and proceeds in
the ascending order of sequence number until a match is found or all the IKE proposals are found
mismatching. The matching IKE proposals are used to establish the secure tunnel.
The two matching IKE proposals have the same encryption algorithm, authentication method,
authentication algorithm, and DH group. The SA lifetime takes the SA lifetime with a smaller value of the
two.
By default, there is an IKE proposal, which has the lowest preference and uses the default encryption
algorithm, authentication method, authentication algorithm, DH group, and ISAKMP SA lifetime.
When IPsec SAs are traffic expired:
In FIPS mode, both the IPsec SAs and the corresponding IKE SAs are renegotiated.
In non-FIPS mode, only the IPsec SAs are renegotiated.
To configure an IKE proposal:
387
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IKE proposal

and enter its view.
ike proposal proposal-number
N/A
Optional.
3.
4.
5.
Specify an encryption
algorithm for the IKE
proposal.
encryption-algorithm { 3des-cbc |
aes-cbc [ key-length ] | des-cbc }
method for the IKE
proposal.
authentication-method
{ pre-share | rsa-signature }
algorithm for the IKE
proposal.
authentication-algorithm { md5 |
sha }
In FIPS mode, DES-CBC or 3DES-CBC

are not supported, and the IKE
proposal uses 128-bit AES-CBC for
encryption by default.
In non-FIPS mode, the IKE proposal
uses 56-bit DES-CBC for encryption by
default.
Optional.
Pre-shared key by default.
Optional.
SHA1 by default.
In FIPS mode, MD5 is not supported.
Optional.
6.
Specify a DH group for key

negotiation in phase 1.
dh { group1 | group2 | group5 |

group14 }
In FIPS mode, the default group is

group2, the 1024-bit Diffie-Hellman
group.
In non-FIPS mode, the default group is
group1, the 768-bit Diffie-Hellman
group.
Optional.
7.
Set the ISAKMP SA lifetime

for the IKE proposal.
sa duration seconds
Before an ISAKMP SA expires, IKE

negotiates a new SA to replace it. DH
calculation in IKE negotiation takes
time, especially on low-end devices. To
prevent SA updates from influencing
normal communication, set the lifetime
greater than 10 minutes.
Configuring an IKE peer

For an IKE-based IPsec policy, you must configure an IKE peer by performing the following tasks:
Specify the IKE negotiation mode for the local end to use in IKE negotiation phase 1. If you obtain
the IP address of the remote end dynamically and use pre-shared key authentication, HP
recommends setting the IKE negotiation mode of the local end to aggressive. When acting as the
IKE negotiation responder, the local end uses the IKE negotiation mode of the remote end.
Specify the IKE proposals for the local end to use when acting as the IKE negotiation initiator. When
acting as the responder, the local end uses the IKE proposals configured in system view for
negotiation.
388
Configure a pre-shared key for pre-shared key authentication or a PKI domain for digital signature
authentication.
Specify the ID type for the local end to use in IKE negotiation phase 1. With pre-shared key
authentication, the ID type must be IP address for main mode IKE negotiation. It can be IP address,
FQDN, or user FQDN for aggressive mode IKE negotiation.
Specify the name or IP address of the local security gateway. You perform this task only when you
want to specify a special address, a loopback interface address, for example, as the local security
gateway address.
Specify the name or IP address of the remote security gateway. For the local end to initiate IKE
negotiation, you must specify the name or IP address of the remote security gateway on the local
end so the local end can find the remote end.
Enable NAT traversal. If there is NAT gateway on the path for tunneling, you must configure NAT
traversal at the two ends of the IPsec tunnel, because one end might use a public address while the
other end uses a private address.
Specify the DPD detector for the IKE peer.
To configure an IKE peer:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IKE peer and

enter IKE peer view.
ike peer peer-name
N/A
3.
Specify the IKE negotiation

mode for phase 1.
Optional.
exchange-mode { aggressive | main }
The default is main.

In FIPS mode, the aggressive mode
is not supported.
Optional.
4.
Specify the IKE proposals

for the IKE peer to
reference.
proposal proposal-number&<1-6>
By default, an IKE peer references

no IKE proposals, and, when
initiating IKE negotiation, it uses the
IKE proposals configured in system
view.
If the IKE negotiation mode in
phase 1 is aggressive, only the first
IKE proposal specified for the IKE
peer takes effect.
Configure either command
according to the authentication
method for the IKE proposal.
5.
Configure a pre-shared
key for pre-shared key
authentication or specify a
PKI domain for digital
signature authentication.
To configure a pre-shared key:

pre-shared-key [ [ cipher |
simple ] key ]
To specify a PKI domain:
certificate domain domain-name
389
In FIPS mode, the simple keyword is

not supported. You can configure a
ciphertext pre-shared key by using
the cipher key option or a plaintext
pre-shared key in interactive mode.
The key must contain at least eight
characters comprising digits,
uppercase and lowercase letters,
and special characters.
Step
6.
Command
Select the ID type for IKE
negotiation phase 1.
Remarks
id-type { ip | name | user-fqdn }
Optional.
By default, the ID type is IP.
Optional.
7.
Configure a name for the

local security gateway.
local-name name
By default, no name is configured

for the local security gateway in IKE
peer view, and the security
gateway name configured by using
the ike local-name command is
used.
Optional.
8.
Specify the name of the

remote security gateway.
9.
Enable the NAT traversal

function for IPsec/IKE.
remote-name name
The remote gateway name

configured with remote-name
command on the local gateway
must be identical to the local name
configured with the local-name
command on the peer.
Required when a NAT gateway is
present in the VPN tunnel
constructed by IPsec/IKE.
nat traversal
Optional.
10. Configure an IP address
for the local gateway.
local-address ip-address
By default, it is the primary IP

address of the interface referencing
the security policy.
Optional.
11. Specify the IP addresses of

the remote gateway.
remote-address { hostname
[ dynamic ] | low-ip-address
[ high-ip-address ] }
Set the subnet type of the local

12. Set the subnet types of the
two ends.
end:
local { multi-subnet |
single-subnet }
Set the subnet type of the peer

end:
peer { multi-subnet |
single-subnet }
The remote IP address configured

with the remote-address command
on the local gateway must be
identical to the local IP address
configured with the local-address
command on the peer.
Optional.
The default subnet type is
single-subnet.
Use these two commands only
when the device is working
together with a NetScreen device.
Optional.
13. Apply a DPD detector to

the IKE peer.
dpd dpd-name
390
No DPD detector is applied to an

IKE peer by default.
For more information about DPD
configuration, see "Configuring a
DPD detector."
NOTE:
After modifying the configuration of an IPsec IKE peer, execute the reset ipsec sa and reset ike sa
commands to clear existing IPsec and IKE SAs. Otherwise, SA re-negotiation will fail.
Setting keepalive timers

IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured
with the keepalive timeout, you must configure the keepalive packet transmission interval on the local end.
If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA is tagged with the
TIMEOUT tag (if it does not have the tag), or deleted along with the IPsec SAs it negotiated (when it has
the tag already).
The keepalive timeout configured at the local end must be longer than the keepalive interval configured
at the remote end. Since it seldom occurs that more than three consecutive packets are lost on a network,
you can configure the keepalive timeout to be three times of the keepalive interval.
To set the keepalive timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the ISAKMP SA keepalive

interval.
ike sa keepalive-timer interval

seconds
No keepalive packet is sent by

default.
3.
Set the ISAKMP SA keepalive

timeout.
ike sa keepalive-timer timeout

seconds
No keepalive packet is sent by

default.
Setting the NAT keepalive timer

If IPsec traffic needs to pass through NAT security gateways, you must configure the NAT traversal
function. If no packet travels across an IPsec tunnel in a certain period of time, the NAT mapping might
get aged and be deleted. This disables the tunnel beyond the NAT gateway from transmitting data to the
intended end. To prevent NAT mappings from being aged, an ISAKMP SA behind the NAT security
gateway sends NAT keepalive packets to its peer at a certain interval to keep the NAT session alive.
To set the NAT keepalive timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the NAT keepalive

interval.
ike sa nat-keepalive-timer interval

seconds
Configuring a DPD detector

DPD irregularly detects dead IKE peers. It works as follows:
1.
When the local end sends an IPsec packet, it checks the time the last IPsec packet was received
from the peer.
391
2.
If the time interval exceeds the DPD interval, it sends a DPD hello to the peer.
3.
If the local end receives no DPD acknowledgement within the DPD packet retransmission interval,
it retransmits the DPD hello.
4.
If the local end still receives no DPD acknowledgement after having made the maximum number of
retransmission attempts (two by default), it considers the peer already dead, and clears the IKE SA
and the IPsec SAs based on the IKE SA.
DPD enables an IKE entity to check the liveliness of its peer only when necessary. It generates less traffic
than the keepalive mechanism, which exchanges messages periodically.
To configure a DPD detector:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a DPD detector and

enter its view.
ike dpd dpd-name
N/A
3.
Set the DPD interval.
interval-time interval-time
4.
Set the DPD packet

retransmission interval.
time-out time-out
Optional.
Optional.
Disabling next payload field checking

The Next payload field is in the generic payload header of the last payload of the IKE negotiation
message (the message includes multiple payloads). According to the protocol, this field must be 0 if the
payload is the last payload of the packet. However, it might be set to other values on some brands of
devices. For interoperability, disable the checking of this field.
To disable Next payload field checking:
Step
Command
Remark
1.
Enter system view.
system-view
N/A
2.
Disable Next payload field

checking.
ike next-payload check disabled
Enabled by default.
Displaying and maintaining IKE

Task
Command
Remarks
Display IKE DPD information.
display ike dpd [ dpd-name ] [ | { begin |

Display IKE peer information.
display ike peer [ peer-name ] [ | { begin |

392
Task
Command
Remarks
Display IKE SA information.
display ike sa [ active | standby | verbose

[ connection-id connection-id |
remote-address remote-address ] ] [ | { begin
Display IKE proposal information.
display ike proposal [ | { begin | exclude |

Support for the active

and standby keywords
model. For more
the Command
References for HP
Unified Wired-WLAN
Products.
Clear SAs established by IKE.
reset ike sa [ connection-id | active |

standby ]
Support for the active

and standby keywords
model. For more
the Command
References for HP
Unified Wired-WLAN
Products.
IKE configuration examples

For more information, see WLAN Configuration Guide.
Troubleshooting IKE
When you configure parameters to establish an IPsec tunnel, enable IKE error debugging to locate
configuration problems:
<AC> debugging ike error
Proposal mismatch
Symptom
The proposals mismatch.
Analysis
The following is the debugging information:
got NOTIFY of type NO_PROPOSAL_CHOSEN
Or
drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN
The two parties in the negotiation have no matched proposals.
393
Solution
For the negotiation in phase 1, look up the IKE proposals for a match.
For the negotiation in phase 2, verify that the parameters of the IPsec policies applied on the interfaces
are matched, and that the referred IPsec transform sets have a match in protocol, encryption and
authentication algorithms.
Failing to establish an IPsec tunnel

Symptom
The expected IPsec tunnel cannot be established.
Analysis
Sometimes this might happen if an IPsec tunnel cannot be established or there is no way to communicate
in the presence of an IPsec tunnel in an unstable network.
If ACLs of both parties are configured correctly, and proposals are also matched, the problem is usually
caused by the reboot of one router after the IPsec tunnel is established.
Solution
Use the display ike sa command to verify that both parties have established an SA in phase 1.
Use the display ipsec sa policy command to verify that the IPsec policy on the interface has
established IPsec SA.
If the two commands show that one party has an SA, but the other does not, use the reset ipsec sa
command to clear the IPsec SA that has no corresponding SA, use the reset ike sa command to
clear the IKE SA that has no corresponding IKE SA, and then trigger SA re-negotiation.
394
Configuring ALG
The term "router" in this document refers to both routers and routing-capable WX series access
controllers.
Application Level Gateway (ALG) processes the payload information of application layer packets to
make sure data connections can be established.
NAT typically translates only IP address and port information in packet headers and does not analyze
fields in application layer payloads. However, the packet payloads of some protocols may contain IP
address or port information, which may cause problems if not translated. For example, an FTP
application involves both data connection and control connection, and data connection establishment
dynamically depends on the payload information of the control connection.
ALG works with NAT or ASPF to implement the following functions:
Address translationResolves the source IP address, port, protocol type (TCP or UDP), and remote
IP address information in packet payloads.
Data connection detectionExtracts information required for data connection establishment and
establishing data connections for data exchange.
Application layer status checkingInspects the status of the application layer protocol in packets.
Packets with correct states have their status updated and are sent for further processing, whereas
packets with incorrect states are dropped.
Support for these functions depends on the application layer protocol.

ALG can process the following protocol packets:
DNS
FTP
H.323, including RAS, H.225, and H.245
ILS
MSN
NBT
PPTP
QQ
RTSP
SCCP
SIP
SQLNET, a language in Oracle
TFTP
ALG process
The following example describes the FTP operation of an ALG-enabled router.
395
As shown in Figure 140, the host on the external network accesses the FTP server on the internal network
in passive mode through the ALG-enabled router.
Figure 140 Network diagram for ALG-enabled FTP application in passive mode
Inside network
Outside network
NAT
Host
Router
FTP-ALG enabled
FTP server
FTP_CMD (PASV)
FTP_CMD (PASV)
FTP_EnterPassive (IP1, Port1)
ALG
IP1, Port1-------> IP2, Port2
FTP_EnterPassive (IP2, Port2)
FTP_Connet (IP2, Port2)
FTP_Connet (IP1, Port1)
The communication process includes the following steps:

1.
Establishing a control connection.

The host sends a TCP connection request to the server. If a TCP connection is established, the server
and the host enter the user authentication stage.
2.
Authenticating the user.

The host sends the server an authentication request, which contains the FTP commands (user and
password) and the contents.
When the request passes through the ALG-enabled device, the commands in the payload of the
packet are resolved and used to check whether the protocol state transition is correctly proceeding.
If not, the request will be dropped. In this way, ALG protects the server against clients that send
packets with state errors or log in to the server with unauthorized user accounts.
An authentication request with the correct state is forwarded by the ALG-enabled device to the
server, which authenticates the host according to the information in the packet.
3.
Establishing a data connection.

If the host passes the authentication, a data connection is established between it and the server. If
the host is accessing the server in passive mode, the server sends the host a PASV response that
uses its private network address and port number (IP1, Port1). When the response arrives at the
ALG-enabled device, the device resolves the packet and translates the server's private network
address and port number into the server's public network address and port number (IP2, Port2)
respectively. Then, the device uses the public network address and port number to establish a data
connection with the host.
4.
Exchanging data.
The host and the FTP server exchange data through the established data connection.
396
Enabling ALG
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
Enable ALG.
alg { all | dns | ftp | h323 | ils | msn |

nbt | pptp | qq | rtsp | sccp | sip |
sqlnet | tftp }
Optional.
2.
By default, ALG is enabled for all

protocols.
ALG configuration examples

an 830 switch are Access interfaces in VLAN 1. When configuring the two aggregate interfaces, make
sure their permitted VLANs are the same. HP also recommends that you set their link type to be the same.
FTP ALG configuration example

The example describes ALG configurations, assuming other required configurations on the server and
client have been done.
As shown in Figure 141, a company uses the private network segment 192.168.1.0/24, and has four
public network addresses: 5.5.5.1, 5.5.5.9, 5.5.5.10, and 5.5.5.11. The company wants to provide FTP
services to the outside.
Configure NAT and ALG on the AC so that hosts on the external network can access the FTP server on the
internal network.
# Configure the address pool and ACL.
<AC> system-view
[AC] nat address-group 1 5.5.5.9 5.5.5.11
397
[AC-acl-basic-2001] rule permit

[AC-acl-basic-2001] quit
# Enable ALG for FTP.

[AC] alg ftp
# Configure NAT.
[AC-Vlan-interface3] nat outbound 2001 address-group 1
# Configure internal FTP server.

[AC-Vlan-interface3] nat server protocol tcp global 5.5.5.10 ftp inside 192.168.1.2 ftp
SIP/H.323 ALG configuration example

H.323 ALG configuration is similar to SIP ALG configuration. This example describes SIP ALG
configuration, assuming other required configurations on the server and client have been done.
As shown in Figure 142, a company uses the private network segment 192.168.1.0/24, and has four
public network addresses: 5.5.5.1, 5.5.5.9, 5.5.5.10, and 5.5.5.11. SIP UA 1 is on the internal network
and SIP UA 2 is on the external network.
Configure NAT and ALG on the AC to enable SIP UA 1 and SIP UA 2 to communicate by using their
aliases, and to enable SIP UA 1 to select an IP address from the range 5.5.5.9 to 5.5.5.11 when
registering with the SIP server on the external network.
# Configure the address pool and ACL.
<AC> system-view
[AC-acl-basic-2001] rule permit source 192.168.1.0 0.0.0.255
[AC-acl-basic-2001] rule deny
# Enable ALG for SIP.

[AC] alg sip
# Configure NAT.
398
NBT ALG configuration example

The example describes ALG configurations, assuming other required configurations on the server and
client have been done.
As shown in Figure 143, a company using the private network segment 192.168.1.0/24 wants to provide
NBT services to the outside.
Configure NAT and ALG on the AC so that Host A uses 5.5.5.9 as its external IP address, the WINS
server uses 5.5.5.10 as its external IP address, and Host B can access the WINS server and Host A by
using host names.
# Configure a static NAT entry.
<AC> system-view
[AC] nat static 192.168.1.3 5.5.5.9
# Enable ALG for NBT.

[AC] alg nbt
# Configure NAT.
[AC-Vlan-interface3] nat outbound static
# Configure the internal WINS server.

[AC-Vlan-interface3] nat server protocol udp global 5.5.5.10 137 inside 192.168.1.2 137
[AC-Vlan-interface3] nat server protocol udp global 5.5.5.10 138 inside 192.168.1.2 138
[AC-Vlan-interface3] nat server protocol tcp global 5.5.5.10 139 inside 192.168.1.2 139
399
Configuring firewall
The term "router" in this document refers to both routers and routing-capable HP wireless products.
Overview
A firewall blocks unauthorized Internet access to a protected network while allowing internal network
users to access the Internet through WWW, or to send and receive e-mails. A firewall can also be used
to control access to the Internet, for example, to permit only specific hosts within the organization to
access the Internet. Many of today's firewalls offer additional features, such as identity authentication
and encryption.
Another application of firewall is to protect the mainframe and important resources (such as data) on
internal networks. Any access to protected data is filtered by the firewall, even if the access is initiated by
a user within the internal network.
The device mainly implements three categories of firewalls:
ACL based packet filter
Application Specific Packet Filter (ASPF)
Address translation
This chapter focuses on ACL packet-filter firewall and ASPF. For more information about address
translation, see "Configuring NAT."
ACL based packet filter

An ACL packet-filter firewall implements IP packet specific filtering.
Before an IP packet can be forwarded, the firewall obtains the header information of the packet,
including the following:
Number of the upper layer protocol carried by the IP layer
Source address
Destination address
Source port number
Destination port number
The firewall compares the head information against the preset ACL rules and processes the packet based
on the comparison result.
An ACL packet-filter is a static firewall. It cannot solve the following issues:
For multi-channel application layer protocols, such as FTP and H.323, the values of some security
policy parameters are unpredictable.
ICMP attacks cannot be prevented because not all faked ICMP error messages from the network
can be recognized.
For a TCP connection, the first packet must be a SYN packet. Any non-SYN packet that is the first
packet over the TCP connection is dropped. If a packet-filter firewall is deployed in a network, the
400
non-SYN packets of existing TCP connections passing the firewall for the first time are dropped,
breaking the existing TCP connections.
ASPF
ASPF was proposed to address the issues that a static firewall cannot solve. An ASPF implements
application layer and transport specific, namely status-based, packet filtering. An ASPF can detect
application layer protocols including FTP, GTP, HTTP, SMTP, Real RTSP, SCCP, SIP, and H.323 (Q.931,
H.245, and RTP/RTCP), and transport layer protocols TCP and UDP.
ASPF functions
An ASPF provides the following functions:
Application layer protocol inspectionASPF checks the application layer information of packets,
such as the protocol type and port number, and monitors the application layer protocol status for
each connection. ASPF maintains the status information of each connection, and based on the
status information, determines whether to permit a packet to pass through the firewall into the
internal network, thus defending the internal network against attacks.
Transport layer protocol inspection (generic TCP and UDP inspection)ASPF checks a TCP/UDP
packet's source and destination addresses and port numbers to determine whether to permit the
packet to pass through the firewall into the internal network.
Connection status inspectionASPF can filter packets according to connection status.
Port to Application Mapping (PAM)Allows you to specify port numbers other than the standard
ones for application layer protocols.
ICMP error message inspectionASPF checks the connection information carried in an ICMP error
message. If the information does not match the connection, the ASPF processes the packet as
configured, for example, it discards the packet.
First packet inspection for TCP connectionASPF checks the first packet over a TCP connection. If
the first packet over a TCP connection is not a SYN packet, the ASPF will discard the packet.
At the border of a network, an ASPF can work in coordination with a packet-filter firewall to provide the
network with a security policy that is more comprehensive and better satisfies the actual needs.
ASPF basic concepts
PAM
While application layer protocols use the standard port numbers for communication, PAM allows
you to define a set of new port numbers for different applications, and provides mechanisms to
maintain and use the configuration information of user-defined ports.
PAM supports two types of port mapping mechanisms: general port mapping and host port
mapping.
{
General port mappingA mapping of a user-defined port number to an application layer

protocol. If port 8080 is mapped to HTTP, for example, all TCP packets to port 8080 are
regarded as HTTP packets.
Host port mappingA mapping of a user-defined port number to an application layer protocol
for packets to/from specific hosts. For example, you can establish a host port mapping so that
all TCP packets using 8080 as the destination port and 10.110.0.0/16 as the destination
network segment are regarded as HTTP packets. The hosts can be specified by means of a basic
ACL.
Single-channel protocol and multi-channel protocol

401
Single-channel protocolA single-channel protocol establishes only one channel to exchange

both control messages and data for a user. SMTP and HTTP are examples of single-channel
protocols.
Multi-channel protocolA multi-channel protocol establishes more than one channel for a user
and transfers control messages and user data through different channels. FTP and RTSP are
examples of multi-channel protocols.
Internal interface and external interface

On an edge device configured with ASPF to protect servers on the internal network, interfaces
connected with the internal network are internal interfaces and the interface connected with the
Internet is the external interface.
When an ASPF is applied on the outbound direction of the external interface of a device, a
temporary channel can be opened on the firewall for return packets to internal network users
accessing the Internet.
Application layer protocol inspection

As shown in Figure 144, to protect the internal network, an ACL is usually required on the router to permit
internal hosts to access external networks while prohibiting hosts on external networks from accessing the
internal network. However, the ACL will also filter out the return packets to internal users, thus failing the
connection setup attempts.
Figure 144 Application layer protocol inspection
Packets of other sessions are blocked

Client A
Client A initiates a session
WAN
Return packets of
the session are
permitted to pass
Client B
Router
Server
Protected network
ASPF implements the application layer protocol inspection function in cooperation with the session
management and ALG features. After detecting the first packet of a session, ASPF matches the packet
with the configured policy and sends the result to the session management feature, which is responsible
for session information database establishment and session status maintenance. Then, the ASPF
processes subsequent packets of the session based on session status information returned by the session
management feature.
For information about session management, see "Managing sessions." For information about ALG, see
"Configuring ALG."
Transport layer protocol inspection

The transport layer protocol inspection here refers to generic TCP/UDP inspection. Different from
application layer protocol inspection, generic TCP/UDP inspection is specific to the transport layer
information in the packets, such as source and destination addresses and port number. generic TCP/UDP
inspection requires a full match between the packets returned to the external interface of the ASPF and
the packets previously sent out from the external interface of ASPF, namely a perfect match of the source
and destination address and port number. Otherwise, the return packets will be blocked. Therefore, for
402
multi-channel application layer protocols like FTP and H.323, the deployment of TCP inspection without
application layer inspection will lead to failure of establishing a data connection.
Configuring a packet-filter firewall

WLAN-ESS interfaces do not support IPv6 packet-filter firewall.
User profiles do not support IPv6 packet-filter firewall.
Packet-filter firewall configuration task list

Task
Remarks
Enabling the firewall function
Required.
Configuring the default filtering action of the firewall
Optional.
Applying an ACL packet-filter firewall to an interface
Perform at least one of

the tasks.
Applying an ACL packet-filter firewall to a user profile

To enable IPv4 firewall:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the IPv4 firewall function.
firewall enable
Command
Remarks
To enable IPv6 firewall:

Step
1.
Enter system view.
system-view
N/A
2.
firewall ipv6 enable
Configuring the default filtering action of the firewall

The default filtering action configuration is used for the firewall to determine whether to permit a data
packet to pass or deny the packet when there is no appropriate criterion for judgment.
To configure the default filtering action of the IPv4 firewall:
Step
1.
Enter system view.
2.
Specify the default filtering

action of the IPv4 firewall.
Command
Remarks
system-view
N/A
Optional.
firewall default { deny | permit }
403
By default, the firewall permits

packets to pass.
To configure the default filtering action of the IPv6 firewall:

Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.

action of the IPv6 firewall.
firewall ipv6 default { deny |

permit }
Optional.
By default, the firewall permits
packets to pass.
Applying an ACL packet-filter firewall to an interface

When an ACL is applied to an interface, the time range-based filtering will also work at the same time.
In addition, you can specify separate access rules for inbound and outbound packets.
A basic ACL defines rules based only on the Layer 3 source IP addresses to analyze and process data
packets.
An advanced ACL defines rules according to the source and destination IP addresses of packets, the type
of protocol over IP, TCP/UDP source and destination ports.
To apply an IPv4 ACL-based packet-filter firewall to an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Apply an IPv4 ACL to the

interface.
firewall packet-filter { acl-number |

name acl-name } { inbound |
outbound }
By default, no ACL-based
packet-filter firewall is applied to
filter IPv4 packets on an interface.
You can apply only one IPv4 ACL
to filter packets in one direction of
an interface.
To apply an IPv6 ACL-based packet-filter firewall to an interface:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Apply an IPv6 ACL to the

interface.
firewall packet-filter ipv6

{ acl6-number | name acl6-name }
{ inbound | outbound }
404
By default, no ACL-based
packet-filter firewall is applied to
filter IPv6 packets on an interface.
You can apply only one IPv6 ACL
to filter packets in one direction of
an interface.
Applying an ACL packet-filter firewall to a user profile

Perform this task to implement user-based packet filtering. After a user passes authentication, if the user
is authorized with a user profile and the user profile is configured with a packet-filter firewall, the packets
received or sent by the user are filtered by the firewall as configured.
To apply an ACL-based packet-filter firewall to a user profile:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter user profile view.
user-profile user-profile-name
N/A
3.
Apply an ACL to the user

profile.
firewall packet-filter { acl-number |

name acl-name } { inbound |
outbound }
By default, packet filtering is not

configured for any user profile.
You can apply only one ACL to
filter packets in one direction of a
user profile.
Displaying and maintaining a packet-filter firewall

Task
Command
Remarks
Display the packet filtering

statistics of the IPv4 firewall.
display firewall-statistics { all | interface

interface-type interface-number |
user-profile user-profile-name } [ | { begin |
Display the packet filtering

statistics of the IPv6 firewall.
display firewall ipv6 statistics { all |

interface interface-type interface-number }
Clear the packet filtering statistics

of the IPv4 firewall.
reset firewall-statistics { all | interface

interface-type interface-number |
user-profile user-profile-name }
Clear the packet filtering statistics

of the IPv6 firewall.
reset firewall ipv6 statistics { all | interface

interface-type interface-number }
Packet-filter firewall configuration example

405
As shown in Figure 145, the internal network of a company is connected to VLAN-interface 2 of the AC,
and the internal users access the Internet through VLAN-interface 3 of the AC.
The company provides WWW, FTP and Telnet services to the outside. The internal subnet of the company
is 129.1.1.0/24, on which the internal FTP server address is 129.1.1.1, the Telnet server address is 129.1.1.2,
and the internal WWW server address is 129.1.1.3. The public address of the company is 20.1.1.1. NAT
is enabled on the AC so that hosts on the internal network can access to the Internet and external hosts
can access the internal servers.
Configure the firewall feature to achieve the following aims:
Only specific users on the external network are allowed access to the internal servers.
This example assumes the specific external user is at 20.3.3.3.
Only specific hosts on the internal network are permitted to access the external network.

129.1.1.1/24
129.1.1.2/24
FTP server Telnet server
129.1.1.3/24
WWW server
Internal network
Vlan-int 2
129.1.1.5/24
Vlan-int 3
20.1.1.1/16
WAN
Internal host
AP
AC
External host
20.3.3.3/32
129.1.1.4/24
# Enable the firewall function on the AC.
<AC> system-view
[AC] firewall enable
# Create advanced ACL 3001.

# Configure rules to permit specific hosts to access external networks and permit internal servers to
access external networks.
[AC-acl-adv-3001] rule permit ip source 129.1.1.1 0
# Configure a rule to prohibit all IP packets from passing the firewall.

[AC-acl-adv-3001] rule deny ip
# Create advanced ACL 3002.

406
# Configure a rule to allow a specific external user to access internal servers.

[AC-acl-adv-3002] rule permit tcp source 20.3.3.3 0 destination 129.1.1.0 0.0.0.255
# Configure a rule to permit specific data (only packets of which the port number is greater than 1024)
to get access to the internal network.
[AC-acl-adv-3002] rule permit tcp destination 20.1.1.1 0 destination-port gt 1024
# Apply ACL 3001 to packets that come in through VLAN-interface 2.

[AC-Vlan-interface2] firewall packet-filter 3001 inbound
# Apply ACL 3002 to packets that come in through VLAN-interface 3.

Configuring an ASPF
ASPF configuration task list
Task
Remarks
Required.
Configuring an ASPF policy
Required.
Applying an ASPF policy to an interface
Perform at least one of the tasks.
Applying an ASPF policy to a user profile

Configuring port mapping
Optional.

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
firewall enable
Configuring an ASPF policy

Note the following guidelines when you configure an ASPF policy:
If you enable TCP or UDP inspection without configuring application layer protocol inspection,
some packets may fail to get a response. Therefore, enable application layer protocol inspection
together with TCP/UDP inspection.
In the case of a Telnet application, you only need to configure TCP inspection.
407
To configure an ASPF policy:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an ASPF policy and

enter its view.
aspf-policy aspf-policy-number
N/A
3.
Drop ICMP error messages.
icmp-error drop
4.
Drop non-SYN packet that is

the first packet over a TCP
connection.
Optional.
By default, ICMP error messages
are not dropped.
Optional.
tcp syn-check
By default, a non-SYN packet that

is the first packet over a TCP
connection is not dropped.
Applying an ASPF policy to an interface

Two concepts are distinguished in ASPF policy: internal interface and external interface.
If the device is connected to both the internal network and the Internet, and employs ASPF to protect the
internal servers, the interface connected to the internal network is the internal interface and the one
connected to the Internet is the external interface.
IF both ASPF and packet-filter firewall are applied to the external interface, access to the internal network
from the Internet is denied. The response packet can pass ASPF when internal network users access the
Internet.
To monitor the traffic through an interface, you must apply the configured ASPF policy to that interface.
Make sure a connection initiation packet and the corresponding return packet are based on the same
interface, because it is based on interfaces that an ASPF stores and maintains the application layer
protocol status.
To apply an ASPF policy on an Interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
interface-number
N/A
3.
Apply an ASPF policy to the

interface.
firewall aspf aspf-policy-number

Not applied by default.
Applying an ASPF policy to a user profile

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter user profile view.
user-profile user-profile-name
N/A
408
Step
Apply an ASPF policy to the
user profile.
3.
Command
Remarks
firewall aspf aspf-policy-number

By default, no ASPF policy is

applied to any user profile.
Configuring port mapping

Two mapping mechanisms exist: general port mapping and basic ACLbased host port mapping.
General port mappingRefers to a mapping of a user-defined port number to an application layer

protocol. If port 8080 is mapped to HTTP, for example, all TCP packets the destination port of which
is port 8080 are regarded as HTTP packets.
Host port mappingRefers to a mapping of a user-defined port number to an application layer

protocol for packets to some specific hosts. For example, you can establish a host port mapping so
that all TCP packets using port 8080 sent to the network segment 10.110.0.0 are regarded as HTTP
packets. The address range of hosts can be specified by means of a basic ACL.
To configure port mapping:

Step
1.
Enter system view.
2.
Configure mapping between

the port and the application
protocol.
Command
Remarks
system-view
N/A
port-mapping application-name
port port-number [ acl acl-number ]
The application layer protocols

supported by this function include
FTP, GTP, H323, HTTP, RTSP,
SCCP, SIP, SMTP, and SQLNET.
Displaying and maintaining ASPF

Task
Command
Remarks
Display all ASPF policy and

session information.
display aspf all [ | { begin | exclude |

Display the ASPF policy

configuration applied to the
interface.
display aspf interface [ | { begin | exclude |

Display the configuration

information of a specific ASPF
policy.
display aspf policy aspf-policy-number [ |

Display the port mapping

information.
display port-mapping [ application-name |

port port-number ] [ | { begin | exclude |
ASPF configuration example

409
Configure an ASPF policy on the AC to drop ICMP error messages and non-SYN packets that are the first
packets over TCP connections.
This example applies to scenarios where local users need to access remote network services.
# Enable the firewall function on the AC.
<AC> system-view
[AC] firewall enable
# Configure ACL 3111 to prohibit all IP packets from entering the internal network. The ASPF will create
a TACL for packets permitted to pass the firewall.
# Create an ASPF policy.

[AC] aspf-policy 1
[AC-aspf-policy-1] icmp-error drop
[AC-aspf-policy-1] tcp syn-check
[AC-aspf-policy-1] quit
# Apply ACL 3111 and the ASPF policy to interface VLAN-interface 3.

[AC-Vlan-interface3] firewall aspf 1 outbound
410
Managing sessions
Overview
Session management is a common feature designed to implement session-based services such as NAT
and ASPF. Session management regards packet exchanges at transport layer as sessions and updates
the session status, or ages sessions out according to information in the initiator or responder packet.
Session management allows multiple features to process the same service packet. Session management
can be applied for the follow purposes:
Fast match between packets and sessions.
Management of transport layer protocol states.
Identification of application layer protocols.
Session aging based on protocol state or application layer protocol type.
Persistent sessions.
Checksum verification for transport layer protocol packets.
Special packet match for the application layer protocols requiring port negotiation.
Resolution of ICMP error control packets and session match based on resolution results.
How session management works

Session management tracks the connection status by inspecting the transport layer protocol (TCP or UDP)
information, performing unified status maintenance and management of all connections.
In actual applications, session management works together with ASPF to dynamically determine whether
a packet can pass the firewall and enter the internal network according to connection status, thus
preventing intrusion.
The session management function only tracks connection status. It does not block potential attack
packets.
Session management functions

Session management enables the device to provide the following functions:
Supporting session creation, session status update and timeout time setting based on protocol state
for such IPv4 packets as TCP, UDP, ICMP, Raw IP packets.
Supporting port mapping for application layer protocols and allowing application layer protocols
to use customized ports and adopt different session timeout time.
Supporting checksum verification for TCP, UDP, and ICMP packets.

In case of checksum verification failure, the system will not match sessions or create sessions.
Instead, other services based on session management will process the packets.
Supporting ICMP error packet mapping and allowing the system to search for original sessions
according to the payload of these packets.
411
Because error packets are generated due to host errors, the mapping can help speed up the aging
of the original sessions.
Supporting persistent sessions, which are kept alive for a long period of time.
Supporting session management of control channels and dynamic data channels of application
layer protocols, for example, FTP.
Session management task list

Task at a glance
(Optional) Setting session aging time for different protocol states
(Optional) Configuring session aging time for different application layer protocols
(Optional) Enabling checksum verification
(Optional) Specifying persistent sessions
These tasks are mutually independent and can be configured in any order.
Setting session aging time for different protocol states

If the application layer protocol of a session supports session aging time configuration, the session takes
the session aging time set based on the application layer protocol type as its aging time when it is in the
READY/ESTABLISH state. For more information about the configuration, see "Configuring session aging
time for different application layer protocols."
If a session entry is not matched with any packets in a specified period of time, the entry will be aged out.
IMPORTANT:
For a large amount of sessions (more than 800000), do not specify too short aging time. Otherwise, the
console might be slow in response.
To set the session aging times based on protocol state:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
412
Step
Command
Remarks
This aging time setting is effective
on only the sessions that are being
established.
The default values are as follows:
2.
Set the aging time for sessions

of a specified protocol and in
a specified state.
session aging-time { accelerate |

fin | icmp-closed | icmp-open |
rawip-open | rawip-ready | syn |
tcp-est | udp-open | udp-ready }
time-value
accelerate10 seconds.
fin30 seconds.
icmp-closed30 seconds.
icmp-open60 seconds.
rawip-open30 seconds.
rawip-ready60 seconds.
syn15 seconds.
tcp-est3600 seconds.
udp-open30 seconds.
udp-ready60 seconds.
Configuring session aging time for different application layer

protocols
For sessions in the READY (with UDP) or ESTABLISH (with TCP) state, you can set the session aging times
according to the types of the application layer protocols to which the sessions belong.
IMPORTANT:
For a large amount of sessions (more than 800000), do not specify too short aging time. Otherwise, the
console might be slow in response.
To set session aging times based on application layer protocol type:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Aging times set in this command
applies to only the sessions in the
READY/ESTABLISH state.
2.
Set the aging time for sessions

of an application layer
protocol.
application aging-time { dns | ftp |

msn | qq | sip } time-value
The default values are as follows:
dns60 seconds.
ftp3600 seconds.
msn3600 seconds.
qq60 seconds.
sip300 seconds.
Enabling checksum verification

To make sure session tracking is not affected by packets with checksum errors, you can enable checksum
verification for protocol packets. With checksum verification enabled, the session management feature
413
processes only packets with correct checksums. Packets with incorrect checksums will be processed by
other services based on the session management.
IMPORTANT:
Checksum verification might degrade the device performance. Enable it with caution.
To enable checksum verification for protocol packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable checksum verification.
session checksum { all | { icmp |

tcp | udp } * }
Specifying persistent sessions

You can set the sessions that match the permit statements in a specific basic or advanced ACL as
persistent sessions, and set longer lifetime or never-age-out persistent sessions. A lifelong session is not
removed until the device receives a connection close request from the initiator or responder, or you
manually clear the session entries.
For more information about the configuration of basic and advance ACLs, see ACL and QoS
To specify persistent sessions:
Step
1.
2.
Enter system view.
Specify persistent sessions.
Command
Remarks
system-view
N/A
session persist acl acl-number

[ aging-time time-value ]
By default, no persistent sessions

are specified.
If you configure this command
multiple times, the last
configuration takes effect.
Specifying the operating mode for session management

By default, session management operates in bidirectional mode, and it can process only bidirectional
sessions. You can set the operating mode to hybrid mode for processing both bidirectional sessions and
unidirectional sessions. In a unidirectional session, packets in a specific direction can pass the device.
In the hybrid mode, some features cannot function correctly, and system security is adversely affected. For
example, in hybrid mode, ASPF cannot drop a non-SYN packet that is the first packet over a TCP
connection. If unidirectional sessions exist, set the operating mode to hybrid.
To specify the operating mode for session management:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
414
Step
Command
Remarks
Set the hybrid mode:

Specify an operating mode
for session management.
2.
session mode hybrid
Set the bidirectional mode:
By default, bidirectional mode is

used.
undo session mode
Configuring session logging

Session logs provide information about user access, IP address translation, and network traffic for
security auditing. These logs are sent in flow log format to the log server or the information center.
Enabling session logging

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
N/A
3.
(Required.) Enable
session logging.
session log enable [ acl acl-number ]

By default, session logging is

disabled.
Setting session logging thresholds

The device supports time-based or traffic-based logging:
Time-based loggingThe device outputs session logs at an interval.
Traffic-based loggingThe device outputs a session log when the traffic amount of a session
reaches a threshold. The traffic-based thresholds can be byte-based and packet-based. If you set
both thresholds, the last configuration takes effect.
If you set both time-based and traffic-based logging, the device outputs a session log when either
threshold is reached. After outputting a session log, the device resets the traffic counter and restarts the
interval for the session.
To set session logging thresholds:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
(Optional.) Set the

time-based logging.
session log time-active time-value
The defaut value is 0, which

means that the device does not
output time-based session logs.
Set the packet-based threshold:

3.
(Optional.) Set a
traffic-based logging type.
session log packets-active

packets-value
Set the byte-based threshold:
session log bytes-active bytes-value
415
The defaut value is 0, which

means that the device does not
output traffic-based session
logs.
Displaying and maintaining session management

Task
Command
Remarks
Display the session aging times for

application layer protocols.
display application aging-time [ |

Display the session aging times in

different protocol states.
display session aging-time [ | { begin

| exclude | include }
Display information about sessions.
display session table [ source-ip

source-ip ] [ destination-ip
destination-ip ] [ protocol-type { icmp
| raw-ip | tcp | udp } ] [ source-port
source-port ] [ destination-port
destination-port ] [ count | verbose ]
Display statistics about sessions.
display session statistics [ | { begin |

exclude | include }
Display session relationship table

information.
display session relation-table [ |

Clear sessions.
reset session [ source-ip source-ip ]

[ destination-ip destination-ip ]
[ protocol-type { icmp | raw-ip | tcp |
udp } ] [ source-port source-port ]
[ destination-port destination-port ]
Clear session statistics.
reset session statistics
416
Configuring Web filtering

Overview
In legacy network security solutions, network protection mainly targets external attacks. With the
popularity of network applications in every walk of life, however, the internal network also faces security
threats caused by internal user access to illegal networks. To protect the internal network against such
threats, the network devices must be able to filter illegal access requests from internal users.
Web filtering can help devices prevent internal users from accessing unauthorized websites and block
Java applets and ActiveX objects from Web pages. Web filtering provides the following functions:
URL address filtering
IP address-supported URL address filtering
URL parameter filtering
Java blocking
ActiveX blocking
URL address filtering

URL address filtering helps prevent internal users from accessing prohibited websites or restrict them to
specific websites by checking URL addresses contained in Web requests.
Processing procedure
1.
After receiving a Web request, the device resolves the URL address in the request.
2.
The device matches the URL address against the configured filtering entries.
3.
If a match is found and the filtering action of the matched entry is permit, the device forwards the
request.
4.
If a match is found and the filtering action of the matched entry is deny, the device drops the Web
request and sends a TCP reset packet to both the client that sent the request and the server.
5.
If no match is found, the device forwards or drops the request, depending on the default filtering
action configured for URL address filtering.
IP address-supported URL address filtering

Once the URL address filtering function is enabled, the system denies all Web requests that use IP
addresses by default. By enabling support for IP address in URL address filtering, you can configure the
device to allow internal users to access specified or all websites based on the website IP addresses.
After the device receives a Web request that uses an IP address, it processes the request as follows:
If URL address filtering supports IP addresses, the device forwards the request. The device permits all
Web requests that use the websites' IP addresses to pass.
417
If URL address filtering does not support IP addresses, the device checks the ACL rules for URL
address filtering. If the ACL permits the IP address, the device forwards the request. Otherwise, the
device drops the request.
URL parameter filtering

Many Web pages are dynamic, connected with databases, and support data query and modification
through Web requests. This makes it possible to fabricate special SQL statements in Web requests to
obtain confidential data from databases or break down databases by repeatedly modifying database
information. This kind of attack is called SQL injection attack.
To address this problem, the device compares the URL parameters in a Web request against SQL
statement keywords and some other characters that might constitute SQL statements. If a match is found,
the device regards the request as an SQL injection attack and denies it. This protection mechanism is
called URL parameter filtering.
Web requests transmit parameters mainly by using GET and POST methods. The method used for
transmitting parameters determines the positions of the URL parameters. The device obtains parameters
based on the parameter transmission method and performs filtering. The device supports URL parameter
filtering of Web requests with the GET, POST or PUT method.
After receiving a Web request containing URL parameters, the device obtains the parameters according
to the parameter transmission method and processes the request accordingly:
If the parameters are transmitted by a method other than GET, POST and PUT, the device directly
forwards the Web request.
If the parameters are transmitted by the method of GET, POST or PUT, the device obtains the URL
parameters from the Web request and compares the URL parameters against the configured
filtering entries. If a match is found, the device denies the request. Otherwise, the device forwards
the request.
Java blocking
Java blocking protects networks from Java applets attacks.
After the Java blocking function is enabled, all requests for Java applets of Web pages are filtered. If
Java applets in some Web pages are expected, configure ACL rules to permit requests to Java applets of
these Web pages.
If the Java blocking function is enabled but no ACL is configured for it, the device replaces
suffixes .class and .jar with .block in all Web requests and then forwards the requests.
If the Java blocking function is enabled and an ACL is configured for it, the device uses ACL rules
to determine whether to replaces suffixes .class and .jar with .block in Web requests. If the
destination server in a Web request is a server permitted by the ACL, no replacement occurs and
the request is forwarded; otherwise, the suffix in the request is replaced with .block before the
request is forwarded.
In addition to the default suffixes .class and .jar, you can add Java blocking suffixes (filename
suffixes to be replaced in Web requests) through command lines.
418
ActiveX blocking
ActiveX blocking protects networks from being attacked by malicious ActiveX plugins.
After the ActiveX blocking function is enabled, requests for ActiveX plugins to all Web pages will be
filtered. If the ActiveX plugins in some Web pages are expected, you can configure ACL rules to permit
requests to the ActiveX plugins of these Web pages.
If the ActiveX blocking function is enabled but no ACL is configured for it, the device replaces the
suffix .ocx with .block in all Web requests before forwarding the requests.
If the ActiveX blocking function is enabled and an ACL is configured for it, the device determines
whether to replaces suffix .ocx with .block in Web requests according to the ACL rules. If the
destination server in a Web request is a server permitted by the ACL, no replacement occurs and
the request is forwarded; otherwise, the suffix is replaced with .block and then the request is
forwarded.
In addition to the default suffix .ocx, you can add ActiveX blocking suffixes (that is, the filename
suffixes to be replaced in Web requests) through command lines.
Configuring Web filtering

IP address-supported URL filtering can take effect only after the URL address filtering is enabled, while
URL parameter filtering, Java blocking, and ActiveX blocking can be enabled independently.
Configuring URL address filtering

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the URL address

filtering function.
firewall http url-filter host enable
3.

action.
firewall http url-filter host default { deny |

permit }
Optional.
4.
Add a URL address filtering

entry.
firewall http url-filter host url-address { deny |

permit } url-address
N/A
5.

URL address filtering.
display firewall http url-filter host [ all | item

keywords | verbose ] [ | { begin | exclude |
Optional.
The default is deny.
Configuring IP address-supported URL address filtering

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the URL address filtering

function.
firewall http url-filter host enable
419
Step
Command
Remarks
firewall http url-filter host ip-address

{ deny | permit }
Deny by default.
3.
Configure IP address-supported
URL address filtering.
4.
Specify an ACL for URL address

filtering.
firewall http url-filter host acl acl-number
5.
Display information about URL

address filtering.
display firewall http url-filter host [ all |

item keywords | verbose ] [ | { begin |
Optional.
By default, no ACL is
specified for URL address
filtering.
Optional.
The source IP addresses specified in the ACL for URL address filtering must be the IP addresses of the
websites allowed to be accessed by using their IP addresses.
Configuring URL parameter filtering

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the URL parameter

filtering function.
firewall http url-filter parameter enable
3.
Add a URL parameter

filtering entry.
firewall http url-filter parameter { default |

keywords keywords }
N/A
4.

URL parameter filtering.
display firewall http url-filter parameter [ all

| item keywords | verbose ] [ | { begin |
Optional.
Configuring Java blocking

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the Java blocking

function.
firewall http java-blocking enable
3.
Add a Java blocking suffix

keyword.
firewall http java-blocking suffix keywords
Optional.
4.
Specify an ACL for Java

blocking.
firewall http java-blocking acl acl-number
5.

Java blocking.
display firewall http java-blocking [ all |

Optional.
specified for Java blocking.
Optional.
In the ACL for Java blocking, you need to configure the source IP addresses as the IP addresses of the
HTTP servers allowed to be accessed, and set the action to permit.
420
Configuring ActiveX blocking

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the ActiveX blocking

function.
firewall http activex-blocking enable
3.
Add an ActiveX blocking

suffix keyword.
firewall http activex-blocking suffix

keywords
Optional.
Optional.
4.
Specify an ACL for ActiveX

blocking.
firewall http activex-blocking acl acl-number
5.

ActiveX blocking.
display firewall http activex-blocking [ all |

specified for ActiveX
blocking.
Optional.
In the ACL for ActiveX blocking, you need to configure the source IP addresses as the IP addresses of the
HTTP servers allowed to be accessed and set the action to permit.
Displaying and maintaining Web filtering

Task
Command
Remarks

address filtering.
display firewall http url-filter host [ all | item


parameter filtering.
display firewall http url-filter parameter [ all |

Display information about Java

blocking.
display firewall http java-blocking [ all | item

Display information about ActiveX

blocking.
display firewall http activex-blocking [ all |

Clear Web filtering statistics.
reset firewall http { activex-blocking |

java-blocking | url-filter host | url-filter
parameter } counter
Web filtering configuration examples

421
URL address filtering configuration example

The hosts in the network segment 192.168.1.0/24 access the Internet through the AC. The AC is enabled
with the URL address filtering function, and allows the hosts to access only www.webflt.com using the URL
address or IP address.
# Configure IP addresses for the interfaces. (Details not shown.)
# Configure a NAT policy for the outbound interface.
<AC> system-view
[AC-acl-basic-2200] rule 0 permit source 192.168.1.0 0.0.0.255
[AC-acl-basic-2200] rule 1 deny source any
[AC] interface Vlan-interface 1
# Enable the URL address filtering function.

[AC] firewall http url-filter host enable
# Allow users to access only website www.webfit.com, and set the default filtering action to deny.
[AC] firewall http url-filter host url-address permit www.webflt.com
[AC] firewall http url-filter host default deny
422
# Configure an ACL for URL address filtering.

# Allow users to use IP addresses to access websites.

[AC] firewall http url-filter host ip-address permit
[AC] firewall http url-filter host acl 2000
After the configurations are completed, open a Web browser on a host in the LAN, enter website
http://www.webflt.com or http://3.3.3.3, and you can access this website correctly. Enter other
website addresses, and you are not allowed to access the corresponding websites.
# Display detailed information about URL address filtering.
[AC] display firewall http url-filter host verbose
URL-filter host is enabled.
Default method: deny.
The support for IP address: permit.
The configured ACL group is 2000.
There are 1 packet(s) being filtered.
There are 1 packet(s) being passed.
# Display URL address filtering information for all filtering entries.

[AC] display firewall http url-filter host all
SN
Match-Times
Keywords
-----------------------------------1
www.webflt.com
URL parameter filtering configuration example

The hosts in the network segment 192.168.1.0/24 access the Internet through the AC. The AC is enabled
with the URL parameter filtering function, which uses the user-defined filtering entry group to filter Web
requests.
423
<AC> system-view
# Enable the URL parameter filtering function, and add URL parameter filtering entry group.
[AC] firewall http url-filter parameter enable
[AC] firewall http url-filter parameter keywords group
# Use the display firewall http url-filter parameter verbose command to display detailed URL parameter
filtering information.
[AC] display firewall http url-filter parameter verbose
URL-filter parameter is enabled.
# Use the display firewall http url-filter parameter all command to display URL parameter filtering
information for all filtering entries.
[AC] display firewall http url-filter parameter all
SN
Match-Times
Keywords
-----------------------------------1
group
424
Java blocking configuration example

The hosts in the network segment 192.168.1.0/24 access the Internet through the AC. Enable Java
blocking on the AC, add suffix keyword .js, and configure the device to allow only Java applet requests
to the website at 5.5.5.5.
<AC> system-view
# Configure an ACL numbered 2100 for Java blocking.

# Enable the Java blocking function, add blocking suffix keyword .js, and specify ACL 2100 for Java
blocking.
[AC] firewall http java-blocking enable
[AC] firewall http java-blocking suffix .js
[AC] firewall http java-blocking acl 2100
425
# Use the display firewall http java-blocking verbose command to display detailed Java blocking
information.
[AC] display firewall http java-blocking verbose
Java blocking is enabled.
The configured ACL group is 2100.
# Use the display firewall http java-blocking all command to display Java blocking information for all
blocking suffix keywords.
[AC] display firewall http java-blocking all
SN
Match-Times
Keywords
-----------------------------------1
.CLASS
.JAR
.js
The output shows that there are three Java blocking suffix keywords, of which .CLASS and .JAR are the
default ones, and .js is a user-defined one and has been matched once.
Troubleshooting Web filtering

Failed to add filtering entry or suffix keyword due to upper limit
Symptom
When you try to add a URL address filtering entry or URL parameter filtering entry, the system
prompts you that no more entry can be added.
When you add a Java blocking or ActiveX blocking suffix keyword, the system prompts you that no
more keyword can be added.
Analysis
The number of URL address filtering entries, URL parameter filtering entries, Java blocking suffix keywords,
or ActiveX blocking suffix keywords has reached the upper limit.
Solution
If necessary, remove some configured entries or keywords before adding new ones.
Invalid characters are present in the configured parameter

Symptom
When you configure a URL address filtering entry or URL parameter filtering entry, the system displays a
character error message.
Analysis
A URL address filtering entry can contain only 0 to 9, a to z, A to Z, dot (.), hyphen (-), underline (_), and
wildcards caret (^), dollar sign ($), ampersand (&), and asterisk (*). A URL parameter filtering entry can
contain only 0 to 9, a to z, A to Z, wildcards caret (^), dollar sign ($), ampersand (&), and asterisk (*),
and other ASCII characters with values between 31 and 127.
426
Solution
Make sure that all entered characters are valid.
Invalid use of wildcard

Symptom
When you configure a URL address filtering entry or URL parameter filtering entry, the system prompts
you that the wildcards are not used correctly.
Analysis
The wildcards for URL address filtering entries and those for URL parameter filtering entries have different
usage restrictions:
Table 16 Wildcards for URL address filtering entries
Wildcard
Meaning
Usage guidelines
Matches website addresses

starting with the keyword
It can be present once at the beginning of a filtering

entry.
Matches website addresses

ending with the keyword
It can be present once at the end of a filtering entry.
&
Stands for a valid character other

than a dot (.)
It can be present multiple times at any position of a

filtering entry, consecutively or inconsecutively, but
cannot be used together with an asterisk (*).
Stands for any number of valid

characters and spaces excluding
a dot (.)
It can be present once at the beginning or in the middle

of a filtering entry. It cannot be at the end and cannot be
used next to a caret (^) or a dollar sign ($).
Table 17 Wildcards for URL parameter filtering entries

Wildcard
Meaning
Usage guidelines
Matches parameters starting with

the keyword
Can be present once at the beginning of a filtering

entry.
Matches parameters ending with

the keyword
It can be present once at the end of a filtering entry.
&
Stands for one valid character
It can be present multiple times at any position of a

filtering entry, consecutively or inconsecutively, and
cannot be used next to an asterisk (*). If it is present at
the beginning or end of a filtering entry, it must be next
to a caret (^) or a dollar sign ($).
Stands for a string of up to 4 valid

characters, including spaces
It can be present once in the middle of a filtering entry.
Solution
Use the wildcards correctly according to the above principles.
427
Invalid blocking suffix

Symptom
When you configure a Java blocking suffix keyword or ActiveX blocking suffix keyword, the system
prompts you that there are invalid suffix keywords.
Analysis
A blocking suffix requires a dot (.) as part of it. If no dot or multiple dots are configured, the configuration
fails.
Solution
Configure a suffix keyword according to the description in the analysis.
ACL configuration failed

Symptom
An ACL rule uses the IP address of a host in the internal network as the source address and permits
requests from the host. The ACL is referenced for URL address filtering, Java blocking or ActiveX blocking,
but it does not work.
Analysis
For URL address filtering, Java blocking and ActiveX blocking, ACLs permit access to servers in external
networks rather than hosts in the internal network. This is because the internal network is assumed to be
trusted.
Solution
Specify the IP address of the server in the external network as the source IP address in the ACL rule.
Unable to access the HTTP server by IP address

Symptom
After the URL address filtering function is enabled, you cannot access the HTTP server by its IP address.
Analysis
By default, the URL address filtering function disables access by IP address. Web requests that use the IP
address to access the HTTP server will be filtered.
Solution
Configure an ACL to permit Web requests to the IP address of the HTTP server.
428
Configuring user isolation

User isolation includes the following types:
VLAN-based user isolationIsolates users in the same VLAN from accessing each other at Layer 2.
SSID-based user isolationIsolates users using the same SSID from accessing each other at Layer
2.
VLAN-based user isolation

VLAN-based user isolation allows users to access the network, and at the same time, it isolates users from
accessing each other at Layer 2 for security purposes.
When VLAN-based user isolation is enabled, an AC isolates packets from the same VLAN in the
following ways:
When an AC receives unicast, broadcast, or multicast packets from a wireless user to another
wireless user, the AC determines whether to isolate the two users based on the permitted MAC
address list.
When an AC receives unicast packets from a wireless user to a wired user, the AC determines
whether to isolate the two users based on the permitted MAC address list. However, the AC permits
all broadcast and multicast packets from a wireless user to a wired user.
When an AC receives unicast packets from a wired user to another wired user, the AC determines
whether to isolate the two users based on the permitted MAC address list. However, the AC permits
all broadcast and multicast packets from a wired user to another wired user.
When an AC receives unicast packets from a wired user to a wireless user, the AC determines
whether to isolate the two users based on the permitted MAC address list. The user-isolation permit
broadcast command setting determines whether the AC permits broadcast or multicast packets
(from a wired user to a wireless user).
For correct communication between users and the gateway, add the MAC address of the gateway to the
permitted MAC address list.
As shown in Figure 150, the wireless client, the wired server, and the wired host in VLAN 2 access the
Internet through the same gateway. When VLAN-based user isolation is enabled on the AC, the
following rules apply:
If you add only the MAC address of the gateway to the permitted MAC address list, the client, server,
and host are isolated at Layer 2. They can access the Internet.
If you add only the MAC address of the client to the permitted MAC address list, the client and the
server, and the client and the host, can access each other at Layer 2, but the server and the host
cannot.
If you add the MAC addresses of the gateway, the server, and the client to the permitted MAC
address list, the client, the server, and the host can access one another at Layer 2. They also can
access the Internet.
429
SSID-based user isolation

For security purposes and accounting accuracy, enable SSID-based user isolation. It disables wireless
users that use the same SSID from accessing each other at Layer 2.
When SSID-based user isolation is enabled on the AC, all the wireless users using the same SSID are
disabled from forwarding Layer 2 unicast or broadcast packets to each other.
Configuring VLAN-based user isolation

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable user isolation for the

specified VLANs.
user-isolation vlan vlan-list enable
By default, user isolation is

disabled.
Optional.
3.
Specify permitted MAC

addresses for the specified
VLANs.
user-isolation vlan vlan-list

permit-mac mac-list
430
Up to 16 permitted MAC
addresses can be configured for a
VLAN.
To avoid network disruption
caused by user isolation, add the
MAC address of the gateway to
the permitted MAC address list
and then enable user isolation.
Step
4.
Command
Permit broadcast and
multicast packets from a wired
user to a wireless user.
Remarks
Optional.
user-isolation permit broadcast
By default, broadcast and multicast

packets from a wired user to a
wireless user are permitted.
Configuring SSID-based user isolation

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure WLAN service

template.
wlan service-template
service-template-number { clear |
crypto }
N/A
3.
Enable SSID-based user

isolation.
Optional.
user-isolation enable
By default, SSID-based user

isolation is disabled.
Displaying and maintaining user isolation

Task
Command
Remarks
Display user isolation statistics.
display user-isolation statistics

[ vlan vlan-id ] [ | { begin | exclude
Clear user isolation statistics.
reset user-isolation statistics [ vlan

vlan-id ]
User isolation configuration example

431
As shown in Figure 151, configure user isolation on the AC, so Client A, Client B, and Host A in VLAN 2
can access the Internet, but they cannot access one another at Layer 2.
Internet
Gateway
MAC address: 000f-e2127788
AC
AP
Host A
Client A
VLAN 2
Client B
1.
Configure the AC:

# Configure the AP so that a connection can be established between the AC and AP. (Details not
shown.)
For information about establishing the connection, see WLAN Configuration Guide.
<AC> system-view
# Add the MAC address of the gateway to the permitted MAC address list of VLAN 2 so that Client
A, Client B, and Host A in VLAN 2 can access the Internet.
[AC] user-isolation vlan 2 permit-mac 000f-e212-7788
# Enable user isolation for VLAN 2 so that users in VLAN 2 cannot access each other at Layer 2.
[AC] user-isolation vlan 2 enable
2.
Verify the configuration.

Client A, Client B, and Host A in VLAN 2 can access the Internet, but they cannot access one
another at Layer 2.
432
Configuring source IP address verification

Overview
Source IP address verification is intended to improve wireless network security by blocking illegal packets.
For example, it can prevent illegal hosts from using a valid IP address to access the network.
Source IP address verification can filter packets based on the IP-MAC binding entries.
For a client using an IPv4 address, the AP can obtain the IP address assigned to the client in the DHCPv4
packets exchanged between the DHCP server and the client, and bind the IP address with the MAC
address of the client.
For a client using an IPv6 address, the AP can generate binding entries in either of the following ways:
DHCPv6The AP obtains the complete IPv6 address assigned to the client in the DHCPv6 packets
exchanged between the DHCPv6 server and the client, and binds the IPv6 address with the MAC
address of the client. If the AP obtains the IPv6 address prefix assigned to the client, it cannot
generate the proper binding entry.
NDThe AP obtains the broadcast IPv6 address prefix in the router advertisement packets
exchanged between the router and the client, and binds the IPv6 address prefix with the MAC
address of the client.
For more information about DHCP, DHCPv6, and ND, see Layer 3 Configuration Guide.
After source IP address verification is enabled, the AP looks up the binding entries for received packets.
If the source MAC address and source IP address of a packet matches a binding entry, the AP forwards
the packet. Otherwise, the AP discards it. Figure 152 shows how source IP address verification works.
Figure 152 Source IP address verification process
Configuring source IP address verification

Source IP address verification is effective on a per-SSID basis. After you enable this feature for an SSID,
the AP only revivifies the source IP address of the clients using the SSID to access the network, but does
not check the source IP addresses of the clients using other SSIDs.
433
For a client using an SSID configured with source IP address verification, if it accesses the network
through AP local authentication, the source IP address verification feature is effective but the IP-MAC
binding entry for the client cannot be displayed on the AC. If the client needs to roam to an AP of another
AC in the roaming group, the AC to which the client roams must be configured with source IP address
verification for the specified SSID. Otherwise, the client connection is lost. For more information about AP
local authentication and WLAN roaming, see WLAN Configuration Guide.
To configure source IP address verification:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure a WLAN
service template.
wlan service-template
service-template-number { clear |
crypto }
N/A
3.
Enable source IP
address verification for
IPv4 clients.
ip verify source
By default, source IP address

verification is disabled for IPv4
clients.
Enable source IP
address verification for
IPv6 clients.
ipv6 verify source
By default, source IP address

verification is disabled for IPv6
clients.
4.
Displaying and maintaining source IP address

verification
Task
Command
Displaying IPv4/IPv6
binding entries.
display wlan client { ip | ipv6 } source binding [ mac-address mac-address ] [ |

Source IP address verification configuration

example
an 830 switch and an 870 appliance are Access interfaces in VLAN 1. When configuring the two
434
Source IPv4 address verification configuration example

As shown in Figure 153, the clients access the network using the SSID "service", and the DHCP server
dynamically assigns IP addresses for the clients.
Enable source IP address verification for the clients using the SSID to prevent illegal access.
DHCP server
Eth1/1
Client 1
IP network
AC
Switch
Client 2
AP
Client 3
1.
Configure the DHCP server:

# Enable DHCP.
<DHCP> system-view
[DHCP] dhcp enable
# Assign an IP address to interface Ethernet 1/1.

[DHCP] interface ethernet 1/1
[DHCP-Ethernet1/1] ip address 10.1.1.1 24
# Configure interface Ethernet 1/1 to operate in DHCP server mode.

[DHCP-Ethernet1/1] dhcp select server global-pool
[DHCP-Ethernet1/1] quit
# Create DHCP address pool 0, and assign network segment 10.1.1.0/24 to the address pool.
[DHCP] dhcp server ip-pool 0
[DHCP-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0
2.
Configure the AC:

# Create a WLAN-ESS interface.
<AC> system-view
[AC-WLAN-ESS1] quit
# Configure a WLAN service template, specify service as the SSID, and bind the WLAN-ESS
interface with the service template.
[AC-wlan-st-1] ssid service
435
# Enable source IP address verification for IPv4 clients.

[AC-wlan-st-1] ip verify source
[AC-wlan-st-1] quit
# Create an AP template named ap1.

# Configure 802.11gn radio.

[AC-wlan-ap-ap1] radio 2 type dot11gn

The MAC address of Client 1 is 001d-0f31-87dd, and that of Client 2 is 001c-f08f-f7f1. They are legal
clients but Client 3 is an illegal client. After they obtain IP addresses from the DHCP server, you can see
the IPv4 binding entries for the two clients by using the display wlan client ip source binding command.
The AP filters the received packets using the two binding entries. It forwards the packets from Client 1 and
Client 2, but discards the packets from Client 3.
<Sysname> display wlan client ip source binding
IP Source Binding Information
-----------------------------------------------------------MAC Address
APID/RID
Type
Binding IP Address
-----------------------------------------------------------001d-0f31-87dd
1/2
DHCP
10.1.1.1
001c-f08f-f7f1
1/2
DHCP
10.1.1.2
------------------------------------------------------------
Source IPv6 address verification configuration example (using

DHCPv6 server)
As shown in Figure 154, the clients access the network using the SSID "service", and the DHCPv6
server dynamically assigns IPv6 addresses for the clients.
Enable source IP address verification for the IPv6 clients using the SSID to prevent illegal access.
436

DHCPv6 server
Eth1/1
Client 1
IP network
AC
Switch
AP
Client 2
Client 3
1.
Configure the DHCPv6 server:

# Enable IPv6 forwarding and DHCPv6 server.
<DHCPv6> system-view
[DHCPv6] ipv6
[DHCPv6] ipv6 dhcp server enable
# Create DHCPv6 address pool 1, and assign network segment 2001:2::/64 to the address pool.
[DHCPv6] ipv6 dhcp pool 1
[DHCPv6-dhcp6-pool-1] network 2001:2::/64
[DHCPv6-dhcp6-pool-1] quit
# Assign an IPv6 address to interface Ethernet 1/1.

[DHCPv6] interface ethernet 1/1
[DHCPv6-Ethernet1/1] ipv6 address 2001:2::1/64
# Enable interface Ethernet 1/1 to send RA messages.

[DHCPv6-Ethernet1/1] undo ipv6 nd ra halt
# Configure interface Ethernet 1/1 to operate in DHCPv6 server mode, and reference address
pool 1.
[DHCPv6-Ethernet1/1] ipv6 dhcp server apply pool 1
2.
Configure the AC:

<AC> system-view
[AC-WLAN-ESS1] quit

[AC-wlan-st-1] ipv6 verify source
437

[AC-wlan-st-1] quit



clients but Client 3 is an illegal client. After they obtain IPv6 addresses from the DHCPv6 server, you can
see the IPv6 binding entries for the two clients by using the display wlan client ipv6 source binding
command. The AP filters the received IPv6 packets using the two binding entries. It forwards the packets
from Client 1 and Client 2, but discards the packets from Client 3.
<Sysname> display wlan client ipv6 source binding
IPv6 Source Binding Information
-----------------------------------------------------------MAC Address
APID/RID
Type
Binding IP Address
-----------------------------------------------------------001d-0f31-87dd
1/2
DHCPv6
2001:2::2
001c-f08f-f7f1
1/2
DHCPv6
2001:2::3
------------------------------------------------------------
Source IPv6 address verification configuration example (using

ND)
As shown in Figure 155, the clients access the network using the SSID "service", and the router
dynamically assigns IPv6 address prefixes for the clients.
Enable source IP address verification for the IPv6 clients using the SSID to prevent illegal access.
438

Router
Eth1/1
Client 1
IP network
AC
Switch
AP
Client 2
Client 3
1.
Configure the router:

# Enable IPv6 forwarding.
<Router> system-view
[Router] ipv6
# Assign an IPv6 address to interface Ethernet 1/1.

[Router] interface ethernet 1/1
[Router-Ethernet1/1] ipv6 address 2001::1/64
# Enable interface Ethernet 1/1 to send RA messages.

[Router-Ethernet1/1] undo ipv6 nd ra halt
# Specify the address prefix to distribute as 2001::/64, with life time being 86400 seconds. The
preferred life time is 3600 seconds.
[Router-Ethernet1/1] ipv6 nd ra prefix 2001::/64 86400 3600
2.
Configure the AC:

<AC> system-view
[AC-WLAN-ESS1] quit

[AC-wlan-st-1] ipv6 verify source
[AC-wlan-st-1] quit

439


clients but Client 3 is an illegal client. After they obtain IPv6 address prefixes through ND, you can see
the IPv6 binding entries for the two clients by using the display wlan client ipv6 source binding command.
The AP filters the received IPv6 packets using the two binding entries. It forwards the packets from Client
1 and Client 2, but discards the packets from Client 3.
<Sysname> display wlan client ipv6 source binding
IPv6 Source Binding Information
-----------------------------------------------------------MAC Address
APID/RID
Type
Binding IP Address
-----------------------------------------------------------001d-0f31-87dd
1/2
ND
2001::
001c-f08f-f7f1
1/2
ND
2001::
------------------------------------------------------------
440
Configuring FIPS
Overview
Federal Information Processing Standards (FIPS) was developed by the National Institute of Standard
and Technology (NIST) of the United States. FIPS specifies the requirements for cryptographic modules.
FIPS 140-2 defines four levels of security, named "Level 1" to "Level 4" from low to high. The device
supports Level 2.
Unless otherwise noted, in this document the term "FIPS" refers to FIPS 140-2.
FIPS self-tests
CAUTION:
If the device reboots repeatedly, it might be caused by software failures or hardware damages. Contact
HP Support to upgrade the software or repair the damaged hardware.
When the device operates in FIPS mode, it has self-test mechanisms, including power-up self-test and
conditional self-test, to ensure the correct operation of cryptography modules.
Power-up self-tests
The power-up self-test, also called "known-answer test", examines the availability of FIPS-allowed
cryptographic algorithms. A cryptographic algorithm is run on data for which the correct output is
already known. The calculated output is compared with the known answer. If they are not identical, the
known-answer test fails.
The power-up self-test examines the cryptographic algorithms listed in Table 18.
Table 18 Power-up self-test list
Type
Operations
Tests the following algorithms:
Cryptographic algorithm
self-test
DSA (signature and authentication)

RSA (signature and authentication)
RSA (encryption and decryption)
AES
3DES
SHA1
SHA256
SHA512
HMAC-SHA1
Random number generator algorithms
441
Type
Operations
Tests the following algorithms used by cryptographic engines:
Cryptographic engine self-test
DSA (signature and authentication)

RSA (signature and authentication)
RSA (encryption and decryption)
AES
3DES
SHA1
HMAC-SHA1
Random number generator algorithms
Conditional self-tests
A conditional self-test runs when an asymmetrical cryptographic module or a random number generator
module is invoked. Conditional self-tests include the following types:
Pair-wise consistency testThis test is run when a DSA/RSA asymmetrical key-pair is generated. It
uses the public key to encrypt a plain text, and uses the private key to decrypt the encrypted text. If
the decryption is successful, the test succeeds. Otherwise, the test fails.
Continuous random number generator testThis test is run when a random number is generated.
If two consecutive random numbers are different, the test succeeds. Otherwise, the test fails. This test
can also be run when a DSA/RSA asymmetrical key-pair is generated.
Triggering self-tests
To examine whether the cryptography modules operate correctly, you can trigger a self-test on the
cryptographic algorithms. The triggered self-test is the same as the power-up self-test. If the self-test fails,
the device automatically reboots.
To trigger a self-test:
Step
Command
1.
Enter system view.
system-view
2.
Trigger a self-test.
fips self-test
To enter FIPS mode, follow these steps:
1.
Enable FIPS mode.
2.
Enable the password control function.
3.
Configure the username and password to log in to the device in FIPS mode. The password must
include at least 10 characters and must contain uppercase and lowercase letters, digits, and
special characters.
4.
Delete all MD5-based digital certificates.
5.
Delete the DSA key pairs that have a modulus length of less than 1024 bits and all RSA key pairs.
442
6.
Save the configuration.
Enabling FIPS mode

Follow these guidelines when you enable FIPS mode:
If you must enable both FIPS mode and the password control function, enable FIPS mode first.
If you must disable both FIPS mode and the password control function, disable password control
first.
After FIPS mode is enabled, delete the FIPS 140-2-incompliant local user service type Telnet, HTTP,
or FTP before you reboot the device.
To enable FIPS mode:

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable FIPS mode.
fips mode enable
By default, the FIPS mode is

disabled.
Configuration changes in FIPS mode

After you enable FIPS mode and reboot the device, the following system changes occur:
The FTP/TFTP server is disabled.
The Telnet server is disabled.
The HTTP server is disabled.
SNMPv1 and SNMPv2c are disabled. Only SNMPv3 is available.
The SSL server only supports TLS1.0.
The SSH server does not support SSHv1 clients.
Generated RSA key pairs must have a modulus length of 2048 bits, and DSA key pairs have a
modulus length from 1024 to 2048 bits.
SSH, SNMPv3, IPsec, and SSL do not support DES, RC4, or MD5.
Displaying and maintaining FIPS

Execute display commands in any view.
Task
Command
Display FIPS mode state.
display fips status
FIPS configuration example

443
As shown in Figure 156, Host connects to AC through a console port. Configure AC to operate in FIPS
mode, and create a local user for Host so that Host can log in to AC.
CAUTION:
After you enable FIPS mode, you must create a local user and its password before you reboot the device.
Otherwise, you cannot log in to the device. To log in to the device, reboot the device without the
configuration file (by ignoring or removing the configuration file) so that the device operates in non-FIPS
mode, and then make correct configurations.
# Enable the FIPS mode.
<Sysname> system-view
[Sysname] fips mode enable
FIPS mode change requires a device reboot. Continue?[Y/N]:y
Modify the configuration to be fully compliant with FIPS mode, save the configuration to
the next-startup configuration file, and then reboot to enter FIPS mode.
# Enable the password control function.

[Sysname] password-control enable
# Create a local user named test, and set its service type as terminal, privilege level as 3, and password
as AAbbcc1234%. The password is a string of at least 10 characters by default, and must contain both
uppercase and lowercase letters, digits, and special characters. (Use an interactive way to configure the
password for the local user. Enter password in local user view and follow the prompts to enter the
password.)
[Sysname] local-user test
[Sysname-luser-test] service-type terminal
[Sysname-luser-test] authorization-attribute level 3
[Sysname-luser-test] password
Password:***********
Confirm :***********
444
Updating user(s) information, please wait...........

[Sysname-luser-test] quit
# Save the configuration.

[Sysname] save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[cfa0:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):
cfa0:/startup.cfg exists, overwrite? [Y/N]:y
Validating file. Please wait....
Configuration is saved to device successfully.
# Reboot the device.

<Sysname> reboot

After the device reboots, enter the username test and the password AAbbcc1234%. The system prompts
that your first login is successful, and requires you to enter a new password. Enter a new password which
has at least four characters different than the previous one and confirm the password. Then, the system
displays the <Sysname> prompt.
User interface con0 is available.
Please press ENTER.
Login authentication
Username:test
Password:
Info: First logged in. For security reasons you will need to change your password.
Please enter your new password.
Password:**********
Confirm :**********
Updating user(s) information, please wait...........
<Sysname>
# Display the current FIPS mode.

<Sysname> display fips status
FIPS mode is enabled
445
Configuring protocol packet rate limit

This feature helps you rate-limit packets of a specific protocol to prevent the packets from occupying too
much bandwidth.
Protocol packets can be rate-limited in the following modes:
Bandwidth limit per protocolYou set a maximum bandwidth for packets of a specific protocol.
When the maximum bandwidth is exceeded, the packets are discarded.
Bandwidth limit per flowYou set a maximum bandwidth for each flow to ensure that the same
kind of requests from all users are fairly treated. Packets of the same protocol and from the same
user are considered as one flow. The system records the number of passed and dropped protocol
packets to help network administrators locate problems. Bandwidth limit per flow takes effect only
when bandwidth limit per protocol takes effect.
Enabling protocol packet rate limit

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable protocol packet rate

limit.
anti-attack enable
By default, protocol packet rate

limit is disabled.
Enabling per-protocol bandwidth limit

Step
1.
2.
Enter system view.
Enable per-protocol
bandwidth limit.
Command
Remarks
system-view
N/A
anti-attack protocol { all |

protocol } enable
By default, per-protocol bandwidth limit is

disabled for all protocols.
To display the protocols whose packets
can be rate limited, use the display
anti-attack protocol command.
Configuring the threshold for per-protocol bandwidth limit

Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Configure the threshold for

per-protocol bandwidth limit.
anti-attack protocol
protocol threshold rate-limit
446
Each protocol has a default threshold. You

can use the display anti-attack protocol
{ protocol } command to view the default
threshold for a protocol.
Configuring the threshold for per-flow bandwidth limit

Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable per-flow bandwidth

limit and configure the
threshold.
anti-attack protocol protocol

flow-threshold flow-rate-limit
By default, per-flow bandwidth

limit is disabled for packets of all
protocols.
Table 19 Supported number of flows of each device
Device type
HP
11900/10500/7500
20G unified
wired-WLAN module
HP 830 24/8-Port PoE+

unified wired-WLAN
switch access controller
engine
HP 850 Unified
Wired-WLAN
Appliance/ HP 870
unified wired-WLAN
appliance access
controller engine
Supported number of
flows
8192
1024
8192
NOTE:
Support for the number of flows varies by device model. The system automatically clears all flow entries
when the maximum number is reached.
Displaying and maintaining protocol packet rate limit

Task
Command
Remarks
Display rate limit information about

the specified protocol or all
protocols.
display anti-attack { all | protocol

[ protocol ] }
447
Support and other resources

Contacting HP
For worldwide technical support information, see the HP support website:
http://www.hp.com/support
Before contacting HP, collect the following information:
Product model names and numbers
Technical support registration number (if applicable)
Product serial numbers
Error messages
Operating system type and revision level
Detailed questions
Subscription service
HP recommends that you register your product at the Subscriber's Choice for Business website:
http://www.hp.com/go/wwalerts
After registering, you will receive email notification of product enhancements, new driver versions,
firmware updates, and other product resources.
Related information
Documents
To find related documents, browse to the Manuals page of the HP Business Support Center website:
http://www.hp.com/support/manuals
For related documentation, navigate to the Networking section, and select a networking category.
For a complete list of acronyms and their definitions, see HP FlexNetwork Technology Acronyms.
Websites
HP.com http://www.hp.com
HP Networking http://www.hp.com/go/networking
HP manuals http://www.hp.com/support/manuals
HP download drivers and software http://www.hp.com/support/downloads
HP software depot http://www.software.hp.com
HP Education http://www.hp.com/learn
448
Conventions
This section describes the conventions used in this documentation set.
Command conventions
Convention
Description
Boldface
Bold text represents commands and keywords that you enter literally as shown.
Italic
Italic text represents arguments that you replace with actual values.
[]
Square brackets enclose syntax choices (keywords or arguments) that are optional.
{ x | y | ... }
Braces enclose a set of required syntax choices separated by vertical bars, from which
you select one.
[ x | y | ... ]
Square brackets enclose a set of optional syntax choices separated by vertical bars, from
which you select one or none.
{ x | y | ... } *
Asterisk-marked braces enclose a set of required syntax choices separated by vertical

bars, from which you select at least one.
[ x | y | ... ] *
Asterisk-marked square brackets enclose optional syntax choices separated by vertical

bars, from which you select one choice, multiple choices, or none.
&<1-n>
The argument or keyword and argument combination before the ampersand (&) sign can
be entered 1 to n times.
A line that starts with a pound (#) sign is comments.
GUI conventions
Convention
Description
Boldface
Window names, button names, field names, and menu items are in bold text. For
example, the New User window appears; click OK.
>
Multi-level menus are separated by angle brackets. For example, File > Create > Folder.
Convention
Description
Symbols
WARNING
An alert that calls attention to important information that if not understood or followed can
result in personal injury.
CAUTION
An alert that calls attention to important information that if not understood or followed can
result in data loss, data corruption, or damage to hardware or software.
IMPORTANT
An alert that calls attention to essential information.
NOTE
TIP
An alert that contains additional or supplementary information.

An alert that provides helpful information.
449
Network topology icons

Represents a generic network device, such as a router, switch, or firewall.
Represents a routing-capable device, such as a router or Layer 3 switch.
Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports
Layer 2 forwarding and other Layer 2 features.
Represents an access controller, a unified wired-WLAN module, or the switching engine
on a unified wired-WLAN switch.
Represents an access point.
Represents a mesh access point.
Represents omnidirectional signals.
Represents directional signals.
Port numbering in examples

The port numbers in this document are for illustration only and might be unavailable on your device.
450
Index
ABCDEFHILMNOPRSTUVW
Configuring ARP active acknowledgement,342
Configuring ARP detection,346
AAA configuration considerations and task list,20
Configuring ARP filtering,355
AAA configuration examples,60
Configuring ARP gateway protection,353
ALG configuration examples,397
Configuring ARP packet rate limit,339
ALG process,395
Configuring ARP packet source MAC consistency

check,342
ARP attack protection configuration task list,336

Associating an SSID and AP with a portal server and
an authentication domain,165
Configuring authorized ARP,342

Configuring local EAP authentication,58
Configuring MAC-based quick portal

authentication,162
Basic configuration for MAC authentication,125
Configuring mandatory webpage pushing,171
Configuring NAS ID profile for port security,226
Configuration changes in FIPS mode,443
Configuring port security features,223
Configuration considerations,442
Configuring port security for WLAN ports,224
Configuration prerequisites,150
Configuring port security stateful failover,227
Configuration prerequisites,107
Configuring portal detection functions,166
Configuration task list,125
Configuring portal stateful failover,163
Configuring RADIUS related attributes,160
Configuring session logging,415
Configuring source IP address verification,433
Configuration task list for IKE,386

detection,339
Configuring a certificate access control policy,280

Configuring a DPD detector,391
Configuring SSID-based user isolation,431
Configuring a MAC authentication guest VLAN,127
Configuring the accounting delay feature,118
Configuring a name for the local security gateway,387
Configuring the authentication trigger function,112
Configuring a NAS ID-VLAN binding,59
Configuring the device as an SCP client,306
Configuring a packet-filter firewall,403
Configuring the device as an SFTP client,302
Configuring a PKI domain,275
Configuring the device as an SSH server,294
Configuring a PKI entity,274
Configuring the device as an Stelnet client,300
Configuring AAA methods for ISP domains,49
Configuring the local portal server,151
Configuring AAA schemes,22
Configuring the MAC-after-portal feature,128
Configuring an 802.1X guest VLAN,115
Configuring the online user handshake function,111
Configuring an ASPF,407
Configuring the quiet timer,114
Configuring an Auth-Fail VLAN,116
Configuring unresolvable IP attack protection,337
Configuring an IKE peer,388
Configuring VLAN-based user isolation,430
Configuring an IKE proposal,387
Configuring Web filtering,419
Configuring an SSL client policy,330
Contacting HP,448
Configuring an SSL server policy,328

451
Enabling logging for portal packets,169
Controlled/uncontrolled port and port authorization

status,96
Enabling password control,253
Controlling access of portal users,156
Enabling port security,221
Conventions,449
Creating a local asymmetric key pair,262
Enabling the periodic online user re-authentication

function,114
Creating a user profile,248
Enabling the SYN Cookie feature,334
Exporting the host public key in a specific format to a

file,263
Destroying a local asymmetric key pair,264
Destroying the local RSA key pair,280
FIPS compliance,20
Disabling next payload field checking,392
FIPS compliance,294
Displaying and maintaining 802.1X,118

Displaying and maintaining AAA,60
FIPS compliance,252
Displaying and maintaining FIPS,443
FIPS configuration example,443
Displaying and maintaining IKE,392
FIPS self-tests,441
Displaying and maintaining IPsec,373
Displaying and maintaining MAC authentication,129
HP implementation of 802.1X,105
Displaying and maintaining password control,257
Displaying and maintaining PKI,281

Displaying and maintaining port security,228
Ignoring authorization information from the server,226
Displaying and maintaining portal,171
IKE configuration examples,393
Displaying and maintaining session management,416
Implementing ACL-based IPsec,361
Displaying and maintaining source IP address

verification,434
Initiating 802.1X authentication,99
Displaying and maintaining SSH,307
IPsec configuration examples,374
Displaying and maintaining user isolation,431
Logging off portal users,169
Displaying and maintaining user profile,249

Displaying and maintaining Web filtering,421
Displaying and recording the host public key

information,263
MAC authentication configuration examples,129

N
Displaying or exporting the local host public key,262
Network security services,1
Displaying public keys,265
Network security technologies,1
Displaying SSL,331
Displaying TCP attack protection,335
Network security threats,1
Displaying the host public key in a specific format and

saving it to a file,263
Overview,138
Obtaining certificates,278
Overview,216
Enabling a user profile,249

Enabling ALG,397
Overview,292
Enabling EAP relay or EAP termination,108
Overview,357
Enabling FIPS mode,443
Overview,336
Enabling forced logoff for user SSID switching,169
Overview,327
Enabling host identity check through DHCP

snooping,170
Overview,334
Enabling Layer 3 portal authentication,155
Overview,417
Overview,384
452
Overview,411
Setting user group password control parameters,255
Overview,400
SFTP configuration example,321
Overview,433
Source IP address verification configuration

example,434
Overview,6
Overview,441
Specifying a MAC authentication domain,127
Overview,271
Specifying a mandatory authentication domain on a

port,113
Overview,248
Specifying a portal server for Layer 3 portal

authentication,150
Overview,250
Overview,123
P
Specifying a source IP address for outgoing portal

packets,162
Password control configuration example,258
Specifying an access control method,110
Password control configuration task list,253
Specifying an autoredirection URL for authenticated

portal users,165
Performing configurations in user profile view,249
Specifying supported domain name delimiters,117
PKI configuration examples,281
Specifying the device ID,60
PKI configuration task list,273
Specifying the parameters to be carried in the

redirection URL,170
Port security configuration examples,228

Portal configuration examples,172
Specifying the peer public key on the local device,264
Portal configuration task list,149
SSID-based user isolation,430
Public key configuration examples,266
SSL server policy configuration example,331
Stelnet configuration examples,308
Related information,448
Removing a certificate,280
Tearing down user connections,58
Requesting a certificate,276
Troubleshooting AAA,93
Troubleshooting IKE,393
SCP configuration example,325
Troubleshooting PKI,290
Session management task list,412
Troubleshooting port security,247
Setting a local user password in interactive mode,257
Troubleshooting portal,215
Setting global password control parameters,254
Troubleshooting SSL,333
Setting keepalive timers,391
Troubleshooting Web filtering,426
Setting local user password control parameters,256
Setting port security's limit on the number of MAC

addresses on a port,221
User isolation configuration example,431

User profile configuration task list,248
Setting super password control parameters,256

Setting the 802.1X authentication timeout timers,111
Using MAC authentication with other features,124
Setting the maximum number of authentication request

attempts,111
V
Verifying PKI certificates,279
Setting the maximum number of concurrent 802.1X

users on a port,110
VLAN-based user isolation,429
Setting the NAT keepalive timer,391
Setting the port authorization state,109
Web filtering configuration examples,421
Setting the port security mode,222
453

HP Unified Wired-WLAN Products Security Configuration Guide

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

HP Unified Wired-WLAN Products Security Configuration Guide

Încărcat de

Drepturi de autor:

Formate disponibile

HP Unified Wired-WLAN Products

Security Configuration Guide

Part number: 5998-6511

Legal and notice information

Temporary access control of wireless users 90

Configuring 802.1X 105

Configuration procedure 119

Configuring MAC authentication 123

Configuring portal authentication 138

Specifying a source IP address for outgoing portal packets 162

Configuring port security 216

Configuring the userLoginSecureExt mode on a WLAN port 233

Configuring a user profile 248

Configuring password control 250

Managing public keys 261

Configuring PKI 271

Verifying certificates with CRL checking 279

Configuring SSH 292

Network requirements 325

Configuring SSL 327

Configuring TCP attack protection 334

Configuring ARP attack protection 336

Configuring IPsec 357

Configuring an IPsec transform set 364

Configuring IKE 384

Configuring ALG 395

Configuring firewall 400

Applying an ASPF policy to an interface 408

Managing sessions 411

Configuring Web filtering 417

Configuring user isolation 429

Configuring source IP address verification 433

Configuring FIPS 441

Configuring protocol packet rate limit 446

Support and other resources 448

Network security threats

Information disclosureInformation is leaked to an unauthorized person or entity.

Data integrity damageData integrity is damaged by unauthorized modification or malicious

Denial of serviceMakes information or other network resources unavailable to their intended

Unauthorized usageResources are used by unauthorized persons or in unauthorized ways.

Network security services

Access securityPrevents unauthorized access and use of network resources by implementing

Network security technologies

AuthenticationIdentifies network users and determines whether the user is valid.

IPsec and IKE

Number of the upper layer protocol carried by the IP layer

Source port number

Destination port number

Attack detection and protection

TCP attack protection

Additional security technologies

AuthenticationIdentifies users and determines whether a user is valid.

UsersStores user information, such as usernames, passwords, applied protocols, and IP

DictionaryStores RADIUS protocol attributes and their values.

Security and authentication mechanisms

Basic RADIUS message exchange process

Figure 3 Basic RADIUS message exchange process

RADIUS uses the following workflow:

The RADIUS server returns an acknowledgement (Accounting-Response) and starts accounting.

The user accesses the network resources.

RADIUS packet format

Figure 4 RADIUS packet format

Descriptions of the fields are as follows:

Table 2 Commonly used RADIUS attributes