You are on page 1of 465

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
Configuration procedure 112
Configuring the authentication trigger function 112
Configuration guidelines 113
Configuration procedure 113
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
Configuration guidelines 115
Configuration prerequisites 115
Configuration procedure 116
Configuring an Auth-Fail VLAN 116
Configuration guidelines 116
Configuration prerequisites 116
Configuration procedure 117
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

Configuration procedure 119


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
Configuration prerequisites 150
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
Configuration task list 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


Configuration task list 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
Network requirements 321
Configuration procedure 322
SCP configuration example 325
vi

Network requirements 325


Configuration procedure 325

Configuring SSL 327


Overview 327
SSL security mechanism 327
SSL protocol stack 327
Configuration task list 328
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
Configuration example 354
Configuring ARP filtering 355
Configuration example 355

Configuring IPsec 357


Overview 357
Basic concepts 357
IPsec stateful failover 360
Protocols and standards 361
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
Protocols and standards 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
Network requirements 432
Configuration procedure 432
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
Network requirements 444
Configuration procedure 444
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

Message-Authenticator

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

Set the minimum password


3.

Configure password control


attributes for the user group.

length:
password-control length length

Configure the password

composition policy:
password-control composition
type-number type-number
[ type-length type-length ]

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.
Available in any view.

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
authentication/authorization
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

authentication/authorization server:
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
authentication/authorization
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
authentication/authorization
servers for a scheme must be
different. Otherwise, the
configuration will fail.
All servers for
authentication/authorization
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.

Enter RADIUS scheme view.

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
Set the maximum number of
stop-accounting attempts.

Remarks

retry stop-accounting retry-times

Optional.
The default setting is 500.

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.

Enter RADIUS scheme view.

radius scheme
radius-scheme-name

N/A
By default, no shared key is specified.

3.

Specify a shared key for


secure RADIUS
authentication/authorization
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.

Setting the username format and traffic statistics units


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.

Enter RADIUS scheme view.

radius scheme radius-scheme-name

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.

Enter RADIUS scheme view.

radius scheme radius-scheme-name

N/A

3.

Set the maximum number of


RADIUS request transmission
attempts.

retry retry-times

Optional.
The default setting is 3.

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.

radius scheme radius-scheme-name

N/A

Set the status of the primary RADIUS


authentication/authorization server:
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.

authentication/authorization server:
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.

Enter RADIUS scheme view.

radius scheme
radius-scheme-name

N/A

3.

Specify a source IP address


for outgoing RADIUS packets.

nas-ip { ip-address | ipv6


ipv6-address }

By default, the IP address of the


outbound interface is used as the
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
Guides for HP Unified Wired-WLAN Products.
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.

Enter RADIUS scheme view.

radius scheme
radius-scheme-name

N/A

3.

Specify a backup source IP address for


outgoing RADIUS packets.

nas-backup-ip ip-address

Not specified by default.

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.

Enter RADIUS scheme view.

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.

radius scheme radius-scheme-name

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.

Enter RADIUS scheme view.

radius scheme radius-scheme-name

N/A

3.

Enable the EAP offload feature.

eap offload method peap-mschapv2

Disabled by default.

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.

Enter RADIUS scheme view.

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 }

Disabled by default.

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

Disabled by default.

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 ]

Available in any view.

Display the RADIUS packet


statistics.

display radius statistics [ | { begin | exclude


| include } regular-expression ]

Available in any view.

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 ]

Available in any view.

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 }

Available in user view.

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.

Setting the username format and traffic statistics units

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 ]

Configure at least one


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
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 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
packets is using it.
40

To specify HWTACACS authorization 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
authorization servers.

authorization server:
primary authorization ip-address
[ port-number ]

Configure at least one


command.

Specify a secondary HWTACACS

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
HWTACACS scheme. When the primary server is not available, the secondary server is used. If
redundancy is not required, specify only the primary server.
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
packets is using it.
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.

Enter HWTACACS scheme


view.

hwtacacs scheme
hwtacacs-scheme-name

N/A

Specify the primary HWTACACS


3.

Specify HWTACACS
accounting servers.

accounting server:
primary accounting ip-address
[ port-number ]

Specify a secondary HWTACACS


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

41

Configure at least one command.


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

Set the maximum number of


stop-accounting attempts.

retry stop-accounting retry-times

Optional.
Enabled by default.
Optional.
The default setting is 100.

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.

Enter HWTACACS scheme


view.

hwtacacs scheme
hwtacacs-scheme-name

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.

Setting the username format and traffic statistics units


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.

Enter HWTACACS scheme


view.

hwtacacs scheme
hwtacacs-scheme-name

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.

Specify a source IP address


for outgoing HWTACACS
packets.

hwtacacs nas-ip ip-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 HWTACACS scheme:


43

Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter HWTACACS scheme


view.

hwtacacs scheme
hwtacacs-scheme-name

N/A

3.

Specify a source IP address


for outgoing HWTACACS
packets.

nas-ip ip-address

By default, the IP address of the


outbound interface is used as the
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.

Enter HWTACACS scheme


view.

hwtacacs scheme
hwtacacs-scheme-name

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 ]

Available in any view.

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 ]

Available in any view.

Clear HWTACACS statistics.

reset hwtacacs statistics { accounting | all |


authentication | authorization }

Available in user view.

44

Task

Command

Remarks

Clear buffered stop-accounting


requests that do not get responses.

reset stop-accounting-buffer
hwtacacs-scheme hwtacacs-scheme-name

Available in user view.

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 ]

Not specified by default.

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

N/A

3.

Specify the LDAP


authorization server.

authorization-server ip-address
[ port-number ]

Not specified by default.

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

N/A
Not specified by default.

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.
Not specified by default.

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

N/A

3.

Specify the user search


base DN.

user-parameters search-base-dn
base-dn

Not specified by default.

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.

Enter LDAP scheme view.

ldap scheme ldap-scheme-name

N/A

3.

Specify the search base


DN for group search.

group-parameters search-base-dn
base-dn

Not specified by default.

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.

Not specified by default.

Not specified by default.

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 }
regular-expression ]

Available in any view.

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.
Disabled by default.

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.
Disabled by default.

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.

Enter ISP domain view.

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
authentication method
for LAN users.

authentication lan-access { local | none |


radius-scheme radius-scheme-name [ local |
none ] }

Optional.

Specify the
authentication method
for login users.

authentication login { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local |
ldap-scheme ldap-scheme-name [ local ] |
none | radius-scheme radius-scheme-name
[ local ] }

Specify the
authentication method
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.

The default authentication


method is used by default.
Optional.
The default authentication
method is used by default.
Optional.
The default authentication
method is used by default.

Step

Command

Remarks
Optional.

7.

Specify the
authentication method
for PPP users.

authentication ppp { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }

8.

Specify the
authentication method
for privilege level
switching.

authentication super { hwtacacs-scheme


hwtacacs-scheme-name | radius-scheme
radius-scheme-name }

Specify the
authentication method
for users accessing
through APs.

authentication wlan-ap radius-scheme


radius-scheme-name

9.

The default authentication


method is used by default.
Support for this feature
depends on the device model.
For more information, see
About the Configuration
Guides for HP Unified
Wired-WLAN Products.
Optional.
The default authentication
method is used by default.
Optional.
The default authentication
method is used by default.

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.

Configuration prerequisites
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.

Determine the access type or service type to be configured. With AAA, you can configure an
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.

Configuration guidelines
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.

Configuration procedure
To configure authorization methods for an ISP domain:
Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter ISP domain view.

domain isp-name

N/A

3.

Specify the default


authorization method for
all types of users.

authorization default { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local |
ldap-scheme ldap-scheme-name [ local ] |
none | radius-scheme radius-scheme-name
[ 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.

Specify the authorization


method for login users.

authorization login { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local |
ldap-scheme ldap-scheme-name [ local ] |
none | radius-scheme radius-scheme-name
[ local ] }

7.

Specify the authorization


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.

The default authorization


method is used by default.
The default authorization
method is used by default.
Optional.
The default authorization
method is used by default.
Optional.
The default authorization
method is used by default.

Step

Command

Remarks
Optional.

8.

Specify the authorization


method for PPP users.

authorization ppp { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }

The default authorization


method is used by default.
Support for this feature
depends on the device model.
For more information, see
About the Configuration
Guides for HP Unified
Wired-WLAN Products.

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.

Configuration prerequisites
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.

Determine the access type or service type to be configured. With AAA, you can configure an
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.

Configuration guidelines
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.

Configuration procedure
To configure accounting methods for an ISP domain:
Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter ISP domain view.

domain isp-name

N/A
Optional.
Disabled by default.
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
radius-scheme-name [ local ] }

Optional.

5.

Specify the command


accounting method.

accounting command
hwtacacs-scheme
hwtacacs-scheme-name

Optional.

6.

Specify the accounting


method for LAN users.

accounting lan-access { local | none |


radius-scheme radius-scheme-name
[ local | none ] }

Optional.

7.

Specify the accounting


method for login users.

accounting login { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local
| none | radius-scheme
radius-scheme-name [ local ] }

Optional.

8.

Specify the accounting


method for portal users.

accounting portal { local | none |


radius-scheme radius-scheme-name
[ local ] }

Optional.

The default accounting method


is local for all types of users.

The default accounting method


is used by default.
The default accounting method
is used by default.

The default accounting method


is used by default.

The default accounting method


is used by default.
Optional.

9.

Specify the accounting


method for PPP users.

accounting ppp { hwtacacs-scheme


hwtacacs-scheme-name [ local ] | local
| none | radius-scheme
radius-scheme-name [ local ] }

57

The default accounting method


is used by default.
Support for this feature
depends on the device model.
For more information, see
About the Configuration
Guides for HP Unified
Wired-WLAN Products.

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.

Configuration procedure
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.

Return to system view.

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


Support for this feature depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.
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 |


include } regular-expression ]

Available in any view.

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 ]

Available in any view.

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
Configuration Guide.
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

Configuration procedure
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
Network requirements
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.
Figure 11 Network diagram

Configuration procedure
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] 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 named bbb and set it as the default ISP domain.
[AC] domain bbb
[AC-isp-bbb] quit
[AC] domain default enable bbb

# Create HWTACACS scheme hwtac.


[AC] 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.
[AC-hwtacacs-hwtac] user-name-format without-domain
[AC-hwtacacs-hwtac] quit

# 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

Verifying the configuration


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


Network requirements
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.
Figure 12 Network diagram
LDAP server
10.1.1.1/24

Vlan-int2
10.1.1.2/24

IP network
Telnet user
192.168.1.21/24

Configuration procedure
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
[AC] telnet server enable

# 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

# 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 ISP domain bbb and set it as the default ISP domain.
[AC] domain bbb
[AC-isp-bbb] quit
[AC] domain default enable bbb

# 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

Verifying the configuration


# 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
Network requirements
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.
Figure 17 Network diagram

Configuration prerequisites
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:
a. Click the Service tab.
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


In this section, the server runs on IMC PLAT 5.1 SP1 (E0202P05) and IMC UAM 5.1 (E0301).
1.

Configure the portal server:


a. Click the Service tab.
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

# Specify the primary authentication server and the service port number.
[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] interface vlan-interface 2
[AC-Vlan-interface2] portal server newpt method direct

73

# Specify the portal authentication domain.


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

Verifying the configuration


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
Network requirements
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

Figure 26 Network diagram

Configuration prerequisites
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


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 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

Figure 27 Adding an access device

2.

Add a service:
a. Click the Service tab.
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:
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 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.

Configure a RADIUS scheme:


# 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

# Specify the primary authentication server and the service port number.
[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.

Configure an authentication domain:


# 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

Verifying the configuration


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.
[AC] display connection
Index=22

, Username=dot1x@bbb

MAC=0015-e9a6-7cfe
IP=192.168.1.58
IPv6=N/A
Online=00h01m37s
Total 1 connection(s) matched.

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


Network requirements
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.

Figure 30 Network diagram


Internet
Client
802.1X user

AP
Vlan-int2
192.168.1.1/24

AC

Configuration procedure
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

# Enable port security globally.


[AC] port-security enable

# Specify the 802.1X authentication method.


[AC] dot1x authentication-method eap

# Create a WLAN 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

# 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 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.


[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

81

[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

Verifying the configuration


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


Network requirements
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.

Figure 31 Network diagram

82

Configuration prerequisites

To use the 802.1X client of Windows XP, configure the 802.1X connection properties as follows:
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 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.)

Configuration procedure
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.
[AC] eap-profile eapsvr

# 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
[AC-eap-prof-eapsvr] quit

# Configure the local EAP authentication server, specifying to use EAP profile eapsvr.
[AC] local-server authentication eap-profile 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:
# Enable port security globally.
[AC] port-security enable

# Specify the 802.1X authentication method.


[AC] dot1x authentication-method eap

# Create a WLAN 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

# 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, authorization, and accounting 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

84

Verifying the configuration


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
Network requirements
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.

Figure 32 Network diagram

Configuration procedure
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] interface vlan-interface 2
[AC-Vlan-interface2] ip address 192.168.1.70 255.255.255.0
[AC-Vlan-interface2] quit

# Assign an IP address to VLAN-interface 3, the interface used to connect the server.


[AC] interface vlan-interface 3
[AC-Vlan-interface3] ip address 10.1.1.2 255.255.255.0
[AC-Vlan-interface3] quit

# Enable the AC to provide Telnet services.


[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
[AC-isp-bbb] quit
[AC] domain default enable bbb

# Create an HWTACACS scheme named hwtac.


[AC] hwtacacs scheme 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.
[AC-hwtacacs-hwtac] user-name-format without-domain
[AC-hwtacacs-hwtac] quit

# 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

Verifying the configuration


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


Network requirements
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.
Figure 34 Network diagram

Configuration prerequisites

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 the smart card or other certificates as the EAP authentication type.

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 Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area
and click OK.
d. Click OK.

Configuration procedure
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-profile eapsvr
[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
[AC-eap-prof-eapsvr] quit

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

# Enable port security globally.


[AC] port-security enable

# Specify the 802.1X authentication method.


[AC] dot1x authentication-method eap

# Create a WLAN 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

# 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

89

# Configure the port to use mandatory authentication domain bbb. 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 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

Verifying the configuration


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


Network requirements
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

Figure 35 Network diagram


AC

Internet
Client

AP

L2 switch

Client

Configuration prerequisites

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 the smart card or other certificates as the EAP authentication type.

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 Settings, and in the popup dialog box, select the EAP-TLS in the Authentication Type area
and click OK.
d. Click OK.

Configuration procedure
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:


# Enable port security globally.
[AC] port-security enable

# Set the 802.1X authentication method to EAP.


[AC] dot1x authentication-method eap

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


[AC] interface wlan-ess 1
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext

91

# Disable the multicast trigger function.


[AC-WLAN-ESS1] undo dot1x multicast-trigger

# Disable the online user handshake function.


[AC-WLAN-ESS1] undo dot1x handshake

# 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-profile eapsvr
[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
[AC-eap-prof-eapsvr] quit

# Configure the local EAP authentication server, specifying to use EAP profile eapsvr.
[AC] local-server authentication eap-profile 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] bind WLAN-ESS 1
[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] service-template enable
[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

Verifying the configuration


# 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
Possible reasons include:

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
Check the following:

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
Check the following:

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
Possible reasons include:

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
Check the following:

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

Message-Authenticator
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

Authentication server
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.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration
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.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2 Configuration
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.

Configuration prerequisites

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.

Set the maximum number of


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:

a. interface interface-type
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

The default setting is 2.

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

The default is 100 seconds.

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.

Configuration guidelines
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.

Configuration procedure
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.

The default is 15 seconds.


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.

Configuration guidelines
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.

Configuration procedure
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.

Enter Layer 2 Ethernet


interface view or
WLAN-ESS interface
view.

interface interface-type
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.

Enter Layer 2 Ethernet


interface view or WLAN-ESS
interface view.

interface interface-type
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.
The default setting is 60 seconds.

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.

Enter Layer 2 Ethernet


interface view or WLAN-ESS
interface view.

interface interface-type
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


Configuration guidelines
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


on a port that performs
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."

Configuration prerequisites

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
Configuration Guide.

Configuration procedure
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


Configuration guidelines
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

Relationship description

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."

Port intrusion protection


on a port that performs
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.

See "Configuring port


security."

Configuration prerequisites

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
Configuration Guide.

Configuration procedure
To configure an Auth-Fail VLAN:
Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter Layer 2 Ethernet


interface view or
WLAN-ESS interface
view.

interface interface-type
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.

Enter Layer 2 Ethernet


interface view or
WLAN-ESS interface view.

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 }
regular-expression ]

Available in any view.

Display 802.1X stateful


failover information.

display dot1x synchronization { connection |


statistics | status } [ interface interface-type
interface-number ] [ | { begin | exclude | include }
regular-expression ]

Available in any view.

Clear 802.1X statistics.

reset dot1x statistics [ interface interface-list ]

Available in user view.

Clear 802.1X stateful failover


packet statistics.

reset dot1x synchronization statistics [ interface


interface-type interface-number ]

Available in any view.

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.
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
Configuration Guide.
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.

Network requirements
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.
Figure 46 Network diagram
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

Configuration procedure
# 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.


[AC] dot1x authentication-method eap

# Enable port security.


[AC] port-security enable

# Set the port security mode to userlogin-secure-ext, and enable port-security tx-key-type 11key.
[AC] interface wlan-ess 1
[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] port-security port-mode userlogin-secure-ext
[AC-WLAN-ESS1] port-security tx-key-type 11key
[AC-WLAN-ESS1] dot1x mandatory-domain 2000

# Disable the multicast trigger function and online user handshake function.
[AC-WLAN-ESS1] undo dot1x multicast-trigger
[AC-WLAN-ESS1] undo dot1x handshake
[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 service-template 1 crypto
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] cipher-suite tkip
[AC-wlan-st-1] cipher-suite ccmp
[AC-wlan-st-1] security-ie rsn
[AC-wlan-st-1] service-template enable

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.
[AC] wlan ap ap1 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8
[AC-wlan-ap-ap1] radio 1 type dot11an

# Bind service template 1 to radio 1.


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

Verifying the configuration


# After a user passes authentication, use the display connection command to verify that the 802.1X
connection has been set up.
[AC] display connection

Index=1,Username=localuser@2000
MAC=00-40-96-B3-8A-77
IP=192.168.1.10
IPv6=N/A
Online=00h00m53s
Total 1 connection(s) matched.
[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

Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:1


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
Start=2013-06-30 17:29:39 ,Current=2013-06-30 17:30:51 ,Online=00h01m13s
Total 1 connection matched.

# 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.

a. interface interface-type
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:
a. interface interface-type
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 interface-type
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

Relationship description

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."

Port intrusion protection

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.

See "Configuring port


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 interface-type
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 |
include } regular-expression ]

Available in any view.

Clear MAC authentication


statistics.

reset mac-authentication statistics


[ interface interface-list ]

Available in user view.

MAC authentication configuration examples


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Local MAC authentication configuration example


Network requirements
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

Figure 47 Network diagram


Supplicant

Authenticator

IP network
Client

AP

L2switch

MAC: 00-e0-fc-12-34-56

AC

Configuration procedure
# 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

# Enable port security.


[AC] port-security enable

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


[AC] interface wlan-ess 0
[AC-WLAN-ESS0] port-security port-mode mac-and-psk
[AC-WLAN-ESS0] port-security tx-key-type 11key
[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 service-template 2 crypto
[AC-wlan-st-2] ssid mac-authentication-local
[AC-wlan-st-2] bind wlan-ess 0
[AC-wlan-st-2] authentication-method open-system
[AC-wlan-st-2] cipher-suite ccmp

130

[AC-wlan-st-2] security-ie rsn


[AC-wlan-st-2] service-template enable
[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 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8

# Bind service template 2 to radio 1.


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

Verifying the configuration


# 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
Total 1 connection(s) matched.

131

Auth Index
1299

RADIUS-based MAC authentication configuration example


Network requirements
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.

Figure 48 Network diagram

Configuration procedure
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 scheme 2000
[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
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit

# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and accounting.
[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

132

[AC-isp-2000] quit

# Enable port security.


[AC] port-security enable

# 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] interface wlan-ess 0
[AC-WLAN-ESS0] port-security port-mode mac-and-psk
[AC-WLAN-ESS0] port-security tx-key-type 11key
[AC-WLAN-ESS0] port-security preshared-key pass-phrase 12345678
[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 service-template 2 crypto
[AC-wlan-st-2] ssid mac-authentication-radius
[AC-wlan-st-2] bind wlan-ess 0
[AC-wlan-st-2] authentication-method open-system
[AC-wlan-st-2] cipher-suite ccmp
[AC-wlan-st-2] security-ie rsn
[AC-wlan-st-2] service-template enable
[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 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8

# Bind service template 2 to radio 1.


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

# 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

Verifying the configuration


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

133

Server response timeout value is 100s


The max allowed user number is 20480 per slot
Current user number amounts to 1
Current domain is 2000

Silent MAC User info:


MAC Addr

From Port

Port Index

WLAN-DBSS0:7 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

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
Total 1 connection(s) matched.

ACL assignment configuration example


Network requirements
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

Figure 49 Network diagram


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

Configuration procedure
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 number 3000
[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 scheme 2000
[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
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit

# Apply the RADIUS scheme to an ISP domain for authentication, authorization, and accounting.
[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 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

# Enable port security.


[AC] port-security enable

# 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] interface wlan-ess 0
[AC-WLAN-ESS0] port-security port-mode mac-and-psk
[AC-WLAN-ESS0] port-security tx-key-type 11key
[AC-WLAN-ESS0] port-security preshared-key pass-phrase 12345678
[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 service-template 2 crypto
[AC-wlan-st-2] ssid mac-authentication-acl
[AC-wlan-st-2] bind wlan-ess 0
[AC-wlan-st-2] authentication-method open-system
[AC-wlan-st-2] cipher-suite ccmp
[AC-wlan-st-2] security-ie rsn
[AC-wlan-st-2] service-template enable
[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 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8

# Bind service template 2 to radio 1.


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

Verifying the configuration


# After a WLAN client passes authentication, display MAC authentication settings and statistics.
<AC>display mac-authentication interface WLAN-DBSS 0:9
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 300s
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 2000
Silent MAC User info:
MAC Addr

From Port

Port Index

WLAN-DBSS0:9 is link-up

136

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_SUCCESS

Auth Index
1301

# Display online user information.


<AC> display connection

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
Total 1 connection(s) matched.

# 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

Authentication client

Authentication client

Security policy server

Access device

Portal server

Authentication/accounting
server

Authentication client

Authentication client
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.

Security policy server


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


Support for this feature depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.

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.

Configuration prerequisites
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
Wired-WLAN Products.

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 the local portal server


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.

Configuring the local portal server


To make the local portal server take effect, specify the protocol to be used for communication between
the portal client and local portal server.

Configuration prerequisites
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.

Configuration procedure
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.

Configuration guidelines

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.

Configuration prerequisites
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.

Configuration procedure
To enable Layer 3 portal authentication:
Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter interface view.

interface interface-type
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.

Configuration guidelines

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.

Configuration procedure
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.

Configure at least one


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 interface-type
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
Wired-WLAN Products.

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.

Enter interface view.

interface interface-type
interface-number

N/A

3.

Specify an authentication
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.

Configuration prerequisites
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

Configuration prerequisites
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.

Configuration procedure
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:
a. interface interface-type
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.

Enter interface view.

interface interface-type
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.

Enter interface view.

interface interface-type
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

For more information about the


command, see Security Command
Reference.

4.

Return to system view.

quit

N/A

5.

Enter interface view.

interface interface-type
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 interface-type
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.

Enter interface view.

interface interface-type
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.

Configuring portal stateful failover


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.
Support for this feature depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.
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.

Configuration guidelines

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.

Configuration procedure
To configure stateful failover:
Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter interface view.

interface interface-type
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.

Return to system view.

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

For more information about the


command, see Security Command
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.
For more information about the
command, see Security Command
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.

Enter interface view.

interface interface-type
interface-number

N/A
Not configured by default.

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 ]

Not configured by default.


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
Not configured by default.

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.

Enter interface view.

interface interface-type
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 |
include } regular-expression ]

Available in any view.

Display portal connection statistics


on a specific interface or all
interfaces.

display portal connection statistics { all |


interface interface-type
interface-number } [ | { begin | exclude
| include } regular-expression ]

Available in any view.

Display information about a


portal-free rule or all portal-free
rules.

display portal free-rule [ rule-number ]


[ | { begin | exclude | include }
regular-expression ]

Available in any view.

171

Task

Command

Remarks

Display the portal configuration of


a specific interface.

display portal interface interface-type


interface-number [ | { begin | exclude |
include } regular-expression ]

Available in any view.

Display configuration information


about the local portal server.

display portal local-server [ | { begin |


exclude | include } regular-expression ]

Available in any view.

Display information about a


specific portal server or all portal
servers.

display portal server [ server-name ] [ |


{ begin | exclude | include }
regular-expression ]

Available in any view.

Display portal server statistics on a


specific interface or all interfaces.

display portal server statistics { all |


interface interface-type
interface-number } [ | { begin | exclude
| include } regular-expression ]

Available in any view.

Display TCP spoofing statistics.

display portal tcp-cheat statistics [ |


{ begin | exclude | include }
regular-expression ]

Available in any view.

Display information about portal


users on a specific interface or all
interfaces.

display portal user { all | interface


interface-type interface-number } [ |
{ begin | exclude | include }
regular-expression ]

Available in any view.

Clear portal connection statistics


on a specific interface or all
interfaces.

reset portal connection statistics {all |


interface interface-type
interface-number }

Available in user view.

Clear portal server statistics on a


specific interface or all interfaces.

reset portal server statistics { all |


interface interface-type
interface-number }

Available in user view.

Clear TCP spoofing statistics.

reset portal tcp-cheat statistics

Available in user view.

Portal configuration examples


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

172

Configuring direct portal authentication


Network requirements
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.
Figure 58 Network diagram

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.

Configuring the portal server


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

Configure the portal server:


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

Figure 59 Portal server configuration

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.
Figure 60 Adding an IP address group

3.

Add a portal device:


a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the
portal device configuration page.
b. Click Add to enter the page shown in Figure 61.
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.
Figure 61 Adding a portal device

4.

Associate the portal device with the IP address group:


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.

Configure a RADIUS scheme:


# Create a RADIUS scheme named rs1 and enter its view.
<AC> system-view
[AC] radius scheme rs1

# Configure the server type for the RADIUS scheme. When using the IMC server, you must
configure the RADIUS server type as extended.
[AC-radius-rs1] server-type 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
[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 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.
[AC] interface vlan-interface 1
[ACVlan-interface1] portal domain dm1
[ACVlan-interface1] portal server newpt method direct
[ACVlan-interface1] quit

Configuring re-DHCP portal authentication


Network requirements
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.
Figure 64 Network diagram

Configuration prerequisites and guidelines

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.

Configuration procedure
1.

Configure a RADIUS scheme on the AC:


177

# 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. When using the IMC server, you must set the server
type to extended.
[AC-radius-rs1] server-type 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.113
[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
[AC-radius-rs1] quit

2.

Configure an authentication domain on the AC:


# 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 on the AC:


# 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

[AC] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
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
[AC] interface vlan-interface 10
[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
[ACVlan-interface10] quit

178

Configuring direct portal authentication with extended


functions
Network requirements
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.
Use a RADIUS server as the authentication/authorization server.
Figure 65 Network diagram

Configuration prerequisites
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.

Configuration procedure
1.

Configure a RADIUS scheme on the AC:


# 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. When using the IMC server, you must set the server
type to extended.
[AC-radius-rs1] server-type 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
[AC-radius-rs1] user-name-format without-domain

# Configure the IP address of the security policy server.


[AC-radius-rs1] security-policy-server 192.168.0.113
[AC-radius-rs1] quit

179

2.

Configure an authentication domain on the AC:


# 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.

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 number 3000
[AC-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[AC-acl-adv-3000] quit
[AC] acl number 3001
[AC-acl-adv-3001] rule permit ip
[AC-acl-adv-3001] quit

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:


# 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

[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 extended portal authentication.
[AC] interface vlan-interface 10
[ACVlan-interface10] portal domain dm1
[ACVlan-interface10] portal server newpt method direct
[AC] quit

Configuring re-DHCP portal authentication with extended


functions
Network requirements
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.
Use a RADIUS server as the authentication/authorization server.
180

Figure 66 Network diagram

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
Security policy server
192.168.0.114/24

Configuration prerequisites and guidelines

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.

Configuration procedure
1.

Configure a RADIUS scheme on the AC:


# 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. When using the IMC server, set the server type to
extended.
[AC-radius-rs1] server-type 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.113
[AC-radius-rs1] key authentication simple radius
[AC-radius-rs1] user-name-format without-domain

# Configure the IP address of the security policy server.


[AC-radius-rs1] security-policy-server 192.168.0.114
[AC-radius-rs1] quit

2.

Configure an authentication domain on the AC:


181

# 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.

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 number 3000
[AC-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[AC-acl-adv-3000] quit
[AC] acl number 3001
[AC-acl-adv-3001] rule permit ip
[AC-acl-adv-3001] quit

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:


# 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

[AC] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
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
[AC] interface vlan-interface 100
[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 select relay
[AC-Vlan-interface100] dhcp relay server-select 0
[AC-Vlan-interface100] dhcp relay address-check enable

# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[ACVlan-interface100] portal domain dm1
[ACVlan-interface100] portal server newpt method redhcp
[ACVlan-interface100] quit

182

Configuring portal stateful failover


Network requirements
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.

Figure 67 Network diagram


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

Configuration prerequisites and guidelines


Configure IP addresses for the client, server, and ACs as shown in Figure 67 and make sure they have IP
connectivity between each other.
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.

Configuring the portal server


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

Configure the portal server:


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 68.
c. Configure the portal server parameters as needed. This example uses the default settings.
d. Click OK.
Figure 68 Portal server configuration

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 69.
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.

184

Figure 69 Adding an IP address group

3.

Add a portal device:


a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the
portal device configuration page.
b. Click Add to enter the page shown in Figure 70.
c. Enter the device name AC.
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.
f. Set whether to enable IP address reallocation.
This example uses direct portal authentication. Therefore, select No from the Reallocate IP list.
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.
Figure 70 Adding a portal device

4.

Associate the portal device with the IP address group:


a. As shown in Figure 71, click the icon in the Port Group column of device AC to enter the port
group configuration page.
Figure 71 Device list

185

b. On the port group configuration page, click Add to enter the page shown in Figure 72.
Perform the following configurations.
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.
Figure 72 Adding a port group

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.

Configure a RADIUS scheme:


# Create RADIUS scheme rs1 and enter its view.
[AC1] radius scheme rs1

# Configure the server type for the RADIUS scheme. When using the IMC server, you must
configure the RADIUS server type as extended.
[AC1-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[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.

Configure an authentication domain:


# 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

# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[AC1] interface vlan-interface 10
[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
[AC1Vlan-interface10] quit

# 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
[AC2] interface vlan-interface 20
[AC2Vlan-interface20] vrrp vrid 1 virtual-ip 192.168.0.1

# Set the priority of VLAN-interface 20 in the VRRP group to 150.


[AC2Vlan-interface20] vrrp vrid 1 priority 150
[AC2Vlan-interface20] quit

2.

Configure a RADIUS scheme:


# Create RADIUS scheme rs1 and enter its view.
[AC2] radius scheme rs1

188

# Configure the server type for the RADIUS scheme. When using the IMC server, you must
configure the RADIUS server type as extended.
[AC2-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC2-radius-rs1] primary authentication 192.168.0.111
[AC2-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.)
[AC2-radius-rs1] user-name-format without-domain
[AC2-radius-rs1] quit

3.

Configure an authentication domain:


# Create ISP domain dm1 and enter its view.
[AC2] domain dm1

# Configure AAA methods for the ISP domain.


[AC2-isp-dm1] authentication portal radius-scheme rs1
[AC2-isp-dm1] authorization portal radius-scheme rs1
[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

# Configure a portal-free rule on AC 2, allowing packets from AC 1 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.
[AC2] portal free-rule 0 source interface bridge-aggregation 1 destination any

# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[AC2] interface vlan-interface 10
[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.
[AC2Vlan-interface10] portal nas-ip 192.168.0.1

5.

Configure portal stateful failover:


# Assign interface VLAN-interface 10 to portal group 1.
[AC2Vlan-interface10] portal backup-group 1
[AC2Vlan-interface10] quit

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


[AC2] nas device-id 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.

Configure the WLAN service:


# Specify the backup AC address.
[AC2] wlan backup-ac ip 1.1.1.1

# Enable hot backup.


[AC2] hot-backup enable

# Configure VLAN 8 as the VLAN for AC hot backup.


[AC2] hot-backup vlan 8
[AC2] quit

# Create interface WLAN-ESS 1, and add it to VLAN 10.


[AC2] interface wlan-ess 1
[AC2-WLAN-ESS1] port link-type hybrid
[AC2-WLAN-ESS1] port hybrid vlan 10 untagged
[AC2-WLAN-ESS1] port hybrid pvid vlan 10
[AC2-WLAN-ESS1] quit

# Configure a WLAN service template, and bind the WLAN service template with interface
WLAN-ESS 1.
[AC2] wlan service-template 1 clear
[AC2-wlan-st-1] ssid abc
[AC2-wlan-st-1] bind wlan-ess 1
[AC2-wlan-st-1] service-template enable
[AC2-wlan-st-1] quit

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


[AC2] wlan ap ap1 model MSM460-WW
[AC2-wlan-ap-ap1] serial-id CN2AD330S8
[AC2-wlan-ap-ap1] radio 1
[AC2-wlan-ap-ap1-radio-1] service-template 1
[AC2-wlan-ap-ap1-radio-1] radio enable
[AC2-wlan-ap-ap1-radio-1] quit
[AC2-wlan-ap-ap1] quit

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.


[AC2] dhbk enable backup-type symmetric-path

Verifying the configuration


# 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

Total 1 user(s) matched, 1 listed.


[AC2] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: secondary
MAC

IP

--------------------------------------------------------------------000d-88f8-0eac

9.9.1.2

10

Vlan-interface10

Total 1 user(s) matched, 1 listed.

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
Network requirements
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

Figure 73 Network diagram

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.

Configuration prerequisites
Configure IP addresses for the client, AP, AC, and servers as shown in Figure 73, and make sure they
have IP connectivity between each other.
Configure the RADIUS server to provide authentication and authorization services for users.

Configuring the portal server


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

Configure the portal server:


a. Log in to the IMC management platform 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 74.
c. Configure the portal server heartbeat interval and user heartbeat interval.
d. Use default values for other parameters.
e. Click OK.

192

Figure 74 Portal server configuration

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 75.
c. Enter the IP group name.
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.
e. Select a service group.
By default, the group Ungrouped is used.
f. Select the IP group type Normal.
g. Click OK.
Figure 75 Adding an IP address group

3.

Add a portal device:


a. From the navigation tree, select User Access Manager > Portal Service > Device to enter the
portal device configuration page.
b. Click Add to enter the page shown in Figure 76.
c. Enter the device name AC.
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.
f. Set whether to enable IP address reallocation.
This example uses direct portal authentication. Therefore, select No from the Reallocate IP list.
g. Select Yes for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
Figure 76 Adding a portal device

4.

Associate the portal device with the IP address group:


a. As shown in Figure 77, click the icon in the Port Group column of device AC to enter the port
group configuration page.
Figure 77 Device list

b. On the port group configuration page, click Add to enter the page shown in Figure 78.
Perform the following configurations:
c. Enter the port group name.
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.
e. Use the default settings for other parameters.
f. Click OK.

194

Figure 78 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.

Configure a RADIUS scheme:


# Create RADIUS scheme rs1 and enter its view.
<AC> system-view
[AC] radius scheme rs1

# Configure the server type for the RADIUS scheme. When using the IMC server, you must
configure the RADIUS server type as extended.
[AC-radius-rs1] server-type 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

# Configure the access device to not carry the ISP domain name in the username sent to the
RADIUS server.
[AC-radius-rs1] user-name-format without-domain
[AC-radius-rs1] quit

2.

Configure an authentication domain:


# Create ISP domain dm1 and enter its view.
[AC] domain dm1

# Configure AAA methods for the ISP domain.


[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 a portal server on the AC, making sure the IP address, port number and URL match
those of the actual portal server.
[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.
195

[AC] interface vlan-interface 10


[ACVlan-interface10] portal domain dm1
[ACVlan-interface10] portal server newpt method direct
[ACVlan-interface10] quit

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.

Verifying the configuration


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
Network requirements
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.
Use a RADIUS server as the authentication/authorization server.
Figure 79 Network diagram

Configuration prerequisites and guidelines

Configure IP addresses for the client, AC, and server as shown in Figure 79, and make sure they
have IP connectivity between each other.

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.

Configuration procedure
1.

Configure a RADIUS scheme on the AC:


# 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. When using the IMC server, set the server type to
extended.
197

[AC-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC-radius-rs1] primary authentication 1.1.1.2
[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
[AC-radius-rs1] quit

2.

Configure an authentication domain on the AC:


# 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 the WLAN service on the AC:


# Create interface WLAN-ESS 1 and add it to VLAN 2.
[AC] interface wlan-ess 1
[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] quit

# Configure a WLAN service template, and bind the WLAN service template with the WLAN-ESS
interface.
[AC] wlan service-template 1 clear
[AC-wlan-st-1] ssid abc
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit

# Configure AP on the AC.


[AC] wlan ap ap1 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8
[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

4.

Configure portal authentication on the AC:


# 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.
[AC] interface vlan-interface 2
[ACVlan-interface2] portal domain dm1
[ACVlan-interface2] portal server newpt method direct
[ACVlan-interface2] quit

Verifying the configuration


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


Network requirements
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

Figure 80 Network diagram

Configuration prerequisites and guidelines

Configure IP addresses for the server, client, switches, and ACs and make sure they have IP
connectivity between each other.

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
[AC1] interface vlan-interface 100
[AC1Vlan-interface100] vrrp vrid 1 virtual-ip 16.16.0.8

# Set the priority of VLAN-interface 100 in VRRP group 1 to 200.


[AC1Vlan-interface100] vrrp vrid 1 priority 200

200

# On VLAN-interface 100, configure the interface to be tracked as VLAN-interface 8 and reduce


the priority of VLAN-interface 100 in VRRP group 1 by 120 when the interface state of
VLAN-interface 8 becomes Down or Removed.
[AC1Vlan-interface100] vrrp vrid 1 track interface vlan-interface8 reduced 120
[AC1Vlan-interface100] quit

# Create VRRP group 2, and configure the virtual IP address of VRRP group 2 as 8.1.1.68.
[AC1] interface vlan-interface 8
[AC1Vlan-interface8] vrrp vrid 2 virtual-ip 8.1.1.68

# Set the priority of VLAN-interface 8 in VRRP group 2 to 200.


[AC1Vlan-interface8] vrrp vrid 2 priority 200

# On VLAN-interface 8, configure the interface to be tracked as VLAN-interface 100 and reduce


the priority of VLAN-interface 8 in VRRP group 2 by 120 when the interface state of VLAN-interface
100 becomes Down or Removed.
[AC1Vlan-interface8] vrrp vrid 2 track interface vlan-interface100 reduced 120
[AC1Vlan-interface8] quit

2.

Configure a RADIUS scheme:


# Create RADIUS scheme rs1 and enter its view.
[AC1] radius scheme rs1

# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[AC1-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC1-radius-rs1] primary authentication 8.1.1.2
[AC1-radius-rs1] key authentication simple expert

# 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.)
[AC1-radius-rs1] user-name-format without-domain
[AC1-radius-rs1] quit

3.

Configure an authentication domain:


# 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 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 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

# Configure the local portal server to support HTTP.


201

[AC1] portal local-server http

# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[AC1] interface vlan-interface 100
[AC1Vlan-interface100] portal domain dm1
[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.
[AC1Vlan-interface100] portal nas-ip 16.16.0.8

5.

Configure portal stateful failover:


# Assign interface VLAN-interface 100 to portal group 1.
[AC1] interface vlan-interface 100
[AC1Vlan-interface100] portal backup-group 1
[AC1Vlan-interface100] quit

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


[AC1] nas device-id 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.
[AC1] radius nas-ip 8.1.1.68

6.

Configure the WLAN service:


# Specify the backup AC address.
[AC1] wlan backup-ac ip 2.2.2.3

# Enable hot backup.


[AC1] hot-backup enable

# Configure VLAN 10 as the VLAN for AC hot backup.


[AC1] hot-backup vlan 10
[AC1] quit

# Create interface WLAN-ESS 1, and add it to VLAN 100.


[AC1] interface wlan-ess 1
[AC1-WLAN-ESS1] port link-type hybrid
[AC1-WLAN-ESS1] port hybrid vlan 100 untagged
[AC1-WLAN-ESS1] port hybrid pvid vlan 100
[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.
[AC1] wlan ap ap1 model MSM460-WW
[AC1-wlan-ap-ap1] serial-id CN2AD330S8
[AC1-wlan-ap-ap1] radio 1
[AC1-wlan-ap-ap1-radio-1] service-template 1
[AC1-wlan-ap-ap1-radio-1] radio enable

202

[AC1-wlan-ap-ap1-radio-1] quit
[AC1-wlan-ap-ap1] quit

7.

Configure the stateful failover function:


# Configure VLAN 10 as the backup VLAN for stateful failover.
[AC1] dhbk vlan 10

# Enable symmetric-path mode stateful failover.


[AC1] dhbk enable backup-type symmetric-path

Configuring AC 2
1.

Configure VRRP:
# Create VRRP group 1, and configure the virtual IP address of VRRP group 1 as 16.16.0.8.
<AC2> system-view
[AC2] interface vlan-interface 100
[AC2Vlan-interface100] vrrp vrid 1 virtual-ip 16.16.0.8
[AC2Vlan-interface100] quit

# Create VRRP group 2, and configure the virtual IP address of VRRP group 2 as 8.1.1.68.
[AC2] interface vlan-interface 8
[AC2Vlan-interface8] vrrp vrid 2 virtual-ip 8.1.1.68
[AC2Vlan-interface8] quit

2.

Configure a RADIUS scheme:


# Create RADIUS scheme rs1 and enter its view.
[AC2] radius scheme rs1

# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[AC2-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC2-radius-rs1] primary authentication 8.1.1.2
[AC2-radius-rs1] key authentication simple expert

# 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.)
[AC2-radius-rs1] user-name-format without-domain
[AC2-radius-rs1] quit

3.

Configure an authentication domain:


# Create ISP domain dm1 and enter its view.
[AC2] domain dm1

# Configure AAA methods for the ISP domain.


[AC2-isp-dm1] authentication portal radius-scheme rs1
[AC2-isp-dm1] authorization portal radius-scheme rs1
[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

# Configure a portal-free rule on AC 2, allowing packets from AC 1 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.
[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

# On the interface connected to the client, specify the authentication domain dm1 for portal users
and enable portal authentication.
[AC2] interface vlan-interface 100
[AC2Vlan-interface100] portal domain dm1
[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.
[AC2Vlan-interface100] portal nas-ip 16.16.0.8

5.

Configure portal stateful failover:


# Assign interface VLAN-interface 100 to portal group 1.
[AC2] interface vlan-interface 100
[AC2Vlan-interface100] portal backup-group 1
[AC2Vlan-interface100] quit

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


[AC2] nas device-id 2

# Configure the source IP address for outgoing RADIUS packets as 8.1.1.68, the virtual IP address
of VRRP group 2.
[AC2] radius nas-ip 8.1.1.68

6.

Configure the WLAN service:


# Specify the backup AC IP address.
[AC2] wlan backup-ac ip 2.2.2.1

# Enable hot backup.


[AC2] hot-backup enable

# Configure VLAN 10 as the VLAN for AC hot backup.


[AC2] hot-backup vlan 10
[AC2] quit

# Create interface WLAN-ESS 1, and add it to VLAN 100.


[AC2] interface wlan-ess 1
[AC2-WLAN-ESS1] port link-type hybrid
[AC2-WLAN-ESS1] port hybrid vlan 100 untagged
[AC2-WLAN-ESS1] port hybrid pvid vlan 100
[AC2-WLAN-ESS1] quit

# Configure a WLAN service template, and bind the WLAN service template with interface
WLAN-ESS 1.
[AC2] wlan service-template 1 clear
[AC2-wlan-st-1] ssid abc
[AC2-wlan-st-1] bind wlan-ess 1
[AC2-wlan-st-1] service-template enable
[AC2-wlan-st-1] quit

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


204

[AC2] wlan ap ap1 model MSM460-WW


[AC2-wlan-ap-ap1] serial-id CN2AD330S8
[AC2-wlan-ap-ap1] radio 1
[AC2-wlan-ap-ap1-radio-1] service-template 1
[AC2-wlan-ap-ap1-radio-1] radio enable
[AC2-wlan-ap-ap1-radio-1] quit
[AC2-wlan-ap-ap1] quit

7.

Configure the stateful failover function:


# Configure VLAN 10 as the backup VLAN for stateful failover.
[AC2] dhbk vlan 10

# Enable symmetric-path mode stateful failover.


[AC2] dhbk enable backup-type symmetric-path

Verifying the configuration


# 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.
[AC1] display portal user all
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

Total 1 user(s) matched, 1 listed.


[AC2] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode: secondary
MAC

IP

--------------------------------------------------------------------000d-88f8-0eac

16.16.0.12

100

Vlan-interface100

Total 1 user(s) matched, 1 listed.

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


Network requirements
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.

Figure 81 Network diagram

Configuring the AC
1.

Configure a RADIUS scheme on the AC:


# 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. When you use the IMC server, set the server type to
extended.
[AC-radius-rs1] server-type extended

# Specify the primary authentication/authorization server, and configure the shared key for
secure communication with the server.
[AC-radius-rs1] primary authentication 8.1.1.40
[AC-radius-rs1] key authentication simple 123456789

# 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
[AC-radius-rs1] quit

# Specify the NAS IP of the AC.


[AC-radius-rs1] nas-ip 112.113.1.1
[AC-radius-rs1] quit

2.

Configure an authentication domain on the AC:


# Configure 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 on the AC:


# Configure the portal server as follows:
{

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
[AC-Vlan-interface5] ip address 112.115.1.1 16
[AC-Vlan-interface5] quit

# 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
[AC-Vlan-interface3] ip address 112.113.1.1 16

# On the interface connected to the client, specify the authentication domain as dm1 for portal
users, and enable direct portal authentication.
[ACVlan-interface3] portal domain dm1
[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
[ACVlan-interface3] quit

# 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] interface vlan-interface 3
[AC-Vlan-interface3] portal mac-trigger enable
[AC-Vlan-interface3] quit

Configuring the portal server


This section uses IMC PLAT 5.2 (E0401) and IMC UAM 5.2 (E0402).
1.

Configure the portal server:


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 82.
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.

Configure the IP address group:


a. From the navigation tree, select User Access Manager > Portal Service > IP Group.
b. Click Add to enter the page shown in Figure 83.
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.
Figure 83 Adding an IP address group

3.

Add a portal device:


a. From the navigation tree, select User Access Manager > Portal Service > Device.
b. Click Add to enter the page shown in Figure 84.
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.
Figure 84 Adding a portal device

4.

Associate the portal device with the IP address group:


a. From the navigation tree, select User Access Manager > Portal Service > Device.
b. As shown in Figure 85, click the icon in the Operation column for device Portal and select
Configure Port Group.
Figure 85 Device list

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.
Figure 86 Adding a port group

5.

Configure an access rule:


a. From the navigation tree, select User Access Manager > Access Rule Management.
b. Click Add to enter the page shown in Figure 87.
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.
b. Click Add to enter the page shown in Figure 88.
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.
Figure 89 Adding an access device

8.

Configure the access user:


a. Click the User tab.
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:


a. Click the Service tab.
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:


a. Click the Service tab.
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.

Verifying the configuration


# 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
Work-mode:stand-alone
MAC

IP

Vlan

Interface

---------------------------------------------------------------------------3ca9-f414-4c20

112.113.0.1

Vlan-interface3

Total 1 user(s) matched, 1 listed.

# 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
Work-mode:stand-alone
MAC

IP

Vlan

Interface

---------------------------------------------------------------------------3ca9-f414-4c20

112.113.0.1

Vlan-interface3

Total 1 user(s) matched, 1 listed.

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.

Configuration task list


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.

Enter interface view.

interface interface-type interface-number

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

Enter interface view.

interface interface-type
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.


Not configured by default.
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 |
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.

Enter interface view.

interface interface-type
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.

Enter interface view.

interface interface-type
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.

Return to system view.

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.

Enter interface view.

interface interface-type
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 |
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.

Enter interface view.

interface interface-type
interface-number

N/A

3.

Enable key negotiation of the


11key type.

port-security tx-key-type 11key

Disabled by default.

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.

interface interface-type interface-number

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.

Enter interface view.

interface interface-type
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.

Enter interface view.

interface interface-type
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 ] [ |


{ begin | exclude | include } regular-expression ]

Available in any view.

Display information about


blocked MAC addresses.

display port-security mac-address block


[ interface interface-type interface-number ] [ vlan
vlan-id ] [ count ] [ | { begin | exclude | include }
regular-expression ]

Available in any view.

Display information about PSK


users.

display port-security preshared-key user


[ interface interface-type interface-number ] [ |
{ begin | exclude | include } regular-expression ]

Available in any view.

Port security configuration examples


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Configuring the userLoginWithOUI mode


Network requirements
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.

Figure 93 Network diagram

Configuration procedure
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.

Configure port security:


# Enable port security.
[AC] port-security enable

# Add five OUI values.


[AC] port-security oui 1234-0100-1111 index 1
[AC] port-security oui 1234-0200-1111 index 2
[AC] port-security oui 1234-0300-1111 index 3
[AC] port-security oui 1234-0400-1111 index 4
[AC] port-security oui 1234-0500-1111 index 5

# Configure the mandatory authentication domain sun for 802.1X users on WLAN-ESS 1. Set the
port security mode to userLoginWithOUI.
[AC] interface wlan-ess 1
[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 service-template 2 clear
[AC-wlan-st-2] ssid mactest
[AC-wlan-st-2] bind wlan-ess 1
[AC-wlan-st-2] authentication-method open-system
[AC-wlan-st-2] service-template enable
[AC-wlan-st-2] quit

# Create an AP template named ap1, and set its model to MSM460-WW and serial ID to
CN2AD330S8.
[AC] wlan ap ap1 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8
[AC-wlan-ap-ap1] radio 1 type dot11an

230

# Map service template 2 to radio 1, and enable the radio.


[AC-wlan-ap-ap1-radio-1] service-template 2
[AC-wlan-ap-ap1-radio-1] radio enable
[AC-wlan-ap-ap1-radio-1] return

Verifying the configuration


# 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
Encryption Key : N/A
Probe username : N/A
Probe interval : N/A
Second Auth Server:
IP: 192.168.1.3
Encryption Key : N/A
Probe username : N/A
Probe interval : N/A
Second Acct Server:
IP: 192.168.1.2
Encryption Key : N/A
Probe username : N/A
Probe interval : N/A
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.
<AC> display connection

Index=1,Username= test@sun
MAC=12-34-01-00-11-11
IP=10.1.0.1
IPv6=N/A
Online=00h00m53s
Total 1 connection(s) matched.
<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

Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:1


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
Start=2013-07-01 15:39:49 ,Current=2013-07-01 15:50:07 ,Online=00h10m18s
Total 1 connection matched.

Configuring the userLoginSecureExt mode on a WLAN port


Network requirements
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.
Figure 94 Network diagram
RADIUS server

SSID 1
AP

IP network

Client A

AC
Client B

Configuration procedure
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
[AC] port-security enable

2.

Configure RADIUS:
# Configure RADIUS scheme 2000.
[AC] 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.
[AC-radius-2000] user-name-format without-domain
[AC-radius-2000] quit

# 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.


[AC] interface wlan-ess 1

# Set the port security mode to userLoginSecureExt.


[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext

# Enable key negotiation of the 11key type.


[AC-WLAN-ESS1] port-security tx-key-type 11key

# Disable the 802.1X multicast trigger and online user handshake functions.
[AC-WLAN-ESS1] undo dot1x multicast-trigger
[AC-WLAN-ESS1] undo dot1x handshake
[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.


[AC] dot1x authentication-method 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 service-template 1 crypto
[AC-wlan-st-1] ssid SSID1

# Bind the interface to the service template.


[AC-wlan-st-1] bind wlan-ess 1

# Enable open system authentication, the AES-CCMP cipher suite, and the RSN-IE in the beacon
and probe responses.
[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] cipher-suite ccmp

234

[AC-wlan-st-1] security-ie rsn

# Enable the service template function.


[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit

# Create an AP template named ap1, and set its model to MSM460-WW and serial ID to
CN2AD330S8.
[AC] wlan ap ap1 model MSM460-WW
[AC-wlan-ap-ap1] serial-id CN2AD330S8

# Bind the service template 1 to the port radio 1, and enable the radio.
[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] return

Verifying the configuration


# 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

Port Type=Wireless-802.11,Port Name=WLAN-DBSS1:0


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

Start=2013-11-16 16:58:51 ,Current=2013-11-16 16:59:29 ,Online=00h00m38s


Total 1 connection matched.
<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
Network requirements
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

Figure 95 Network diagram

Configuration procedure
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.

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

# Enable port security.


[AC] port-security enable

# Set the 802.1X authentication method to EAP.


[AC] dot1x authentication-method eap

# 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.
[AC] interface wlan-ess 1
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext

# Enable the MAC-based VLAN function and configure VLAN 1 as the guest VLAN.
[AC-WLAN-ESS1] port link-type hybrid
[AC-WLAN-ESS1] port hybrid vlan 1 to 2 untagged
[AC-WLAN-ESS1] port hybrid pvid vlan 2
[AC-WLAN-ESS1] mac-vlan enable
[AC-WLAN-ESS1] dot1x guest-vlan 1

# Disable the 802.1X multicast trigger and online user handshake functions.
[AC-WLAN-ESS1] undo dot1x handshake
[AC-WLAN-ESS1] undo dot1x multicast-trigger
[AC-WLAN-ESS1] quit

# Configure the WLAN service template.


[AC] wlan service-template 1 clear
[AC-wlan-st-1] ssid SSID1

237

[AC-wlan-st-1] bind wlan-ess 1


[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit

# Configure the service template of the AP.


[AC] wlan ap 1 model MSM460-WW
[AC-wlan-ap-1] serial-id CN2AD330S8
[AC-wlan-ap-1] radio 1
[AC-wlan-ap-1-radio-1] service-template 1
[AC-wlan-ap-1-radio-1] radio enable
[AC-wlan-ap-1-radio-1] return

Verifying the configuration


# 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
Total 1 connection matched.

Configuring port security with guest VLAN and VLAN


assignment
Network requirements
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

Figure 96 Network diagram


AC
Authentication server

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.
Figure 97 Network diagram

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

Figure 98 Network diagram

Configuration procedure
Use the iNode client in this example. The client that comes with Windows does not support the function.
This example covers only some of the required AAA and RADIUS configuration commands. For more
information, see Security Command Reference.
# Configure RADIUS scheme 2000.
<AC> system-view
[AC] radius scheme 2000
[AC-radius-2000] primary authentication 10.11.1.1 1812
[AC-radius-2000] primary accounting 10.11.1.1 1813
[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 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.


[AC] port-security enable

# Set the 802.1X authentication method to EAP.


[AC] dot1x authentication-method eap

240

# Configure wireless port WLAN-ESS 1.


[AC] interface wlan-ess 1
[AC-WLAN-ESS1] port link-type hybrid
[AC-WLAN-ESS1] port hybrid vlan 1 to 2 5 10 untagged
[AC-WLAN-ESS1] port-security port-mode userlogin-secure-ext
[AC-WLAN-ESS1] mac-vlan enable
[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 service-template 1 clear
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 1
[AC-wlan-st-1] authentication-method open-system
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit

# Configure an AP template named 1.


[AC] wlan ap 1 model MSM460-WW
[AC-wlan-ap-1] serial-id CN2AD330S8
[AC-wlan-ap-1] radio 1
[AC-wlan-ap-1-radio-1] service-template 1
[AC-wlan-ap-1-radio-1] radio enable
[AC-wlan-ap-1-radio-1] return

Verifying the configuration


# 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
Total 1 connection matched.

241

Configuring 802.1X stateful failover for port security


Network requirements
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.
Figure 99 Network diagram

Configuration considerations
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.

Configure port security:


# 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.


[AC1] interface wlan-ess 1

# 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

# Disable the 802.1X multicast trigger and online user handshake functions.
[AC1-WLAN-ESS1] undo dot1x multicast-trigger
[AC1-WLAN-ESS1] undo dot1x handshake
[AC1-WLAN-ESS1] quit

# Enable global port security.


[AC1] port-security enable

2.

Configure stateful failover:


# Specify VLAN 10 as the backup VLAN for stateful failover.
[AC1] dhbk vlan 10

# Enable symmetric-path mode stateful failover.


[AC1] dhbk enable backup-type symmetric-path

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] nas device-id 1

# Configure RADIUS scheme 2003.


[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.
[AC1] wlan backup-ac ip 1.1.1.5

# 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] ssid abc
[AC1-wlan-st-1] bind wlan-ess 1
[AC1-wlan-st-1] authentication-method open-system
[AC1-wlan-st-1] cipher-suite ccmp
[AC1-wlan-st-1] security-ie rsn
[AC1-wlan-st-1] service-template enable
[AC1-wlan-st-1] quit

# Configure the AP information.


[AC1] wlan ap ap1 model MSM460-WW
[AC1-wlan-ap-ap1] serial-id CN2AD330S8
[AC1-wlan-ap-ap1] radio 1 type dot11an
[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

# 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.


[AC1] hot-backup enable

# Set VLAN 10 as the VLAN for AC hot backup.


[AC1] hot-backup vlan 10

Configuring AC 2
1.

Configure port security:


# 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.


[AC2] interface wlan-ess 1

# 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

# Disable the 802.1X multicast trigger and online user handshake functions.
[AC2-WLAN-ESS1] undo dot1x multicast-trigger
[AC2-WLAN-ESS1] undo dot1x handshake
[AC2-WLAN-ESS1] quit

# Enable global port security.


[AC2] port-security enable

2.

Configure stateful failover:


# Specify VLAN 10 as the backup VLAN for stateful failover.
[AC2] dhbk vlan 10

# Enable symmetric-path mode stateful failover.


[AC2] dhbk enable backup-type symmetric-path

3.

Create VRRP group 1 on interface VLAN-interface 8.


[AC2] interface vlan 8
[AC2-Vlan-interface8] ip address 192.168.100.2 24
[AC2-Vlan-interface8] vrrp vrid 1 virtual-ip 192.168.100.5
[AC2-Vlan-interface8] quit

4.

Configure AAA:
# Specify the device ID to be used in stateful failover mode as 2.
[AC2] nas device-id 2

# Configure RADIUS scheme 2003.


[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.
[AC2] wlan backup-ac ip 1.1.1.4

# 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] ssid abc
[AC2-wlan-st-1] bind wlan-ess 1
[AC2-wlan-st-1] authentication-method open-system
[AC2-wlan-st-1] cipher-suite ccmp
[AC2-wlan-st-1] security-ie rsn
[AC2-wlan-st-1] service-template enable
[AC2-wlan-st-1] quit

# Configure the AP information.


[AC2] wlan ap ap1 model MSM460-WW
[AC2-wlan-ap-ap1] serial-id CN2AD330S8
[AC2-wlan-ap-ap1] radio 1 type dot11an
[AC2-wlan-ap-ap1-radio-1] service-template 1
[AC2-wlan-ap-ap1-radio-1] radio enable
[AC2-wlan-ap-ap1-radio-1] quit
[AC2-wlan-ap-ap1] quit

# 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.


[AC2] hot-backup enable

# Set VLAN 10 as the VLAN for AC hot backup.


[AC2] hot-backup vlan 10

Verifying the configuration


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 WLAN configuration, see WLAN 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


| include } regular-expression ]

Available in any view.

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
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.

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.

Set the minimum password


update interval.

password-control password
update interval interval

Set the minimum password


length.

password-control length 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.

Configure the password


composition policy.

Configure the password


complexity checking policy.

password-control composition
type-number type-number
[ type-length type-length ]

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.

Set the maximum number of


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.

60 seconds by default.

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.

Configure the password


aging time for the user group.

Optional.
password-control aging aging-time

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.

password-control length length

Configure the password


composition policy for the
user group.

password-control composition
type-number type-number
[ type-length type-length ]

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.

local-user user-name

N/A
Optional.

3.

Configure the password


aging time for the local user.

password-control aging aging-time

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.

password-control length length

By default, the setting equals that


for the user group to which the
local user belongs. If no minimum
password length is configured for
the user group, the global setting
applies to the local user.
Optional.

5.

Configure the password


composition policy for the
local user.

password-control composition
type-number type-number
[ type-length type-length ]

By default, the settings equal those


for the user group to which the
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
Configuration Guide.
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.

Configure the password


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.

local-user user-name

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 ]


[ | { begin | exclude | include }
regular-expression ]

Available in any view.

Display information about users in


the password control blacklist.

display password-control blacklist


[ user-name name | ip
ipv4-address | ipv6 ipv6-address ]
[ | { begin | exclude | include }
regular-expression ]

Available in any view.

Delete users from the password


control blacklist.

reset password-control blacklist


{ all | user-name name }

Available in user view.


Available in user view.

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


The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary with device models.
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
Configuration Guide.
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.

Network requirements
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.

Configuration procedure
# 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

Verifying the configuration


# 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 (10 characters)

Password composition:

Enabled (3 types,

5 characters per type)

# 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 (12 characters)

Password composition:

Enabled (2 types,

Total 1 local user(s) matched.

260

5 characters per type)

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."

Configuration task list


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


| exclude | include } regular-expression ]

Available in any view.

Display the local DSA public keys.

display public-key local dsa public [ | { begin


| exclude | include } regular-expression ]

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.

Return to system view.

peer-public-key end

N/A

Displaying public keys


Task

Command

Remarks

Display the local public keys

display public-key local { dsa| rsa } public


[ | { begin | exclude | include }
regular-expression ]

Available in any view.

Display the specified or all peer


public keys on the local device.

display public-key peer [ brief | name


publickey-name ] [ | { begin | exclude |
include } regular-expression ]

Available in any view.

265

Public key configuration examples


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Manually specifying the peer public key on the local device


Network requirements
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.

Figure 101 Network diagram

Configuration procedure
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

=====================================================
Time of Key pair created: 09:50:07

2013/08/07

Key name: SERVER_KEY


Key type: RSA Encryption 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:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7
66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA32647
0034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001

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


Network requirements
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.

Figure 102 Network diagram

Configuration procedure
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> 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

=====================================================
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

=====================================================

268

Time of Key pair created: 09:50:07

2013/08/07

Key name: SERVER_KEY


Key type: RSA Encryption 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:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E7
66BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA32647
0034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001

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.

pki domain domain-name

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."

Configuration guidelines

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.

Configuration procedure
To manually request a certificate:

277

Step

Command

Remarks

1.

Enter system view.

system-view

N/A

2.

Enter PKI domain view.

pki domain domain-name

N/A

3.

Set the certificate request


mode to manual.

certificate request mode manual

4.

Return to system view.

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.

Enter PKI domain view.

pki domain domain-name

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.

Return to system view.

quit

N/A

7.

Retrieve the CA certificate.

See "Obtaining certificates"

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.

Enter PKI domain view.

pki domain domain-name

N/A

3.

Disable CRL checking.

crl check disable

Enabled by default.

279

Step

Command

Remarks

4.

Return to system view.

quit

N/A

5.

Retrieve the CA certificate.

See "Obtaining certificates"

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.

Return to system view.

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 }
regular-expression ]

Available in any view.

Display CRLs.

display pki crl domain


domain-name [ | { begin | exclude
| include } regular-expression ]

Available in any view.

Display information about one or


all certificate attribute groups.

display pki certificate


attribute-group { group-name |
all } [ | { begin | exclude |
include } regular-expression ]

Available in any view.

Display information about one or


all certificate access control
policies.

display pki certificate


access-control-policy { policy-name
| all } [ | { begin | exclude |
include } regular-expression ]

Available in any view.

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.
The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
281

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
Configuration Guide.
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.

Certificate request from an RSA Keon CA server


Network requirements
As shown in Figure 104, the AC submits a local certificate request to the CA server.
The AC acquires the CRLs for certificate verification.
Figure 104 Network diagram

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
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 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!

Verifying the configuration


# 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
Signature Algorithm: sha1WithRSAEncryption
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


Network requirements
As shown in Figure 105, configure PKI entity AC to request a local certificate from the CA server.
Figure 105 Network diagram

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:


[AC] 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 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!

Verifying the configuration


# 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
Signature Algorithm: sha1WithRSAEncryption
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
Signature Algorithm: sha1WithRSAEncryption
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


Network requirements

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.

Figure 106 Network diagram

288

Configuration procedure
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
Possible reasons include:

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
Possible reasons include:

The network connection is not proper. For example, the network cable might be damaged or loose.

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.

Make sure the network connection is physically proper.

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
Possible reasons include:

The network connection is not proper. For example, the network cable might be damaged or loose.

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.

Make sure the network connection is physically proper.

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
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 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.

Configuration guidelines
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.

Configuration procedure
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

Disabled by default.

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

Disabled by default.

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.

Return to system view.

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.

Configuration procedure
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

The default setting is 60 seconds.


If a user does not finish the
authentication when the timeout
timer expires, the connection
cannot be established.

Step

Command

Remarks
Optional.
The default setting is 3.

5.

Set the maximum number of


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.

Enabling and disabling first-time authentication


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 } |
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 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 } ] *

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.

Enabling and disabling first-time authentication

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 } |
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:
sftp 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 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.

For more information, see


"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.

Enter SFTP client view.

For more information, see


"Establishing a connection to an
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.

Enter SFTP client view.

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.

Enter SFTP client view.

For more information, see


"Establishing a connection to an
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

Enabling and disabling first-time authentication

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


| include } regular-expression ]

Available in any view.

Display the source IP address or


interface information configured for
the Stelnet client.

display ssh client source [ | { begin | exclude


| include } regular-expression ]

Available in any view.

Display SSH server status


information or session information
on an SSH server.

display ssh server { status | session } [ |


{ begin | exclude | include }
regular-expression ]

Available in any view.

Display the mappings between


SSH servers and their host public
keys on an SSH client.

display ssh server-info [ | { begin | exclude |


include } regular-expression ]

Available in any view.

307

Task

Command

Remarks

Display information about one or


all SSH users on an SSH server.

display ssh user-information [ username ] [ |


{ begin | exclude | include }
regular-expression ]

Available in any view.

Display the public keys of the local


key pairs.

display public-key local { dsa | rsa } public


[ | { begin | exclude | include }
regular-expression ]

Available in any view.

Display the public keys of the SSH


peers.

display public-key peer [ brief | name


publickey-name ] [ | { begin | exclude |
include } regular-expression ]

Available in any view.

Stelnet configuration examples


This section provides examples of configuring Stelnet.
The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Password authentication enabled Stelnet server configuration


example
Network requirements
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.

Figure 107 Network diagram

308

Configuration procedure
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.
A file saving window appears.
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
[AC] public-key local create rsa

# 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.
[AC] interface vlan-interface 2
[AC-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[AC-Vlan-interface2] quit

# Set the authentication mode to AAA for the user interfaces.


[AC] user-interface vty 0 4
[AC-ui-vty0-4] authentication-mode scheme

# 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
Network requirements
As shown in Figure 112:

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

Figure 112 Network diagram

Configuration considerations
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.

Configuration procedure
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.
A file saving window appears.
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.
A file saving window appears.
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
[AC] public-key local create rsa

# 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.
[AC] interface vlan-interface 2
[AC-Vlan-interface2] ip address 192.168.1.40 255.255.255.0
[AC-Vlan-interface2] quit

# Set the authentication mode to AAA for the user interfaces.


[AC] user-interface vty 0 4
[AC-ui-vty0-4] authentication-mode scheme

# Enable the user interfaces to support SSH.


[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.

Establish a connection to the Stelnet server:


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
Network requirements
As shown in Figure 118:

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.

Figure 118 Network diagram

317

Configuration procedure
1.

Configure the Stelnet server:


# Generate the RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa

# Enable the SSH server function.


[Switch] ssh server enable

# Configure an IP address for VLAN-interface 2. The Stelnet 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

# Set the authentication mode to AAA for the user interfaces.


[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme

# Enable the user interfaces to support SSH.


[Switch-ui-vty0-4] protocol inbound ssh
[Switch-ui-vty0-4] quit

# Create a local user client001.


[Switch] local-user client001

# Specify the password as aabbcc for the local user.


[Switch-luser-client001] password simple aabbcc

# Set the user privilege level to 3 for the local user.


[Switch-luser-client001] authorization-attribute level 3

# Specify the service type as ssh for the local user.


[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.

Establish a connection to the Stelnet server:


# Configure an IP address for VLAN-interface 2.
<AC> system-view
[AC] interface vlan-interface 2
[AC-Vlan-interface2] ip address 192.168.1.56 255.255.255.0
[AC-Vlan-interface2] quit
[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
Press CTRL+K to abort
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
Network requirements
As shown in Figure 119:

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.

Figure 119 Network diagram

Configuration considerations
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.

Configuration procedure
1.

Configure the Stelnet client AC:


# Create VLAN-interface 2 and assign an IP address to it.
<AC> system-view
[AC] interface vlan-interface 2
[AC-Vlan-interface2] ip address 192.168.1.56 255.255.255.0
[AC-Vlan-interface2] quit

# Generate RSA key pairs.


[AC] public-key local create rsa

# 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:


# Generate the RSA key pairs.
<Switch> system-view
[Switch] public-key local create rsa

# Enable the SSH server function.


[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

# Set the authentication mode to AAA for the user interfaces.


[Switch] user-interface vty 0 4
[Switch-ui-vty0-4] authentication-mode scheme

# Enable the user interfaces to support SSH.


[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 ...
Press CTRL+K to abort
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


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Network requirements
As shown in Figure 120:

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

Figure 120 Network diagram

Configuration procedure
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] interface vlan-interface 2
[AC2-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[AC2-Vlan-interface2] quit

# Set the authentication mode to AAA for the user interfaces.


[AC2] user-interface vty 0 4
[AC2-ui-vty0-4] authentication-mode scheme

# Enable the user interfaces to support SSH.


[AC2-ui-vty0-4] protocol inbound ssh
[AC2-ui-vty0-4] quit

# Create a local user client001.


[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:


# Configure an IP address for VLAN-interface 2.
322

<AC1> system-view
[AC1] interface vlan-interface 2
[AC1-Vlan-interface2] ip address 192.168.0.2 255.255.255.0
[AC1-Vlan-interface2] quit
[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 ...
Press CTRL+K to abort
Connected to 192.168.0.1 ...

The Server is not authenticated. Continue? [Y/N]:y


Do you want to save the server public key? [Y/N]:n
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

1759 Aug 23 06:52 startup.cfg

-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

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

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

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

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

1759 Aug 23 06:52 startup.cfg

-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.
The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Network requirements
As shown in Figure 121:

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.

Figure 121 Network diagram

Configuration procedure
1.

Configure the SCP server AC 2:


<AC2> system-view
[AC2] public-key local create rsa

# Enable the SSH server function.


[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] interface vlan-interface 2
[AC2-Vlan-interface2] ip address 192.168.0.1 255.255.255.0
[AC2-Vlan-interface2] quit

# Set the authentication mode to AAA for the user interfaces.


[AC2] user-interface vty 0 4
[AC2-ui-vty0-4] authentication-mode scheme

325

# Enable the user interfaces to support SSH.


[AC2-ui-vty0-4] protocol inbound ssh
[AC2-ui-vty0-4] quit

# Create a local user client001.


[AC2] local-user client001

# Specify the password as aabbcc for the local user.


[AC2-luser-client001] password simple aabbcc

# Specify the service type as ssh for the local user.


[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] interface vlan-interface 2
[AC1-Vlan-interface2] ip address 192.168.0.2 255.255.255.0
[AC1-Vlan-interface2] quit
[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 ...
Press CTRL+K to abort
Connected to 192.168.0.1 ...

The Server is not authenticated. Continue? [Y/N]:y


Do you want to save the server public key? [Y/N]:n
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.

Configuration task list


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_aes_256_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_128_cbc_sha |
rsa_aes_256_cbc_sha ] *

5.

Set the handshake timeout


time for the SSL server.

handshake timeout time

Optional.
3600 seconds by default.
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.

Set the maximum number of


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.

Disabled by default.
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_aes_128_cbc_sha |
rsa_aes_256_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_128_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 } [ |


{ begin | exclude | include } regular-expression ]

Available in any view.

Display SSL client policy


information.

display ssl client-policy { policy-name | all } [ | { begin


| exclude | include } regular-expression ]

Available in any view.

SSL server policy configuration example


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Network requirements
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.
Figure 124 Network diagram

331

Configuration procedure
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.


[AC] public-key local create rsa

# 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 |


include } regular-expression ]

Available in any view.

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).


Configure this function on gateways (recommended).
Optional.
Configure this function on access devices (recommended).
Optional.
Configure this function on gateways (recommended).

Perform the following tasks to prevent user and gateway spoofing:


Task

Remarks
Optional.

Configuring ARP active acknowledgement

Configure this function on gateways (recommended).


Optional.

Configuring authorized ARP

Configure this function on gateways (recommended).

336

Task

Remarks
Optional.

Configuring ARP detection

Configure this function on access devices (recommended).


Optional.

Configuring ARP gateway protection

Configure this function on access devices (recommended).


Optional.

Configuring ARP filtering

Configure this function on access devices (recommended).

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

Disabled by default.

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 [ |


{ begin | exclude | include }
regular-expression ]

Available in any view.

Configuration example
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
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.
Figure 125 Network diagram

338

Configuration considerations
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.

Configuration procedure
# 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.

interface interface-type interface-number

N/A

Configure or disable ARP packet rate


limit.

arp rate-limit { disable | rate pps drop }

Disabled by default.

3.

Configuring source MAC-based ARP attack


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 }

Disabled by default.

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.


300 seconds by default.
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 |
include } regular-expression ]

Available in any view.

Source MAC-based ARP attack detection configuration


example
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.

340

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.

Network requirements
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.
Figure 126 Network diagram

Configuration considerations
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

Configuration procedure
# 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

Disabled by default.

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

Disabled by default.

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.

Enter interface view.

interface interface-type interface-number

N/A

3.

Configure the DHCP server (or


DHCP relay agent) to support
authorized ARP.

dhcp update arp

Not configured by default.

Enable authorized ARP on the


interface.

arp authorized enable

Disabled by default.

4.

Authorized ARP configuration example (on a DHCP server)


The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
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.
Figure 127 Network diagram

Configuration procedure
# 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.


[AC] interface vlan-interface 10
[AC-Vlan-interface10] ip address 10.1.1.1 255.255.255.0

# Enable authorized ARP.


[AC-Vlan-interface10] dhcp update arp
[AC-Vlan-interface10] arp authorized enable
[AC-Vlan-interface10] quit

# 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)
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
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

Figure 128 Network diagram


DHCP Server
Device
10.2.1.2/24

DHCP Relay

DHCP Client

VLAN 10
10.1.1.1/24

AC

Switch

AP

Client

Configuration procedure
1.

Configure the DHCP server:


<Device> system-view
[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.


[AC] dhcp relay server-group 1 ip 10.2.1.2

# Configure the IP address of VLAN-interface 10.


[AC] interface vlan-interface 10
[AC-Vlan-interface10] ip address 10.1.1.1 255.255.255.0
[AC-Vlan-interface10] quit

# Enable DHCP relay agent on VLAN-interface 10.


[AC] interface vlan-interface 10
[AC-Vlan-interface10] dhcp select relay

# Correlate VLAN-interface 10 to DHCP server group 1.


[AC-Vlan-interface10] dhcp relay server-select 1

# Enable authorized ARP.


[AC-Vlan-interface10] dhcp update arp
[AC-Vlan-interface10] arp authorized enable
[AC-Vlan-interface10] quit

# 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.
Not configured by default.
N/A

Step

Command

Remarks

4.

Enable ARP detection.

arp detection enable

Disabled by default.

5.

Return to system view.

quit

N/A

6.

Enter Layer 2 Ethernet interface


view/Layer 2 aggregate
interface/WLAN-ESS interface
view.

interface interface-type
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

Disabled by default.

4.

Return to system view.

quit

N/A

5.

Enable ARP packet validity check


and specify the objects to be
checked.

arp detection validate { dst-mac | ip |


src-mac } *

Disabled by default.

Enter Layer 2 Ethernet interface


view/Layer 2 aggregate
interface/WLAN-ESS interface
view.

interface interface-type
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

Disabled by default.

Displaying and maintaining ARP detection


Task

Command

Remarks

Display the VLANs enabled


with ARP detection.

display arp detection [ | { begin | exclude |


include } regular-expression ]

Available in any view.

Display the ARP detection


statistics.

display arp detection statistics [ interface


interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]

Available in any view.

Clear the ARP detection


statistics.

reset arp detection statistics [ interface


interface-type interface-number ]

Available in user view.

User validity check configuration example


The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
As shown in Figure 129:

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.

Figure 129 Network diagram


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

Configuration procedure
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.


<Device> system-view
[Device] dhcp enable
[Device] dhcp server ip-pool 0
[Device-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0

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

# Enable port security.


[AC] port-security enable

# Configure EAP relay for 802.1X user authentication.


[AC] dot1x authentication-method eap

# Enable wireless 802.1X authentication on the AC.


<AC> system-view
[AC] interface wlan-ess 0
[AC-WLAN-ESS0] port access vlan 10
[AC-WLAN-ESS0] port-security port-mode userlogin-secure-ext
[AC-WLAN-ESS0] port-security tx-key-type 11key
[AC-WLAN-ESS0] undo dot1x multicast-trigger
[AC-WLAN-ESS0] undo dot1x handshake
[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.
[AC] wlan service-template 1 crypto
[AC-wlan-st-1] ssid dot1x
[AC-wlan-st-1] bind wlan-ess 0

# Enable open system authentication.


[AC-wlan-st-1] authentication-method open-system

# Enable TKIP cipher suite.


[AC-wlan-st-1] cipher-suite tkip

# Enable the WPA-IE in the beacon and probe responses.


[AC-wlan-st-1] security-ie wpa
[AC-wlan-st-1] service-template enable
[AC-wlan-st-1] quit

# Create AP template 2100 with the model MSM460-WW and serial number CN2AD330S8.
[AC] wlan ap 2100 model MSM460-WW
[AC-wlan-ap-2100] serial-id CN2AD330S8

# Bind the WLAN service template to radio 1, and enable the radio.
[AC-wlan-ap-2100] radio 1

350

[AC-wlan-ap-2100-radio-1] service-template 1
[AC-wlan-ap-2100-radio-1] radio enable

# 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
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements

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

Figure 130 Network diagram

Configuration procedure
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.


<Device> system-view
[Device] dhcp enable
[Device] dhcp server ip-pool 0
[Device-dhcp-pool-0] network 10.1.1.0 mask 255.255.255.0

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] interface wlan-ess 0
[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 service-template 1 clear
[AC-wlan-st-1] ssid test
[AC-wlan-st-1] bind wlan-ess 0
[AC-wlan-st-1] service-template enable

# Create AP template 2100 with the model MSM460-WW and serial number CN2AD330S8.
[AC] wlan ap 2100 model MSM460-WW
[AC-wlan-ap-2100] serial-id CN2AD330S8

# Bind the WLAN service template to radio 1, and enable the radio.
[AC-wlan-ap-2100] radio 1
[AC-wlan-ap-2100-radio-1] service-template 1

352

[AC-wlan-ap-2100-radio-1] radio enable

# 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
[AC-Ten-GigabitEthernet1/0/1] quit

# 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
[AC-Ten-GigabitEthernet1/0/1] quit

# 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


WLAN-ESS interface view.

interface interface-type
interface-number

N/A

3.

Enable ARP gateway protection for


a specific gateway.

arp filter source ip-address

Disabled by default.

353

Configuration example
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
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.
Figure 131 Network diagram
Gateway
Device
10.1.1.1/24

Switch

AP 1

Client 1

AC

AP 2

Client 2

Configuration procedure
# 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] interface wlan-ess 0
[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.

Enter Layer 2 Ethernet interface


or WLAN-ESS interface view.

interface interface-type interface-number

N/A

3.

Enable ARP filtering and


configure a permitted entry.

arp filter binding ip-address


mac-address

Disabled by default.

Configuration example
The configuration example was created on the 11900/10500/7500 20G unified wired-WLAN module
and might vary by device model.
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
Configuration Guide.
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.

Network requirements
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

Figure 132 Network diagram

Configuration procedure
# 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] interface wlan-ess 0
[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


Support for this feature depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.
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

Protocols and standards

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 0 permit ip source 1.1.2.0 0.0.0.255 destination 3.3.3.0 0.0.0.255
rule 1 deny ip
#
ipsec policy test 1 isakmp
security acl 3000
ike-peer aa
transform-set 1

362

#
ipsec policy test 2 isakmp
security acl 3001
ike-peer bb
transform-set 1

Configure Router B:
acl number 3001
rule 0 permit ip source 3.3.3.0 0.0.0.255 destination 1.1.2.0 0.0.0.255
rule 1 deny ip
#
ipsec policy test 1 isakmp
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
Configure at least one command.

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

Not configured by default.

Configure the remote


address of the IPsec
tunnel

tunnel remote ip-address

Not configured by default.

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 ]

Configure an authentication
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

Configure an authentication

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.

ipsec policy policy-name


seq-number isakmp

By default, no IPsec policy exists.

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.

security acl acl-number


[ 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>

By default, an IPsec policy


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
information, see About the
Configuration Guides for HP
Unified Wired-WLAN Products.
Optional.
Enabled by default.
N/A

quit

Optional.
11. Set the global SA lifetime.

ipsec sa global-duration
{ time-based seconds |
traffic-based kilobytes }

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.

security acl acl-number

By default, an IPsec policy


references no ACL.

4.

Specify the IPsec transform


sets for the IPsec policy to
reference.

transform-set
transform-set-name&<1-6>

By default, an IPsec policy


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 |


traffic-based kilobytes }

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.

Return to system view.

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
information, see About the
Configuration Guides for HP
Unified Wired-WLAN Products.
Optional.
Enabled by default.
N/A

10. Configure the global SA


lifetime.

ipsec sa global-duration
{ time-based seconds |
traffic-based kilobytes }

11. Create an IPsec policy by


referencing an IPsec policy
template.

ipsec policy policy-name


seq-number isakmp template
template-name

Optional.
By default, time-based SA lifetime
is 3600 seconds and traffic-based
SA lifetime is 1843200 kilobytes.
By default, no IPsec policy exists.

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.

Enter interface view.

interface interface-type interface-number

3.

Apply an IPsec policy group to the interface.

ipsec policy policy-name

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.
Disabled by default.

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.

Support for this feature depends on the device model. For more information, see About the Configuration
Guides for HP Unified Wired-WLAN Products.

Configuration prerequisites
Before you configure IPsec stateful failover, complete the tasks in this section on the two devices.
1.

Configure stateful failover:


{
{

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.

Configuration procedure
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 |
exclude | include } regular-expression ]

Available in any view.

Display IPsec policy template


information.

display ipsec policy-template [ brief | name


template-name [ seq-number ] ] [ | { begin |
exclude | include } regular-expression ]

Available in any view.

Display IPsec transform set


information.

display ipsec transform-set


[ transform-set-name ] [ | { begin | exclude |
include } regular-expression ]

Available in any view.


Available in any view.

Display IPsec SA information.

display ipsec sa [ active | brief | policy


policy-name [ seq-number ] | remote
ip-address | standby ] [ | { begin | exclude |
include } regular-expression ]

Display IPsec packet statistics.

display ipsec statistics [ tunnel-id integer ] [ |


{ begin | exclude | include }
regular-expression ]

Support for the active and


standby keywords
depends on your device
model. For more
information, see About
the Command References
for HP Unified
Wired-WLAN Products.
Available in any view.
Available in any view.

Display IPsec tunnel information.

display ipsec tunnel [ active | standby ] [ |


{ begin | exclude | include }
regular-expression ]

Support for the active and


standby keywords
depends on your device
model. For more
information, see About
the Command References
for HP Unified
Wired-WLAN Products.
Available in user view.

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

Support for the active and


standby keywords
depends on your device
model. For more
information, see About
the Command References
for HP Unified
Wired-WLAN Products.
Available in user view.

IPsec configuration examples


The configuration examples were created on the 11900/10500/7500 20G unified wired-WLAN
module and might vary with device models.
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
Configuration Guide.
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.

Configuration example for IPsec between AC and AP


For more information, see WLAN Configuration Guide.

IPsec stateful failover for LWAPP protection configuration


example
Network requirements
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

Figure 137 Network diagram

Configuring AC 1
# Configure an IP address for VLAN-interface 1.
<AC1> system-view
[AC1] interface Vlan-interface 1
[AC1-Vlan-interface1] ip address 133.1.1.1 16
[AC1-Vlan-interface1] quit

# Enable stateful failover and set the stateful failover heartbeat interval.
[AC1] hot-backup enable
[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] interface vlan-interface 1
[AC1-Vlan-interface1] ipsec policy map
[AC1-Vlan-interface1] quit

# 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
# Configure an IP address for VLAN-interface 1.
<AC2> system-view
[AC2] interface vlan-interface 1
[AC2-Vlan-interface1] ip address 133.1.1.2 16
[AC2-Vlan-interface1] quit

# Enable stateful failover and set the stateful failover heartbeat interval.
[AC2] hot-backup enable
[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] interface vlan-interface 1
[AC2-Vlan-interface1] ipsec policy map
[AC2-Vlan-interface1] quit

# 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

Verifying the configuration


# 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)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600

379

protocol: UDP

protocol: UDP

sa remaining duration (kilobytes/sec): 1843192/3261


max received sequence-number: 127
udp encapsulation used for nat traversal: N
status: --

----------------------------IPsec policy name: "pt"


sequence number: 1
mode: template
----------------------------connection id: 8
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: 12222
port: 0

protocol: UDP

[inbound ESP SAs]


spi: 2106938486 (0x7d955476)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843194/3262
max received sequence-number: 111
anti-replay check enable: Y
anti-replay window size: 32
udp encapsulation used for nat traversal: N
status: --

[outbound ESP SAs]


spi: 1822532692 (0x6ca1a454)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843200/3262
max received sequence-number: 1
udp encapsulation used for nat traversal: N
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
encapsulation mode: tunnel
perfect forward secrecy:
tunnel:
local

address: 133.1.1.2

remote address: 133.1.1.33


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)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843159/2980
max received sequence-number: 206
anti-replay check enable: Y
anti-replay window size: 32
udp encapsulation used for nat traversal: N
status: --

[outbound ESP SAs]


spi: 1048421470 (0x3e7da45e)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843189/2980
max received sequence-number: 207
udp encapsulation used for nat traversal: N
status: --

----------------------------IPsec policy name: "pt"


sequence number: 1
mode: template
----------------------------connection id: 7
encapsulation mode: tunnel
perfect forward secrecy:
tunnel:
local

address: 133.1.1.2

remote address: 133.1.1.33


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)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843190/2981
max received sequence-number: 205
anti-replay check enable: Y
anti-replay window size: 32
udp encapsulation used for nat traversal: N
status: --

[outbound ESP SAs]


spi: 2945451878 (0xaf900766)
proposal: ESP-ENCRYPT-AES-128 ESP-AUTH-SHA1
sa duration (kilobytes/sec): 1843200/3600
sa remaining duration (kilobytes/sec): 1843200/2981
max received sequence-number: 1
udp encapsulation used for nat traversal: N
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.

Protocols and standards

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 }

Specify an authentication
method for the IKE
proposal.

authentication-method
{ pre-share | rsa-signature }

Specify an authentication
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.
86400 seconds by default.

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

Disabled by default.
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 pee